Project

General

Profile

Actions

Bug #1839

closed

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

Added by mqng2 over 7 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
osmo-bts-litecell15
Target version:
-
Start date:
11/09/2016
Due date:
% Done:

100%

Spec Reference:

Description

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.

Actions #1

Updated by laforge about 7 years ago

  • Assignee set to dexter
Actions #2

Updated by mqng2 about 7 years ago

Hi Harald,

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

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

Regards,

Minh-Quang Nguyen

Concepteur logiciel | Software designer GSM/Network

T. 418 914-7484 x2296 | 1 855 914-7484 | F. 418 914-9477

2150, Cyrille-Duquet, Québec (Québec) G1N 2G3 CANADA

www.nutaq.com

QUEBEC MONTREAL NEW YORK

Facebook Twitter LinkedIn YouTube

-----Original Message-----
From: laforge [REDMINE] [mailto:]
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 #3

Updated by mqng2 about 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 #4

Updated by dexter about 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 #5

Updated by dexter over 6 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100

Patches are merged, so this should be resolved by now.

Actions #6

Updated by laforge over 6 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)