Call Failure

[telwind]

Any Idea what cause Blocked Calls with these?
This logged by TEMS 9.0.3 with K800i phone

1. In first case, the handshiking was as follows:

UL Service Request
UL Channel Request
DL Immediate Assignment
DL Ciphering Mode Command
UL Ciphering Mode Complete
UL Setup
DL Call Proceeding
DL Disconnect
UL Release
Call End

DL Disconnect message:
=============
MS1
Disconnect

Time:
Transaction identifier : 8
Protocol discriminator : (3) Call control; call related SS messages
Message type : 37
Cause
Coding standard : (3) Standard defined for the GSM PLMNS
Location : (3) transit network
cause value : (31) Normal, unspecified
================

2. In first case, the handshiking was as follows:

UL Service Request
UL Channel Request
DL Immediate Assignment
DL Ciphering Mode Command
UL Ciphering Mode Complete
UL Setup
DL Call Proceeding
DL Assignment Command
DL Assignment Complete
DL Progress
DL Synsch Channel Information
DL Handover Command
DL Handover Access
DL Handover Complete
DL Synsch Channel Information
DL Disconnect
UL Release
Call End

DL Disconnect message:
=============
MS1
Disconnect

Time:
Transaction identifier : 8
Protocol discriminator : (3) Call control; call related SS messages
Message type : 37
Cause
Coding standard : (3) Standard defined for the GSM PLMNS
Location : (3) transit network
cause value : (31) Normal, unspecified
================

[zhanglw268]

From the message sequence, it is most likely the calls were disconnected by BSS or other users.

For 1st case, can you please check the time length between "DL Call Proceeding" and "DL Disconnect",
(1) if it is the link_fail timer's length, it is most likely the BTS didn't receive the "Measurement report" due to interference etc. reason and BTS/BSC time out and disconnected the call;
(2) If it is shorter than link_fail, it most likely the other party ended the call through MSC
(3) If it is longer than link_fail, please check T310's setting at the MSC, it maybe due to MSC T310 timer time out

For 2nd case, please check the time length between "DL Handover Command" and "DL Disconnect", also check the layer 2 to see whether you have 6-7 SABMs to BTS, and there is no DL UA, if this is the case, the BTS/BSC didn't receive the SABM due to interference or other reason, then the system disconnected the call. If this is not the case, the other use may disconnected the call through the MSC.

Regards

David Zhang

[telwind]

From the message sequence, it is most likely the calls were disconnected by BSS or other users.

For 1st case, can you please check the time length between "DL Call Proceeding" and "DL Disconnect",
(1) if it is the link_fail timer's length, it is most likely the BTS didn't receive the "Measurement report" due to interference etc. reason and BTS/BSC time out and disconnected the call;
(2) If it is shorter than link_fail, it most likely the other party ended the call through MSC
(3) If it is longer than link_fail, please check T310's setting at the MSC, it maybe due to MSC T310 timer time out

For 2nd case, please check the time length between "DL Handover Command" and "DL Disconnect", also check the layer 2 to see whether you have 6-7 SABMs to BTS, and there is no DL UA, if this is the case, the BTS/BSC didn't receive the SABM due to interference or other reason, then the system disconnected the call. If this is not the case, the other use may disconnected the call through the MSC.

Regards

David Zhang

Thanks David,
what does mean link_fail?
1st case, The time from DL Call Proceding and Assignment Command (also seen, sorry my misktake) to Disconnect is appro. 22 sec. which much longer than T3107 (6 sec). I checked most the some normal succesful call, it is less than 2sec. We can say this due to uplink fail where Network run time out?

2nd case, the time from Handover Command to Discconect is appro. 18 sec, T3103 is 6 sec. it seems to be time out? there's UL SABM but no DL UA. My concern is that in successful call, there's also no DL UA (only DL RR-RSP), it seems to me that uplink message is failed to be received at network (time out) but msg still doesnt tell us any thing?

[msall]

There are so many smart people out here I like this forum . It would have been better if i could do a lot more things. I enjoy coming here and reading the threads of geniuses wish to be a full time RF engineer one day like you guys. I have been working as a drive tester for 5 years now. Hope to be able to do more and be able to download more stuff from here but am limited. Hope things changed and new members are given more access .

[zhanglw268]

Hi Telwind,

Link_fail is a ******** BSS timer equivalent to the mobile's T100 radio link timeout timer, its purpose is to monitor the Mobile's Measurement report in the uplink so BSS will not keep the resources for the mobile if the mobile losses the connection with the BTS cell. Some vendor may called this as different name.

