If a closer look is taken at what is usually called soft handover it becomes clear that basically there are two different partial procedures belonging to a soft handover. These procedures are called radio link addition and radio link deletion. In the case of radio link addition a new radio link is added to the active set, in the case of radio link deletion a radio link is removed from the current active set of a UE. There is also a special case called radio link substitution (as a rule triggered by reporting RRC measurement event 1C), which means that following a single event-triggered measurement report the worst radio link of an active set is removed while subsequently a better quality radio link is added to the active set of the UE.
Usually RRC protocol messages are seen as events related to these procedures. These messages are RRC Active Set Update Request that indicates a soft handover attempt, RRC Active Set Update Complete that indicates soft handover success and RRC Active Set Update Failure that indicates failed radio link addition. For radio link deletion no dedicated failure event is defined. It is subject of definition if no answer from UE to RRC Active Set Update perviously sent by SRNC must be seen as a failure event. In this case typically the same RRC Active Set Update message is sent again after expiry of a timer on RNC side. The repeated RRC Active Set Update message can be distinguished from the previous one on behalf of its different RRC transaction identifier value.
In RRC Active Set Update Request the message sequences rl-AdditionInformationList and rl-RemovalInformationList are used to determine cases of radio link addition and radio link deletion. The appropriate cell related to these procedures is named by its primary scrambling code as shown in message example 2.13.
Message example 2.13RRC Active Set Update Request for soft handover radio link deletion
| TS 29.331 DCCH-DL (2002-03) (RRC_DCCH_DL) activeSetUpdate (ẳactiveSetUpdate) |
| dL-DCCH-Message |
| 2 message |
| 2.1activeSetUpdate |
| 2.1.1 r3 |
| 2.1.1.1 activeSetUpdate-r3 |
| ***b2*** | 2.1.1.1.1 rrc-TransactionIdentifier | 0 |
| -1001010 | 2.1.1.1.2 maxAllowedUL-TX-Power | 24 |
| 2.1.1.1.3rl-RemovalInformationList |
| 2.1.1.1.3.1 primaryCPICH-Info |
| ***b9*** | 2.1.1.1.3.1.1primaryScramblingCode |426 |
RRC Active Set Update Complete does not contain any specific information element. It is the task of the call trace module to filter out RRC messages belonging to the same connection.
In the case of a failed radio link addition the UE will reply with RRC Active Set Update Failure and this message will contain a failure cause value. The occurrence of different failure cause values can be counted using a separate counter for each possible failure cause. Figure 2.30 gives an overview of soft handover analysis as also defined in 3GPP 32.403.
As long as only communication between UE and SRNC is analysed these events are sufficient, but from the above overview two major problems can be identified if there is a need for a more detailed analysis:
1. RRC protocol events do not allow to determine if the performed handover is:
(a) a softer handover;
(b) an intra-RNC soft handover; or
(c) an inter-RNC soft handover involving the Iur interface.
2. If the soft handover procedure has (already) failed before the SRNC sends any RRC message, e.g. due to problems in the NBAP or ALCAP protocol layer, this will not be reflected by the counter defined in the above scheme. In other words: only soft handover failures caused by the UE and radio transmission conditions in cell will be counted, not soft handover failures caused by UTRAN.
Figure 2.31 illustrates the intra-RNC soft handover procedure and highlights the com- munication that takes place between different protocol entities of the involved network elements including the UE.
Looking at this figure it can be seen that soft handover is not just a single protocol pro- cedure, but rather a complex pattern of different signalling procedures between network elements that interact to perform the handover.
In the first step the UE sends an RRC measurement report indicating that the measured CPICH Ec/N0 value of Cell 2 has entered the reporting range, which means that the RNC is asked to initiate soft handover. While the UE sends this measurement report its radio signal is not only received by Cell 1 but also by Cell 2, however, from the point of view of Cell 2 this signal is still part of the noise/interference in the uplink frequency band, because the cell has not been ordered to decode this UE’s signal.
In the second step the RNC starts the soft handover procedure by performing the NBAP radio link setup procedure towards Cell 2. During this procedure Cell 2 is ordered to decode the UE’s radio signal identified by the UE’s uplink scrambling code. Once the cell has found this uplink channel it sends an NBAP Radio Link Restore Indication message to the RNC.
Figure 2.30 Overview of soft handover protocol events
Figure 2.31 Intra-RNC soft handover procedure
In addition, Cell 2 starts to send the downlink dedicated physical channel (DPCH) of the new radio link. However, this DL DPCH cannot be decoded by the UE, because the UE still does not know downlink channelisation code of new radio link.
The downlink channelisation code and primary scrambling code of the new cell, which has already sent the downlink DPCH, are now transmitted to the UE by the RNC using the RRC Active Set Update Request message. After receiving this message the UE adds a new radio link to its active set and starts to decode the DPCH sent by Cell 2. To confirm that radio link addition on the UE side has been successful the UE sends an RRC Active Set Update Complete message, which is usually seen as a soft handover success event by per- formance measurement software. Due to the special nature of radio transmission in soft handover situation, transport blocks containing portions of the RRC Active Set Update Complete message are transmitted using both uplink dedicated physical (data) channels (DPDCH) simultaneously. By performing macro-diversity combining the RNC will delete duplicated transport blocks and reassemble the single RRC Active Set Update Complete message as sent by the UE. The dotted line used in step 3 of Figure 2.31 visualises this process.
It is important to know that there is no rule that NBAP Radio Link Restore Indication will always be monitored before RRC Active Set Update Complete, because synchronisation processes necessary to send/receive radio signals in a proper manner are running indepen- dently from each other on uplink and downlink physical channels. Hence, it is also possible that RRC Active Set Update Complete is received before NBAP Radio Link Restore Indication, but in this case transport blocks that carry RRC messages are only monitored on the Iub interface of Cell 1.
Finally it must be taken into account that similar rules apply to soft handover radio link removal. Here the RRC active set update procedure is executed before NBAP radio link deletion. Hence, as a rule the UE stops to receive the DL physical channel earlier than the cell stops to receive the UL signal of the UE. As a result it can be expected that on Iub of the cell that is already deleted from the UE’s active set there are still some uplink transport blocks that can be monitored for which macro-diversity filtering rules apply and that may have an impact on UL BLER measurement results as well as being used to reassemble higher layer messages.
Now it is a question of definition which message is seen as an initial soft handover attempt.
The RRC measurement report including event-ID is a good candidate, but there is one limitation. In the case that these reports are sent periodically instead of event-triggered (no event-ID included in message) it is very difficult to identify which measurement report should have triggered the start of the handover procedure that is executed and controlled by the SRNC. To detect a potentially soft handover situation that has been ignored by the SRNC for periodic measurement reports is not impossible, but very hard to do. It requires the follow up of measurement results reported for different neighbour cells and parameter settings that allow performance measurement software to recognise the handover trigger point as internally calculated by SRNC software. Basically the software assumes a soft handover margin of 3 dB. The cell for which soft handover is triggered is identified by the rule that the received pilot of the new cell must be stronger than the received pilot of the best cell in the active set subtracted by the soft handover margin. Certainly parameters such as hysteresis time, which have an decisive impact on soft handover trigger, need to be taken into account and can only be defined by manual configuration of performance measurement
software. Due to these difficulties it must be questioned if the effort in software development really equals the achieved results.
Once handover trigger based on CPICH measurement is detected the RNC will start the NBAP radio link setup procedure in the case of soft handover. If this NBAP radio link setup procedure has been triggered by the RNSAP Radio Link Setup Request or RNSAP Radio Link Addition Request message, we see an inter-RNC soft handover procedure (as shown in Figure 2.32) and on the RNSAP layer handover may already fail prior to the RRC Active Set Update Request sent by the SRNC to the UE.
If instead of NBAP radio link setup the NBAP radio link addition procedure is monitored, a softer handover is performed. In the case of softer handover there is usually no new AAL2 SVC established as physical transport bearer on lub, but it is optionally possible. It is not monitored because nearly all networks seem to be optimised successfully in a way that for softer handover diversity combining is activated in Node B by a parameter included in the NBAP Radio Link Addition Request.
All NBAP and RNSAP procedures define unique counters for Attempt (Initiating Message), Success (Successful Outcome) and Failure events (Unsuccessful Outcome). The only pro- cedures that are left to be analysed during soft handover signalling pattern monitored on UTRAN are ALCAP establishment procedures to set up and delete AAL2 SVC, also known as the Iub or Iur physical transport bearer. Here an error in the procedure is indicated if the answer to the AAL2L3 Establish Request message is Release Confirm containing an error cause value that differs from release cause values ‘normal, unspecified’ and ‘normal call clearing’ as they are monitored when AAL2 SVC is deleted without exception.
All in all it remains very hard to distinguish if an NBAP radio link setup or ALCAP estab- lishment procedure is executed to prepare soft handover or if they are part of other proce- dures such as initial DCH set up, channel type switching or hard handover. Indeed, the subsequent RRC active set update procedure is the only reliable indication that soft hand- over has proceeded.
From the point of view of the author of this book it does not make much sense to define a soft handover success/failure ratio formula that combines all possible protocol procedures monitored on different layers and interfaces. It would rather be advisable to analyse different procedures of different protocols separately and to distinguish – based on subsequent signall- ing patterns – if e.g. NBAP radio link setup has been performed to prepare soft handover or
Figure 2.32 Overview of protocol events – inter-RNC soft handover
any other multi-layer procedure. This would result in a definition of a subset of counters for NBAP radio link setup attempt/success/failure events involved in soft handover, another subset of the same event involved in initial DCH set up, another subset for events involved in hard handover etc. Such an implementation also allows a better and faster root cause analysis to troubleshoot the network compared to a combined soft handover failure ratio that does not indicate in which particular network element or protocol entity the failure has occurred. The same implementation strategy can also be used to identify root causes of e.g. radio link failures that often indicate dropped calls and may also be seen as a final result of erroneous soft handover procedures as shown in Figure 1.10.