5G/NR - RRC Overview
There is a addition RRC states between RRC Connected and Idle and Network/UE can optionally stay in INACTIVE state without completely releasing the RRC when there is no traffic and quickly switch back to CONNECTED states when necessary. (NOTE : There was no corresponding states in LTE, but Rrc Inactive status is added to LTE from Release 16).
To me, RRC INACTIVE state is similar to the combination of FACH and PCH in UMTS. Actually Use case of INACTIVE state is almost same as FACH/PCH in UMTS.
- Overall Statemachine
- Why RRC INACTIVE ?
- What can happen in RRC INACTIVE state ?
- State Transition Sequence
- UE Capability
- RRC Parameters
- Reference
- Get the Test Procedure and Log / Amarisoft TechAcademy
Overall Statemachine
Three states exist rather than two, and the middle one is the reason this page is here. The drawings below show which transitions are allowed, which message triggers each, and how the picture changes once E-UTRA is in it.
The switching between RRC CONNECTED and RRC INACTIVE state happens as shown below.
Highlights of this statemachine / statechange is listed as follows.
- gNB trigger the switching from RRC CONNECTED to RRC INACIVE with RRC Release configured for suspendConfig
- gNB can trigger from RRC INACTIVE to RRC CONNECTED by Paging
- UE can trigger from RRC INACTIVE to RRC CONNECTED by RrcResumeRequest
UE can interact with other radio technology even in RRC INACTIVE state as shown below.
<36.331 v17.2- Figure 4.2.1-2: UE state machine and state transitions between NR/5GC, E-UTRA/EPC and EUTRA/5GC>
This signaling procedure can be illustrated in other way as well illustrated by Rahim Navael as shown below. Rahim kindly approved me to share the illustration in my note.
Image Source : Rahim Navaei's LinkedIn Post
As you see here, this single slide carries a lot of details and may look a little bit intimidated at the first glance. But it would gets more meaningful as you get more familiar with the process. I would suggest you to try to associate this slide with the protocol sequences shown here and check RRC message details in the example.
One message carries the UE into the state : an RRC Release with suspendConfig present is what moves a UE from CONNECTED to INACTIVE. The same message without it releases to IDLE.Two things can bring it back : the UE sends RRCResumeRequest or RRCResumeRequest1, or the network sends Paging and the UE resumes in response.The two request forms differ by identity size : RRCResumeRequest carries a ShortI-RNTI-Value and RRCResumeRequest1 carries the full I-RNTI-Value.INACTIVE can also be left downward : a further Release takes the UE from INACTIVE to IDLE without passing through CONNECTED.The state exists on both radio technologies : the drawing with the green and yellow blocks gives E-UTRA and NR each their own CONNECTED, INACTIVE and IDLE, joined by reselection.
Why RRC INACTIVE ?
What do we need this kind of special RRC State ? Simply put, the main purpose of RrcInactive state is for power saving. Overall thought process of developing and evolving RrcInactive state can be summarized as below.
- We want to save energy consumption when there is no data transmission
- Why don't you just release RRC Connection and goes into Idle mode. It would reduce energy conception a lot.
- We can do it, but what if we are having sporadic/bursty data transmission ? In this case, we would experience long delay because UE/gNB keep going back and forth between RRC CONNECTED and RRC IDLE. This also increase energy consumption because it repeatedly has to go through long signaling sequence from IDLE to CONNECTED.
- Then, let's define a special states states in beween IDLE and CONNECTED. In this state, we just put the states in a dormant state which does not do any data transmission but NAS layer remain connected and RRC is not completely released. We call this special state as RRC INACTIVE.
- What if there is some data to be transmitted in this state ? Then RRC INACTIVE switches to RRC CONNECTED by RRC RESUME process and perform data transmission (this state transition is much simpler than RRC IDLE->RRC CONNECTED switch). ==> this is Release 15, 16 implementation.
- It sounds good, but what if we have sporadic/bursty data transmission with very small data ? Do we still need to switch back and forth between RRC CONNECTED and RRC INACTIVE ?
- If you are with Release 15/16, that may be the only option. But in release 17 it is allowed to perform small amount of data transmission even in RRC INACTIVE state. So the amount of data is very small, we can perform data transmission directly in RRC INACTIVE state without any state transition.
What can happen in RRC INACTIVE state ?
The behavior/Procedure in RRC INACTIVE state is described in 38.331 - 4.2.1 as follows. As of now (Sep 2022) and as per my experience, the most common process and UE behavior we are interested in is highlight in color.
- UE specific DRX may be configured by upper layers or by RRC layer;
- At lower layers, the UE may be configured with a DRX for PTM(Point to MultiPoint) transmission of MBS(Multicast/Broadcast Service) broadcast;
- UE controlled mobility based on network configuration;
- The UE stores the UE Inactive AS context;
- A RAN-based notification area is configured by RRC layer;
- Transfer of unicast data and/or signalling to/from UE over radio bearers configured for SDT(Small Data Transmission) .
The UE:
- Monitors Short Messages transmitted with P-RNTI over DCI
- During SDT(Small Data Transmission) procedure, monitors control channels associated with the shared data channel to determine if data is scheduled for it;
- While SDT(Small Data Transmission) procedure is not ongoing, monitors a Paging channel for CN paging using 5G-S-TMSI and RAN paging using fullI-RNTI, except if the UE is acting as a L2 U2N Remote UE;
- If configured by upper layers for MBS multicast reception, monitors a Paging channel for paging using TMGI;
- Performs neighbouring cell measurements and cell (re-)selection;
- Performs RAN-based notification area updates periodically and when moving outside the configured RAN-based notification area;
- Acquires system information, while SDT procedure is not ongoing, and can send SI request (if configured);
- While SDT procedure is not ongoing, performs logging of available measurements together with location and time for logged measurement configured UEs; While SDT procedure is not ongoing, performs idle/inactive measurements for idle/inactive measurement configured UEs;
- If configured by upper layers for MBS broadcast reception, acquires MCCH change notification and MBS broadcast control information and data;
- Transmits SRS for Positioning.
I think the process in RRC INACTIVE is better described in following specification. Check out which physical channel is active and which RNTI is used in RRC INACTIVE state.
< 38.202 v17.2 - Table 6.2-2: Downlink Reception Type Combinations >
< 38.202 v17.2 - Table 6.2-1: Downlink "Reception Types" >
State Transition Sequence
The captures below are what the state machine looks like on the air. Ten steps run from the capability exchange through a release into RRC INACTIVE, a resume, and a second round of the same. Each step carries the decoded message that produced it.
Following is a example of protocol sequence captured by Amarisoft Callbox and a commercial UE. Suumary of the overall sequence is as follows.
NOTE : If you want to see the contents of full log with Amarisoft Log viewer, go to LogAnalysis section and click on 'Sample Log' in this tutorial of Amarisoft TechAcademy.
[1] Network would check if UE support Rrc Inactive via UE Capability Information. (Step (1))
[2] When there is no traffic for a certain time period, Network would suspend via Rrc Release (Step(2))
[3] Now the call status is in RRC INACTIVE
[4] (I did ping from network). Network will trigger Rrc Resume process via Paging (Step (3))
[5] UE trigger RACH process and send Rrc Resume Request (Step (4))
[6] Network send Rrc Resume (Step (5))
[7] UE send Rrc Resume Complete (Step (6))
[8] Higher layer data (ping in this case) is going on
[9] After a certain time period from the completion of Higher Layer Data exchange, Network trigger Rrc Suspend via Rrc Release (Step (7))
[10] I launched Browser from UE to let UE trigger the resume.
[11] UE trigger RACH process and send Rrc Resume Request (Step (8))
[12] Network send Rrc Resume (Step (9))
[13] UE send Rrc Resume Complete (Step (10))
(1) UE Capability Information
Nothing else in this sequence can happen until the network knows the UE supports the state. The container below ends with
Decoded
{
message c1: ueCapabilityInformation: {
rrc-TransactionIdentifier 0,
criticalExtensions ueCapabilityInformation: {
ue-CapabilityRAT-ContainerList {
{
...
nonCriticalExtension {
...
},
inactiveState supported
}
}
}
}
}
(2) Rrc Release
This is a release that suspends rather than releases. The suspendConfig block is what makes the difference. Everything the UE needs while dormant sits inside it: a full and a short I-RNTI, a RAN paging cycle of
Decoded
{
message c1: rrcRelease: {
rrc-TransactionIdentifier 0,
criticalExtensions rrcRelease: {
suspendConfig {
fullI-RNTI '123450460D'H,
shortI-RNTI '50460D'H,
ran-PagingCycle rf32,
ran-NotificationAreaInfo cellList: {
{
plmn-Identity {
mcc {
0,
0,
1
},
mnc {
0,
1
}
},
ran-AreaCells {
'001234501'H
}
}
},
t380 min30,
nextHopChainingCount 0
}
}
}
}
(3) Paging
The network now wants the UE back, so it pages. The identity used is a
Decoded
{
message c1: paging: {
pagingRecordList {
{
ue-Identity fullI-RNTI: '1234504601'H
}
}
}
}
(4) Rrc Resume Request
The UE answers the page. Only four fields are needed, because the network still holds the stored context and needs nothing more than an identity and a proof of it. The cause reads
Decoded
{
message c1: rrcResumeRequest: {
rrcResumeRequest {
resumeIdentity '504601'H,
resumeMAC-I 'F474'H,
resumeCause mt-Access,
spare '0'B
}
}
}
(5) Rrc Resume
This is by far the longest message in the sequence, at over one hundred and fifty lines. The reason is the radio bearer configuration at the top: srb-ToAddModList and drb-ToAddModList are both rebuilt here, and SRB2 is listed with
: This would be the most complicated message for Resume process.. the configuration is almost like RrcSetup / RrcReconfiguration. If the resume happens with the same cell, this message would be enough to carry PUCCH, SRS, DRX and CA configuration since the NW and UE still keep some context from previous connection, but if the resume happens in different cell, NW would need to send full configuration (like full RrcSetup).
Decoded
{
message c1: rrcResume: {
rrc-TransactionIdentifier 0,
criticalExtensions rrcResume: {
radioBearerConfig {
srb-ToAddModList {
{
srb-Identity 2,
reestablishPDCP true
}
},
drb-ToAddModList {
{
drb-Identity 1,
reestablishPDCP true
}
}
},
masterCellGroup {
cellGroupId 0,
rlc-BearerToAddModList {
{
logicalChannelIdentity 2,
reestablishRLC true
},
{
logicalChannelIdentity 4,
reestablishRLC true
}
},
mac-CellGroupConfig {
phr-Config setup: {
phr-PeriodicTimer sf500,
phr-ProhibitTimer sf200,
phr-Tx-PowerFactorChange dB3,
multiplePHR FALSE,
dummy FALSE,
phr-Type2OtherCell FALSE,
phr-ModeOtherCG real
},
skipUplinkTxDynamic FALSE
},
spCellConfig {
spCellConfigDedicated {
uplinkConfig {
initialUplinkBWP {
pucch-Config setup: {
resourceToAddModList {
{
pucch-ResourceId 16,
startingPRB 50,
intraSlotFrequencyHopping enabled,
secondHopPRB 0,
format format1: {
initialCyclicShift 8,
nrofSymbols 14,
startingSymbolIndex 0,
timeDomainOCC 2
}
},
{
pucch-ResourceId 17,
startingPRB 49,
intraSlotFrequencyHopping enabled,
secondHopPRB 1,
format format2: {
nrofPRBs 1,
nrofSymbols 2,
startingSymbolIndex 2
}
}
},
resourceToReleaseList {
16,
17
},
schedulingRequestResourceToAddModList {
{
schedulingRequestResourceId 1,
schedulingRequestID 0,
periodicityAndOffset sl40: 8,
resource 16
}
}
},
srs-Config setup: {
srs-ResourceToAddModList {
{
srs-ResourceId 0,
nrofSRS-Ports port1,
transmissionComb n2: {
combOffset-n2 0,
cyclicShift-n2 0
},
resourceMapping {
startPosition 0,
nrofSymbols n1,
repetitionFactor n1
},
freqDomainPosition 0,
freqDomainShift 5,
freqHopping {
c-SRS 11,
b-SRS 3,
b-hop 0
},
groupOrSequenceHopping neither,
resourceType aperiodic: {
},
sequenceId 500
}
}
}
}
},
csi-MeasConfig setup: {
csi-ReportConfigToAddModList {
{
reportConfigId 0,
resourcesForChannelMeasurement 0,
csi-IM-ResourcesForInterference 1,
reportConfigType periodic: {
reportSlotConfig slots80: 9,
pucch-CSI-ResourceList {
{
uplinkBandwidthPartId 0,
pucch-Resource 17
}
}
},
reportQuantity cri-RI-PMI-CQI: NULL,
reportFreqConfiguration {
cqi-FormatIndicator widebandCQI,
pmi-FormatIndicator widebandPMI
},
timeRestrictionForChannelMeasurements notConfigured,
timeRestrictionForInterferenceMeasurements notConfigured,
codebookConfig {
codebookType type1: {
subType typeI-SinglePanel: {
nrOfAntennaPorts two: {
twoTX-CodebookSubsetRestriction '111111'B
},
typeI-SinglePanel-ri-Restriction '03'H
},
codebookMode 1
}
},
groupBasedBeamReporting disabled: {
},
cqi-Table table2,
subbandSize value1
}
}
},
tag-Id 0
}
}
}
}
}
}
(6) Rrc Resume Complete
The confirmation is short, which is the point of the whole state. Eight lines close a transition that would have needed a full setup from RRC IDLE. The only content is
Decoded
{
message c1: rrcResumeComplete: {
rrc-TransactionIdentifier 0,
criticalExtensions rrcResumeComplete: {
selectedPLMN-Identity 1
}
}
}
(7) Rrc Release
The second round starts the same way as the first. The suspendConfig is present again, and the identities are new:
Decoded
{
message c1: rrcRelease: {
rrc-TransactionIdentifier 0,
criticalExtensions rrcRelease: {
suspendConfig {
fullI-RNTI '123450460A'H,
shortI-RNTI '50460A'H,
ran-PagingCycle rf32,
ran-NotificationAreaInfo cellList: {
{
plmn-Identity {
mcc {
0,
0,
1
},
mnc {
0,
1
}
},
ran-AreaCells {
'001234501'H
}
}
},
t380 min30,
nextHopChainingCount 0
}
}
}
}
(8) Rrc Resume Request
This resume is started by the UE rather than by the network, and two fields show it. The resumeIdentity reads
Decoded
{
message c1: rrcResumeRequest: {
rrcResumeRequest {
resumeIdentity '50460A'H,
resumeMAC-I 'B534'H,
resumeCause mo-Data,
spare '0'B
}
}
}
(9) Rrc Resume
The message has the same shape as the resume in the first round, and the same length. That is worth seeing directly: a UE-initiated resume costs the network as much signalling as a paged one, because the bearers have to be rebuilt either way.
Decoded
{
message c1: rrcResume: {
rrc-TransactionIdentifier 0,
criticalExtensions rrcResume: {
radioBearerConfig {
srb-ToAddModList {
{
srb-Identity 2,
reestablishPDCP true
}
},
drb-ToAddModList {
{
drb-Identity 1,
reestablishPDCP true
}
}
},
masterCellGroup {
cellGroupId 0,
rlc-BearerToAddModList {
{
logicalChannelIdentity 2,
reestablishRLC true
},
{
logicalChannelIdentity 4,
reestablishRLC true
}
},
mac-CellGroupConfig {
phr-Config setup: {
phr-PeriodicTimer sf500,
phr-ProhibitTimer sf200,
phr-Tx-PowerFactorChange dB3,
multiplePHR FALSE,
dummy FALSE,
phr-Type2OtherCell FALSE,
phr-ModeOtherCG real
},
skipUplinkTxDynamic FALSE
},
spCellConfig {
spCellConfigDedicated {
uplinkConfig {
initialUplinkBWP {
pucch-Config setup: {
resourceToAddModList {
{
pucch-ResourceId 16,
startingPRB 50,
intraSlotFrequencyHopping enabled,
secondHopPRB 0,
format format1: {
initialCyclicShift 8,
nrofSymbols 14,
startingSymbolIndex 0,
timeDomainOCC 2
}
},
{
pucch-ResourceId 17,
startingPRB 49,
intraSlotFrequencyHopping enabled,
secondHopPRB 1,
format format2: {
nrofPRBs 1,
nrofSymbols 2,
startingSymbolIndex 2
}
}
},
resourceToReleaseList {
16,
17
},
schedulingRequestResourceToAddModList {
{
schedulingRequestResourceId 1,
schedulingRequestID 0,
periodicityAndOffset sl40: 8,
resource 16
}
}
},
srs-Config setup: {
srs-ResourceToAddModList {
{
srs-ResourceId 0,
nrofSRS-Ports port1,
transmissionComb n2: {
combOffset-n2 0,
cyclicShift-n2 0
},
resourceMapping {
startPosition 0,
nrofSymbols n1,
repetitionFactor n1
},
freqDomainPosition 0,
freqDomainShift 5,
freqHopping {
c-SRS 11,
b-SRS 3,
b-hop 0
},
groupOrSequenceHopping neither,
resourceType aperiodic: {
},
sequenceId 500
}
}
}
}
},
csi-MeasConfig setup: {
csi-ReportConfigToAddModList {
{
reportConfigId 0,
resourcesForChannelMeasurement 0,
csi-IM-ResourcesForInterference 1,
reportConfigType periodic: {
reportSlotConfig slots80: 9,
pucch-CSI-ResourceList {
{
uplinkBandwidthPartId 0,
pucch-Resource 17
}
}
},
reportQuantity cri-RI-PMI-CQI: NULL,
reportFreqConfiguration {
cqi-FormatIndicator widebandCQI,
pmi-FormatIndicator widebandPMI
},
timeRestrictionForChannelMeasurements notConfigured,
timeRestrictionForInterferenceMeasurements notConfigured,
codebookConfig {
codebookType type1: {
subType typeI-SinglePanel: {
nrOfAntennaPorts two: {
twoTX-CodebookSubsetRestriction '111111'B
},
typeI-SinglePanel-ri-Restriction '03'H
},
codebookMode 1
}
},
groupBasedBeamReporting disabled: {
},
cqi-Table table2,
subbandSize value1
}
}
},
tag-Id 0
}
}
}
}
}
}
(10) Rrc Resume Complete
The second round closes as the first did. Comparing this against the resume above it shows the asymmetry the state is built on, with a long message from the network and a short one back from the UE.
Decoded
{
message c1: rrcResumeComplete: {
rrc-TransactionIdentifier 0,
criticalExtensions rrcResumeComplete: {
selectedPLMN-Identity 1
}
}
}
UE Capability
RRC INACTIVE is not something a network can simply use. The UE has to say it supports the state, and one optional field carries that answer. Without it the network keeps the UE in CONNECTED or releases it to IDLE.
Following is based on
UE-NR-Capability-v1530 ::= SEQUENCE {
fdd-Add-UE-NR-Capabilities-v1530 UE-NR-CapabilityAddXDD-Mode-v1530 OPTIONAL,
tdd-Add-UE-NR-Capabilities-v1530 UE-NR-CapabilityAddXDD-Mode-v1530 OPTIONAL,
dummy ENUMERATED {supported} OPTIONAL,
interRAT-Parameters InterRAT-Parameters OPTIONAL,
inactiveState ENUMERATED {supported} OPTIONAL,
delayBudgetReporting ENUMERATED {supported} OPTIONAL,
nonCriticalExtension UE-NR-Capability-v1540 OPTIONAL
}
One field settles it, and it sits in a Release 15 extension of the capability message. The field is optional, so a UE that omits it is simply not offering the state.
The capability is a single enumerated value : inactiveState is ENUMERATED {supported} and OPTIONAL, so it is present or it is not.It travels in a versioned extension : the field sits in UE-NR-Capability-v1530, which is reached through the nonCriticalExtension chain of the capability message.The network asks before it configures : the capture in step 1 above is the UECapabilityInformation that carries this field, and it comes before any suspendConfig.Absent means the state is unavailable : without the field the network cannot suspend the UE, so the only ways out of CONNECTED are staying there or releasing to IDLE.
RRC Parameters
Four listings follow, and they cover the two directions of the transition. RRCRelease with suspendConfig sends the UE into RRC INACTIVE. RRCResumeRequest brings it back, and ResumeCause says why.
Following is based on
RRCRelease ::= SEQUENCE {
rrc-TransactionIdentifier RRC-TransactionIdentifier,
criticalExtensions CHOICE {
rrcRelease RRCRelease-IEs,
criticalExtensionsFuture SEQUENCE {}
}
}
RRCRelease-IEs ::= SEQUENCE {
redirectedCarrierInfo RedirectedCarrierInfo OPTIONAL, -- Need N
cellReselectionPriorities CellReselectionPriorities OPTIONAL, -- Need R
suspendConfig SuspendConfig OPTIONAL, -- Need R
deprioritisationReq SEQUENCE {
deprioritisationType ENUMERATED {frequency, nr},
deprioritisationTimer ENUMERATED {min5, min10, min15, min30}
} OPTIONAL, -- Need N
lateNonCriticalExtension OCTET STRING OPTIONAL,
nonCriticalExtension RRCRelease-v1540-IEs OPTIONAL
}
Following is based on
SuspendConfig ::= SEQUENCE { fullI-RNTI I-RNTI-Value, shortI-RNTI ShortI-RNTI-Value, ran-PagingCycle PagingCycle, ran-NotificationAreaInfo RAN-NotificationAreaInfo OPTIONAL, -- Need M t380 PeriodicRNAU-TimerValue OPTIONAL, -- Need R nextHopChainingCount NextHopChainingCount, ..., [[ sl-UEIdentityRemote-r17 RNTI-Value OPTIONAL, -- Cond L2RemoteUE sdt-Config-r17 SetupRelease { SDT-Config-r17 } OPTIONAL, -- Need M srs-PosRRC-Inactive-r17 SetupRelease { SRS-PosRRC-Inactive-r17 } OPTIONAL, -- Need M ran-ExtendedPagingCycle-r17 ExtendedPagingCycle-r17 OPTIONAL -- Cond RANPaging ]], [[ ncd-SSB-RedCapInitialBWP-SDT-r17 SetupRelease {NonCellDefiningSSB-r17} OPTIONAL -- Need M ]], [[ resumeIndication-r18 ENUMERATED {true} OPTIONAL, -- Need N srs-PosRRC-InactiveEnhanced-r18 SetupRelease { SRS-PosRRC-InactiveEnhanced-r18 } OPTIONAL, -- Need M ran-ExtendedPagingCycleConfig-r18 ExtendedPagingCycleConfig-r18 OPTIONAL, -- Cond RANPaging multicastConfigInactive-r18 SetupRelease { MulticastConfigInactive-r18 } OPTIONAL -- Need M ]] }
Following is based on
RRCResumeRequest ::= SEQUENCE {
rrcResumeRequest RRCResumeRequest-IEs
}
RRCResumeRequest-IEs ::= SEQUENCE {
resumeIdentity ShortI-RNTI-Value,
resumeMAC-I BIT STRING (SIZE (16)),
resumeCause ResumeCause,
spare BIT STRING (SIZE (1))
}
RRCResumeRequest1 ::= SEQUENCE {
rrcResumeRequest1 RRCResumeRequest1-IEs
}
RRCResumeRequest1-IEs ::= SEQUENCE {
resumeIdentity I-RNTI-Value,
resumeMAC-I BIT STRING (SIZE (16)),
resumeCause ResumeCause,
spare BIT STRING (SIZE (1))
}
Following is based on
ResumeCause ::= ENUMERATED {emergency, highPriorityAccess, mt-Access, mo-Signalling, mo-Data, mo-VoiceCall, mo-VideoCall, mo-SMS, rna-Update, mps-PriorityAccess, mcs-PriorityAccess, mt-SDT-v1810, srs-PosConfigOrActivationReq-v1800, spare3, spare2, spare1 }
Reference
[1] 3GPP 38.331
[2] Key details of RRC Inactive State in 5G.