10 wcdma rno drop call analysis

00 2010-8-252010-8-25

Drop-call AnalysisDrop-call Analysis

11 2010-8-252010-8-25

� Analysis procedure� Neighbor list analysis� Coverage analysis� Handover analysis� Signaling analysis


22 2010-8-252010-8-25

analysis procedureanalysis procedure

• Drive test tools:– Qualcomm test UE/Moto A835 test UE– Agilent scanner 6455c – Agilent 6474A software

• Post processing tools:– ACTIX Analyzer V2.0

33 2010-8-252010-8-25


• Drop call event definition:

44 2010-8-252010-8-25


• Drop call analysis procedure

55 2010-8-252010-8-25


• 1. To get the information about:– the place of the drop call,

– in the edge of the 3G coverage or not– which 3G cells related

– the distance between related 3G cells and the drop call point

– which 3G cell the call dropped on.

66 2010-8-252010-8-25


• 2.To analyze Neighbor list:– to find out any cell not defined in the neighbor list.– the best serving 3G cell before the call dropped– the best serving 3G/2G cell after the call dropped– the existing neighbor list of the best serving 3G cell

• intra-freq HO neighbor list • inter-freq HO neighbor list • inter-RAT HO neighbor list

77 2010-8-252010-8-25


• 3. To analyze the coverage:– the pilot coverage

• CPICH transmission power• Coverage limited• System interference• Poor uplink coverage• Poor downlink coverage• pilot pollution

88 2010-8-252010-8-25


• 3. To analyze the coverage:– the service coverage

• Service related Maximum downlink transmission power

• SIR before the call dropped• Max uplink transmission power allowed for UE• Actual uplink transmission power before the call

dropped

99 2010-8-252010-8-25


• 4. To analyze the handover:– the signal change

• Source cell• Target cell

– insufficient handover area• Too late to add new cell• Too early to delete old cell

– ping-pang handover

1010 2010-8-252010-8-25


• 5. To analyze the signaling:– for confused drop call

– signaling in UE side in conjunction with signaling in network side

– Different interface: Iu, Iub, Iur, Uu– Different layer: NAS, RRC

1111 2010-8-252010-8-25



1212 2010-8-252010-8-25

Neighbor list analysisNeighbor list analysis

• There maybe missing neighbor if the best serving cell is not the same one before and after the call dropped.

• Before the call dropped, the best serving cell maybe not the signal strongest cell

• Before the call dropped, the best serving cell should be picked out by the latest measurement control message and corresponding 1d event measurement report.

1313 2010-8-252010-8-25


• Compare the scanner data with UE data– prior to the drop, the CPICH Ec/Io (and

CPICH RSCP) degrades for UE ONLY while scanner shows no degradation

– prior to the drop, the best server for the UE is not the same as that of the scanner

1414 2010-8-252010-8-25


• Dropcall position

1515 2010-8-252010-8-25


• Active set and monitor set information

1616 2010-8-252010-8-25


• Radio parameters information

1717 2010-8-252010-8-25


• CPICH EcIo Compare between scanner and UE

1818 2010-8-252010-8-25


• CPICH RSCP compare between scanner and UE

1919 2010-8-252010-8-25


• SC compare between scanner and UE

2020 2010-8-252010-8-25


• The measurement control message from cell SC358

measurement control_sc358

• Conclusion: cell SC364 should be defined in the neighbor list of cell SC358 to avoid the dropcall in this place

2121 2010-8-252010-8-25



2222 2010-8-252010-8-25

Coverage analysisCoverage analysis

• System Interference:– Both scanner and UE, the signal strongest cell – CPICH_EcNo_in_ActiveSet < -15 dB – And, CPICH_RSCP_in_ActiveSet > -80 dBm

• Poor Uplink Coverage:– Both scanner and UE– CPICH_EcNo_in_ActiveSet > -15 dB– And, CPICH_RSCP_in_ActiveSet > -95 dBm– And, UeTransmittedPower > 15 dBm

2323 2010-8-252010-8-25


• Poor Downlink Coverage: – Both scanner and UE , the signal strongest cell – CPICH_EcNo_in_ActiveSet < -15 dB– And, CPICH_RSCP_in_ActiveSet < -95 dBm– And, UeTransmittedPower < -15 dBm.

• Coverage Limited– Both scanner and UE , the signal strongest cell – CPICH_EcNo_in_ActiveSet < -15 dB– And, CPICH_RSCP_in_ActiveSet < -95 dBm– And, UeTransmittedPower > 10 dBm.

2424 2010-8-252010-8-25


• Pilot pollution:– 4 or more pilots with their Ec/No above -15 dB

are in the active or monitored set

