Cellular Network Infrastructure » OsmoGSMTester

As far as I understand, when using AoIP those values are sent from osmo-bsc, which has them stored in the config. That's the related part of the config being used in the same test:

bts 0
  type sysmobts
  band GSM-1800
  cell_identity 0
  location_area_code 23
  training_sequence_code 7
  base_station_id_code 63
  ms max power 33
  cell reselection hysteresis 4
  rxlev access min 0
  channel allocator ascending
  rach tx integer 9
  rach max transmission 7
  ip.access unit_id 1 0
  oml ip.access stream_id 255 line 0
  gprs mode none
  trx 0
   rf_locked 0
   arfcn 868
   nominal power 23
   max_power_red 0
   rsl e1 tei 0
   timeslot 0
    phys_chan_config CCCH+SDCCH4
   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

Summary:
training_sequence_code 7
arfcn 868
nominal power 23
max_power_red 0

Not sure how the TxPower value sent is usually calculated (nominal-power - max_power_red ?), but anyway the other 2 values which are seen as 0 on the log, are not configured to be 0 on the config file. Not sure if 0 for TxPower is good given the setup on the osmo-gsm-tester, but I guess it's not?

Having a look at the pcap file containing the OML traces (attached archive, directory run.2017-08-01_09-05-26/aoip_sms:sysmo/mo_mt_sms.py/osmo-bsc_10.42.42.5/pcap/), I can see frame num 21 "Set Radio Carrier Attributes" which sets attribute id "RF Max Power Reduction" to "0" and "ARFCN List" attribute to "868". On the other hand, on the BTS log it seems only the Max Power Reduction one is being handled (or at least it only logs that one). I cannot find the TSC attribute being sent, at least on the same message.

To have into account: found in #2419, all osmo-gsm-tester jenkins runs for the "aoip" tests have been / are using a built openbsc branch "aoip" which is more than 1 month old. I think this is done on purpose by Neels as he took one working revision which was working at that time.

Acording to http://ftp.osmocom.org/docs/latest/osmobts-abis.pdf , "4.2.3 Set Radio Carrier Attributes" the ARFCN List attribute is ignored by the BTS:

This message conforms to 3GPP TS 12.21, with the following limitation, as frequency hopping is not supported by OsmoBTS.
Table 13:
Set Radio Carrier Attributes
IE limitations
TS 12.21 §
IE Name
Handling
9.4.5
ARFCN List
ignored

And in 4.5.1 it says:

0x04
9.4.5
ARFCN List
←
Received, with exactly 1 ARFCN: see
Section 4.6.2; ignored by
Set Radio
Attribute
message (Section 4.2.3)

The same manual states that "TSC" can be received (with some limitations) by the BTS using the same message. Same for "RF Max Power Reduction" (without limitations).

The limitation described for TSC:

Due to limitations in the currently supported PHY implementations, OsmoBTS supports only one global TSC for all channels on
one TRX, rather than a separate TSC for each timeslot, as expected by 3GPP TS 12.21.

May BCCH ARFCN need to be set too? I actually see a "Set BTS Attributes" message BSC->BTS with "BCCH ARFCN"="868" in a pcap file of a correct scenario (osmo-bts-sysmo not stopping and showing in the log the configs are received correctly). I attach it here so both can be compared. I cannot find the "Set BTS Attributes" message on the wrong scenario pcap.

In the correct scenario, values seem to be received correctly by osmo-bts:

[0;m19700303071616703 DL1C <0006> oml.c:423 Init TRX (ARFCN 868, TSC 7, RxPower -75.000000 dBm, TxPower  0.00 dBm

So far, it looks like a race condition in osmo-bsc, when hit some messages to configure the osmo-bts are avoided. As this happens only in "aoip" tests which are using an old code version of openbsc:aoip branch, I think it may be better to wait until we update the aoip branch to be used by hourly osmo-gsm-tester tests and then check if it still occurs from time to time.

I haven't seen this bug for quite a while now, I think it was some bug while development was ogoing and we were stuck to an older version.