Project

General

Profile

Support #4213

ms-power-control

Added by S_erge_y about 2 months ago. Updated 14 days ago.

Status:
Feedback
Priority:
High
Assignee:
Category:
osmo-bts-trx
Target version:
-
Start date:
09/23/2019
Due date:
% Done:

0%

Spec Reference:

Description

Hello, I tried a lot of configuration options, but could not achieve MS power control. I use osmo-bts-trx and limesdr mini. Is this possible in this project branch?

If I use the time slot setting TCH/F_PDCH - I get this error on OsmoBTS:
<0004> measurement.c:644 (bts=0,trx=0,ts=2,ss=0) Incorrect number of SUB measurements detected! (25 vs exp 3)
If I use simply TCH/F, on console I don't see errors, but MS again used power from OpenBSC (ms max power). After call end i see:
<000e> l1sap.c:143 (bts=0,trx=0,ts=2,ss=0) RTP clock out of sync with lower layer: 1280 vs 160 (505509->505544)

If I try use this line: 'osmotrx ms-power-loop' or 'osmotrx ms-power-loop -20', I accept:
Error occurred during reading the below line:
osmotrx ms-power-loop

Also, the work is not affected:
power-ramp max-initial 13 dBm
power-ramp step-size 2 dB
power-ramp step-interval 1
ms-power-control dsp

uplink-power-target -75
osmotrx timing-advance-loop
osmotrx rx-gain 15
(I differently changed the parameters of the lines, there is no result)

In the same time OsmoPCU successfully controls power with configs:
alpha 10
gamma 60
But this does not apply to calls, SMS, USSD, paging.

If I set ms max power 33 - mobile phone will send a signal with power 2W in meter from BS, and on TRX console I see posts "Clipping", while making a call.

Versions:
OpenBSC version 1.3.1-dirty
OsmoBTS version 1.1.0.15-474e
OsmoTRX version 1.1.1.28-ee2b

dump.zip dump.zip 24.8 KB S_erge_y, 09/24/2019 12:58 PM
loops.c loops.c 11.7 KB S_erge_y, 09/28/2019 07:24 AM
FIX_loops.c FIX_loops.c 10.5 KB S_erge_y, 09/29/2019 06:20 PM
loops_areas.c loops_areas.c 6.89 KB S_erge_y, 11/01/2019 08:08 AM
loops_areas_fix.c loops_areas_fix.c 6.89 KB S_erge_y, 11/01/2019 08:54 AM

Related issues

Related to OsmoBTS - Feature #1851: generalize power control and TA loop codeIn Progress11/18/2016

Related to OsmoBSC - Bug #4244: Take MS power class into account to calculate appropiate MS Power levelFeedback10/30/2019

History

#1 Updated by fixeria about 2 months ago

Hello Sergey,

If I use the time slot setting TCH/F_PDCH - I get this error on OsmoBTS:
<0004> measurement.c:644 (bts=0,trx=0,ts=2,ss=0) Incorrect number of SUB measurements detected! (25 vs exp 3)
If I use simply TCH/F, on console I don't see errors, but MS again used power from OpenBSC (ms max power).

Hmm, this is interesting, but not related to the power control loop. dexter, any ideas? AFAIR, you've been working on measurements, so maybe TCH/F_PDCH is not handled correctly?

After call end i see:
<000e> l1sap.c:143 (bts=0,trx=0,ts=2,ss=0) RTP clock out of sync with lower layer: 1280 vs 160 (505509->505544)

This is a known issue, and also not related to power control.

If I try use this line: 'osmotrx ms-power-loop' or 'osmotrx ms-power-loop -20', I accept:
Error occurred during reading the below line:
osmotrx ms-power-loop

Most likely, you're placing this line in a wrong place, or with wrong spacing. I just tested with the recent version, and it works for me just fine. See an example: https://git.osmocom.org/osmo-bts/tree/doc/examples/trx/osmo-bts-trx-calypso.cfg#n29.

Also, the work is not affected:
power-ramp max-initial 13 dBm
power-ramp step-size 2 dB
power-ramp step-interval 1

IIRC, power ramping is for BTS, not for the MS. No need to change it.

ms-power-control dsp

This means that the MS Power should be controlled by the DSP. There is no DSP (I mean a separate black-box) that would control MS power when you're using OsmoTRX.

In the same time OsmoPCU successfully controls power with configs: [...]
But this does not apply to calls, SMS, USSD, paging.

For sure, OsmoPCU controls the packet-switched domain and has nothing to do with SMS, USSD, etc.

