Cellular Network Infrastructure » Radio Access Network » OsmoBTS

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.

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)

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

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.

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.

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.

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 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 =]

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.

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...

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

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>"

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

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,
    },

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.

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

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.

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).

Hi, if you use current osmo-bts-trx and osmo-bsc master I would expect MS Power loop to work correctly nowadays.

Simply make sure your .cfg files are up to date with latest osmo-bts changes:

• Drop line "ms-power-control dsp", use "ms-power-control osmo". Generic osmo algo has been improved and should be used instead of the bts-trx one.
• Drop line "osmotrx ms-power-loop -XYZ", that's the value used by bts-trx specific algo which you don't want to use (and it may enable it if you have it in the config).
• Keep line "uplink-power-target -XYZ", that's the one being used by osmo generic algorithm.

Keeping this task open for a while waiting for @S_erge_y to give it a try. Other than that I assume this ticket can be closed.

Thanks, but it's not work for me =(

I use next config:

line vty
 no login
phy 0
 osmotrx ip 127.0.0.1
 osmotrx fn-advance 0
 osmotrx rts-advance 1
! osmotrx ms-power-loop -80 (Tried to change (and off/on this string - no effect)
 instance 0
!  osmotrx rx-gain 29 (Tried to change - no effect)
  osmotrx tx-attenuation oml
bts 0
 band GSM900
 ipa unit-id 123 123
 oml remote-ip 127.0.0.1
 rtp jitter-buffer 50
 uplink-power-target -80 (Tried to change - no effect)
 trx 0
  ms-power-control osmo
  phy 0 instance 0

Experiment was conducted on the newly installed Debian 10 (Armbian_19.11.3). Compiled packages (master branches): libosmocore, libosmo-abis, osmo-trx, osmo-bts, osmo-pcu latest (today) versions. Only osmo-pcu regulates MS power. With make call, I have max MS power permitted in bsc...

On osmo-bsc I see only

<000c> loops.c:124 (bts=0,trx=0,ts=2,ss=0) Got RSSI value of 0
<000c> loops.c:124 (bts=0,trx=0,ts=2,ss=0) Got RSSI value of 0
<000c> loops.c:220 (bts=0,trx=0,ts=2,ss=0) TOA is correct (22), keeping current TA of 4
<000c> loops.c:124 (bts=0,trx=0,ts=2,ss=0) Got RSSI value of -2
<000c> loops.c:124 (bts=0,trx=0,ts=2,ss=0) Got RSSI value of -9
<000c> loops.c:124 (bts=0,trx=0,ts=2,ss=0) Got RSSI value of 0
<000c> loops.c:124 (bts=0,trx=0,ts=2,ss=0) Got RSSI value of 0
<000c> loops.c:220 (bts=0,trx=0,ts=2,ss=0) TOA is correct (23), keeping current TA of 4

Can you enable "logging level meas info" to see if you are receiving measurement reports successfully?

You can also add a gdb breakpoint or printf in l1sap_ph_data_ind(), in the 2 conditionals blocks "if (L1SAP_IS_LINK_SACCH(link_id))" to understand better what's going on.

With "logging level meas info" I get next log:

000c> loops.c:220 (bts=0,trx=0,ts=2,ss=0) TOA is correct (63), keeping current TA of 4
<0004> measurement.c:644 (bts=0,trx=0,ts=2,ss=0) Incorrect number of SUB measurements detected! (25 vs exp 3)
<0004> measurement.c:680 (bts=0,trx=0,ts=2,ss=0) Computed TA256(  64) BER-FULL( 1.09%), RSSI-FULL(-  0dBm), BER-SUB( 0.84%), RSSI-SUB(-  0dBm)
<0004> measurement.c:693 (bts=0,trx=0,ts=2,ss=0) UL MEAS RXLEV_FULL(63), RXLEV_SUB(63),RXQUAL_FULL(3), RXQUAL_SUB(3), num_meas_sub(25), num_ul_meas(25)
<0004> measurement.c:644 (bts=0,trx=0,ts=2,ss=0) Incorrect number of SUB measurements detected! (25 vs exp 3)
<0004> measurement.c:680 (bts=0,trx=0,ts=2,ss=0) Computed TA256(  65) BER-FULL( 1.09%), RSSI-FULL(-  0dBm), BER-SUB( 1.08%), RSSI-SUB(-  0dBm)
<0004> measurement.c:693 (bts=0,trx=0,ts=2,ss=0) UL MEAS RXLEV_FULL(63), RXLEV_SUB(63),RXQUAL_FULL(3), RXQUAL_SUB(3), num_meas_sub(25), num_ul_meas(25)
<0004> measurement.c:644 (bts=0,trx=0,ts=2,ss=0) Incorrect number of SUB measurements detected! (25 vs exp 3)
<0004> measurement.c:680 (bts=0,trx=0,ts=2,ss=0) Computed TA256(  62) BER-FULL( 1.09%), RSSI-FULL(-  0dBm), BER-SUB( 0.73%), RSSI-SUB(-  0dBm)
<0004> measurement.c:693 (bts=0,trx=0,ts=2,ss=0) UL MEAS RXLEV_FULL(63), RXLEV_SUB(63),RXQUAL_FULL(3), RXQUAL_SUB(2), num_meas_sub(25), num_ul_meas(25)
<0004> measurement.c:644 (bts=0,trx=0,ts=2,ss=0) Incorrect number of SUB measurements detected! (25 vs exp 3)
<0004> measurement.c:680 (bts=0,trx=0,ts=2,ss=0) Computed TA256(  59) BER-FULL( 1.09%), RSSI-FULL(-  0dBm), BER-SUB( 0.99%), RSSI-SUB(-  0dBm)
<0004> measurement.c:693 (bts=0,trx=0,ts=2,ss=0) UL MEAS RXLEV_FULL(63), RXLEV_SUB(63),RXQUAL_FULL(3), RXQUAL_SUB(3), num_meas_sub(25), num_ul_meas(25)
<000c> loops.c:220 (bts=0,trx=0,ts=2,ss=0) TOA is correct (65), keeping current TA of 4
<0004> measurement.c:644 (bts=0,trx=0,ts=2,ss=0) Incorrect number of SUB measurements detected! (25 vs exp 3)
<0004> measurement.c:680 (bts=0,trx=0,ts=2,ss=0) Computed TA256(  57) BER-FULL( 1.09%), RSSI-FULL(-  0dBm), BER-SUB( 0.31%), RSSI-SUB(-  0dBm)
<0004> measurement.c:693 (bts=0,trx=0,ts=2,ss=0) UL MEAS RXLEV_FULL(63), RXLEV_SUB(63),RXQUAL_FULL(3), RXQUAL_SUB(1), num_meas_sub(25), num_ul_meas(25)
<0004> measurement.c:644 (bts=0,trx=0,ts=2,ss=0) Incorrect number of SUB measurements detected! (25 vs exp 3)
<0004> measurement.c:680 (bts=0,trx=0,ts=2,ss=0) Computed TA256(  60) BER-FULL( 1.09%), RSSI-FULL(-  0dBm), BER-SUB( 0.52%), RSSI-SUB(-  0dBm)
<0004> measurement.c:693 (bts=0,trx=0,ts=2,ss=0) UL MEAS RXLEV_FULL(63), RXLEV_SUB(63),RXQUAL_FULL(3), RXQUAL_SUB(2), num_meas_sub(25), num_ul_meas(25)
<0004> measurement.c:644 (bts=0,trx=0,ts=2,ss=0) Incorrect number of SUB measurements detected! (25 vs exp 3)
<0004> measurement.c:680 (bts=0,trx=0,ts=2,ss=0) Computed TA256(  57) BER-FULL( 1.09%), RSSI-FULL(-  0dBm), BER-SUB( 0.35%), RSSI-SUB(-  0dBm)
<0004> measurement.c:693 (bts=0,trx=0,ts=2,ss=0) UL MEAS RXLEV_FULL(63), RXLEV_SUB(63),RXQUAL_FULL(3), RXQUAL_SUB(1), num_meas_sub(25), num_ul_meas(25)

New information: BTS ignoring BSC config. If I set 23, I all the same get 33 dBm on MS.

For ts=2 I set TCH/F (instead TCH/F_PDCH), but it didn’t affect either. Conducted experiments with handover, there are problems with TCH/F_PDCH. Maby maybe later I create a report about this. If I understand how to remove the asterisk error "codec_gsm.c:103 gsmtolin_framein: Invalid GSM data (1)" during a successful handover.

Can you provide a full pcap trace with all protocols around BTS and BSC together with config files used in both? and if possible also log files, make sure osmo-bts.cfg has:

logging level loop debug
logging level meas info

PS: it may be easier to debug this further if you ping me over IRC at freenode's channel #osmocom.

I add new logging level strings, but not receive other logs...

I don’t have more time today to dump all connections and continue experiments later. This most likely will not help and the matter is directly in the BTS. It is strange that the problem is only with me.

I managed to try two different versions (Armbian Buster, Armbian Stretch) of the systems (suddenly something is not compiling correctly?), It works the same way.

<000c> loops.c:220 (bts=0,trx=0,ts=2,ss=0) TOA is correct (22), keeping current TA of 4
<000c> loops.c:124 (bts=0,trx=0,ts=2,ss=0) Got RSSI value of 0

Something definitely wrong with your setup. TA=4 corresponds to a distcnce of 4 * 550 meters, so around ~2 km. RSSI ~0 is also odd. I have never seen such a strong signal, even having a phone close to the BTS. With such values I would not expect power / ToA loops to work correctly.

Something definitely wrong with your setup.

It is with the setting of the BTS? The config cited above. What exactly is there that I can’t understand.

Just in case, one more setting (for osmo-trx-lms):

log stderr
  logging filter all 1
  logging color 1
  logging print category 1
  logging timestamp 1
  logging level all info
!
line vty
 no login
!
trx
 bind-ip 127.0.0.1
 remote-ip 127.0.0.1
 base-port 5700
 egprs enable
 tx-sps 4
 rx-sps 4
 chan 0
  tx-path BAND1
  rx-path LNAW

TA=4

Yes, this is strange. Most likely a delay in the board limesdr-mini. I already have several of them. Everyone has the same problem with TA. Sometimes appears the value "3".
Most likely because of this, I also can not reduce ping on the mobile Internet. My minimum ~410 ms. And ~160 of ~240 (theoretical, 4 timeslots) kbit/s DW.

RSSI ~0

The phone is 20 cm from the receiving antenna. And radiates all 2 watts.
The value can be reduced by setting: osmotrx rx-gain. But that makes no sense. This phone should reduce power, not the station’s sensitivity.

I did not manage to create a dump, but I managed to try another version of the system (ubuntu xenial_server). The results are the same - maximum MS power.

I did not manage to create a dump, but I managed to try another version of the system (ubuntu xenial_server).

Better share the requested logs and the packet capture. Trying distributions wouldn't change much.

Most likely because of this, I also can not reduce ping on the mobile Internet. My minimum ~410 ms.

This is normal for our implementation of OsmoPCU.

The phone is 20 cm from the receiving antenna. And radiates all 2 watts.

That's not a good idea. You're basically saturating the input of your SDR. Keep it a few meters away.

I add new logging level strings, but not receive other logs...

At least in osmo-trx-lms.cfg you're using a deprecated VTY parameter (read the warnings carefully):

logging level all info

Here is what you can just copy-paste (otherwise we will spend weeks configuring the logging). Remove any other logging related parameters and place this block at the head of your configuration:

OsmoTRX:

log stderr
 logging filter all 1
 logging print category-hex 0
 logging print category 1
 logging print level 1
 logging print file 1
 logging timestamp 1
 logging color 1
 logging level set-all info
!
log file /tmp/osmo-trx-lms.log
 logging filter all 1
 logging print category-hex 0
 logging print category 1
 logging print level 1
 logging print file 1
 logging timestamp 1
 logging color 1
 logging level set-all info
 logging level lms debug

OsmoBTS:

log stderr
 logging filter all 1
 logging print category-hex 0
 logging print category 1
 logging print level 1
 logging print file 1
 logging timestamp 1
 logging color 1
 logging level set-all notice
 logging level loop debug
 logging level meas info
!
log file /tmp/osmo-bts-trx.log
 logging filter all 1
 logging print category-hex 0
 logging print category 1
 logging print level 1
 logging print file 1
 logging timestamp 1
 logging color 1
 logging level set-all notice
 logging level loop debug
 logging level meas debug

Then make a test run (attach your MS, try USSD, calling), shutdown the network and attach both log files /tmp/osmo-trx-lms.log and /tmp/osmo-bts-trx.log (as files, please do not copy-paste them directly) to this ticket. Do not forget to record the packet capture, it should be in sync with your logs.

Any news regarding this ticket? @S_erge_y

Now I use my version of power adjustment, there is not enough time for new experiments.
(To record a full dump, I need to start new system on another machine. I want to exclude the sending of unnecessary data to the Internet.)

New: Limesdr MINI does not support the range I need: LNAL (800-900 MHz), only be configured LNAL_NC, but in this mode the receiver hears almost nothing.
I use LNAW, maybe because of this, my phone power is not correctly regulated?

Note: for GSM850, 900 on limesdr we need to use tx-path BAND2, this allows you to transmit a signal much stronger. BAND1 - radiates weaker.

Hello, again. It's time to write another report.
I got a little time and I checked the new version OsmoBTS.
To update also had to update libosmocore to the current version.
Sadly, power management is still not working for me.
At the moment I checked only GSM850, because I built limesdrmini into the amplifier housing of the corresponding frequency.
Note: the system responds to a line ms max power from BSC.
If I set max ms power to 23 on BSC, I see maximum power first (33), when make a call, which after a second falls to the established 23.
This is correct, because initially the phone does not know how much power it will need, and after the connection is established, it is adjusted to the minimum necessary.
The problem is that more power is not regulated and remains at 23 dBm.
My solution with editing file loops.c no longer works, since in the new version I got error compiling string

static void ms_power_val(struct gsm_lchan *lchan, struct l1sched_chan_state *chan_state, int8_t rssi)

For BTS with repeater I used next configs:
lms.cfg:

log stderr
  logging filter all 1
  logging color 1
  logging print category 1
  logging timestamp 1
  logging level all info
trx
 bind-ip 127.0.0.1
 remote-ip 127.0.0.1
 base-port 5700
 egprs enable
 tx-sps 4
 rx-sps 4
 chan 0

bts.cfg:
line vty
no login
phy 0
osmotrx ip 127.0.0.1
osmotrx fn-advance 0
osmotrx rts-advance 1
instance 0
osmotrx rx-gain 29 (If I set 30 or above - I get clipping)
osmotrx tx-attenuation 20 (for repeater I need attenuation)
bts 0
band GSM850
ipa unit-id 100 002
oml remote-ip 127.0.0.1
rtp jitter-buffer 50
uplink-power-target -50 (The border on console of the receiver in the region of -60. I do not know why. Regardless of the availability of an amplifier.)
trx 0
ms-power-control osmo
phy 0 instance 0

Unfortunately, I can’t check other frequencies now.

Hello, again. It's time to write another report.

I am sorry, but your N-th report is not informative. You have been requested to provide:

• log output of both OsmoBSC and OsmoBTS, and
• *.pcap capture of the interface between them.

Without this information we cannot help you, and would have to Reject this ticket. Thank you for understanding.

Okayface =]

I attach the file logs.zip
Sorry for such a long wait.

Your osmo-bsc is not appending "MS Power Params" IE (different than "MS Power" IE) during CHAnnel Activation (see frame 49045 in your pcap file). osmo-bts will only enable Autonomous Power Control Loop upon receive of that IE during Channel Activation message (or MS POwer Control message).

• Your osmo-bsc is too old. Make sure your BSC is at least 6b9e0e4e8834428f85f169106ed7b6141f5b185b. Even better, use at least latest release 1.6.0.
• Your osmo-bsc.cfg is wrong and doesn't set the BTS as "sysmobts". osmo-bsc will only send the MS Power Param IE to osmo-bts.
  

   bts 0
    type sysmobts
  

I have line 'type sysmobts', without it, the system does not start.

Make sure your BSC is at least 6b9e0e4e8834428f85f169106ed7b6141f5b185b.

In any case, thanks for the support!

openbsc is deprecated since a while ago, don't expect to have MS Power loop or other features ever working correctly if you are using it.

You must use osmo-bsc.git: https://git.osmocom.org/osmo-bsc/

Closing the ticket since I think the issue is clear now.