Bug #6459
openSiemens P1 stops uplink transmission if MS power level is being set below 15 dBm
0%
Description
This is more a documentation about a speciality of the Siemens P1 (Telekom D1 314) than a bug report.
- If setting "ms max power" below 15 dBm, the phone will not attach.
- If using dynamic MS power control, the phone stops transmitting uplink completely if instructed by the RAN to set power below 15 dBm. If control loop resets it back to >= 15 dBm, it continues transmitting.
Used RAN Software: Current OsmoBSC + OsmoBTS + Osmo-TRX-UHD from Gitea (incl. libosmocore etc.) + USRP B200.
SIM card: Sysmocom SJA2
P1 Software Version 18.06.93 09:58:48
Files
| OsmoBTS_LogOutput.txt | OsmoBTS_LogOutput.txt | 28.9 KB | |||
| SiemensP1_MSMaxPower15_MSPowerControl.pcap | SiemensP1_MSMaxPower15_MSPowerControl.pcap | 96.2 KB | |||
| 0505-3G0.DOC | 0505-3G0.DOC | 56.5 KB | |||
| 0505-3G0.pdf | View 0505-3G0.pdf | 356 KB | |||
| 0505D330.pdf | View 0505D330.pdf | 465 KB | |||
| 0505dcs-330.ZIP | 0505dcs-330.ZIP | 94.8 KB |
Updated by nt2mku about 1 month ago
Sorry, wrong project category. It's for OsmoBSC, so please either delete or move to OsmoBSC. Thanks.
Updated by laforge about 1 month ago
No worries, we can simply move it over to the right project. Im not at my computer right now, will do later.
Updated by fixeria about 1 month ago
- Project changed from OpenBSC to OsmoBSC
- Category deleted (
documentation)
Very interesting, thanks for sharing!
I would be interested to see a PCAP with the A-bis/RSL + LAPDm traces.
Maybe there is something in the MS Classmark, that we do not parse/interpret correctly.
(I moved this ticket to OsmoBSC)
Updated by nt2mku about 1 month ago
- File OsmoBTS_LogOutput.txt OsmoBTS_LogOutput.txt added
- File SiemensP1_MSMaxPower15_MSPowerControl.pcap SiemensP1_MSMaxPower15_MSPowerControl.pcap added
- PCAP of OsmoBTS-gsmtap and RSL
- Logging output of OsmoBTS power control loop
Phone has been placed 30 cm next to the SDR.
The uplink transmission stops with the step-down to 11 dBm (control value 16) and restarts with step-up to 13 dBm (control value 15).
The phone attaches if setting ms max power to 12 (dBm). Below that, it does not try to attach.
MS power control setting:
ms max power 15 ms-power-control mode dyn-bts ctrl-interval 2 step-size inc 2 red 2 rxlev-thresh lower 32 upper 38 rxlev-thresh-comp lower 10 12 upper 19 20 rxlev-avg algo unweighted rxlev-avg params hreqave 4 hreqt 6 rxqual-thresh lower 3 upper 0 rxqual-thresh-comp lower 5 7 upper 15 18 rxqual-avg algo osmo-ewma beta 50 rxqual-avg params hreqave 2 hreqt 3 ci-thresh fr-efr enable ci-thresh fr-efr lower 7 upper 11 ci-thresh-comp fr-efr lower 2 10 upper 3 4 ci-avg fr-efr algo osmo-ewma beta 50 ci-avg fr-efr params hreqave 2 hreqt 3
(Unfortunately, I cannot edit the description and headline. It would be great if someone could correct the power value to 12 instead of 15 dBm)
Updated by laforge about 1 month ago
- File 0505-3G0.DOC 0505-3G0.DOC added
It would be interesting to look at an old version of GSM TS 05.05 to investigate if the encoding changed.
The oldest version available via 3GPP https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=258 is 3.16.0 which leads to https://www.3gpp.org/ftp/Specs/archive/05_series/05.05/0505-3g0.zip which contains a MS Word for DOS file (attached for simplicity). However, the tables of that file are not rendered well in LibreOffice today, and TextMaker doesn't even seem to support this file at all.
I guess we either need to run dosbox or some other emulator with word-for-dos, or use a converter like https://github.com/slomkowski/gc1039-winword-converter to convert it into something that present-day software can render and display correctly.
Updated by nt2mku about 1 month ago
- File 0505-3G0.pdf 0505-3G0.pdf added
Word 6.0 for WinNT runs fine on Win10.
Updated by nt2mku about 1 month ago
- File 0505D330.pdf 0505D330.pdf added
- File 0505dcs-330.ZIP 0505dcs-330.ZIP added
...and here is another document for DCS (which contains the ETSI STY files).
Updated by laforge about 1 month ago
ok, so that version indeed only knows power control levels up to 15, and not higher. Next we'd need to find out what kind of criteria we can use to limit the range in the BSC. I'd expect there is going to be some classmark bit or the like.
Updated by laforge about 1 month ago
laforge wrote in #note-8:
ok, so that version indeed only knows power control levels up to 15, and not higher. Next we'd need to find out what kind of criteria we can use to limit the range in the BSC. I'd expect there is going to be some classmark bit or the like.
The MS CLASSMARK 1 IE indicates phase1/phase2/R99+ - and indeed the CM1 IE of the LU REQ in the provided PCAP file states it is a "phase 1" MS.
According to https://bilder.buecher.de/zusatz/22/22229/22229616_lese_1.pdf
| Phase | Freeze Date | Spec Versions |
|---|---|---|
| 1 | 1991 | 3.X.X |
| 2 | October 1995 | 4.X.X |
| 2+ | never | 5.x.x; aka R96 and higher |
Updated by laforge about 1 month ago
I checked TS 05.05 4.23 and it already contains higher power control levels. So only phase 1 seem to be affected.
So what we need to do is to limit the range of the power control level if CM1 indicates phase1.
Updated by nt2mku about 1 month ago
laforge wrote in #note-10:
I checked TS 05.05 4.23 and it already contains higher power control levels. So only phase 1 seem to be affected.
So what we need to do is to limit the range of the power control level if CM1 indicates phase1.
Could the mobile terminated setup issue with this phone (it does not like octet 3a) be a related problem here, because phase 1 specs did not implement additional codecs?
If yes, setup message encoding needs to take the CM1 value into account and omit 3a in case of phase 1. I can open another issue for that, if requested.
Updated by laforge about 1 month ago
nt2mku wrote in #note-11:
laforge wrote in #note-10:
I checked TS 05.05 4.23 and it already contains higher power control levels. So only phase 1 seem to be affected.
So what we need to do is to limit the range of the power control level if CM1 indicates phase1.
Could the mobile terminated setup issue with this phone (it does not like octet 3a) be a related problem here, because phase 1 specs did not implement additional codecs?
possibly, or even likely. Feel free to check and compare the definition of those octets in a GMS TS 04.08 of v3.x (Phase 1) vs one of v4.x (Phase 2) to be sure.
If yes, setup message encoding needs to take the CM1 value into account and omit 3a in case of phase 1. I can open another issue for that, if requested.
Yes, but let's try to avoid discussing two separate topics in the same redmine issue.
