Bug #6459
open
Siemens P1 stops uplink transmission if MS power level is being set below 15 dBm
Added by nt2mku about 1 month ago.
Updated about 1 month ago.
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
Sorry, wrong project category. It's for OsmoBSC, so please either delete or move to OsmoBSC. Thanks.
No worries, we can simply move it over to the right project. Im not at my computer right now, will do later.
- 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)
Thanks for moving the ticket. I did another test today generating trace files:
- 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)
Word 6.0 for WinNT runs fine on Win10.
...and here is another document for DCS (which contains the ETSI STY files).
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.
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 |
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.
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.
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.
Also available in: Atom
PDF