OpenBSC version 1.3.1-dirty

Just to note, OpenBSC has been deprecated a few years ago. This means it's not maintained and does not get new features anymore.

#2 Updated by fixeria about 2 months ago

  • Status changed from New to Feedback
  • Target version deleted (osmo-bts-trx refresh)

#3 Updated by S_erge_y about 2 months ago

Most likely, you're placing this line in a wrong place, or with wrong spacing. I just tested with the recent version, and it works for me just fine. See an example: https://git.osmocom.org/osmo-bts/tree/doc/examples/trx/osmo-bts-trx-calypso.cfg#n29.

I try this example and got: Shutdown timer expired, line " osmotrx legacy-setbsic" only needed for Calypso (motorola) BS?
Without line BS started, but mobile phone still use 33 dBm (2W).

Timeslots for test on BSC I set to TCH_F

  trx 0
   rf_locked 0
   arfcn 73
   timeslot 0
    phys_chan_config CCCH+SDCCH4
    hopping enabled 1
   timeslot 1
    phys_chan_config SDCCH8
   timeslot 2
    phys_chan_config TCH/F
   timeslot 3
    phys_chan_config TCH/F
   timeslot 4
    phys_chan_config TCH/F
   timeslot 5
    phys_chan_config TCH/F
   timeslot 6
    phys_chan_config TCH/F
   timeslot 7
    phys_chan_config TCH/F

Lines nominal power 15, max_power_red 23 I not using, this refers to the power of the BS, if not mistaken. (with lines checked - no result)

Also checked with different string combinations
osmotrx ms-power-loop -65 (change -65 from -25 to -85), enable/disable osmotrx timing-advance-loop, gsmtap-sapi ccch, gsmtap-sapi pdtch, min-qual-rach 50, min-qual-norm -5, uplink-power-target -75, osmotrx rx-gain 1 (change 1)

#4 Updated by S_erge_y about 2 months ago

Now I launched CalypsoBTS, but situation is same, phone uses maximum power, it's not about limesdr problem?
CalypsoBTS using OsmoBTS version 0.8.1.318-a52c7

timeslot 0
phys_chan_config CCCH+SDCCH4
hopping enabled 0
timeslot 1
phys_chan_config TCH/F
hopping enabled 0

#5 Updated by fixeria about 2 months ago

I try this example and got: Shutdown timer expired, line " osmotrx legacy-setbsic" only needed for Calypso (motorola) BS?

Because that's just an example, not 'ready-to-use' configuration for your needs.

Now I launched CalypsoBTS, but situation is same, phone uses maximum power, it's not about limesdr problem?

Would be great to look at LAPDm captures, so we could see what's actually being sent by the BTS. You will need to add the following to your configuration file (see our examples if you don't know where to add):

gsmtap-sapi agch
gsmtap-sapi sdcch
gsmtap-sapi tch/f
gsmtap-sapi tch/h
gsmtap-sapi sacch

also, please correct the logging level to get more information:

logging level loop debug

and start osmo-bts-trx with '-i' flag like that:

osmo-bts-trx -c osmo-bts.cfg -i 127.0.0.1

so you should see LAPDm traces in Wireshark (filter with 'gsmtap').

Please attach this capture file and the logs of OsmoBTS to this issue.

#6 Updated by S_erge_y about 2 months ago

Config with gsmtap-sapi lines - no result.

Dump contain two variants: with and without PDCH.
In each I made one USSD request and one call.

Perhaps this will help: on PCU I also have a problem with the uplink, but not with the power, the osmoPCU cannot pick up the coding system and uses either 1 or 9 (usually always 1, 9 - only if pre-selected in configuration).

<0007> gprs_ms.cpp:645 Unable to update UL (M)CS MCS-9 because we don't have link quality measurements.

The maximum speed is obtained - 19.5 KBAit/s, ping 430 ms (in theory I should get 236,8 Kbit/s [29 KBAit/s] on 4 timeslots, and lower latency, maby 19.5 - top speed for osmo-bts-lms)

#7 Updated by fixeria about 2 months ago

