Bug #2730
closed
BSC doesn't release RF conenction or SCCP connection after main signalling link is closed
Added by laforge over 6 years ago.
Updated about 6 years ago.
Description
If a MS sends us an "RLL RELEASE IND" on SAPI0/DCCH, it closes the main signaling link.
I'm developing TC_chan_rel_rll_rel_ind in the ttcn-3 BSC_Tests.ttcn to produce this scenario.
OsmoBSC currently seems to ignore this, meaning that neither do we
- attempt to re-establish it
- properly close the Radio channel (RF CHAN REL, ...)
- close the SCCP/A connection
I'm not entirely sure what's the specified action at that point. The best is probably to drop the RF channel and A connection in such situations, rather than trying to recover from something that clearly looks like an implementation bug of a phone.
T3111 could play into this, e.g. if the main signalling connection is closed, T3111 should be started until the RF CHAN REL is performed. At the same time, we should probably stop the SACCH when starting T3111.
See Timers
- Status changed from New to In Progress
- Assignee changed from dexter to laforge
- % Done changed from 0 to 70
I have a patch in Change-Id Ia8a49eaceb3a644d5de1c7e0934798ed04f0287e of the laforge/fsm branch.
- Priority changed from Normal to High
- Status changed from In Progress to Stalled
waiting for dexter to complete the work on the FSM branch
- Status changed from Stalled to Resolved
- % Done changed from 70 to 100
patch has been merged, BSC_Tests.TC_chan_rel_rll_rel_ind passes.
Also available in: Atom
PDF
