aboutsummaryrefslogtreecommitdiffstats
path: root/include/osmocom
diff options
context:
space:
mode:
authorPau Espin Pedrol <pespin@sysmocom.de>2019-09-04 20:40:50 +0200
committerPau Espin Pedrol <pespin@sysmocom.de>2019-09-18 12:44:57 +0200
commitb7e0f0c6d05d79c0fbe8baa0a7370e90df5faa3c (patch)
tree290ce05346dc73b63358194b60d76715816ab406 /include/osmocom
parent7d88844909ce52dcf936d7cd233df555f58a998f (diff)
bsc_subscr_conn_fsm: Cleanly clear BSSAP conn if associated channel closed during WAIT_CC
TTCN3 BSC_Tests.TC_ms_rel_ind_does_not_cause_bssmap_reset seems to sometimes run into a race condition on the order of messages received by osmo-bsc comming from MSC and BTS. Usual (expected) scenario): BTS->BSC EST IND BSC->MSC CL3 Info BSC<-MSC CC BTS->BSC REL IND BTS<-BSC DEACT SACCH BSC->MSC ClearRequest BSC<-MSC ClearCommand BSC->MSC ClearComplete BTS<-BSC RF Chan Release BTS->BSC RF Chan Release ACK Sometimes CC message and REL IND message are received swapped (because they are sent by different components asynchronously in TTCN3). As a result, osmo-bsc was failing to go into CLEARING state and was unable to send the ClearRequest because CC was still not received. So the idea is to stay in WAIT_CC until CC is received, then check if the lchan was dropped and in that case go into clearing state. Change-Id: Id1abf5ee44c60925b478123409f26bd29006202b
Diffstat (limited to 'include/osmocom')
0 files changed, 0 insertions, 0 deletions