As far as I can see from your captures, MS Power Level is always 5 (see L1 SACCH Header of System Information 5/5ter/6 packets). This value corresponds to 33 dBm (~2 W), exactly as you described. You didn't attach the logs of OsmoBTS, so it's hard to guess why. But given that SDR is not the best solution for a BTS PHY, and that the value of MS Power Level is calculated from the Uplink RSSI measurements by OsmoTRX (which of course are not accurate unless you've calibrated your LimeSDR), I think the problem is that your LimeSDR reports too low RSSI values. I also noticed quite high Timing Advance value (4), which corresponds to a delay of ~2 km from the BTS.

BTW, I just tested the network with my LimeSDR-Mini, and I see MS Power Level 14 (15 dBm, ~30 mW). At the same time, I am also getting TA=4. Maybe because I have 'uplink-power-target -75' in my config, feel free to test.

USSD: "Balans? Deneg net, no vy derzhites'!"

I hope you know what you're doing. Using GSM bands without a valid license (which is impossible to get) is illegal in Russia.

#8 Updated by S_erge_y about 2 months ago

You didn't attach the logs of OsmoBTS

<0000> rsl.c:812 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN ACT ACK
<0011> lapd_core.c:921 Store content res. (dl=0xb701f498)
<0000> rsl.c:791 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN REL ACK
<0000> rsl.c:812 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN ACT ACK
<0011> lapd_core.c:921 Store content res. (dl=0xb701f498)
<0000> rsl.c:791 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN REL ACK
<0000> rsl.c:812 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN ACT ACK
<0011> lapd_core.c:921 Store content res. (dl=0xb701f498)
<0000> rsl.c:791 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) (ss=0) SDCCH Tx CHAN REL ACK

I don’t see anything here...

I am also getting TA=4

If i flash target/firmware/board/compal_e99/rssi.highram.bin on motorola - see distance ~1.5 km, but I'm in the meter from bs. And get TA=4 too.

'uplink-power-target -75'

Trying, not work for me.

I think the problem is that your LimeSDR reports too low RSSI values

Mayby, but on osmocombb I have same problem.
I tried looking for calibration instructions, but for EDGE, what is your speed? Does coding system management work?

I hope you know what you're doing.

Oh, I hope too... Not talk about bad surrounding world =]

#9 Updated by S_erge_y about 2 months ago

Most likely it’s not a matter of calibration, because the osmoPCU correctly sees the signal without any problems.

On start transmitting

<0007> gprs_rlcmac_meas.cpp:106 UL RSSI of TLLI=0xd03b21b7: -30 dBm
<0007> gprs_rlcmac_meas.cpp:106 UL RSSI of TLLI=0xd03b21b7: -36 dBm

After correct power:

<0007> gprs_rlcmac_meas.cpp:106 UL RSSI of TLLI=0xd03b21b7: -45 dBm

I tried to disconnect RX antenna - in 20 seconds phone “accelerates” to two watts per transmission.

#10 Updated by S_erge_y about 2 months ago

I looked at the problem from the other side.
I turned off the explicitly set maximum power in the BSC, the phone worked with the minimum (13 dBm? I have a home-made meter, it is visible "stronger, weaker", but there are no exact values). But the power is not regulated at all, if you go over several walls and record the sound stream from the phone - there is a lot of interference (the sound disappears), if I statically up power - everything is stable.

I tried to change the parameters:
osmotrx ms-power-loop: 10, 1, 0, -1, -10, -60, -100, -110
uplink-power-target: 65, 10, 0, -1, -10, -65, -75, -100, -105 -110, (-115 - osmoBTS not start)

It's all combinations not work for me, uplink not regulated...

#11 Updated by S_erge_y about 2 months ago

Good news, everyone!
Found a TEMPORARY power adjustment solution.
I’m not a programmer, I didn’t understand how the power control should work initially, so we have some shi(f)t coding...
From the original code we do not need functions: ms_power_diff, ms_power_clock.
The contents of the function ms_power_val can be replaced with a power reduction circuit (See attachment loops.c).

About values:
13 - is more than necessary. But I read that this is the recommended minimum value for MS.
I tried to send 5 - USSD works, but calls are not being made.

About config:
On BSC we need setup max ms power, I use 33
On BTS config we need " osmotrx ms-power-loop -100"
What does -100 I do not know .But it work.

At the beginning of the transfer, the phone uses a maximum power from BSC, then it decreases from loops.c
On console:

