Project

General

Profile

Actions

Bug #3948

closed

OsmoMSC doesn't close SCCP connection after successful LU over IuCS

Added by laforge almost 5 years ago. Updated almost 5 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
IuCS support
Target version:
-
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

msc.log msc.log 32 KB osmo-msc log file laforge, 04/23/2019 07:20 AM
msc_release_bug.pcap msc_release_bug.pcap 5.49 KB pcap file laforge, 04/23/2019 07:20 AM
ttcn3.log ttcn3.log 265 KB TITAN log of the TTCN3 test laforge, 04/23/2019 07:20 AM

Related issues

Related to OsmoSGSN - Bug #3995: OsmoSGSN doesn't close SCCP connection after successful LU over IuPSClosedlynxis05/10/2019

Actions
Actions #1

Updated by laforge almost 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
Actions #2

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.

Actions #3

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.

Actions #4

Updated by laforge almost 5 years ago

  • Related to Bug #3995: OsmoSGSN doesn't close SCCP connection after successful LU over IuPS added
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)