Actions
Bug #3948
closedOsmoMSC doesn't close SCCP connection after successful LU over IuCS
Start date:
04/23/2019
Due date:
% Done:
100%
Resolution:
Spec Reference:
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
Related issues
Updated by laforge about 5 years ago
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
Updated by laforge almost 5 years ago
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.
Updated by laforge almost 5 years ago
- 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.
Updated by laforge almost 5 years ago
- Related to Bug #3995: OsmoSGSN doesn't close SCCP connection after successful LU over IuPS added
Actions