<000c> loops.c:227 (bts=0,trx=0,ts=2,ss=0) RSSI value: -16
<000c> loops.c:228 (bts=0,trx=0,ts=2,ss=0) Set ms_power_ctrl.current value: 17
<000c> loops.c:227 (bts=0,trx=0,ts=2,ss=0) RSSI value: -16
<000c> loops.c:228 (bts=0,trx=0,ts=2,ss=0) Set ms_power_ctrl.current value: 17
<000c> loops.c:227 (bts=0,trx=0,ts=2,ss=0) RSSI value: -16
<000c> loops.c:228 (bts=0,trx=0,ts=2,ss=0) Set ms_power_ctrl.current value: 17
<000c> loops.c:227 (bts=0,trx=0,ts=2,ss=0) RSSI value: -16
<000c> loops.c:228 (bts=0,trx=0,ts=2,ss=0) Set ms_power_ctrl.current value: 17
<0004> measurement.c:644 (bts=0,trx=0,ts=2,ss=0) Incorrect number of SUB measurements detected! (25 vs exp 3)
<000c> loops.c:227 (bts=0,trx=0,ts=2,ss=0) RSSI value: -18
<000c> loops.c:228 (bts=0,trx=0,ts=2,ss=0) Set ms_power_ctrl.current value: 18
<000c> loops.c:227 (bts=0,trx=0,ts=2,ss=0) RSSI value: -22
<000c> loops.c:228 (bts=0,trx=0,ts=2,ss=0) Set ms_power_ctrl.current value: 20
<000c> loops.c:227 (bts=0,trx=0,ts=2,ss=0) RSSI value: -22
<000c> loops.c:228 (bts=0,trx=0,ts=2,ss=0) Set ms_power_ctrl.current value: 20
<000c> loops.c:227 (bts=0,trx=0,ts=2,ss=0) RSSI value: -22
<000c> loops.c:228 (bts=0,trx=0,ts=2,ss=0) Set ms_power_ctrl.current value: 20
<0004> measurement.c:644 (bts=0,trx=0,ts=2,ss=0) Incorrect number of SUB measurements detected! (25 vs exp 3)
<000c> loops.c:227 (bts=0,trx=0,ts=2,ss=0) RSSI value: -21
<000c> loops.c:228 (bts=0,trx=0,ts=2,ss=0) Set ms_power_ctrl.current value: 19
<000c> loops.c:227 (bts=0,trx=0,ts=2,ss=0) RSSI value: -18
<000c> loops.c:228 (bts=0,trx=0,ts=2,ss=0) Set ms_power_ctrl.current value: 18
<000c> loops.c:227 (bts=0,trx=0,ts=2,ss=0) RSSI value: -18
<000c> loops.c:228 (bts=0,trx=0,ts=2,ss=0) Set ms_power_ctrl.current value: 18

To see we need:
At start, use the key: --debug=DLOOP
In the configuration: logging level loop debug

Not using:

! osmotrx timing-advance-loop
! uplink-power-target -10
! gsmtap-sapi ccch
! gsmtap-sapi pdtch
! gsmtap-sapi agch
! gsmtap-sapi sdcch
! gsmtap-sapi tch/f
! gsmtap-sapi tch/h
! gsmtap-sapi sacch
! min-qual-rach 20
! min-qual-norm -75

#12 Updated by S_erge_y about 2 months ago

The idea is working, but I made a mistake. It turns out that the maximum power value of 2W is "5", the minimum is "30".
Turned over the power grid, now it works as it should.

It would not be a bad idea to reduce the power refresh rate, but I don’t know how to delay and skip a few requests.
I tried it like this, but it didn’t work:

if (!(chan_state->meas.clock & 1))
return;

TA intervals are requested much less often, you can try to call a function from there, but this is a very large crutch.

The power values from the switch/case affected by the parameter: " osmotrx rx-gain <value>"

#13 Updated by laforge 26 days ago

  • Status changed from Feedback to New
  • Assignee set to pespin
  • Priority changed from Normal to High

#14 Updated by laforge 26 days ago

  • Related to Feature #1851: generalize power control and TA loop code added

#15 Updated by pespin 22 days ago

  • Status changed from New to Feedback

Hi,

I am not really sure about the status of this task.
Which version of osmo-bts are you using? Against which one did you do changes? Can you provide a diff against that commit instead of the full .c file? Did you follow any specs when applying your change?
If you are using a recent osmo-bts, afaik it will only do the MS power control loop if BSC sends the MS Power Parameters IE during CHAN ACT, which didn't do until the patch I submitted to gerrit today. And if you are using old OpenBSC, I bet it never sent it.

Check these commits which will hopefully be merged soon:
https://gerrit.osmocom.org/c/osmo-bsc/+/15882
https://gerrit.osmocom.org/c/osmo-bts/+/15877

#16 Updated by S_erge_y 22 days ago

Can you provide a diff against that commit instead of the full .c file?

Question for me? I don’t have a diff file, the changes were made as an experiment, I just wanted to achieve power control. At any price. The solution is not universal. I already several times to redefine the RSSI-Power ratio, since I use different antennas / amplifiers during the experiments.

