Disconnect from CN

[Rifa]

Hi,
I would like to know on which spec I could find info for reasons for CN sending DISCONNECT message during call setup. From the MEGAMON trace we noticed that after alert message, RNC received a ccisconnect message and RNC released the setup.
The cause value for disconnect was Normal, Unspecified.
Do we know why the CN sends this diconnect and says normal?
What are possible reasons for this scenario?

Appreciate the advice from the GURU's

Thank you,

[ninjafine]

Hi Rifa! Please check first what kind of codec you were using. If it was AMR-WB or it was Multi-Rab then
check if all rabs are properly activated from both RAN sides (originated and terminated) and Core network as well.

[babak1349]

Hi,
I would like to know on which spec I could find info for reasons for CN sending DISCONNECT message during call setup. From the MEGAMON trace we noticed that after alert message, RNC received a ccisconnect message and RNC released the setup.
The cause value for disconnect was Normal, Unspecified.
Do we know why the CN sends this diconnect and says normal?
What are possible reasons for this scenario?

Appreciate the advice from the GURU's

Thank you,

Hello,
CC messages are NAS messages and radio part just encapsulating them on RRC signaling... and doesn't have really control over them. So you need to see after what kind of messages the failures are happening... you need to trace both party (MO and MT sides).
it is true that some radio interface procedure can cause NAS disconnection (for example authentication failure , or resources on MGW can not be allocated)

You need to check massage flow

cheers

[babak1349]

Hello,
CC messages are NAS messages and radio part just encapsulating them on RRC signaling... and doesn't have really control over them. So you need to see after what kind of messages the failures are happening... you need to trace both party (MO and MT sides).
it is true that some radio interface procedure can cause NAS disconnection (for example authentication failure , or resources on MGW can not be allocated)

You need to check massage flow

cheers

Hi again,
try to see if the problem is from UMTS to UMTS or UMTS to GSM or UMTS to PSTN....
If it is after "Alerting" toward originating mobile, it means the terminating mobile doesn't send "connect" message or Source MSC doesn't receive it.... and I don't think that would be related to resource allocation ib both MO and MT sides...
very weird .....!!!!!

cheers

[babak1349]

Hi again,
try to see if the problem is from UMTS to UMTS or UMTS to GSM or UMTS to PSTN....
If it is after "Alerting" toward originating mobile, it means the terminating mobile doesn't send "connect" message or Source MSC doesn't receive it.... and I don't think that would be related to resource allocation ib both MO and MT sides...
very weird .....!!!!!

cheers

You can look at the attached document page6 and afterward to see exact the message flows....

cheers

[Rifa]

Thank you. I have checked 3GPP 32407 section4.1.2.10, and it says it is due to CN.

Calling party releasing the call after alerting: On transmission of "DISCONNECT"(cause #16 "normal call clearing") to called party after receipt of " ALERTING" from called party in the case of Inter-MSC call.
Calling party releasing the call before alerting: On receipt of "REL"(cause value=normal unspecified or normal call clearing) from originating MSC-S when Network call states of called party is in N0.1,N6,N9 in the case of Inter-MSC call.
- User busy: Called Party is Pre-defined "busy" in VLR when receipt of "IAM" in the case of Inter-MSC call.
- No answer from the user: When T301 expires in the case of Inter-MSC call.
- User Refused: When receipt of "DISCONNECT"( cause #17 "user busy" or cause #21 "call rejected") from called party after receipt of "ALERTING" from called party in the case of Inter-MSC call.