2525 2010-8-252010-8-25


• To analyze the coverage, need to– Analyze the pilot coverage in conjunction with

the service coverage– Analyze the uplink coverage in conjunction

with the downlink coverage

– Analyze the scanner data in conjunction with the UE data

– Analyze the CPICH RSCP in conjunction with CPICH Ec/Io, SC

2626 2010-8-252010-8-25


• Dropcall position

2727 2010-8-252010-8-25


• Active set and monitor set information

2828 2010-8-252010-8-25


• Radio parameters information

2929 2010-8-252010-8-25


• CPICH Ec/Io

3030 2010-8-252010-8-25


• CPICH RSCP

3131 2010-8-252010-8-25



3232 2010-8-252010-8-25

Handover analysisHandover analysis

• Handover type:– Intra-freq HO

– Inter-freq HO– Inter-RAT HO

• insufficient handover area• ping-pang handover

3333 2010-8-252010-8-25


• Signal strength change

3434 2010-8-252010-8-25

Drop calls and scrambling code plot• Scanner Best Server

Scrambling Code plot

It shows that drop call 1 occurred at an area of frequent change of best server as shown by the scanner scrambling code plot


3535 2010-8-252010-8-25

Drop Call Number 1 (with Ec/Io from scanner & UE at time of drop)

Drop Call 1 (UE vs. scanner best server)


3636 2010-8-252010-8-25

• compare Ec/Io from both scanner and UE at the time of the drop: – the UE Ec/Io to drop to < -21 dB while the scanner

remained above -11 dB.

• Comparing the best servers from the UE and the scanner at the time of drop: – for the scanner and UE SC008 is the best server prior

to the drop. However, about 30 seconds before the drop, the scanner selected SC018 as the best server while the UE continued to have only SC009 in its active set resulting in the drop call. Immediately after the drop, the UE camps on SC018.


3737 2010-8-252010-8-25

Drop Call Number 1 (Active & monitored sets at time of drop)


3838 2010-8-252010-8-25

• Examining the UE Active and Monitored set: – does not show SC018 to be measured by the UE

prior to the drop. This scenario resembles a missing neighbour problem, although in this case the two cells in question are neighboured.

• It seems that the best server’s changes from SC009 to SC011 and then to SC018 were too fast for this UE to perform soft handoff on time. Although, other UEs may have succeeded in performing soft handoff in such conditions, it is important to improve the cell dominance in the affected area.


3939 2010-8-252010-8-25

RSCP coverage from SC018– at the location of the

drop, SC018 should not be the best server...

– the cell’s is extending into a large area. E.g. around the location of drop call, SC018 RSCP is > -75dBm

– Cell SC018 clearly requires some down tilting to control its interference into the area of Drop 1


4040 2010-8-252010-8-25

• Drop Call 1 Summary: – The drop call appears to be associated with

unnecessary change of best servers caused by excessive dominance of SC018. To improve the dominance in the affected area, SC018 should be considered for downtilting


4141 2010-8-252010-8-25



4242 2010-8-252010-8-25

Signaling analysisSignaling analysis

• CS Normal release procedure

4343 2010-8-252010-8-25


• 1.UE sends message “RRC_UL_DIR_TRANSF” to RNC，IE ”nas message” is 0325，means “disconnect”message of call control sublayer in NAS layer。

• 2.RNC sends message “RANAP_DIRECT_TRANSFER”to CN，IE ”nas message” is 0325，means “disconnect”message of call control sublayer in NAS layer。

• 3. CN sends message “RANAP_DIRECT_TRANSFER”to RNC，IE ”nas PDU” is 832d，means “release”message of call control sublayer in NAS layer。

• 4.RNC sends message “RRC_DL_DIRECT_TRANSF” to UE，IE ”nas PDU” is 832d，means “release” message of call control sublayer in NAS layer。

4444 2010-8-252010-8-25


• 5.UE sends message “RRC_UL_DIR_TRANSF” to RNC，IE ”nas PDU” is 032a，means “release complete”message of call control sublayer in NAS layer。

• 6. RNC sends message “RANAP_DIRECT_TRANSFER”to CN，means “release complete” message of call control sublayer in NAS layer。

• 7.CN sends message “RANAP_IU_RELEASE_COMMAND” to RNC，start release Iu interface resource。

• 8. RNC sends message “RANAP_IU_RELEASE_COMPLETE” to CN。

4545 2010-8-252010-8-25


• 9.RNC sends message “RRC_RRC_CONN_REL” to UE，start release RRC connection。

• 10. UE sends message “RRC_RRC_CONN_REL_CMP” to RNC。

• 11.RNC sends message “NBAP_RL_DEL_REQ”to Node B，start release Iub interface resource。

