Đang tải... (xem toàn văn)
Dropped call investigation Phân tích các vấn đề, nguyên nhân dẫn đến hiện tượng rớt cuộc gọi trong mạng GSM Phân tích các vấn đề, nguyên nhân dẫn đến hiện tượng rớt cuộc gọi trong mạng GSM Phân tích các vấn đề, nguyên nhân dẫn đến hiện tượng rớt cuộc gọi trong mạng GSM Phân tích các vấn đề, nguyên nhân dẫn đến hiện tượng rớt cuộc gọi trong mạng GSM Phân tích các vấn đề, nguyên nhân dẫn đến hiện tượng rớt cuộc gọi trong mạng GSM
REPORT (18) Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other) Nr - No ERA/LVR/PO Stephan Trzeciak LVR/PO-97:0148 Dokansv/Godk - Doc respons/Approved Kontr - Checked ERA/LVR/POC Datum - Date 1997-09-12 Rev A REPORT - DROPPED CALL INVESTIGATION Edited Summary E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc File REPORT (18) Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other) Nr - No ERA/LVR/PO Stephan Trzeciak LVR/PO-97:0148 Dokansv/Godk - Doc respons/Approved Kontr - Checked ERA/LVR/POC Datum - Date 1997-09-12 Rev File A Abstract This document describes the results from the Dropped call investigation The aim was to investigate the reasons for dropped calls and how well the statistics correspond to the dropped calls Three cells were chosen and all signalling on respective A-bis interfaces were recorded during 14 - 18 hours including peak hour The A interface were also recorded during one hour on each cell The recordings were later post-processed and every abnormal call was analysed STS data was collected as well The analysis showed that the majority of the dropped calls was due to low signal strength, high interference or end of battery in the mobile station Only one minor problem in the CME20 system was found A few cases of abnormal mobile station behaviour were found, none of them very serious The STS counter for dropped calls on TCH, TNDROP, was corresponding very well to the reality The equivalent counter for SDCCH, CNDROP, was counting fewer drops than was found when analysing the recordings This can be improved by some changes in the CME20 system The overall performance was very good and no problems were found in the interwork between the CME20 system and the mobile station E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc REPORT (18) Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other) Nr - No ERA/LVR/PO Stephan Trzeciak LVR/PO-97:0148 Dokansv/Godk - Doc respons/Approved Kontr - Checked ERA/LVR/POC Datum - Date 1997-09-12 Rev File A Contents INTRODUCTION TEST OBJECT MEASUREMENT AND ANALYSIS .5 SIGNALLING AND STS COUNTERS 4.1 SIGNALLING .6 4.2 STATISTICS RESULT 5.1.1 Abnormal events on TCH 5.1.2 Abnormal events on SDCCH 10 5.1.3 Mobile test .13 SUMMARY 14 6.1 TCH 14 6.2 SDCCH 14 6.3 MOBILE STATION PROBLEMS 15 6.4 STS ACCURACY 15 6.4.1 TCH .15 6.4.2 SDCCH 16 POSSIBLE ENHANCEMENTS 17 SUMMARY 18 REFERENCES .18 E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc REPORT (18) Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other) Nr - No ERA/LVR/PO Stephan Trzeciak LVR/PO-97:0148 Dokansv/Godk - Doc respons/Approved Kontr - Checked ERA/LVR/POC Datum - Date 1997-09-12 Rev File A INTRODUCTION An investigation about the reasons for dropped calls in a CME20 R5 system was made by ERA/LV/SP Anders Milén, ERA/LV/SP Bengt Norstedt, ERA/LVR/POC Stefan Svennebring and ERA/LVR/PO Per-Daniel Ståhlnacke in end of November 1996 The signalling links from Abis and A interface were recorded and STS data was collected These recordings were then post-processed and analysed internally by Ericsson TEST OBJECT The recordings were made on three cells connected to BSC A and MSC A, both with CME20 R5 software The A interface had eight C7 signalling links The BTS software was R14 (RBS200) The recorded cells were: CELL TRXs Environment Suburban Suburban/rural Suburban/rural E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc REPORT (18) Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other) Nr - No ERA/LVR/PO Stephan Trzeciak LVR/PO-97:0148 Dokansv/Godk - Doc respons/Approved Kontr - Checked ERA/LVR/POC Datum - Date 1997-09-12 Rev File A MEASUREMENT AND ANALYSIS The signalling links on the Abis and A interface were recorded using an ELMI 7300 protocol analyser MSC A BSC Protocol analyser A” BTS To avoid too large logs, the recordings were done in intervals of to 12 hours, depending on traffic load The recorded data was later post-processed by a tool able to extract all dropped and abnormal calls The output was loaded into a data base were the calls were analysed manually one by one It turned out to be enough to examine at the Abis interface to determine the cause of the dropped calls as the A interface did not add any more information STS data was also collected and post-processed E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc REPORT (18) Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other) Nr - No ERA/LVR/PO Stephan Trzeciak LVR/PO-97:0148 Dokansv/Godk - Doc respons/Approved Kontr - Checked ERA/LVR/POC Datum - Date 1997-09-12 SIGNALLING AND STS COUNTERS 4.1 SIGNALLING Rev File A To understand the mechanisms behind dropped calls the reader must have some basic knowledge about the signalling Radio Link Time-out Every time a SACCH message cannot be decoded the radio link time-out counter is decreased by If the message can be decoded the counter is incremented by However, the value can not exceed the initial value The initial value is set by the parameter RLINKT for radio link time-out in the mobile station and by RLINKUP for time-out in the BSC If the mobile station is lost and no measurement reports are received in the BSC, there will be a radio link time-out and the message Channel Release (cause: abnormal release, unspecified) is sent to the mobile station and the SACCH is deactivated in the BTS A Clear Request message is sent to the MSC as well To be sure that the mobile has stopped transmitting the BSC now waits RLINKT SACCH periods before the timeslot is released and a new call can be established on the channel Layer time-out If the BTS never get an acknowledge on a Layer message after the time T200xN200, the BTS will send Error Indication (cause: T200 expired) to the BSC which will send Channel release (cause: abnormal release, timer expired) to the mobile station and a Clear Request to the MSC The SACCH is deactivated and the BSC waits RLINKT SACCH periods before the timeslot is released and a new call can use the channel This is only valid if the call is in steady state, i.e not during handover or assignment Release Indication When the BTS receives a Layer DISC frame from the mobile it replies with a Layer UA frame to the mobile station and a Release Indication to the BSC In CME20 R5 the system does only react on Release Indication if it is received during a normal disconnect situation If such a message is received unexpectedly this will usually cause radio link time-out or timer T200 expiration as the mobile station stops the transmitting of measurement reports It is also possible that the release will be normal depending on when the Release Indication is received E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc REPORT (18) Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other) Nr - No ERA/LVR/PO Stephan Trzeciak LVR/PO-97:0148 Dokansv/Godk - Doc respons/Approved Kontr - Checked ERA/LVR/POC Datum - Date Rev 1997-09-12 File A MSC time-out This can manifest itself in different ways: Normal release: If the MSC never receives a response on a message (e.g Identity Request) and there is no radio link time-out or layer timeout, the MSC will send a Clear Command to the BSC The time-out is depending on the message When receiving Clear Command, the BSC will send a Channel Release (cause: normal release) and then deactivate the SACCH Reject (only SDCCH): If the MSC never receives a response on the first message after Establish Indication, the MSC will send a reject message If the connection was a Location Update it will be a Location Update Reject (cause: network failure) and if the connection was an MO call (CM Service Request) a CM Service Reject (cause: network failure) will be sent The MSC will then send a Clear Command to the BSC and the call is cleared by Channel Release (cause: normal release) Assignment to TCH Before sending an Assignment Command from the BSC at TCH assignment, the following criteria has to be fulfilled (in CME R5): a There must be a TCH channel available, i.e no congestion b The locating must have received at least one valid measurement report If the criteria is unfulfilled, Assignment Command will not be sent and a Channel Release (cause: abnormal release, unspecified) will be sent to the mobile station and a Clear Request to the MSC 4.2 STATISTICS Only the counters related to dropped calls are described here The counters are defined as follows: TCALLS: Allocation attempts, incremented at every attempt to seizure a TCH regardless of whether the seizure succeeded or not CCALLS: Allocation attempts, incremented at every attempt to seizure an SDCCH, including handover attempts, regardless of whether the seizure succeeded or not TMSESTB: MS connection establishment on TCH CMSESTB: MS connection establishment on SDCCH E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc REPORT (18) Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other) Nr - No ERA/LVR/PO Stephan Trzeciak LVR/PO-97:0148 Dokansv/Godk - Doc respons/Approved ERA/LVR/POC Kontr - Checked Datum - Date 1997-09-12 Rev File A TNDROP: Dropped connection due to failure on TCH, incremented when the - BSC sends CLEAR REQUEST message - CLEAR COMMAND is received in BSC if the cause code differs from the cause codes ‘Call control’ and ‘Handover successful’ and CLEAR REQUEST has not been sent previously On Abis this will cause a Channel Release with cause “Abnormal release” CNDROP: as TNDROP but for SDCCH TDISQA and CDISQA: Low quality up or downlink, incremented if RxQualUl > QLIMUL or if RxQualDl > QLIMDL RxQualUl and RxQualDl are filtered RxQual value up and downlink Note! The TDISQA and CDISQA were never be stepped in this case as the parameters QLIMUL and QLIMDL were set to 100 TDISSS1 (TCH) and CDISSS1 (SDCCH) : Low signal strength up or downlink, incremented if SSUl < -104 dBm or if SSUncompDl < - 104 dBm SSUl are filtered signal strength value uplink and SSUncompDl are uncompensated filtered signal strength value downlink Note! If no measurement reports at all are received from the mobile station the counters TDISQA, CDISQA, TDISSS1 and CDISSS1 are not incremented TDISTA: Excessive Timing Advance, incremented if TA > TALIM E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc REPORT (18) Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other) Nr - No ERA/LVR/PO Stephan Trzeciak LVR/PO-97:0148 Dokansv/Godk - Doc respons/Approved Kontr - Checked ERA/LVR/POC Datum - Date 1997-09-12 RESULT 5.1.1 Abnormal events on TCH Rev File A Following abnormal cases were found: Radio link time-out Counters: TNDROP, possible TDISSS1, TDISQA Cause: Low signal strength or high interference Time-out on Layer 2: T200 expiration Counters: TNDROP, possible TDISSS1, TDISQA Cause: Low signal strength or high interference Drop after Notify (user suspended) Counters: TNDROP, possible TDISSS1, TDISQA Some mobiles seem to drop the connection when the message “Notify: user suspended” is sent The message Notify should not cause a drop This could be mobile fault but as only two cases are seen there are not enough statistics to draw any conclusions; it could be a coincidence No answer on IMSI Detach Counters: TNDROP, possible TDISSS1, TDISQA The system does not respond to “IMSI detach” if the message is received before Setup, which will cause a radio link time-out Unsuccessful Assignment to TCH Counter: CNDROP The mobile never established itself on TCH and failed to return to SDCCH After a time-out in the BSC the call is released by sending Channel Release (cause: abnormal release unspecified) to the mobile station Cause: Low signal strength or high interference Unsuccessful outgoing handover Counters: TNDROP Either the mobile station never received the Handover Command or it failed both to establish itself on the target cell and to re-establish itself on the originating cell The call is released by sending Channel Release (cause: abnormal release unspecified) to the mobile station Cause: Low signal strength or high interference E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc REPORT 10 (18) Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other) Nr - No ERA/LVR/PO Stephan Trzeciak LVR/PO-97:0148 Dokansv/Godk - Doc respons/Approved ERA/LVR/POC Kontr - Checked Datum - Date Rev 1997-09-12 File A Unsuccessful incoming handover Counters: TNDROP in originating cell The mobile never established itself on the target cell and failed to return to the originating cell After a time-out in the BSC the call is released by sending Channel Release (cause: abnormal release unspecified) to the mobile station Cause: Low signal strength or high interference 5.1.2 Abnormal events on SDCCH Following abnormal cases were found: Location Update Reject, normal release Counter: none a No answer on Authentication Request This happens when the mobile fails to answer Authentication Request After - seconds there is a time out in the MSC and a LU Reject with cause Network Failure is sent Cause: Low signal strength or high interference b Other reject causes Following reject causes have been seen: IMSI unknown in HLR PMLN not allowed CM service Reject, normal release Counter: none a Reject cause: Network failure This happens when the mobile fails to answer Authentication Request After - seconds the MSC times out and sends CM Service Reject Cause: Low signal strength or high interference b Reject cause: Message not compatible with call state The mobile station have probably dropped the previous call and now the user tries again before the old call is completely cleared in the system c Reject cause: Message type not compatible with protocol state The mobile station is sending CM Service Request (MO call establishment) during call set-up, which is not allowed This is seen on Motorola M300, M301, M400, Flare and Flare Refresh E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc REPORT 11 (18) Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other) Nr - No ERA/LVR/PO Stephan Trzeciak LVR/PO-97:0148 Dokansv/Godk - Doc respons/Approved Kontr - Checked ERA/LVR/POC Datum - Date Rev 1997-09-12 File A d The mobile disconnects Layer (Release Indication) after Authentication Request But as the system does not react to Release Indication there will be a time-out in MSC after - seconds and a CM Service Reject with cause Network Failure is sent Possible cause: Low signal strength or high interference e Other reject causes Following reject causes have been seen: IMSI unknown to VLR IMEI not accepted Time-out on Layer 2: T200 expiration Counter: CNDROP, possibly CDISSS1 and CDISQA Cause: Low signal strength or high interference Error indication (Sequence Error) and Channel Release, abnormal release: unspecified Counter: CNDROP, possibly CDISSS1 and CDISQA Cause: A fault have occurred on the radio link layer (GSM 08.58) Radio link time-out Counter: CNDROP, possibly CDISSS1 and CDISQA Cause: Low signal strength or high interference MSC time-out Counter: None Cause: Low signal strength or high interference Unexpected Release Indication We can only guess why the mobile station behaves like this: it can be that the mobile station gets confused when the user is behaving strangely, faulty mobile station, etc a Abnormal Release, unspecified The behaviour is as case and the same counters are incremented b Release Indication after no response from mobile station, abnormal release unspecified In this case the mobile does not respond when it should In many cases no Setup message is received from the mobile station After ten seconds the mobile station is releasing the connection This will cause a radio link time-out (case 5) This is seen on Motorola M301, M400 and Flare E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc REPORT 12 (18) Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other) Nr - No ERA/LVR/PO Stephan Trzeciak LVR/PO-97:0148 Dokansv/Godk - Doc respons/Approved Kontr - Checked ERA/LVR/POC Datum - Date 1997-09-12 Rev File A c Release Indication SAPI 3, abnormal release unspecified The system sends an Establish Request SAPI to establish a SAPI link for sending an SMS If the mobile fails to reply on SABM the BTS sends Release Indication and Error Indication: Timer T200 The system responds to this by a Channel Release, abnormal release: unspecified This case can be caused by low signal strength or high interference Counters as in case d Normal release In some cases the Release Indication comes just before Location Update Accept In this case there will be a normal release and no counters are increased This means that the system thinks that the Location Update is successful when it in fact has failed Another case is when the MSC times out before there is a Radio Link Time-out which will cause a normal release See case 2.d for CM Service Reject after a Release Indication No counters are incremented No Assignment Command, abnormal release, unspecified Counters: CNDROP, possibly CDISSS1 and CDISQA a No Measurement Reports from mobile station Cause: Low signal strength or high interference b Congestion, no available channels Unsuccessful assignment to TCH, abnormal release unspecified Counters: CNDROP, possibly CDISSS1 and CDISQA Cause: Low signal strength or high interference a Assignment Failure is sent, abnormal release unspecified The assignment to TCH failed but the mobile station succeeded to return to the old SDCCH The system disconnects the call after a time-out and sends Channel Release with cause “abnormal release, unspecified” b Layer time-out on Assignment Command The mobile station does not send acknowledge on Layer 2, probably because of low signal strength or bad quality The mobile is lost c Mobile fails to return to old SDCCH, abnormal release unspecified The mobile receives the Assignment Command, fails to establish contact with TCH and finally fails to return to the old SDCCH The mobile is lost E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc REPORT 13 (18) Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other) Nr - No ERA/LVR/PO Stephan Trzeciak LVR/PO-97:0148 Dokansv/Godk - Doc respons/Approved Kontr - Checked ERA/LVR/POC 5.1.3 Datum - Date 1997-09-12 Rev File A Mobile test A live test was done to see what response different faults had in the system Nothing abnormal was found Ericsson 337 Power off during conversation Result: Normal release Battery removed during conversation Result: radio link time-out - TNDROP stepped Normal disconnection Result: Normal release Battery dead during conversation Result: radio link time-out - TNDROP stepped Battery dead during call set-up Result: layer time-out: T200 - TNDROP stepped Antenna removed Result: radio link time-out - TNDROP stepped AEG Normal disconnection Result: Normal release Power off during conversation Result: IMSI detach Battery removal Result: radio link time-out - TNDROP stepped Siemens Battery removal Result: radio link time-out - TNDROP stepped E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc REPORT 14 (18) Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other) Nr - No ERA/LVR/PO Stephan Trzeciak LVR/PO-97:0148 Dokansv/Godk - Doc respons/Approved Kontr - Checked ERA/LVR/POC Datum - Date 1997-09-12 Rev File A SUMMARY From the subscribers point of view, the most serious dropped calls are those that interrupts an ongoing conversation, i.e call dropped in TCH If the calls are dropped on SDCCH the user simply re-dials again and hopefully succeed with the new call set-up On the contrary, drops on SDCCH are more serious from a system point of view A radio link time-out on SDCCH will occupy an SDCCH sub-channel for (RLINKUP+RLINKT)/2 seconds and increase the risk for congestion 6.1 TCH Case 5, unsuccessful Assignment to TCH, is covered in chapter 6.2 “SDCCH” Case 7, is not discussed here as those drops are treated in the originating cell, but it can be said that these drops are caused by low signal strength or interference The different cases can be grouped together according to the reasons: A Case 1, and are most likely caused by low signal strength, interference or end of battery in the mobile station B Case could be caused by a faulty mobile station but as the amount of samples are very few, no conclusion can be drawn C Case is caused by a fault in the CME20 system 6.2 SDCCH The different cases can be grouped together according to the reasons: A Dropped calls according to case 1.a, 2.a, 3, 5, 6, 7.c, 8.a, 9.a, 9.b and 9.c are most likely caused by low signal strength, interference or end of power in the mobile station B Case 2.c and 7.b are probably caused by faulty behaviour in the mobile station C Case 2.d, 7.a, 7.b and 7.d are caused by a strange behaviour from the mobile station but does not necessary have to be a fault D 1.b and 2.e are normal and caused by faulty or unknown SIM E 2.b are normal and are only affecting the user for a limited amount of time E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc REPORT 15 (18) Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other) Nr - No ERA/LVR/PO Stephan Trzeciak LVR/PO-97:0148 Dokansv/Godk - Doc respons/Approved Kontr - Checked ERA/LVR/POC 6.3 Datum - Date 1997-09-12 Rev File A MOBILE STATION PROBLEMS In general, the mobile stations are working very well However, a small fragment of the dropped calls are due to strange mobile behaviour This was mainly seen on SDCCH where the signalling is more complex In case 2.c, the mobile station is sending CM Service Request (cause: mobile originating call) during the call set-up The system reacts to this by sending a CM Service Reject (cause: Message not compatible with call state) In some cases the mobile seems to accept the reject and the original call is continued In other cases the mobile disconnects the call with reason “user busy” This is seen on Motorola M300, M301, M400, Flare and Flare Refresh In case 7.b the mobile station does not send the Setup message Instead there is a Release indication after approximately 10 seconds This is seen on Motorola M301, M400 and Flare 6.4 STS ACCURACY One question was how well the STS counters are in accordance with the dropped calls How well the counters TDISSS1 and CDISSS1 are reflecting the reality is not investigated as this is very time consuming First one must define how a dropped call is perceived Is a rejected message a drop or not? The user maybe experiences it as a drop while it from a system point of view is not Is a unsuccessful Location update a drop? The user is usually not aware that the mobile station makes a Location update and does not know whether it was successful or not But from the system point of view an unsuccessful Location update can cause a longer occupation time on SDCCH than necessary 6.4.1 TCH Case and is not taken into consideration as case is affecting the SDCCH and case the counters in another cell All cases will step TNDROP This is what the system recognises as a drop The user does experience all cases except case 4, no answer on IMSI detach, as a drop E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc REPORT 16 (18) Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other) Nr - No ERA/LVR/PO Stephan Trzeciak LVR/PO-97:0148 Dokansv/Godk - Doc respons/Approved Kontr - Checked ERA/LVR/POC Datum - Date 1997-09-12 Rev File A System experienced drops Observed TNDROP 81 83 203 212 53 55 Table Table indicates that TNDROP corresponds well to dropped calls on TCH The difference is due to mismatch in Abis recording period and TNDROP period as there will be a gap in the recording every time a new log is started It is also possible that a few drops were missed during the analysis User experienced drops Observed TNDROP 77 83 202 212 51 55 Table Table shows that the user experienced drops is lower that TNDROP, maybe even lower then shown here as a drop during a normal disconnect phase will increment TNDROP but is not noticed by the subscriber 6.4.2 SDCCH If we look at the dropped calls from a system point of view, Location Update Reject, CM Service Reject and MSC time-out is not treated as a drop System experienced drops Observed CNDROP 86 85 607 621 300 303 Table The CNDROP corresponds well to the system experienced drops on SDCCH according to table The difference in the numbers are due to the same reasons as for TCH (table 2) But this does not correspond very well to how the subscriber perceives the call drops as MSC time-out and CM Service Reject not step CNDROP If this event is taken into account we have following numbers (Location Update Reject not included): E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc REPORT 17 (18) Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other) Nr - No ERA/LVR/PO Stephan Trzeciak LVR/PO-97:0148 Dokansv/Godk - Doc respons/Approved Kontr - Checked ERA/LVR/POC Datum - Date 1997-09-12 Rev File A User experienced drops Observed CNDROP 139 85 752 621 339 303 Table Table clearly shows that CNDROP is not reflecting the subscribers experience of dropped call very well As mentioned before, the subscriber is usually not aware about a Location Update Reject And this is not a big problem as the mobile will try again but of course this is a bit unnecessary and can be minimised by improving the cell plan and cell parameters POSSIBLE ENHANCEMENTS Following improvements can be done to make the CME20 system even better and the STS counters more in accordance with the actual dropped calls: TCH TNDROP is quite accurate already But the IMSI Detach message should trigger a normal release even if it is received before the Setup message SDCCH A Release Indication should always trigger a release even if it is unexpected A MSC time-out should increment the TNDROP and CNDROP It is also possible to increase the MSC time-out period by one or two seconds to get a Layer time-out or radio link time-out instead which will increment the drop counters Note that the MSC timers can not be set by command Counters for CM Service Reject and Location Update Reject could be introduced to get a more complete picture of the unsuccessful calls OTHER QLIMUL and QLIMDL could be set to a more accurate value For more information see ref E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc REPORT 18 (18) Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other) Nr - No ERA/LVR/PO Stephan Trzeciak LVR/PO-97:0148 Dokansv/Godk - Doc respons/Approved Kontr - Checked ERA/LVR/POC Datum - Date 1997-09-12 Rev File A SUMMARY In general the interwork between the CME20 system and the mobile stations is working very well The majority of the dropped calls are due to low signal strength, high interference or battery discharge in the mobile station That means that the part of the dropped calls that lacks reasons when the statistics are analysed usually is caused by battery discharge, which gives a fast drop without reason, low signal strength, but still above -104 dBm, or high interference The CME20 system is working very well Except for the fact that the system does not react on IMSI detach if received on TCH before Setup (which is very rare), no strange behaviour has been seen TNDROP is reflecting the reality very well, but CNDROP can be improved Note that CNDROP is sensitive to the parameter settings in the MSC and then of course also to different MSC types (Ericsson, Siemens, etc.) Some strange behaviour from mobile stations has been noticed But not very serious ditto This is not very common and seems to be of a type that just happens occasionally REFERENCES 1/100 56-FCU 144 01 Uen Rev A - Engineering guidelines, Locating E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements\dropped call report\970148a.doc [...]... Rev File A SUMMARY From the subscribers point of view, the most serious dropped calls are those that interrupts an ongoing conversation, i.e call dropped in TCH If the calls are dropped on SDCCH the user simply re-dials again and hopefully succeed with the new call set-up On the contrary, drops on SDCCH are more serious from a system point of view A radio link time-out on SDCCH will occupy an SDCCH... statistics&measurements \dropped call report\970148a.doc REPORT 14 (18) Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other) Nr - No ERA/LVR/PO Stephan Trzeciak LVR/PO-97:0148 Dokansv/Godk - Doc respons/Approved Kontr - Checked ERA/LVR/POC 6 Datum - Date 1997-09-12 Rev File A SUMMARY From the subscribers point of view, the most serious dropped calls are those that interrupts... However, a small fragment of the dropped calls are due to strange mobile behaviour This was mainly seen on SDCCH where the signalling is more complex In case 2.c, the mobile station is sending CM Service Request (cause: mobile originating call) during the call set-up The system reacts to this by sending a CM Service Reject (cause: Message not compatible with call state) In some cases the mobile seems... Motorola M301, M400 and Flare 6.4 STS ACCURACY One question was how well the STS counters are in accordance with the dropped calls How well the counters TDISSS1 and CDISSS1 are reflecting the reality is not investigated as this is very time consuming First one must define how a dropped call is perceived Is a rejected message a drop or not? The user maybe experiences it as a drop while it from a system... File A SUMMARY In general the interwork between the CME20 system and the mobile stations is working very well The majority of the dropped calls are due to low signal strength, high interference or battery discharge in the mobile station That means that the part of the dropped calls that lacks reasons when the statistics are analysed usually is caused by battery discharge, which gives a fast drop without... 2) But this does not correspond very well to how the subscriber perceives the call drops as MSC time-out and CM Service Reject do not step CNDROP If this event is taken into account we have following numbers (Location Update Reject not included): E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements \dropped call report\970148a.doc REPORT 17 (18) Uppgjord (även faktaansvarig om annan)... Service Reject and Location Update Reject could be introduced to get a more complete picture of the unsuccessful calls OTHER QLIMUL and QLIMDL could be set to a more accurate value For more information see ref 1 E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements \dropped call report\970148a.doc REPORT 18 (18) Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible... statistics&measurements \dropped call report\970148a.doc REPORT 15 (18) Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other) Nr - No ERA/LVR/PO Stephan Trzeciak LVR/PO-97:0148 Dokansv/Godk - Doc respons/Approved Kontr - Checked ERA/LVR/POC 6.3 Datum - Date 1997-09-12 Rev File A MOBILE STATION PROBLEMS In general, the mobile stations are working very well However, a small fragment of the dropped. .. as the amount of samples are very few, no conclusion can be drawn C Case 4 is caused by a fault in the CME20 system 6.2 SDCCH The different cases can be grouped together according to the reasons: A Dropped calls according to case 1.a, 2.a, 3, 5, 6, 7.c, 8.a, 9.a, 9.b and 9.c are most likely caused by low signal strength, interference or end of power in the mobile station B Case 2.c and 7.b are probably... This is what the system recognises as a drop The user does experience all cases except case 4, no answer on IMSI detach, as a drop E:\cdpo\npi tools&guideline\1-guidelines\1.5 statistics&measurements \dropped call report\970148a.doc REPORT 16 (18) Uppgjord (även faktaansvarig om annan) - Prepared (also subject responsible if other) Nr - No ERA/LVR/PO Stephan Trzeciak LVR/PO-97:0148 Dokansv/Godk - Doc respons/Approved