Bug #2380
closedlogical channels can get stuck if BTS sends no RELEASE INDICATION for SACCH / T3109 can be disabled
100%
Description
Every so often we received bug reports from users indicating "stuck" logical channels in the BSC, which accumulat over time and don't get automatically recycled. Unfortunately I cannot seem to find any issue here in redmine about it, but I just have experienced something similar here during testing with osmo-bts-virtual, virtphy and my L1CTL/LAPDm test cases from osmo-ttcn3-hacks.
From the BSC side, formerly-used channels would still show up in "show lchan", even on a completely idle cell:
OpenBSC> show lchan BTS 0, TRX 0, Timeslot 0, Lchan 1: Type SDCCH Connection: 0, State: RELEASE REQUESTED BS Power: 3 dBm, MS Power: 36 dBm Channel Mode / Codec: signalling No Subscriber Bound IP: 0.0.0.0 Port 0 RTP_TYPE2=0 CONN_ID=0 Measurement Report: Flags: DLinval RXL-FULL-ul: -110 dBm, RXL-SUB-ul: -110 dBm RXQ-FULL-ul: 0, RXQ-SUB-ul: 0
I can not trigger this with a well-behaving MS (e.g. OsmocomBB performing a LU). In that case, the lchan is released as expected (rsl_lu_normal.pcapng)
However, from a L1CTL based test case that doesn't properly establish LAPDm on the radio channel, it can be reproduced quite easily ( (rsl_est_fefe_fail.pcapng).
Initial comparison of the pcap traces shows that the erroneous case (causing stuck lchan) doesn't ever show a RELEASE INDICATION from BTS to BSC. This is not a surprise, as there is no functional LAPDm entity in the test case, and hence there is no established SACCH that could be released.
Files
Related issues