Bug #1839: LC15: BTS failed to send LAPDm UA command to MS after receiving LAPDm DISC - OsmoBTS - Open Source Mobile Communications

-----Original Message-----
From: laforge [REDMINE] [mailto:redmine@lists.osmocom.org]
Sent: Thursday, January 12, 2017 9:24 AM
Subject: [OsmoBTS - Bug #1839] LC15: BTS failed to send LAPDm UA command to MS after receiving LAPDm DISC

Issue #1839 has been updated by laforge.

Assignee set to dexter

Bug #1839: LC15: BTS failed to send LAPDm UA command to MS after receiving LAPDm DISC

https://osmocom.org/issues/1839#change-2800 <https://osmocom.org/issues/1839#change-2800>

Author: mqng2

Status: New

Priority: Normal

Assignee: dexter

Category: osmo-bts-litecell15

Target version:

Spec Reference:

We are facing an issue with MOC with a Motorola Rarz phone. This phone is time to time failed to establish the call if we perform fast successive MOC from this phone.

We have built a special version of DSP to trace all LADPm messages between L1 and L2. When the MO terminates the call, the BTS does not send L2 LAPDm UA message to the L1 after receiving LAPDm DISC from the MS.

Looking at “lapd_core.c” in libosmocore, we have seen that there is an L2 LAPDm UA message supposed to be sent to L1 but it has never sent to the L1 for unknown reason.

We did a small test by commented out “l1sap_chan_rel(lchan->ts->trx, chan_nr);” line in function rsl_rx_rf_chan_rel in osmo-bts/src/common/rsl.c. We observed that the BTS sent out the UA as expected.

It looks like the BTS releases the RF channel too fast preventing the BTS to send the pending LAPDm UA messagge in Tx queue.

--

You have received this notification because you have either subscribed to it, or are involved in it.

To change your notification preferences, please click here: https://osmocom.org/my/account <https://osmocom.org/my/account>

Actions

Copy link

#3

Updated by mqng2 over 7 years ago

This issue has fixed and tested at our end with LC15 in below commit

https://gitlab.com/nrw_noa/osmo-bts/commit/95d1f15ad108c1c1869c1965144acd64c1395d8c

Actions

Copy link

#4

Updated by dexter over 7 years ago

Status changed from New to In Progress
% Done changed from 0 to 90

Integrated the change now. Unfortunately I could not find the changes to the gsm_lchan struct in gsm_data_shared.h (openbsc), but it looks obvious to me that it is just the msg buffer pointer and the flag that has to be added. I gave the whole thing a quick test run (not on the LC).

Looks ok to me. However, I am not 100% sure about rsl.c. I do not entirely get why the message has to pass rslms_is_meas_rep(msg) and (rh->msg_type == RSL_MT_REL_IND), but this is also the case in the original patch.

See also:
https://gerrit.osmocom.org/1626
https://gerrit.osmocom.org/1625

Actions

Copy link

#5