Bug #2730

BSC doesn't release RF conenction or SCCP connection after main signalling link is closed

Added by laforge 4 months ago. Updated 7 days ago.

Target version:
Start date:
Due date:
% Done:


Spec Reference:


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.


#1 Updated by laforge 3 months ago

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

#2 Updated by laforge 3 months ago

  • Assignee set to dexter

#3 Updated by laforge about 2 months ago

  • 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.

#4 Updated by laforge about 2 months ago

  • Priority changed from Normal to High

#5 Updated by laforge about 2 months ago

  • Status changed from In Progress to Stalled

waiting for dexter to complete the work on the FSM branch

#6 Updated by laforge 7 days ago

  • 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