• 12. Node B sends message “NBAP_RL_DEL_RSP” to RNC，end the whole release procedure。

4646 2010-8-252010-8-25


• PS normal release procedure

4747 2010-8-252010-8-25


• 1.UE sends message “RRC_UL_DIR_TRANSF” to RNC，IE “nasmessage” is 0a46, indicates message “deactivate PDP context request” in session management sublayer.

• 2.RNC sends message “RANAP_DIRECT_TRANSFER” to CN，IE “nas pdu” is 0a46, indicates message “deactivate PDP context request “ in session management sublayer

• 3. CN sends message “RANAP_DIRECT_TRANSFER” to RNC, IE “nas pdu” is 8a47, indicates message “deactivate PDP context accept” in session management sublayer.

• 4. CN send message “RANAP_RAB_ASSIGNMENT_REQ” to RNC, IE “RAB list” including RAB ID to point out which RAB need to be released.

4848 2010-8-252010-8-25


• 5. RNC sends message “RRC_DL_DIRECT_TRANSF” to UE, IE ”nasmessage” is 8a47, indicates message “deactivate PDP context accept” in session management sublayer.

• 6. RNC send message “NBAP_RL_RECFG_PREP” to NODEB

• 7. NODEB send message “NBAP_RL_RECFG_READY” to RNC

• 8. RNC send message “RRC_RB_REL” to UE, start to release RB

4949 2010-8-252010-8-25


• 9. NODEB sends message “NBAP_RL_RECFG_COMMIT” to RNC

• 10. UE sends message “RRC_RB_REL_CMP “ to RNC, indicates the traffic RB release completed

• 11. RNC sends message “RANAP_RAB_ASSIGNMENT_RESP” to CN, indicates the RAB release completed

• 12. CN send message “RANAP_IU_RELEASE_COMMAND” to RNC, start to release Iu resource: RANAP layer resource and ALCAP layer resource

5050 2010-8-252010-8-25


• 13. RNC send message “RANAP_IU_RELEASE_COMPLETE” to RNC

• 14.RNC send message “RRC_RRC_CONN_REL” to UE, start to release RRC connection

• 15. UE send message “RRC_RRC_CONN_REL_CMP”to RNC

• 16.RNC send message “NBAP_RL_DEL_REQ” to NODEB, start to release Iub resource: NBAP layer resource, ALCAP layer, and PHY layer

• 17. NODEB send message “NBAP_RL_DEL_RSP” to RNC, the whole release procedure completed

5151 2010-8-252010-8-25


• compare with the CS release procedure:– PS Step1~3 is corresponding to CS step 1~6,

to release NAS– step4～11 are special for PS

– PS step12～17 is the same as the CS step7～12

5252 2010-8-252010-8-25

• If RSCP & Ec/Io degrades before drop for BOTH scanner and UE then check for coverage problems

• If prior to the drop, the Ec/Io (and RSCP) degrades for UE ONLY while scanner shows no degradation, then the following checks should be made:

– Is the best server for the UE is the same as that of the scanner? (If not, its possible that the UE failed to perform soft handoff)

– Does UE camp on new cell immediately after drop?– If the UE camps on a new cell after the drop, was that cell

neighboured to the previous cell? (if not, consider adding thisneighbour)

– Was the UE measuring this neighbour?– Were there too many and too quick changes of best server

making it difficult for UE to perform measurements and SHO in time. (if this is the case: improve cell dominance through antenna optimisation)


5353 2010-8-252010-8-25

• Does the UE Tx power increase to max prior to dropping call while Ec/Io level remains good?– If the Tx power increase is gradual and UE is far from

site the failure is due to uplink coverage limitation– If the increase is sudden and UE may be not be too

far from site - Check uplink load from SIB7 following drop call – is it unusually high?

• If uplink load is reported to be high, confirm from network stats that the high load is due to genuine traffic – otherwise check for a possible site fault

• If uplink load is not high, problem could be due to possible power control failure.


5454 2010-8-252010-8-25

• If the above steps do not reveal the causes of the drop calls then analysis of the messages should be carried out to determine the sequence of events prior to the drop call.

• If the drop call does not appear to be RF related and the RF conditions at the location of the drop appear to be good then no further work is needed as part of the RF Optimisation.

• However, exact location of the drop should be marked for later comparisons with future drive surveys (if un-explained drops keep occurring at the same location, more detailed investigation will be required to establish the exact causes).


5555 2010-8-252010-8-25

10 wcdma rno drop call analysis

Documents

coverage analysis cpich

coverage analysis cpich

neighbor list analysis

handover analysis sc

coverage analysis active

g coverage

neighbor list of cell

ue cpich