For the 1st case, you saw the "DL Assignment Command", you must also see "UL Assignment Complete" message, your TEMS mobile was waiting for "DL Alerting" message or "DL Progress" but received the "DL Disconnect" message. I think that BTS and BSS got the "Assignment Complete" message and sent to MSC, the MSC shall send you the "Alerting" message while MSC was trying to find the called party. The most possible 2 reasons are:
(a) the called party refused to pick up the call, or pick up the phone and quickly hang it up. I think that you have a dedicated phone to call for the optimization, you shall check with the person who provide the number in the "Setup" message.
(b) The controlling MSC, or other party like PSTN is busy so your call is disconnected with call control. You can check the time between "UL Assignment Complete" and "DL Disconnect", then check whether there is a MSC timer to control the time for Alerting message.

For 2nd case, I think that it shall be normal since the TEMS sometimes doesn't show the right message sequence, this is most likely a normal case that the called party ended your call. You can check with the dialled number.

The above guesses maybe wrong if you have a lot complaints from the end users for abnormal call disconnection, then you need the MSC and BSS engineers to sit together to have a call trace to see what the reason MSC disconnected the call with cause value "(31) Normal, unspecified
".

Regards

David

[telwind]

Thanks for your helpful answer,

Your are right, 1st case UL assignment complete msg seen. as said the time from UL assignment complete to disconnect is really longer than timer t3107. is is possible that MSC timer is out due to some reason. the a) should not be because if called subs refused to pick the call then Alerting msg normally send to MS (but Connect msg is not).
2nd case, i agreed that TEMS may show wrong call sequence and the called sub may refused to pick the call or congestion.

Thans again for your help.

[zhanglw268]

Hi Telwind,

As you have checked that the "UL Assignment Complete" message was seen on TEMS, and T3107 is set to 7 seconds, the call is "Disconnected" after 22 seconds, so the problem is not related to T3107 any more.

The problem must be at the MSC interacting with HLR and PSTN depending on the number dialled in the SETUP message, normally MSC starts dialog with HLR and PSTN etc. when MSC receives the "UL Assignment Complete". From the length of the time, it looks like that the SS7 ISUP guard timer T7 (which is normally set to 20 seconds by default) time out after IAM (Initial Address Message ) was sent. The "Disconnect" cause value from other party may not be 31, the cause value most likely is Q931's cause value, then MSC send the value to BSS, but BSS only use partial Q931's cause value per 3GPP24.008, so BSS may map the cause value to 31 ["(31) Normal, unspecified"]

If you really want to find the root cause, you need to talk with MSC engineer and MSC engineer trace the problem and figure it out for you.

Regards

David

[telwind]

David,

I have tried everything but from the seen only, this is still limited information to us for finding the problem.

Anyway thanks you. You have already help me alot.

[zhanglw268]

Hi Telwind,

you are welcome.

I personally think that this is MSC interacting with HLR/PSTN etc. problem or MSC itself problem, the two cases may point to the same issue, you can check 2nd case's time between "DL Assignment Complete" and "DL Disconnect", it shall be roughly same as the 1st case; If the called number is the same, you have a strong case to speak to MSC side's engineer. It will be more easier if the MSC and BSS are from same vendor, if it is not the case, it would be difficult to figure it out for you in normal circumstance.

Regards

David

[telwind]

thanks David,

i've collected the only timer definition here, if you find something better pls share to us.

Check your PM for password

Thanks.

[zhanglw268]

I put the information I collected to the below and you can download them from.

Q.931 Disconnect Codes:
http://www.docstoc.com/docs/57214301/Q931-Disconnect-Cause-Codes (http://www.docstoc.com/docs/57214301/Q931-Disconnect-Cause-Codes)
GSM DISCONNECT Cause Codes:
http://www.docstoc.com/docs/57214296/DISCONNECT_RELEASE_Cause_Codes_in_RAN (http://www.docstoc.com/docs/57214296/DISCONNECT_RELEASE_Cause_Codes_in_RAN)
GSM GPRS timers from 3GPP24.008 version 8:
http://www.docstoc.com/docs/57214300/GSM-GPRS-Timers (http://www.docstoc.com/docs/57214300/GSM-GPRS-Timers)
SS7/C7 ISUP timers:
http://www.docstoc.com/docs/57214303/SS7C7_ISUP_Timers (http://www.docstoc.com/docs/57214303/SS7C7_ISUP_Timers)

******** GSM call setup flow chart with timers and statistics pegging:
http://www.docstoc.com/docs/55200563/********-GSM-call-setup-flow-chart (http://www.docstoc.com/docs/55200563/********-GSM-call-setup-flow-chart)

------------------------------------------------------------------
If you like this post, reputation is highly appreciated. :p