Project

General

Profile

Bug #2415

osmo-bts-sysmo sometimes ending prematurely

Added by pespin 17 days ago. Updated 16 days ago.

Status:
New
Priority:
Normal
Assignee:
Target version:
-
Start date:
08/01/2017
Due date:
% Done:

0%

Spec Reference:

Description

[0;m19700302111615804 DLINP <0012> input/ipaccess.c:705 received ID get
19700302111615805 DABIS <000d> abis.c:101 OML Signalling link up
19700302111615806 DOML <0001> oml.c:301 OC=SITE-MANAGER INST=(ff,ff,ff) Tx STATE CHG REP
19700302111615806 DOML <0001> oml.c:301 OC=BTS INST=(00,ff,ff) Tx STATE CHG REP
19700302111615807 DOML <0001> oml.c:301 OC=GPRS-NSE INST=(00,ff,ff) Tx STATE CHG REP
19700302111615807 DOML <0001> oml.c:301 OC=GPRS-CELL INST=(00,ff,ff) Tx STATE CHG REP
19700302111615807 DOML <0001> oml.c:301 OC=GPRS-NSVC INST=(00,00,ff) Tx STATE CHG REP
19700302111615807 DOML <0001> oml.c:301 OC=GPRS-NSVC INST=(00,01,ff) Tx STATE CHG REP
19700302111615807 DOML <0001> oml.c:301 OC=RADIO-CARRIER INST=(00,00,ff) Tx STATE CHG REP
19700302111615808 DOML <0001> oml.c:301 OC=BASEBAND-TRANSCEIVER INST=(00,00,ff) Tx STATE CHG REP
19700302111615808 DOML <0001> oml.c:301 OC=CHANNEL INST=(00,00,00) Tx STATE CHG REP
19700302111615808 DOML <0001> oml.c:301 OC=CHANNEL INST=(00,00,01) Tx STATE CHG REP
19700302111615808 DOML <0001> oml.c:301 OC=CHANNEL INST=(00,00,02) Tx STATE CHG REP
19700302111615808 DOML <0001> oml.c:301 OC=CHANNEL INST=(00,00,03) Tx STATE CHG REP
19700302111615809 DOML <0001> oml.c:301 OC=CHANNEL INST=(00,00,04) Tx STATE CHG REP
19700302111615809 DOML <0001> oml.c:301 OC=CHANNEL INST=(00,00,05) Tx STATE CHG REP
19700302111615809 DOML <0001> oml.c:301 OC=CHANNEL INST=(00,00,06) Tx STATE CHG REP
19700302111615809 DOML <0001> oml.c:301 OC=CHANNEL INST=(00,00,07) Tx STATE CHG REP
19700302111615811 DOML <0001> oml.c:528 OC=BTS(01) INST=(00,00,ff) Rx GET ATTR
19700302111615812 DOML <0001> oml.c:266 OC=BTS INST=(00,ff,ff) Tx Get Attribute Response
19700302111615853 DOML <0001> oml.c:528 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) Rx GET ATTR
19700302111615853 DOML <0001> oml.c:266 OC=BTS INST=(00,ff,ff) Tx Get Attribute Response
19700302111615854 DOML <0001> oml.c:250 O&M Get Attributes [0], Manufacturer Dependent State is unsupported by BTS.
19700302111615855 DOML <0001> oml.c:984 OC=RADIO-CARRIER(02) INST=(00,00,ff) Rx OPSTART
19700302111615857 DOML <0001> oml.c:736 OC=RADIO-CARRIER(02) INST=(00,00,ff) Rx SET RADIO CARRIER ATTR
19700302111615857 DOML <0001> oml.c:768 Set RF Max Power Reduction = 0 dBm
19700302111615857 DOML <0001> oml.c:430 Sending FOM ACK.
19700302111615859 DOML <0001> oml.c:1012 OC=RADIO-CARRIER(02) INST=(00,00,ff) Rx CHG ADM STATE
19700302111615859 DOML <0001> oml.c:1038 ADM state already was Unlocked
19700302111615859 DL1C <0006> l1_if.c:1397 Tx RF-MUTE.req (0, 0, 0, 0, 0, 0, 0, 0)
19700302111615859 DL1C <0006> l1_if.c:184 Tx SYS prim MUTE-RF.req
19700302111615860 DL1C <0006> l1_if.c:1370 Rx RF-MUTE.conf with status=Success
19700302111615860 DL1C <0006> main.c:115 Set global status #1 to 0 (0001 -> 0001), LEDs: ACT 1
19700302111615862 DOML <0001> oml.c:984 OC=RADIO-CARRIER(02) INST=(00,00,ff) Rx OPSTART
19700302111615862 DL1C <0006> oml.c:423 Init TRX (ARFCN 0, TSC 0, RxPower -75.000000 dBm, TxPower  0.00 dBm
19700302111615863 DL1C <0006> oml.c:343 Rx MPH-INIT.conf (status=Invalid parameter)
19700302111615863 DL1C <0006> oml.c:348 Rx MPH-INIT.conf status=Invalid parameter
19700302111615863 DOML <0001> bts.c:208 Shutting down BTS 0, Reason MPH-INIT failure

Attached run archive with failure details.

Issue appeared in test: aoip_sms:sysmo.mo_mt_sms.py
To be checked if it's AoIP specific or not. Let's monitor osmo-gsm-tester-run jenkins job for followups on this issue.

trial-1874-run.tgz (410 KB) pespin, 08/01/2017 09:30 AM

bsc-pcap-correct.pcap (153 KB) pespin, 08/02/2017 03:13 PM


Related issues

Blocked by OsmoGSMTester - Bug #2419: Recent AoIP builds failing on osmo-gsm-tester Closed 08/01/2017

History

#1 Updated by laforge 17 days ago

On Tue, Aug 01, 2017 at 09:32:42AM +0000, pespin [REDMINE] wrote:

> 19700302111615862 DL1C <0006> oml.c:423 Init TRX (ARFCN 0, TSC 0, RxPower -75.000000 dBm, TxPower  0.00 dBm
> 19700302111615863 DL1C <0006> oml.c:343 Rx MPH-INIT.conf (status=Invalid parameter)
> 19700302111615863 DL1C <0006> oml.c:348 Rx MPH-INIT.conf status=Invalid parameter
> 19700302111615863 DOML <0001> bts.c:208 Shutting down BTS 0, Reason MPH-INIT failure
> 

AS you can see, the ARFCN is 0, TSC is 0 and TxPower is 0 dBm. While thos are all theoretically
possible (though ARFCN 0 is not in the 1800MHz band, which is probably why it gets rejected?)
it seems like there are some uninitialized values used.

#2 Updated by pespin 17 days ago

  • Assignee changed from osmo-gsm-tester to pespin

#3 Updated by pespin 16 days ago

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.

#4 Updated by pespin 16 days ago

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.

#5 Updated by pespin 16 days ago

  • Blocked by Bug #2419: Recent AoIP builds failing on osmo-gsm-tester added

Also available in: Atom PDF