Project

General

Profile

Support #4213

ms-power-control

Added by S_erge_y 30 days ago. Updated 24 days ago.

Status:
Feedback
Priority:
Normal
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

History

#1 Updated by fixeria 30 days 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 30 days ago

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

#3 Updated by S_erge_y 29 days 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 29 days 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 29 days 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 29 days 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 29 days 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 29 days 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 29 days 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 29 days 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 25 days 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 24 days 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>"

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)