An RRC connection can break while the UE is still in RRC_CONNECTED, for example when the radio link fails or a handover fails. RRC connection re-establishment lets the UE continue that connection in the cell it selects next, without going through RRC_IDLE first. The procedure needs AS security to be active already, and it succeeds only if the selected cell holds the UE context.
- What is this
- How it work
- When it happens
- Causes of RRC Connection Re-establishment Request
- Common UE side Process
- Reference
What is this
A failure in RRC_CONNECTED does not have to end the connection. The UE keeps its context and its security keys, and it tries to continue the same RRC connection instead of starting a new one.
It is a kind of mechanism to make a recovery when radio link got broken for some reason. (See "When it happens" section for these reason)
At first the procedure restores only a small part of the connection. 36.331 lists three things. SRB1 resumes, AS security is re-activated without changing the algorithms, and only the PCell is configured. The other radio bearers stay suspended until the first RRCConnectionReconfiguration after the re-establishment resumes SRB2 and the DRBs. The SCells are released, so the network must also configure carrier aggregation again.
Two conditions limit the procedure. First, the UE initiates it only when AS security has been activated. Without AS security, the UE moves to RRC_IDLE directly. A NB-IoT UE that supports re-establishment for the Control Plane CIoT EPS/5GS optimisation is the only exception. Second, the re-establishment succeeds only if the selected cell is prepared, which means that it has a valid UE context. Otherwise E-UTRAN answers with RRCConnectionReestablishmentReject, and the UE leaves RRC_CONNECTED.
Re-establishment keeps the RRC connection : the UE does not go through RRC_IDLE and a new connection setup when it succeeds.Only SRB1 comes back at once : SRB2 and the DRBs wait for the first RRCConnectionReconfiguration after the procedure.Security is a precondition : a UE without AS security goes straight to RRC_IDLE, except for the NB-IoT control plane case.The target cell needs the UE context : an unprepared cell rejects the request.
How it work
The UE does not send the request at the moment of the failure. It first starts T311 and searches for a suitable cell. It sends the request only after it has selected a cell, and at that point it starts T301. Then three RRC messages complete the procedure.
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.
Let's put the three messages on a time line together with the two timers. Figure 1 also shows the RRCConnectionReconfiguration that follows the procedure, because that message is what brings the DRBs back.
Figure 1. RRC connection re-establishment as specified in 36.331. The request and its answer travel on SRB0, and SRB2 and the DRBs stay suspended until the first RRCConnectionReconfiguration after the procedure.
T311 : starts when the procedure starts, and stops when the UE selects a suitable E-UTRA cell or a cell of another RAT. If the selected cell belongs to another RAT, the UE leaves RRC_CONNECTED instead of sending the request.T301 : starts when the UE sends RRCConnectionReestablishmentRequest, and stops on RRCConnectionReestablishment or RRCConnectionReestablishmentReject. It also stops when the selected cell becomes unsuitable.SRB0 and SRB1 : the request and the answer use SRB0, because SRB1 is not yet available. RRCConnectionReestablishmentComplete is the first message on the restored SRB1.The last arrow : the first RRCConnectionReconfiguration after the procedure re-establishes PDCP and RLC for SRB2 and the DRBs, and then resumes them.
If T311 or T301 expires, the UE leaves RRC_CONNECTED with release cause 'RRC connection failure'. The same happens when the UE receives RRCConnectionReestablishmentReject. Since Release 16 there is also a second path. If the UE is configured with attemptCondReconf and the failure was an RLF of the MCG or a handover failure, the UE checks the selected cell first. If that cell is one of its conditional handover candidates, the UE applies the stored conditional reconfiguration of that cell and performs a handover instead of sending the request.
RRCConnectionReestablishmentRequest
The request travels on SRB0, so it is neither ciphered nor integrity protected. The UE therefore proves its identity with three values that the old cell can check: its old C-RNTI, the PCI of the old PCell and a 16 bit shortMAC-I.
Following is based on
RRCConnectionReestablishmentRequest ::= SEQUENCE {
criticalExtensions CHOICE {
rrcConnectionReestablishmentRequest-r8
RRCConnectionReestablishmentRequest-r8-IEs,
criticalExtensionsFuture SEQUENCE {}
}
}
RRCConnectionReestablishmentRequest-r8-IEs ::= SEQUENCE {
ue-Identity ReestabUE-Identity,
reestablishmentCause ReestablishmentCause,
spare BIT STRING (SIZE (2))
}
ReestabUE-Identity ::= SEQUENCE {
c-RNTI C-RNTI,
physCellId PhysCellId,
shortMAC-I ShortMAC-I
}
ReestablishmentCause ::= ENUMERATED {
reconfigurationFailure, handoverFailure,
otherFailure, spare1
}
ShortMAC-I ::= BIT STRING (SIZE (16))
36.331 sets these fields as follows. The c-RNTI is the C-RNTI used in the source PCell after a handover or mobility from E-UTRA failure, and the one used in the PCell where the trigger occurred in all other cases. The physCellId follows the same rule. The shortMAC-I is the 16 least significant bits of a MAC-I. The UE calculates it over VarShortMAC-Input, with the KRRCint key and the integrity algorithm of that same PCell. COUNT, BEARER and DIRECTION are all set to binary ones for this calculation.
VarShortMAC-Input holds three values. The cellIdentity is the one in SIB1 of the cell where the UE now sends the request. The physCellId and the c-RNTI are those of the PCell before the failure. So the new cell can check the shortMAC-I only after it gets the old KRRCint from the old cell, which is exactly what a prepared cell has.
Decoded RRC message,
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]
Read this block as a layout rather than a capture. The identity fields are all zero, and the reestablishmentCause line lists all four values of the ENUMERATED type. A real request carries exactly one of them. The 2 bit spare field at the end matches the spare BIT STRING in the ASN.1 above.
RRCConnectionReestablishment
The eNB answers on SRB0 with RRCConnectionReestablishment. The message carries only two things: a radioResourceConfigDedicated that sets up SRB1 again, and the nextHopChainingCount that the UE needs for its new KeNB.
Following is based on
RRCConnectionReestablishment ::= SEQUENCE {
rrc-TransactionIdentifier RRC-TransactionIdentifier,
criticalExtensions CHOICE {
c1 CHOICE{
rrcConnectionReestablishment-r8 RRCConnectionReestablishment-r8-IEs,
spare7 NULL,
spare6 NULL, spare5 NULL, spare4 NULL,
spare3 NULL, spare2 NULL, spare1 NULL
},
criticalExtensionsFuture SEQUENCE {}
}
}
RRCConnectionReestablishment-r8-IEs ::= SEQUENCE {
radioResourceConfigDedicated RadioResourceConfigDedicated,
nextHopChainingCount NextHopChainingCount,
nonCriticalExtension RRCConnectionReestablishment-v8a0-IEs OPTIONAL
}
RRCConnectionReestablishment-v8a0-IEs ::= SEQUENCE {
lateNonCriticalExtension OCTET STRING OPTIONAL,
nonCriticalExtension SEQUENCE {} OPTIONAL
}
NextHopChainingCount ::= INTEGER (0..7)
Decoded RRC message,
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
The same RRCConnectionReestablishment example, encoded as a hex string.
HEX string : 00 12 9B 3E 86 03 B5 79 E8 96 6C 30 64 99 80 20 A0 28 68 3C 1E 00
In this example, radioResourceConfigDedicated carries SRB1 with the default RLC and logical channel configuration, an explicit MAC main configuration and a full physicalConfigDedicated. The antenna configuration is TM3 with the 2 antenna codebook subset. No DRB appears, which matches the rule that only SRB1 resumes at this point.
The nextHopChainingCount is 0 here, and its range is 0 to 7. For a UE connected to EPC, the UE uses this value to update KeNB from the KASME key, as 33.401 specifies. Then it derives new KRRCint, KRRCenc and KUPenc keys for the same algorithms as before. So the eNB does not need a SecurityModeCommand after the re-establishment.
When it happens
Re-establishment is a recovery procedure, so every trigger is some kind of failure while the UE is in RRC_CONNECTED. The first five cases below are the ones a plain LTE connection meets, and they come straight from the trigger list in 36.331.
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)
36.331 v19.3.0 words Case 4 more narrowly. The integrity check failure indication must concern SRB1 or SRB2. The same clause has also grown well beyond these five cases. The later triggers come from dual connectivity and from MCG failure recovery.
- RLF of the MCG while SCG transmission is suspended, or while an NR PSCell change or PSCell addition is ongoing.
- An RRC connection reconfiguration failure on the NR part of the configuration, as specified in 38.331 clause 5.3.5.8.
- In (NG)EN-DC while MCG transmission is suspended: RLF of the SCG, SCG change failure, SCG configuration failure, or an integrity check failure on SRB3.
- T316 expiry. When T316 is configured, an RLF first starts MCG failure recovery through the SCG, and re-establishment follows only if T316 expires.
For NTN there is one more condition. If the cell broadcasts SystemInformationBlockType31, the UE initiates re-establishment only when it has a valid GNSS position.
Every trigger is a failure : radio link, handover, mobility, integrity or reconfiguration failure starts the procedure.RLF with T316 configured is different : the UE tries MCG failure recovery first and re-establishes only if T316 expires.Dual connectivity added triggers : failures on the NR side can also end in LTE re-establishment when the MCG is suspended.
Causes of RRC Connection 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.
The cause is coarse on purpose. There are only three values plus spare1, so an RLF and an integrity check failure both arrive as otherFailure. A network that wants the detail relies on the RLF report instead. After an RLF or a handover failure, the UE writes the global cell identity of the selected cell into reestablishmentCellId of VarRLF-Report. When RLF information is available, the UE includes rlf-InfoAvailable in RRCConnectionReestablishmentComplete. The network can then fetch the report with UEInformationRequest.
Three causes cover every trigger : reconfigurationFailure, handoverFailure and otherFailure, with spare1 unused.RLF is reported as otherFailure : the detail comes from the RLF report, not from the cause value.
Common UE side Process
Once RRCConnectionReestablishment arrives, the UE follows the same steps whatever triggered the procedure. The first six steps bring SRB1 back, and the steps after them restore security.
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
36.331 v19.3.0 adds one variation to step iii). If SRB1 was configured with NR PDCP and the UE is connected to EPC, the UE releases the NR PDCP entity and establishes an E-UTRA PDCP entity for SRB1 instead.
The procedure continues after step vi). The UE updates KeNB with the nextHopChainingCount from the message, and it stores that value. It derives the KRRCint, KRRCenc and KUPenc keys for the previously configured algorithms. Then it activates integrity protection and ciphering immediately, so RRCConnectionReestablishmentComplete is already protected. Before it submits that message, the UE may add availability flags such as rlf-InfoAvailable, logMeasAvailable and connEstFailInfoAvailable. E-UTRAN should not send any message on SRB1 before it receives RRCConnectionReestablishmentComplete.
SRB1 first, then security : the UE rebuilds SRB1 and then re-activates security with fresh keys but the same algorithms.The Complete message is already protected : integrity protection and ciphering apply from RRCConnectionReestablishmentComplete onward.Failure paths all end the same way : T311 expiry, T301 expiry, an unsuitable cell and RRCConnectionReestablishmentReject all take the UE out of RRC_CONNECTED.
Reference
- 3GPP TS 36.331 v19.3.0 - clause 5.3.7 RRC connection re-establishment, clause 5.4.3.5, clause 5.3.5.3, clause 7.3 timers, and the ASN.1 of the re-establishment messages