There are three categories of handover in the LTE system:
- In terms of networking mode, there are inter-frequency handover and intra-frequency handover.
- In terms of causes which trigger the handover, there are coverage-triggered handover, load-triggered handover, service-triggered handover, and UE travelling speed-triggered handover.
- In terms of the network topology, there are intra-eNodeB handover, the intra-MME but inter-eNodeB handover, and the inter-MME and inter-eNodeB handover.
Process and Categories of LTE Handover.
LTE Handover Flow Chart.
The handover process is shown below:
The handover process is explained as below:
- Measurement Control: It is usually carried by the reconfiguration message for the initial access or for last handover command.
- Measurement Report: UE reports the cells reaching the handover threshold based on the measurement control message of current cell.
- HO Request: The source cell asks for the resource information and configuration information from the target cell after it receives the measurement report.
- HO Request Ack: The target cell sends the admission information from the UE and other configuration information to the source cell.
- RRC Connection Reconfiguration: The target cell sends the admission information and configuration information to the UE, and tells the UE that it has got ready to accept the UE. This reconfiguration message contains the measurement control message of the target cell.
- SN Status Transfer: The source cell transfers the cached data of UE services to the target cell.
- MSG1 (Random Access Preamble): When the UE receives the reconfiguration message (handover command) in the step 5, it begins to access to the target cell by using the access message contained in the reconfiguration message.
- MSG2 (Random Access Response): The target cell sends back the access response. When the UE receives this response message, the random access process can be regarded finished.
- RRC Connection Reconfiguration Complete: The UE will sends out the reconfiguration complete message on the RRC layer. The handover is completed in this step.
- Release Resource: When the UE gets connected to the target cell successfully, the target cell will ask the source cell to delete the UE context information.
Handover Categories.
In this article, the LTE handover is classified into intra-eNodeB handover, handover on the X2 interface, and the handover on the S1 interface. In all handovers mentioned below, the UE gets connected to the target cell and obtains the measurement configuration information.
1. Intra-eNodeB Handover.
As for this kind of handover, both the source cell and the target cell are controlled by the same eNodeB. This eNodeB will determine whether to perform the handover or not by itself, and it will not apply for the transmission path replacement from the core network.
2. Handover at the X2 Interface.
This kind of handover is an inter-cell handover, and is used to establish the connection to the X2 interface. When the eNodeB receives the measurement report, it will send the handover request to the target cell (as shown in the step 3 of Figure 1‑1) through the X2 interface. It sends the handover command to the UE only when it receives response from the target cell (as shown in the step 4 of Figure 1‑1). At the same time, the eNodeB will send the SNStatus Transfer message (which contains the cached data packets and the No. of cached data packets) to the target cell. After the UE gets connected to the target cell, the target cell will send the transmission path replacement request to the core network, aiming to ask the core network to switch the UE service from the source cell to the target cell.
Handover at the S1 Interface.
The handover at the S1 interface only takes place when there is no X2 interface handover or intra-eNodeB handover between two neighboring cells.
The signaling flow of the S1 interface handover is similar to that of the X2 interface handover. However, the handover delay at the S1 interface is a bit longer than that at the X2 interface.
Checking Signaling at the UE.
At the UE, you can check complete handover signaling only through the diagnosis information given by the CNT or CNA, as shown in Table 1.
Table 1 – Handover Signaling Observed at the UE.
| MS Time | Messages Name |
| 18:39:46:103 | Measurement Report |
| 18:39:46:313 | RRC Connection Reconfiguration |
| 18:39:46:325 | ML1 Downlink Common Configuration |
| 18:39:46:325 | ML1 Downlink Dedicated Configuration |
| 18:39:46:325 | ML1 Uplink Common Configuration |
| 18:39:46:325 | ML1 Uplink Dedicated Configuration |
| 18:39:46:330 | RLC UL Configuration |
| 18:39:46:330 | PDCP DL Configuration |
| 18:39:46:331 | RRC Connection Reconfiguration Complete |
| 18:39:46:331 | MAC RACH Trigger |
| 18:39:46:341 | Msg1 |
| 18:39:46:351 | RAR |
| 18:39:46:352 | Msg3 |
Note: In this table, the RRC Connection Reconfiguration Complete message is actually carried by the MSG3 message.
Measurement Report.
The UE conducts the measurement based on the measurement control message sent by the service cell, and then reports the cell which meets requirement to the service cell.
Figure 5 – Measurement Report.
MeasResults: the measurement value of the service cell
MeasResultNeighCells: the measurement value which reaches the threshold of triggering the A3 measurement event
Note: For the sake of easy reading of reported value, the reported value is the sum of the actual measurement value and 140dB, as shown in the formula below:
RSRP (dBm) = rsrpResult-140dBm
Example:
If the reported value is “52”, the actual measurement value will be “52-140=-88dBm”.
RRC Connection Reconfiguration.
The source cell sends the admission information and the configuration information received from the target cell to the UE, and tells the UE the target cell has got ready to accept it. This reconfiguration information contains the measurement control message from the target cell.
- measConfig
This message contains information about the neighboring cell list, event determination threshold, and reporting interval.
Figure 6 – Neighboring Cell List Contained in the measConfig Message.
- mobilityControllnfo
The reconfiguration message can be regarded as the handover command only when it carries the mobilityControllnfo message. The mobilityControllnfo message contains PIC of target cell and all configuration information needed by the access.
Figure 7 – mobilityControlInfo Message.
1: This reconfiguration message is the handover command because it contains the mobilityControlInfo message.
2: PCI of target cell.
3: Configuration of T304.
4: C_RNTI is used for the non-contention random access of the target cell.
5: RACH configuration.
MSG1
The UE gets connected to the target cell by using the access configuration information carried by the handover command.
Table 2 – MSG1 Message.
| Message Detail |
| Msg1 |
| Preamble sequence = 10 |
| Physical root index = 650 |
| Cyclic shift = 220 |
| PRACH Tx Power = 14 |
| Beta PRACH = 242 |
| PRACH frequency offset = 12 |
| Preamble format = 0 |
| Random access request timing SFN= 507 |
| Random access request timing SubSFN= 2 |
| Random access response window start SFN = 507 |
| Random access response window start SubSFN = 5 |
| Random access response window end SFN = 508 |
| Random access response window end SubSFN = 5 |
| RA RNTI = 3 |
The UE gets connected to the target cell with the preamble sequence = 10 and the physical root index =650 (this information is obtained from the PRACH config message). As shown in the Table 2, the preamble format =0, and the random access request is sent out at the sub-system frame No. 2 of the system frame No. 507. The random access response window ranges from SFN\SF: 507\5 to SFN\SF: 508\5 (the length of this window is 10ms), which is consistent with the RA-response window size (10sf).
The Random Access Radio Network Temporary Identifier (RA RNTI) only exists during the period between the MSG1 and the MSG2. The UE generates the RA RNTI based on a dedicated algorithm. The RA RNTI will be carried by the MSG1 and sent to the eNodeB. The eNodeB will scramble the MSG2 according to this RA RNTI. The UE can demodulate the PDCCH properly only when it receives the RA RNATI carried by the MSG2.
MSG2 (RAR).
For all handovers mentioned in this article are the non-contention handover, it can be regarded that the UE gets connected to the target cell successfully if the MSG2 message is received.
MSG3.
The packing of the reconfiguration complete message is finished at the time the handover command is received. However, it is carried and sent through the MSG3. In this regard, the random access to the target cell can be regarded as a random access issued by the reconfiguration complete message.
Collecting Statistics of Handover Delay through the CNA.
Perform the following steps to collect statistics of the handover delay:
- Create a new project in the CNA. Next, import the log to be analyzed into this project.
- From the navigation tree, select MS1 [Qualcomm] to expand this node.
- Select the sub-node Delay under it.
- In the Delay window at the right panel, select the checkbox before the Control HO Delay.
- Right-click it to select Add from the pop-up menu.
- Click Apply.
Figure 8. Delay -1.
7. From the navigation tree, select the sub-node Presentation under the node MS1 [Qualcomm].
8. Select the sub-node Signaling under it.
9. Double-click the node Delay from the navigation tree to view the statistics.
Handover Delay Method Analysis.
The handover delay statistics collected by the CNA is the handover delay on the control plane. This delay starts from the time when the RRC reconfiguration message is received and ends at the time when the RAR message is received. The UE handover process can be divided into three stages shown below:
- From the time when the RRC reconfiguration message is received to the time when the RRC reconfiguration complete message is received.
- From the time when the RRC reconfiguration complete message is received to the time when the MSG1 message is received.
- From the time when the MSG1 message is received to the time when the MSG2 is received.
Figure shows Analysis Method of the Handover Delay.’
Analysis Method of RRC Reconfiguration.
After the measurement is conducted, the UE will send the measurement report to the service cell if any measurement event is triggered and implemented. The service cell will send the handover request to the target cell and ask the target cell to get ready for the UE access. It sends the RRC Connection Reconfiguration message (it contains the mobility control message) to the UE only after when it receives response from the target cell.
The UE will move into the handover process after it receives the RRC Connection Reconfiguration message. Next, when the UE gets ready for the link establishment, it will send out the MSG1 to the target cell.
The delay mentioned in this section is processed by the UE, and it is usually less than 25ms. If this delay is longer than 25ms, please submit this problem to the UE vendor and ask them to solve this problem.
Table – Analysis Method of RRC Reconfiguration Message.
| ML1 Downlink Common Configuration. |
| ML1 Downlink Dedicated Configuration. |
| ML1 Uplink Common Configuration. |
| ML1 Uplink Dedicated Configuration. |
| RLC UL Configuration. |
| PDCP DL Configuration. |
| RRC Connection Reconfiguration Complete. |
PRACH Configuration Analysis Method.
From the time when the RRC reconfiguration complete message is received to the time when the MSG1 message is received, the random access process will be triggered after the UE have finished the preparation of RRC connection establishment. If the delay during this period is larger than 10ms, you should check the transmission interval configured for the PRACH Config Index in the OMC. If this interval is larger than expected, the transmissions at the PRACH will be reduced, and the delay will be increased.
For detailed information about the PRACH, see the table 5.7.1-3 in the 3GPP Protocol 36211-880.
Table 5.7.1-3 in the 3GPP Protocol 36211-880.
| PRACH Config No. | Preamble Format | Density Every 10 ms (DRA) | Version (rRA) |
| 0 | 0 | 0.5 | 0 |
| 1 | 0 | 0.5 | 1 |
| 2 | 0 | 0.5 | 2 |
| 3 | 0 | 1 | 0 |
| 4 | 0 | 1 | 1 |
| 5 | 0 | 1 | 2 |
| 6 | 0 | 2 | 0 |
| 7 | 0 | 2 | 1 |
| 8 | 0 | 2 | 2 |
Analysis Method of MSG1.
If the delay for the period from the time when the MSG1 is received to the time when the MSG2 is received is longer than 14ms, please analyze this problem as follows:
Figure below shows analysis Method of MSG1 Message.
The UE re-sends the MSG1 based on the PRACH transmission period if it does not receive the MSG2 after the MSG1 is sent out. In this case, the length of this delay will be increased. You can analyze the PDCCH uplink and downlink respectively if the MSG2 is not received.
Uplink:
- Check whether the MSG1 received based on the PRACH packet reception information at the MTS of OMC.
- Check the reception power of the MTS uplink channel. If this reception power is larger than -99dBm, you need to solve the uplink interference problem (e.g. GPS cross-over timeslot interference).
- Increase the expected PRACH reception power, increase the climbing step of PRACH power, and decrease the detection threshold of PRACH absolution prefix.
Downlink:
- If the UE does not receive the PDCCH scrambled by the RA_RNTI, please check the downlink RSRP and the SINR. If the RSRP is larger than -119dBm and SINR is larger than -3dB, please adjust the engineering parameters, RS power and PCI to solve the downlink coverage problem.
- Increase the initial value of CCE convergence in large public space. The higher this value is, the easier the demodulation will be.
Case Study.
Increase of Handover Delay Due to the Retransmission of MSG1.
Problem Description.
The test in this case study is described as follows:
Time: Wednesday, October 12th, 2011
Tools: Qualcomm UE and CNT, frequency scanner and CNT.
Test Method: This is a long call detection test. The reception antenna of the UE is installed inside the vehicle and the cell load is 50%.
Test PC: Panasonic CF-810 (Windows XP_SP3).
Test Results:
| Handover Quantity | Max. Delay | Mini. Delay | Average Delay | Target Delay | Remarks |
| 123 | 143 | 31 | 43.61 | 40 | Fail |
Required KPI in the Contract:
Handover delay (signal) = T2 (HO CMD) – T1 (HO CMP) < 40ms
Handover delay (conversion formula in the CNA): Delay= RAR – RRC Connection Reconfiguration
Note: Prerequisites of KPI Acceptance Test.
- The RSRP should be larger than -116dBm and the C-RS SINR should be larger than 0dB in the test area.
- The abnormal delay caused by non-eNodeB problem will not be taken into account of the delay statistics.
- If the handover takes place between two eNodeBs, consider the interface X2 handover.
- In the test area, the traffic load should be 50%.
Analysis Method.
Here is the handover process for the period when the delay is increased due to the retransmission of the MSG1 message.
Figure of Handover Process.
Here is the signalling observed in the CAN:
Table below shows signaling Observed in the CNA.
| MS Time | Channel Name | Message Name | |
| A | 15:38:47:082 | UL DCCH | Measurement Report. |
| B | 15:38:47:114 | DL DCCH | RRC Connection Reconfiguration. |
| 15:38:47:125 | ML1 Config | ML1 Downlink Common Configuration. | |
| 15:38:47:125 | ML1 Config | ML1 Downlink Dedicated Configuration. | |
| 15:38:47:125 | ML1 Config | ML1 Uplink Common Configuration. | |
| 15:38:47:125 | ML1 Config | ML1 Uplink Dedicated Configuration. | |
| 15:38:47:130 | MAC Config | MAC Configuration | |
| 15:38:47:130 | DL RLC | RLC DL Configuration. | |
| 15:38:47:130 | UL RLC | RLC UL Configuration. | |
| 15:38:47:131 | DL PDCP | PDCP DL Configuration. | |
| 15:38:47:131 | UL PDCP | PDCP UL Configuration. | |
| E’ | 15:38:47:131 | UL DCCH | RRC Connection Reconfiguration Complete. |
| 15:38:47:131 | MAC Config | MAC RACH Trigger. | |
| C | 15:38:47:141 | UL MAC | Msg1 |
| D | 15:38:47:150 | DL MAC | RAR |
| 15:38:47:150 | MAC Config | MAC RACH Attempt | |
| E | 15:38:47:150 | UL MAC | Msg3 (use for sending E’). |
A:
B: The UE receives the handover command from the eNodeB.
C: The UE sends out the random access preamble.
D: The UE receives the random access response.
E: The UE sends out the random access complete message.
E’: The packing of the random access complete message is finished and sent out along with the MSG3 message.
Divide the handover delay into three segments and then analyze the delay. Three segments of delay are shown below:
- From the time when the RRC reconfiguration message is received to the time when the RRC reconfiguration message complete message is received.
- From the time when the RRC reconfiguration message complete message is received to the time when the MSG1 message is sent out.
- From the time when the MSG1 message is sent out to the time when the MSG2 message is sent out.
The analysis results are shown below:
| LOG Date | Times | ReConfig-> ReconfigComp | ReconfigComp-> MSG1 | MSG1 -> RAR | MSG1_NUM | C Plan Delay | Remarks |
| October 12th | 19 | 19.4 | 5.9 | 26.1 | 1.57 | 50.6 | Before the optimization |
| December 3rd | 87 | 19.5 | 4.87 | 10.8 | 1.046 | 35.1 | After the optimization |
Solving the Problem.
After comparing different logs, you can find that during the longer segment of handover delay, the retransmission of MSG1 messages will increase the length of delay. Here is the chart of the relation between the length of delay and the times of MSG1 retransmission:
Figure below represents relation between the Length of Delay and the Times of MSG1 Retransmission.
Actually, this problem is caused by frequently missing preambles in the detection. The UE receives the MSG2 messages after the MSG1 is retransmitted for many times. In the Traceme, you can find that the UE retransmits the MSG1 because it waits the MSG2 longer than expected. In the PHYLog, no DCI for the MSG2 can be detected. If you want to retransmit the MSG2 in case of large signal, you need to modify the FPGA version of the eNodeB (This will be solved in the B08 version). If you want to retransmit the MSG1 in case of small signal, you need increase the RRU gain from 6dB to 10dB.
Solution:
You can modify the PRACH Absolute Preamble Threshold for Enode B Detecting Preamble from 2000 to 50. After the modification, the log is shown as below:
| LOG Date | Times | ReConfig-> ReconfigComp | ReconfigComp-> MSG1 | MSG1->RAR | MSG1_NUM | C Plan Delay | Remarks |
| December 3rd | 87 | 19.5 | 4.87 | 10.8 | 1.046 | 35.1 | After the optimization |
Summary
In most cases, if you want to locate and analyze the handover delay problem, you need to collect all necessary self-test statistics and detailed signaling analysis information. Next, you can use the EXCLE filtering function to find out the key signaling you need.
You are suggested to divide the handover delay into three segments and then conduct the analysis. Three segments of delay are shown below:
- From the time when the RRC reconfiguration message is received to the time when the RRC reconfiguration message complete message is received.
- From the time when the RRC reconfiguration message complete message is received to the time when the MSG1 message is sent out.
- From the time when the MSG1 message is sent out to the time when the MSG2 message is sent out.
In the stage 3 of handover process, you need to check the following items:
- Check whether the MSG1 is retransmitted;
- Check the interval of every two retransmission.
- Check the content of the MSG1 message.
- Check the transmission power of the UE.
In the stage 4 of handover process, you need to check the following items: