Project

General

Profile

Support #4213

ms-power-control

Added by S_erge_y 3 months ago. Updated 17 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 levelResolved10/30/2019

History

#1 Updated by fixeria 3 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 3 months ago

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

#3 Updated by S_erge_y 3 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 3 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 3 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 3 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 3 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 3 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 3 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 3 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 3 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 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 about 2 months ago

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

#14 Updated by laforge about 2 months ago

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

#15 Updated by pespin about 2 months 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 about 2 months 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 about 1 month 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 about 1 month ago

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

#19 Updated by pespin about 1 month ago

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

#20 Updated by S_erge_y about 1 month 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 about 1 month 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).

#22 Updated by pespin 22 days ago

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.

#23 Updated by S_erge_y 18 days ago

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

#24 Updated by pespin 18 days ago

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.

#25 Updated by S_erge_y 18 days ago

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.

#26 Updated by pespin 18 days ago

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.

#27 Updated by S_erge_y 18 days ago

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.

#28 Updated by fixeria 17 days ago

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

#29 Updated by S_erge_y 17 days ago

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.

#30 Updated by fixeria 17 days ago

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.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)