This process starts when UE is in RRC_CONNECTED mode. The purpose of this procedure is to re-establish the RRC connection to continue RRC connection, which involves the resumptions of SRB1 operation and the re-activation of security.
This process would not be initiated if UE does not have AS security activated and UE goes to RRC_IDLE mode directly.
Here is the possible overview of the process:
RRC connection re-establishment, successful
RRC connection re-establishment, failure
Reasons of initiation of this procedure may one of the following:
Upon detecting radio link failure
Upon handover failure
upon mobility from E-UTRA failure
upon integrity check failure from indication from layers
upon an RRC connection reconfiguration failure.
Upon initiation of the procedure, the UE shall:
stop timer T310, if running;
start timer T311;
suspend all RBs except SRB0;
reset MAC;
apply the default physical channel configuration
apply the default semi-persistent scheduling configuration
apply the default MAC main configuration
release reportProximityConfig and any associated proximity status reporting timer;
perform cell selection in accordance with the cell selection process.
When UE goes for cell selection while T311 is running it goes through following steps:
stop timer T311;
start timer T301;
apply the timeAligmentTimerCommon included in SIB2;
initiate transmission of RRCConnectionReestablishmentRequest message.
If UE is returning to source cell then also it has to go through above 4 steps.
Now lets look what UE sends in RRCCOnnectionRestablishmentRequest message:
The UE shall set the contents of this message as follow
- set the ue-Identity as
- set the c-RNTI to the C-RNTI used in the source cell (handover and mobility from E-UTRA failure) or used in the cell in which the trigger for the re-establishment occurred (other cases);
- set the physCellId to the physical cell identity of the source cell (handover and mobility from E-UTRA failure) or of the cell in which the trigger for the re-establishment occurred (other cases);
- set the shortMAC-I to the 16 least significant bits of the MAC-I calculated:
- over the ASN.1 encoded as per section 8 (i.e., a multiple of 8 bits) VarShortMAC-Input;
- with the KRRCint key and integrity protection algorithm that was used in the source cell (handover and mobility from E-UTRA failure) or of the cell in which the trigger for the re-establishment occurred (other cases); and
- with all input bits for COUNT, BEARER and DIRECTION set to binary ones;
- set the reestablishmentCause as follows:
- if the re-establishment procedure was initiated due to reconfiguration failure (the UE is unable to comply with the reconfiguration):
- set the reestablishmentCause to the value ‘reconfigurationFailure’;
- else if the re-establishment procedure was initiated due to handover failure as intra-LTE handover failure or inter-RAT mobility from EUTRA failure:
- set the reestablishmentCause to the value ‘handoverFailure’;
- else:
- set the reestablishmentCause to the value ‘otherFailure‘;
The UE shall submit the RRCConnectionReestablishmentRequest message to lower layers for transmission
< How it work >
it works in three steps as shown below (refer to 36.331 5.3.7 RRC connection re-establishment for the details)
i) UE --> NW : RRCConnectionReestablishmentRequest
ii) UE <-- NW : RRCConnectionReestablishment
iii) UE --> NW : RRCConnectionReestablishmentComplete
I think most of those who read this page may be pretty familiar with LTE protocol, so just by looking at the contents of these RRC messages, they would figure out a lot of details without much explanation.
RRCConnectionReestablishmentRequest
c1: rrcConnectionReestablishmentRequest (0)
rrcConnectionReestablishmentRequest
criticalExtensions: rrcConnectionReestablishmentRequest-r8 (0)
rrcConnectionReestablishmentRequest-r8
ue-Identity
c-RNTI: 0000 [bit length 16, 0000 0000 0000 0000 decimal value 0]
physCellId: 0
shortMAC-I: 0000 [bit length 16, 0000 0000 0000 0000 decimal value 0]
reestablishmentCause: reconfigurationFailure /handoverFailure/otherFailure/ spare1
spare: 00 [bit length 2, 6 LSB pad bits, 00.. .... decimal value 0]
RRCConnectionReestablishment (An example based on 36.508 - RRCConnectionReestablishment)
c1: rrcConnectionReestablishment (0)
rrcConnectionReestablishment
rrc-TransactionIdentifier: 0
criticalExtensions: c1 (0)
c1: rrcConnectionReestablishment-r8 (0)
rrcConnectionReestablishment-r8
radioResourceConfigDedicated
srb-ToAddModList: 1 item
Item 0
SRB-ToAddMod
srb-Identity: 1
rlc-Config: defaultValue (1)
defaultValue: NULL
logicalChannelConfig: defaultValue (1)
defaultValue: NULL
mac-MainConfig: explicitValue (0)
explicitValue
ul-SCH-Config
maxHARQ-Tx: n5 (4)
periodicBSR-Timer: sf20 (3)
retxBSR-Timer: sf320 (0)
..0. .... ttiBundling: False
drx-Config: release (0)
release: NULL
timeAlignmentTimerDedicated: sf750 (1)
phr-Config: setup (1)
setup
periodicPHR-Timer: sf500 (5)
prohibitPHR-Timer: sf200 (5)
dl-PathlossChange: dB3 (1)
physicalConfigDedicated
pdsch-ConfigDedicated
p-a: dB-3 (2)
pucch-ConfigDedicated
ackNackRepetition: release (0)
release: NULL
pusch-ConfigDedicated
betaOffset-ACK-Index: 9
betaOffset-RI-Index: 6
betaOffset-CQI-Index: 6
uplinkPowerControlDedicated
p0-UE-PUSCH: 0dB
deltaMCS-Enabled: en0 (0)
..1. .... accumulationEnabled: True
p0-UE-PUCCH: 0dB
pSRS-Offset: 3
filterCoefficient: fc4 (4)
cqi-ReportConfig
cqi-ReportModeAperiodic: rm30 (3)
nomPDSCH-RS-EPRE-Offset: 0dB (0)
soundingRS-UL-ConfigDedicated: setup (1)
setup
srs-Bandwidth: bw0 (0)
srs-HoppingBandwidth: hbw0 (0)
freqDomainPosition: 0
..1. .... = duration: indefinite
srs-ConfigIndex: 20
transmissionComb: 0
cyclicShift: cs0 (0)
antennaInfo: explicitValue (0)
explicitValue
transmissionMode: tm3 (2)
codebookSubsetRestriction: n2TxAntenna-tm3 (0)
n2TxAntenna-tm3: c0 [bit length 2, 6 LSB pad bits, 11.. .... decimal value 3]
ue-TransmitAntennaSelection: release (0)
release: NULL
schedulingRequestConfig: setup (1)
setup
sr-PUCCH-ResourceIndex: 60
sr-ConfigIndex: 30
dsr-TransMax: n4 (0)
nextHopChainingCount: 0
HEX string : 00 12 9B 3E 86 03 B5 79 E8 96 6C 30 64 99 80 20 A0 28 68 3C 1E 00
< When it happens >
There are several cases where this process get triggered. According to 36.331 5.3.7.2, there are several cases as described below.
Case 1 : When radio link failure happened
Case 2 : when Handover failure happened
Case 3 : when mobility from E-UTRA failure happened
According to 36.331 5.4.3.5 Mobility from E-UTRA failure,
revert back to the configuration used in the source PCell, excluding the configuration configured by the physicalConfigDedicated, mac-MainConfig and sps-Config;
initiate the connection re-establishment procedure as described in How it works and Common UE side Process
Case 4 : when integrity check failure indication was received from lower layers
Case 5 : when RRC connection reconfiguration failure happened (UE cannot comply to the configuration set by
RRC Connection Reconfiguration message)
< Causes of RRC Reconfiguration Re-establishment Request >
When anything happens where UE need to trigger RRC Connection Re-establishment process as described above, UE sends RRC Connection Re-establishment Request with the cause of one of the followings (36.331-5.3.7.4).
ReconfigurationFailure : if the re-establishment procedure was initiated due to reconfiguration failure (the UE is
unable to comply with the reconfiguration) - Case 5 in previous section
HandoverFailure : the re-establishment procedure was initiated due to handover failure as in intra-LTE handover failure or inter-RAT mobility from EUTRA failure - Case 2, 3 in previous section
OtherFailure : Any failure caused by other than two mentioned above - Case 1, 4 and others.
< Common UE side Process >
Whatever the case is, overall process on UE side is similar as follows. (36.331 5.3.7.5)
i) stop timer T301
ii) consider the current cell to be the PCell
iii) re-establish PDCP for SRB1
iv) re-establish RLC for SRB1
v) perform the radio resource configuration procedure in accordance with the received radioResourceConfigDedicated
vi) resume SRB1
The purpose of RRC reconstruction is to restore RRC signaling connections and reduce dropped connections. However, excessive RRC reconstruction in the source cell will affect cell throughput and user perception. This article introduces the definition of RRC re-establishment, triggering conditions and the handling of problem cells with too much RRC re-establishment in the source cell and low RRC re-establishment success rate.
2.1 RRC reconstruction definition and trigger conditions
When in the RRC connection state, if the handover fails, the wireless link fails, the integrity protection fails, and the RRC reconfiguration fails, the RRC connection re-establishment process will be triggered. This process aims to re-establish RRC connection, including recovery of SRB1 operation, and safe reactivation. The UE in the RRC_CONNECTED state has been activated and can initiate the process to continue the RRC connection. Only when the relevant cell is a cell with a UE context, the connection re-establishment will succeed. If E-UTRAN approves the rebuild, the operation of SRB1 will resume, while the other RBs will remain suspended. If AS security is not activated, the UE will not initiate this process, but directly goes to the RRC_IDLE state.
2.2 Reasons for RRC reconstruction
The reason why the terminal initiated the reconstruction
In the 36.331 protocol, the conditions for initiating reconstruction are described as follows:
The UE shall only initiate the procedure when AS security has beenactivated. The UE initiates the procedure when one of the following conditionsis met:
upon detecting radio link failure, in accordance with 5.3.11; or
upon handover failure, in accordance with 5.3.5.6; or
upon mobility from E-UTRA failure, in accordance with 5.4.3.5; or
upon integrity check failure indication from lower layers; or
upon an RRC connection reconfiguration failure, in accordance with5.3.5.5;
In a nutshell, there are three reasons for UE to initiate reconstruction:
reconfiguration failure
handover failure
radio link failure
2.2.2 reconfiguration failure
The original agreement is as follows:
if the UE is unable to comply with (part of) the configuration included in the RRCConnectionReconfiguration message:
Continue using the configuration used prior to the reception of RRCConnectionReconfigurationmessage
if security has not been activated:
perform the actions uponleaving RRC_CONNECTED as specified in 5.3.12, with release cause other;
initiate the connectionre-establishment procedure as specified in 5.3.7, upon which the connection reconfiguration procedure endif;
In the state that the UE is in the activated state of the security mode, if the cells in the reconfiguration message cannot be matched / compatible after receiving the reconfiguration message, a reconstruction with a cause value of "reconfiguration failure" is initiated.
2.2.3 handoverfailure
if T304 expires (handover failure):
NOTE: Following T304 expiry any dedicated preamble, if provided within therach-ConfigDedicated, is not available for use by the UE anymore.
In the handover process, the UE will start T304 after receiving the reconfiguration message of the handover, but if the UE cannot complete the random access in the target cell before T304 times out, it will initiate a reconstruction with the cause value of "handover failure"
2.2.4 radio link failure （ OtherFailure ）
If the UE detects that "radio link failure" is currently detected, it will initiate a reconstruction with a cause value of "other", which usually causes the RLF to have the following three mechanisms.
Uplink RLC retransmitted to the maximum number of times
"Indication from RLC that the maximum number of retransmissions has been reached", including SRB and DRB, the same mechanism as the downlink SRB and DRB on the eNB side, after the UE RLC sends a PDU, the corresponding state needs to be fed back to the eNB side before the PDU can Complete a normal RLC schedule. There are two reasons for not receiving the eNB status PDU. One reason is that the eNB side uplink has not received any RLC PDU at all, so it will not respond to the status PDU, and the other reason is the status PDU that the eNB responds to. The reason, did not reach the UE side.
Preamble reached the maximum number of transmissions
During the handover process, the PUCCH is not activated after the handover completion command is lost, or the PUCCH is not activated due to Ta timeout during service maintenance. At this time, if the UE has SR transmission, the UE cannot receive the ENB because of downlink problems. The MAC layer confirms that the SR retransmits to the maximum number of times (physicalconfigDedicatedschedulingRequestConfigdsr-TransMax, configured as 64 times) and triggers MAC_RA_IND (contention-based random access), which reaches the maximum number of times due to Preamble transmission (preambleTransMax, 10 times) during random access After reporting the RLF instruction to L3, it initiates a rebuild request.
Delay spectrum first path search failed (UE detects downlink RLF)
The UE DSP judges the delay spectrum filter value every 200ms. If it meets a certain threshold, it reports L3 out of synchronization and starts the T310 timer. Before the T310 times out, if it receives N311 in-sync instructions (N311 = 5), It is considered that the UE resumes the synchronization state (100ms + 10 * (N311 -1) = 140ms, that is, after starting T310, the terminal reports the measurement at 100ms and judges that the records are N311 + 1, and then the measurement is reported every 10ms), otherwise, After T310 time-out (baseline value is 200ms, corresponding MML parameter is configured as T310 = MS200_T310), UE will trigger the rebuilding process (including searching for cells, L3 in synchronization state and continuously receiving N310 out-of-sync instructions reported by L1 (baseline value 6 times, N310 = n6), it is considered to be out of synchronization (the time required for triggering is expected to be: 200ms + 10 * (N310-1) = 250ms, both 200ms measurement report judgments are satisfied, we have recorded N310 + 1, and then measured and reported once every 10ms ), Synchronization, reconstruction), at the same time start the T311 timer (baseline value is 10s, the corresponding MML parameter configuration is T311 = MS10000_T311), if the timeout has not been successfully rebuilt, then enter the IDLE state.
3 RRC connection reconstruction process
Successful reconstruction process
Failed reconstruction process
1.1, UE sends RRC Connection Reestablishment Request message. According to different scenarios, the reconstruction reason carried in the message is different from the cell information:
The cause of reconfiguration triggered by reconfiguration failure is "reconfigurationFailure", where C-RNTI and physCellId are the cell information
The cause of the re-triggering triggered by handover failure is "handoverFailure", where C-RNTI and physCellId are the information of the source cell
The cause of the reconstruction triggered by the failure of the wireless link is "otherFailure", where C-RNTI and physCellId are the cell information
1.2. The eNodeB performs security parameter authentication. If the UE's security parameter authentication information is consistent with the eNodeB, the UE authentication is passed. After UE identity authentication, the eNodeB releases the original resources and re-enters and allocates resources;
1.3. The eNodeB sends an RRC Connection Reestablishment message to the UE on the CCCH channel. The message carries information about the newly allocated resources. The UE receives the RRC Connection Reestablishment message, reconfigures the wireless resources according to the message instructions, and activates encryption and integrity protection;
2. The UE sends an RRC Connection Reestablishment Complete message to the eNodeB.
4 RRC connection reconstruction problem location and processing
No comments:
Post a Comment
If You have any concern you are free to message/comment me.