Actions
Bug #4215
closedosmo-bts-trx: DL burst towards osmo-trx dopped due to enqueued CMD NOHANDOVER
Start date:
09/27/2019
Due date:
% Done:
100%
Spec Reference:
Description
Ass seen in BTS_Tests.TC_deact_sacch.pcap, when BSC sends over RSL a DEACTIVATE SACCH message to the BTS, the BTS enqueues a CMD NOHANDOVER. After that, we can see several of these messages in osmo-bts-trx log:
20386 09:02:08.628490 Sep 27, 2019 09:02:08.628490000 CEST 172.18.9.20 33148 172.18.9.10 4729 GSMTAP 203 phy0.0: Enqueuing TRX control command 'CMD NOHANDOVER 2 0' 20387 09:02:08.628506 Sep 27, 2019 09:02:08.628506000 CEST 172.18.9.20 33148 172.18.9.10 4729 GSMTAP 189 phy0.0: Sending control 'CMD NOHANDOVER 2 0' ... 20389 09:02:08.628780 Sep 27, 2019 09:02:08.628780000 CEST 172.18.9.20 33148 172.18.9.10 4729 GSMTAP 193 phy0.0: Tx burst (hdr_ver=1): tn=0 fn=1401 pwr=0 20390 09:02:08.628794 Sep 27, 2019 09:02:08.628794000 CEST 172.18.9.20 33148 172.18.9.10 4729 GSMTAP 191 phy0.0: Ignoring TX data, transceiver offline. [repeated] ... 20406 09:02:08.629022 Sep 27, 2019 09:02:08.629022000 CEST 172.18.9.20 33148 172.18.9.10 4729 GSMTAP 193 phy0.0: Response message: 'RSP NOHANDOVER 0 2 0'
I have also seen this kind of behavior before when running osmo-bts-trx+osmo-trx locally.
So the problem seems to be in osmo-bts-trx trx_if.c, in trx_if_send_burst():
/* we must be sure that we have clock, and we have sent all control * data */ if (transceiver_available && llist_empty(&l1h->trx_ctrl_list)) { send(l1h->trx_ofd_data.fd, buf, nbits + 6, 0); } else LOGPPHI(l1h->phy_inst, DTRX, LOGL_ERROR, "Ignoring TX data, transceiver offline.\n");
So IIUC, that check is there to make sure we don't send DL bursts while the TRX is stopped or still in progress of being configured, but I guess it should have its DL bursts dropped while already running and having a NOHANDOVER command.
Actions