Bug #4728
closed
wrong BSSMAP Cause Value on RLL RELEASE IND
Added by laforge over 3 years ago.
Updated over 3 years ago.
Description
When a phone releases a data link layer (in this specific examply by sending a DM LAPDm message on SAPI3), the BSC translates that to a "SAPI 'n' Reject" message.
What's misleading is that OsmoBSC is using cause value 0x25 (BSS not equipped) in this situation.
As TS 48.058 clearly states, a RLL REL IND is only sent if the datalink is released by the MS. Thre's no cause value giving further diagnostics, but if the MS releases the link, it is clearly not the BSS's fault, and hence "BSS not equipped" is wrong.
Attaching a pcap file.
Files
- Status changed from New to In Progress
Hi Harald,
What's misleading is that OsmoBSC is using cause value 0x25 (BSS not equipped) in this situation.
here is an extract from 3GPP TS 48.008, section 3.1.18.1.2 (part of "Data Link Control SAPI not Equal to 0"):
Receipt of a layer 3 (DTAP) message from the MSC with the SAPI (indicated in the DLCI)
not equal to "0" will cause one of the following actions:
...
* the sending of a BSSMAP SAPI "N" REJECT message to the MSC if for any reason the data
link cannot be established, A Cause Information Element is included; typical Cause values
are: "O&M intervention", "processor overload", "BSS not equipped", "MS not equipped".
I think GSM0808_CAUSE_MS_NOT_EQUIPPED is a better fit in this case (on receipt of RLL REL IND).
- Status changed from In Progress to Feedback
- % Done changed from 0 to 100
- Category deleted (
A interface)
- Status changed from Feedback to In Progress
- % Done changed from 100 to 90
patches merged. However, I think we're missing a (TTCN3) test for it. Should be relatively easy to send a RLL RELEASE IND on RSL and check for the SAPI N REJECT cause value.
- Status changed from In Progress to Feedback
- % Done changed from 90 to 100
- Status changed from Feedback to Resolved
Also available in: Atom
PDF