Bug #3948
closed
OsmoMSC doesn't close SCCP connection after successful LU over IuCS
Added by laforge about 5 years ago.
Updated almost 5 years ago.
Description
After a UE performs a location update, OsmoMSC doesn't properly close
the SCCP signaling connection.
The Iu Release procedure happens as expected. However, there is no SCCP
disconnect following. The MSC is expected to issue an N-DISCONNECT.req
to the local SCCP provider, which then is resulting in the related
signaling to the SCCP peer (RNC).
OsmoMSC# show cs7 instance 0 sccp connections
I Local Conn. Remote
O Ref SSN PC State Ref SSN PC
- ------ --- ------- ---------------- ------ --- -------
I 000000 142 0.23.1 ACTIVE 128f85 142 0.24.3
OsmoMSC# show subscriber cache
Subscriber:
Extension: 491230000005
LAC: 23/0x17
RAN: UTRAN-Iu
IMSI: 262420000000005
TMSI: 6355C12E
Flags:
IMSI detached: false
Conf. by radio contact: true
Subscr. data conf. by HLR: true
Location conf. in HLR: true
Subscriber dormant: false
Received cancel locataion: false
MS not reachable: false
LA allowed: true
A3A8 last tuple (used 1 times):
seq # : 0
RAND : 9e 34 37 cd 27 3f 7d f0 88 4a da 37 bb c8 29 f7
SRES : 87 25 22 d2
Kc : a7 98 fd a1 7d 4e 01 30
Paging: not paging for 0 requests
SGs-state: SGs-NULL
SGs-MME: (none)
Use: 1 (attached)
Files
A subsequent transaction, such as a MO call fails as follows:
Tue Apr 23 09:28:04 2019 DVLR <000e> vlr_lu_fsm.c:749 vlr_lu_fsm(IMSI-262420000000028:MSISDN-491230000028:TMSI-0x8919E5F1:UTRAN-Iu-0:LU)[0x6120000156a0]{VLR_ULA_S_WAIT_LU_COMPL}: state_chg to VLR_ULA_S_DONE
Tue Apr 23 09:28:04 2019 DMM <0002> vlr_lu_fsm.c:741 RAN_conn(IMSI-262420000000028:MSISDN-491230000028:TMSI-0x8919E5F1:UTRAN-Iu-0:LU)[0x612000015520]{RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_ACCEPTED
Tue Apr 23 09:28:04 2019 DSMPP <000c> smpp_smsc.c:656 [msc_tester] Tx ALERT_NOTIFICATION (491230000028/3/1): Available
Tue Apr 23 09:28:04 2019 DMM <0002> ran_conn.c:146 RAN_conn(IMSI-262420000000028:MSISDN-491230000028:TMSI-0x8919E5F1:UTRAN-Iu-0:LU)[0x612000015520]{RAN_CONN_S_AUTH_CIPH}: state_chg to RAN_CONN_S_ACCEPTED
Tue Apr 23 09:28:04 2019 DMM <0002> ran_conn.c:276 RAN_conn(IMSI-262420000000028:MSISDN-491230000028:TMSI-0x8919E5F1:UTRAN-Iu-0:LU)[0x612000015520]{RAN_CONN_S_ACCEPTED}: Received Event RAN_CONN_E_UNUSED
Tue Apr 23 09:28:04 2019 DMM <0002> ran_conn.c:297 RAN_conn(IMSI-262420000000028:MSISDN-491230000028:TMSI-0x8919E5F1:UTRAN-Iu-0:LU)[0x612000015520]{RAN_CONN_S_ACCEPTED}: state_chg to RAN_CONN_S_RELEASING
Tue Apr 23 09:28:04 2019 DRANAP <000d> iu_client.c:771 sccp_sap_up(N-DATA.indication)
Tue Apr 23 09:28:04 2019 DRANAP <000d> iu_client.c:805 N-DATA.ind(0, 00 13 40 40 00 00 06 00 03 40 01 00 00 0f 40 06 00 62 f2 24 00 17 00 3a 40 08 00 62 f2 24 00 17 00 00 00 10 40 0e 0d 05 24 01 03 50 59 02 05 f4 89 19 e5 f1 00 4f 40 03 00 00 17 00 56 40 05 62 f2 24 09 26 )
Tue Apr 23 09:28:04 2019 DRANAP <000d> iu_client.c:530 handle_co(dir=1, proc=19)
Tue Apr 23 09:28:04 2019 DRANAP <000d> iu_client.c:536 Got InitialUE_Message but this is not a new conn
Tue Apr 23 09:28:04 2019 DRANAP <000d> iu_client.c:599 Error in cn_ranap_handle_co (-1)
Tue Apr 23 09:28:09 2019 DMM <0002> fsm.c:287 RAN_conn(IMSI-262420000000028:MSISDN-491230000028:TMSI-0x8919E5F1:UTRAN-Iu-0:LU)[0x612000015520]{RAN_CONN_S_RELEASING}: Timeout of T0
Tue Apr 23 09:28:09 2019 DMM <0002> ran_conn.c:329 RAN_conn(IMSI-262420000000028:MSISDN-491230000028:TMSI-0x8919E5F1:UTRAN-Iu-0:LU)[0x612000015520]{RAN_CONN_S_RELEASING}: Timeout while releasing, discarding right now
Tue Apr 23 09:28:09 2019 DMM <0002> ran_conn.c:330 RAN_conn(IMSI-262420000000028:MSISDN-491230000028:TMSI-0x8919E5F1:UTRAN-Iu-0:LU)[0x612000015520]{RAN_CONN_S_RELEASING}: Terminating (cause = OSMO_FSM_TERM_TIMEOUT)
Tue Apr 23 09:28:09 2019 DVLR <000e> ran_conn.c:330 vlr_lu_fsm(IMSI-262420000000028:MSISDN-491230000028:TMSI-0x8919E5F1:UTRAN-Iu-0:LU)[0x6120000156a0]{VLR_ULA_S_DONE}: Terminating in cascade, depth 2 (cause = OSMO_FSM_TERM_PARENT, caused by: RAN_conn(IMSI-262420000000028:MSISDN-491230000028:TMSI-0x8919E5F1:UTRAN-Iu-0:LU)[0x612000015520])
Tue Apr 23 09:28:09 2019 DVLR <000e> ran_conn.c:330 vlr_lu_fsm(IMSI-262420000000028:MSISDN-491230000028:TMSI-0x8919E5F1:UTRAN-Iu-0:LU)[0x6120000156a0]{VLR_ULA_S_DONE}: Removing from parent RAN_conn(IMSI-262420000000028:MSISDN-491230000028:TMSI-0x8919E5F1:UTRAN-Iu-0:LU)[0x612000015520]
Tue Apr 23 09:28:09 2019 DVLR <000e> vlr_lu_fsm.c:1415 vlr_lu_fsm(IMSI-262420000000028:MSISDN-491230000028:TMSI-0x8919E5F1:UTRAN-Iu-0:LU)[0x6120000156a0]{VLR_ULA_S_DONE}: fsm_lu_cleanup called with cause OSMO_FSM_TERM_PARENT
Tue Apr 23 09:28:09 2019 DVLR <000e> fsm.c:517 vlr_lu_fsm(IMSI-262420000000028:MSISDN-491230000028:TMSI-0x8919E5F1:UTRAN-Iu-0:LU)[0x6120000156a0]{VLR_ULA_S_DONE}: Deferring: will deallocate with RAN_conn(IMSI-262420000000028:MSISDN-491230000028:TMSI-0x8919E5F1:UTRAN-Iu-0:LU)[0x612000015520]
Tue Apr 23 09:28:09 2019 DMM <0002> fsm.c:533 RAN_conn(IMSI-262420000000028:MSISDN-491230000028:TMSI-0x8919E5F1:UTRAN-Iu-0:LU)[0x612000015520]{RAN_CONN_S_RELEASING}: Deallocated, including all deferred deallocations
FYI: this is what makes most MSC_Tests_Iu.* testcases fail so far, as all of them expect a proper Iu release procedure, including the SCCP disconnect.
- Status changed from New to Resolved
- Assignee set to laforge
- % Done changed from 0 to 100
this problem appears to be resolved after the neels/ho branch merge. We do have the same issue in the SGSN, will create a separte issue for it.
- Related to Bug #3995: OsmoSGSN doesn't close SCCP connection after successful LU over IuPS added
Also available in: Atom
PDF
