SUCCESS AND FAILURE RATES
2.9 CORE NETWORK HARD HANDOVER
2.9.1 INTRA-MSC AND INTER-MSC HARD HANDOVER (3G-3G)
Intra-frequency hard handover becomes necessary if inter-RNC handover needs to be performed, but there is no Iur interface available between the source and target RNC. In such cases (no Iur) each inter-RNC intra-frequency handover must inevitably be a hard handover although the target cell is working on the same frequency as the source cell. If there is no Iur interface the target RNC cannot act as a drift RNC and lend its radio resources to the SRNC. Hence, the target RNC needs to become the SRNC immediately.
Inter-RNC intra-frequency hard handovers are triggered by the same measurement report event-IDs as softer and soft handover radio link additions: 1A. In addition (also true for softer and soft handover) event-ID 1E needs to be considered as another possible trigger if the new strong cell belongs to the detected set and has not been part of the neighbour cell information list sent to the UE by the SRNC.
For performance measurement software it is a problem that it only monitors if an RNC receives an RRC measurement report containing event-ID 1A for a cell identified by primary scrambling codeẳ52. Due to the fact that there is a maximum of only 512 different primary scrambling codes it is possible that PSCẳ52 could be used e.g. five times for cells controlled by the same RNC. One of these five cells is the target cell of the handover procedure, but as long as there is no NBAP Radio Link Setup Request for this cell monitored the performance measurement software can only guess identity of this cell. So how does the RNC know the unique identity of the target cell if there are five options?
For each cell controlled by the RNC a neighbour cell list needs to be manually configured.
This neighbour cell list not only contains the primary scrambling codes as monitored on the Iub interface in RRC measurement messages, but also detailed information of each cell that allows message routing to the target RNC in the case of inter-MSC handover. The full neighbour parameter list can only be monitored on the Iur interface during the RNSAP radio link setup procedure as shown in message example 2.14.
Message example 2.14RNSAP radio link setup response including neighbour cell info list
| ID Name | Comment or Value |
| UMTS RNSAP acc. R99 TS 25.423 ver. 3.7.0 (RNSAP370) successfulOutcome |
| rnsapPDU |
| 1successfulOutcome |
| 1.1 procedureID |
| 1.1.1 procedureCode |id-radioLinkSetup |
| 1.4.1.4.3.1.3.14 neighbouring-UMTS-CellInformation |
| 1.4.1.4.3.1.3.14.1 sequenceOf |
| 1.4.1.4.3.1.3.14.1.1 id | id-Neighbouring-UMTS-CellInformat. . . |
| 1.4.1.4.3.1.3.14.1.2 criticality | ignore |
| 1.4.1.4.3.1.3.14.1.3 value |
| 1.4.1.4.3.1.3.14.1.3.1 rNC-ID | 124 |
| 1.4.1.4.3.1.3.14.1.3.2 neighbouring-FDD-CellInformation |
| 1.4.1.4.3.1.3.14.1.3.2.1 neighbouring-FDD-CellInformationItem |
| 1.4.1.4.3.1.3.14.1.3.2.1.1 c-ID |15009 |
| 1.4.1.4.3.1.3.14.1.3.2.1.2 uARFCNforNu | 9762 |
As can be seen in the message example there are three different cells controlled by RNC 124 listed using their c-ID (as used in NBAP and RNSAP signalling) plus their primary scrambling codes. Having RNC-ID and c-ID each cell is identified uniquely. Appropriate routing information for transmission of handover request messages is easy to derive from RNC-internal routing tables for handover/relo- cation scenarios when the RRC measurement report containing only PSC value is received.
The most common variant of intra-frequency hard handover is 3G-3G inter-MSC hand- over triggered by event-ID 1A if it is detected that the target cell reported together with event-ID is controlled by an RNC connected to a different MSC than the current SRNC.
There is no chance of performing a radio link addition, because usually in this case there is no Iur interface between the SRNC (source RNC) and the target RNC. Instead the SRNC decides – based on information found in the cell neighbour list and routing tables – to start an RANAP relocation/handover procedure.
A relocation is a special type of handover that is characterised by changing the serving cell of the radio connection plus re-routing of bearers for signalling and user data transport to the new serving cell.
A relocation/handover procedure is executed in four major steps (no matter how many signalling messages are involved in each step in detail). Figure 2.36 shows these steps for intra-MSC hard handover/relocation for reasons of graphical simplicity. If another MSC Message example 2.14(Continued)
| ID Name | Comment or Value |
| 1.4.1.4.3.1.3.14.1.3.2.1.3 uARFCNforNd | 10712 |
| 1.4.1.4.3.1.3.14.1.3.2.1.4primaryScramblin.. |77 |
| 1.4.1.4.3.1.3.14.1.3.2.1.5 primaryCPICH-Power | 314 |
| 1.4.1.4.3.1.3.14.1.3.2.1.6 cellIndividualOf.. | 0 |
| 1.4.1.4.3.1.3.14.1.3.2.1.7 txDiversityIndic.. | false |
| 1.4.1.4.3.1.3.14.1.3.2.2 neighbouring-FDD-CellInformationItem |
| 1.4.1.4.3.1.3.14.1.3.2.1.1c-ID |15006 |
| 1.4.1.4.3.1.3.14.1.3.2.1.2 uARFCNforNu | 9762 |
| 1.4.1.4.3.1.3.14.1.3.2.1.3 uARFCNforNd | 10712 |
| 1.4.1.4.3.1.3.14.1.3.2.1.4primaryScramblin.. |96 |
| 1.4.1.4.3.1.3.14.1.3.2.!.5 primaryCPICH-Power | 316 |
| 1.4.1.4.3.1.3.14.1.3.2.1.6 cellIndividualOf.. | 0 |
| 1.4.1.4.3.1.3.14.1.3.2.!.7 txDiversityIndic.. | false |
| 1.4.1.4.3.1.3.14.1.3.2.3 neighbouring-FDD-CellInformationItem |
| 1.4.1.4.3.1.3.14.1.3.2.3.1c-ID |14259 |
| 1.4.1.4.3.1.3.14.1.3.2.3.2 uARFCNforNu | 9762 |
| 1.4.1.4.3.1.3.14.1.3.2.3.3 uARFCNforNd | 10712 |
| 1.4.1.4.3.1.3.14.1.3.2.3.4primaryScramblin.. |100 |
| 1.4.1.4.3.1.3.14.1.3.2.3.5 primaryCPICH-Power | 317 |
| 1.4.1.4.3.1.3.14.1.3.2.3.6 cellIndividualOf.. | 0 |
| 1.4.1.4.3.1.3.14.1.3.2.3.7 txDiversityIndic.. | false |
(inter-MSC handover) is involved this second MSC is located between the shown MSC and the target RNC and an imaginary handover request as well as a handover command are transparently routed through this additional network element. The relocation of transport bearers is only performed on lu and Iub interfaces. The originally serving MSC of the call remains the anchor MSC of the call and continues to control the call link towards the gateway MSC (GMSC) after successful handover/relocation.
The procedure starts with an RRC measurement report (1). Following this the SRNC sends a handover message request to the target RNC (2). This handover message request is of ‘imaginary’ nature, because it is not directly visible in the RANAP signalling messages.
Two different IuCS interfaces and two different RANAP procedures are involved. On the old IuCS the handover message request is ‘hidden’ in the Relocation Required message, on the target IuCS the handover request is forwarded using the RANAP Relocation Request.
Note: 3GPP standard documents use message names in procedure descriptions, but these messages are encoded using ASN.1. Looking at ASN.1 only four different RANAP message codes exist: Initiating Message, Successful Outcome, Outcome and Unsuccessful Outcome.
These message codes are combined with different procedure codes. Each message name used Figure 2.36 Abstract steps of intra-frequency handover/relocation
in 3GPP specifications has its unique ASN.1 message code/procedure code combination.
Hence, RANAP Relocation Required message is encoded as RANAP InitiatingMessage (ProcedureCode: RelocationPreparation). This principle is also valid for other UTRAN protocols. In message example 2.14, for instance, RNSAP Radio Link Setup Response message is presented, which is encoded as RNSAP SuccessfulOutcome (ProcedureCode:
Radio Link Setup).
From the ‘imaginary’ request coming from the SRNC the target RNC constructs a handover command message to be sent to the UE. However, the target RNC does not have a radio connection with the UE – but the SRNC has! Following this, the handover command (which is the previously requested handover message) is sent via the MSC, SRNC and source cell to the UE, because this is the only available radio con- nection (3).
Typically for Intra-frequency hard handover this handover command message is an RRC Physical Channel Reconfiguration Request containing new codes to be used for the radio link in the target cell and additional new identifiers such as a new u-RNTI, which will change due to the fact that the SRNC of connection will change.
After the UE has received the hard handover command message (e.g. RRC Physical Channel Reconfiguration Request) it starts to send/receive data using configuration parameters received in this message. For successful reconfiguration the UE sends the handover complete message (e.g. RRC Physical Channel Reconfiguration Complete message) via the new cell/new Iub to the target RNC. At the target RNC, which has now become the new SRNC of the connection, the loop between the handover command and handover complete is closed and from the point of view of the radio connection handover was successful. There is just one more thing to do: the transport resources on the previously used interfaces (old IuCS, old Iub) need to be deleted as well as all call- specific information in RNC and MSC protocol entities. This information to be deleted includes all the parameters of the RRC context of the UE and assigned (and now suc- cessfully relocated) RABs.
To delete the RRC context and RABs in the old SRNC the feedback of successfully completed handover (4) is delivered by the target RNC (new SRNC) to the core network element (MSC) and from core network back to source RNC (old SRNC). Once again RANAP messages are used to forward this information and subsequently radio links in the old cell are deleted as well as RABs.
Regarding the processing time of NBAP radio link deletion the same problem as already described in for inter-frequency handovers is true: if it takes too long until the old SRNC starts NBAP radio link deletion triggered by feedback about successful relocation the source cell will complain by sending NBAP Radio Link Failure Indication that contact with the UE has been lost. On the other hand the same risk exists that the UE is really lost due to the handover attempt and the handover complete message is not monitored on the new lub.
The RAB is released and performs the RANAP Iu-Release procedure. An appropriate release cause used in this procedure following a successful handover is ‘successful relo- cation’. In the past it was observed that some NEM implemented cause value ‘normal release’, but this is not compliant with 3GPP standards, because ‘normal release’ belongs to the group of NAS causes that should only be used if an NAS protocol event (e.g. Call
Control DISCONNECT) is the reason for terminating an active connection. A relocation/
handover is a radio network related procedure, because it is performed due to the mobility of the UE. Following this the radio network layer cause ‘successful relocation’ must be used in an appropriate Iu-Release procedure.
All details of the procedure are now known and protocol event counters and KPI formulas can be defined, but there are different approaches. On the one hand it is possible to define easy success rates for the procedure using the following protocol events:
InFHHO_Attempt: RANAP Relocation Required containing sourceRNC-to-targetRNC- transparent-container. This container is used to transmit necessary RRC context parameters from source to target RNC and as explained in the next section a similar container for inter-RAT handover looks completely different. Hence, based on the existence of this transparent container 3G-3G handover/relocation can be identified easily.
Note: The same sourceRNC-to-targetRNC-transparent-container can also be used for 3G_Intra-/Inter-MSC inter-frequency handover – if the target cell is working on a different UTRAN frequency than the source cell. If such a handover is possible in the network (depends on network architecture) separate counters for intra- and inter- frequency handover switching in the core network can be defined by checking the event-IDs in the RRC measurement report that triggered the sending of RANAP Relocation Required or are based on the check of uARFCN values provided by the active set tracking the background application (as discussed in the section about inter-frequency handover).
InFHHO_Success: an overall success rate KPI RANAP Iu-Release Command including cause value ‘successful relocation‘ can be seen as a good success event, because on the one hand following the reception of this message the RNC will delete all resources related to included RAB-IDs and on the other hand monitoring this message indicates that hard handover/relocation to target cell/RNC has been successful without any doubt. In the (unlikely) case that the SRNC has some problems relaeasing the old RABs and related radio resources this will not have any impact on the active connection between the UE and the network.
InFHHO_Failure_UE: any RRC Reconfiguration Failure message sent as response to RRC Reconfiguration Request (used as handover command message) must be seen as a failure indication from the UE side.
InFHHO_RL_Failure: if the UE loses contact with the network after it has received the handover command an NBAP Radio Link Failure Indication is expected to be monitored whileInFHHO_Successevent is missed. Due to the possibility that an NBAP Radio Link Failure Indication may also be sent in the case of successful handover it is necessary to perform a careful check to see if this message indicates a failure event or not. If NBAP Radio Link Failure Indication is monitored for a UE that has already received a handover command (Attempt) it needs to be checked if RAB(s) related to this UE have already been ordered to be deleted by the MSC using RANAP Iu-Release (causeẳ‘successful relocation’). If RANAP Iu-Release has not been monitored a timer needs to be started to check if the success event is monitored within a certain time frame. Otherwise handover is considered to have failed and subsequently it needs to be considered to drop the call, too.
Formulas are easily defined:
InFHHO Success Rateẳ
PInFHHO Success
PInFHHO Attempt100% ð2:17ị
InFHHO Failure Rateẳ
PðInFHHO Failure UEỵInFHHO RL Failureị
PInFHHO Attempt 100% ð2:18ị