Bug #4731
open
LAPDm does not implement SAPI priorities between data link layers
Added by laforge over 3 years ago.
Updated over 3 years ago.
Description
AFAIR, The 3GPP specifications contain some very strict rules regarding priorities among different concurrent LAPDm data links for the same subscriber. For example, SAIP0 always has higher priority than SAPI3.
We've just encountered a situation where in MT-SMS, the SAPI3 SABM from BTS to MS was sent before the BTS replied with the UA for SAPI0 (contetion resolution procedure, where we echo the PAGING RESPONSE back to the MS).
A quick look at the LAPDm code in libosmocore reveals that it is doing a round-robin rather than implementing the rules.
TS 44.005 Section 4.2.2 states the priorities for SDCCH and SACCH. I guess we can think of FACCH == SDCCH in this context.
btw: We think this situation never happened so far due to the fact that we had NAGLE enabled on the TCP connections used for RSL. As we have started to disable NAGLE by enabling TCP_NODELAY, the latency of the BSC getting back to the BTS has significatnly been reduced,changing the timing at which a RLL EST REQ for SAPI3 is received by the BTS.
- Status changed from New to In Progress
- Related to Bug #4714: SMS Message Lost Although Delivery Ack Sent added
TS 44.005 Section 4.2.2 states the priorities for SDCCH and SACCH. I guess we can think of FACCH == SDCCH in this context.
During a voice call, SMS/SAPI=3 always goes over SACCH. So don't need to worry about FACCH.
The fix for DCCH has been submitted to Gerrit:
https://gerrit.osmocom.org/c/libosmocore/+/19853 lapdm: fix SAPI-0/SAPI-3 frame prioritization on DCCH
We still need to add some testing coverage for SACCH. Unfortunately it's much more complicated.
- Status changed from Feedback to Stalled
- Priority changed from High to Normal
I'll continue to work on this as soon as I have more time.
- Related to Bug #1979: Priority of SAPI=0/SAPI=3 on SABM added
Also available in: Atom
PDF