Did you follow any specs when applying your change?

I did not adhere to any standards, I just found a piece of code that runs when config line 'osmotrx ms-power-loop' was activated and changed it, also removing some of the dependent lines from other places, since they were no longer used.

I sent it here just in case, all of a sudden someone comes in handy for testing. This is not a serious solution to the problem.

Perhaps the problem is only with the Limesdr mini board, if I connect a second base station (on motorola phones), then the power control works right without changes osmo-bts.

Note: to see only information about power, just run the program with the key --debug=DLOOP. All lines with logging (log stderr, logging filter all...) not needed and were deleted from the configuration file. The blue color in the console is very poorly read. It is better to change file osmo-bts\src\common\logging.c and choose white color.

    [DLOOP] = {
        .name = "DLOOP",
        .description = "Control loops",
        .color = "\033[1;37m",
        .enabled = 1, .loglevel = LOGL_NOTICE,
    },

#17 Updated by S_erge_y 19 days ago

Congratulations... My limesdr broke after another reboot.
LimeUtil --update did not work and I decided to update LimeSuite.
After update LimeSuite and execution command LimeUtil --update --force... Now limesdr alive again!

I install unmodified version osmo-bts and stock power management has worked for me!
But I noticed the following problems: the system does not have time to lower the power when using USSD and sending SMS.
For SMS, power reduction is performed only at the very end of the transmission.
A manually set power grid controls transmission much faster, than standard code osmo-bts.

However, my option has two significant drawbacks: no setting (only before compilation), instability of the transmission power (the phone sends too quietly, at this time the base station raises the power too much, then the phone increases it too late, and a significant reduction command comes from the base station).

I tried to solve the transmission problem by not linearly distributing the value. But it is better to make three areas for signal strength.

In the settings we set the best (needed) signal.
I used osmotrx ms-power-loop 20.
Now if the signal is louder (0 ..
20) - I lower the power.
If the signal is between ms-power-loop-15 (for me -35..-20), I do nothing.
If the signal is quieter than -35, I increase the transmit power.
The tolerance is specified by a line in the code: target_hi = my_target - 15;
Details in the attachment loops_areas.c

This solution does not control the power at the beginning of the transmission of the USSD request, but manages to do after its completion.
It also turns out to lower the power at the end of paging and sending SMS.

I use hardware amplifier to Rx and for me "ms-power-loop -20" - normal value, somewhere at -48 my RX signal breaks off.
For other stations, maby you probably need to use a lower level (-75, -80?...).
Despite the fact that after the update, the standard code worked for me, I will continue to use the modified version, as it adjusts power faster.

#18 Updated by S_erge_y 19 days ago

Fail again.
Need to swap: my_target, target_hi.
I hope there are no more errors.

#19 Updated by pespin 15 days ago

  • Related to Bug #4244: Take MS power class into account to calculate appropiate MS Power level added

#20 Updated by S_erge_y 15 days ago

Thanks for the tip №4244 and documentation https://www.etsi.org/deliver/etsi_gts/05/0505/05.01.00_60/gsmts_0505v050100p.pdf
I tried to fix the restriction on 19, the minimum radiated power remained unchanged (when compared with an erroneous value of 30).

if (rssi > my_target)
{
ms_send = ms_send + 1;
if (ms_send > 19)
   ms_send = 19;
LOGPLCHAN(lchan, DLOOP, LOGL_INFO, "RSSI value: %d, Set ms_power_ctrl.current +1 (DOWN power) value: %d\n", rssi, ms_send);
}

Surprisingly, all test phones took the wrong value (from 20 to 30) and continued to work with minimal power.
Maybe this is true in the other direction? It will not be necessary to determine the power class of the device, just send the maximum allowed value, and the device will choose the closest one that can work according to its class? (For GSM 900 - "2", i.e. 39 dBm)

I did not know that in DCS 1800 mode, values 29, 30, 31, on the contrary increase power. I not check work at 1800, 1900 frequencies and did not encounter this problem. It turns out that for these frequencies you need to redefine the power in another way. My version should not work at 1800, 1900 frequencies.

#21 Updated by pespin 14 days ago

Regarding levels 29, 30 and 31, should be fixed after this commit:
https://gerrit.osmocom.org/c/osmo-bts/+/15971 bts-trx: Implement MS Power control loop calculations using dBm instead of ctl levels

It's only fixed for osmo-bts-trx though, still neds fixing for other BTS types (since control loop is still implemented in another place in the code).

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)