RRC States

An LTE UE is always in one of a small number of RRC states. The state decides which procedures the UE runs, whether the UE or the network controls mobility, and how much radio resource the eNB spends on the UE. The states themselves are simple, but two terms that engineers use every day, Connected User and Active User, are often mixed with them. I'll start with the state diagram, then separate those two terms, connect them to SRB and DRB setup, and finish with what later releases added to the picture.

What are the LTE RRC states and how does the UE move between them ?

At high level view, LTE RRC has only two status (RRC Connected and RRC Idle). It may sound too simple comparing to other Radio Access Technology, but the detailed processes undergoing in these two status is not as simple as you might think. Following illustration is based on 36.331 4.2.1 UE states and state transitions including inter RAT.

As an engineer, you need to have ability to see both forest and the individual trees in the forest. This illustration is important but only a picture of forest. To see the individual trees in the forest, you need to look into almost every pages in this site. I recommend you to switch back and forth between this page and other pages related to each individual process.

The diagram below puts the two E-UTRA states in the middle, with E-UTRA RRC CONNECTED at the top and E-UTRA RRC IDLE at the bottom. The UTRAN states sit on the left and the GERAN states on the right. Each arrow carries the name of the procedure that moves the UE, such as Handover, Reselection, CCO or Connection establishment/release. The two callouts list what the UE does in each E-UTRA state.

E-UTRA RRC CONNECTED and RRC IDLE with the UTRAN and GERAN states and the inter RAT mobility procedures between them

Figure 1. E-UTRA states and inter RAT mobility, after 36.331 Figure 4.2.1-1. The network moves a connected UE by Handover or CCO, while an idle UE moves itself by Reselection.

The upper callout belongs to RRC CONNECTED. It covers unicast data transfer in DL only, UL only or both, Connected Mode DRX, Carrier Aggregation and network controlled mobility. It also lists the UE tasks: monitoring paging and SIBs, monitoring the control channels of the shared data channel, CSI reporting and neighbour cell measurement reporting.
Item i) in the upper callout, No User Data Transfer, is also a valid RRC CONNECTED case. A connected UE does not have to carry data at every moment, and the Active User section below builds on that point.
The lower callout belongs to RRC IDLE. It covers UE specific DRX, UE controlled mobility by Cell Reselection and CCO, monitoring paging and SIBs, neighbour cell measurement, and logging of measurements with location and time for UEs configured for logged measurement.
Only Connection establishment/release links RRC IDLE and RRC CONNECTED inside E-UTRA. Every other arrow crosses to another RAT.
Between RRC CONNECTED and GSM_Idle/GPRS Packet_Idle, the label is CCO with optional NACC. NACC stands for Network Assisted Cell Change, which gives the UE GERAN system information before it moves.

Let's read the two callouts as a question of control. In RRC CONNECTED, the eNB knows the UE at cell level, so the eNB decides when the UE changes cell. The UE only measures and reports. In RRC IDLE, the eNB normally keeps no context for the UE, so the UE chooses its own cell by reselection. The core network can still reach it by paging. This is why the arrows out of RRC CONNECTED say Handover or CCO, and the arrows out of RRC IDLE say Reselection.

E-UTRA has two RRC states when it connects to EPC : RRC_IDLE and RRC_CONNECTED, with Connection establishment/release as the only path between them.
The network controls mobility in RRC_CONNECTED : it uses Handover, or CCO with optional NACC towards GERAN.
The UE controls mobility in RRC_IDLE : it uses cell reselection, and it still listens to paging and system information.
RRC_CONNECTED does not mean data is flowing : the diagram lists No User Data Transfer as one of its cases.

What is the difference between a Connected User and an Active User ?

I was asked of what is the difference between Connected UE and Active UE. However, I don't personally see the term Active User in any of 3GPP specification (Probably I missed something when I am reading the documents). However, from the context in which these two terms are used, I would define these terms as follows.

Connected User : User (UE) that are in RRC Connected
Active User : User (UE) that are in RRC Connected and undergoing User Data Transaction and you may include the UE that performing Signaling Messages (e.g, sending Measurement Report etc) as well.

Based on this definition, you may say Active User can be a kind of subset of Connected user meaning that the number of Active User in a specific moment (at a specific subframe) is highly likely to be smaller than the number of Connected User. It seems that the concept of Active User is often used in the context of estimating the capacity of a base station. In terms of base station point of view, UEs not transmitting/receiving any data (ether U plane or C plane data) would not put any load on it. So these UEs can almost be ignored for that specific moment.

One 3GPP document does use the term, although not as an RRC state. 36.314 defines an eNB Layer 2 measurement called Number of Active UEs, for OAM performance observability. Its purpose is the capacity question above: it helps to work out the bitrate that UEs achieve while they are active.

The 36.314 definition is narrower than the one above in two ways. First, it counts only data on DRBs. A UE counts as active when there is buffered data for its DRBs in the DL, in the UL, or in both. So a UE that is sending only a Measurement Report on an SRB does not count. Second, the eNB samples the count at least once every 0.1 s and averages it over the measurement period. So it is not a per subframe count. For the UL, the eNB cannot see the UE buffer directly. It estimates it from Buffer Status Reports, semi-persistent grants and ongoing HARQ transmissions.

36.314 has four variants of this measurement. Two are per direction and per QCI: Number of Active UEs in the DL per QCI and Number of Active UEs in the UL per QCI. The other two combine DL and UL: Number of Active UEs, and Number of Active UEs per QCI. If you compare a vendor counter with your own estimate, check which variant the counter uses first.

Every Active User is a Connected User : but a Connected User is active only while it has data to send or receive.
3GPP defines Active UE as an eNB measurement, not as a state : 36.314 clause 4.1.3 counts UEs with buffered DRB data.
The 36.314 count leaves out signalling only UEs : it looks at DRB buffers, not at SRB traffic.
The 36.314 count is an average : the eNB samples it at most 0.1 s apart, so it is not a per subframe snapshot.

How do the RRC state, SRB/DRB setup and Connected/Active User relate ?

I think I need to add some comments on the inter-relations among the terms RRC Status and SRB/DRB assignment and Connected/Active User. The three terms live at different layers. The RRC state belongs to RRC, SRB and DRB are radio bearers that RRC configures, and Connected or Active User describes how the eNB sees its load. So I'll follow one UE through the connection setup and watch all three change.

If you think of the protocol sequence of what UE goes through to get into 'RRC Connected Status' from 'RRC Idle', you would notice it always goes through 'RRC Connection Reconfiguration' and would/would not go through 'RRC Connection Setup' depending on whether it is the initial attach process or just to add additional bearer.

If you look further details of RRC Connection Setup and RRC Conection Reconfiguration message, you would notice that RRC Connection Setup is mainly for SRB establishment and RRC Connection Reconfiguration is mainly for setting up DRB setup (RRC Connection Reconfiguration can redefine SRB as well).

This implies that 'RRC Connected Status' indicates the status in which SRB and DRB is allocated for the UE.

Strictly, 36.331 puts the start of RRC_CONNECTED a little earlier. RRC connection establishment involves the establishment of SRB1, so the UE is already in RRC_CONNECTED once RRC Connection Setup completes, with SRB1 only. The eNB then activates AS security. The eNB sets up SRB2 and the DRBs with RRC Connection Reconfiguration only after that, because E-UTRAN does not establish SRB2 or a DRB before security is active. So a short phase exists in which the UE is in RRC_CONNECTED with SRB1 and no DRB. In the normal case, that phase lasts only until the reconfiguration arrives.

Then, can I say the UE with SRB/DRB is always an Active User ?

Not Necessarily. SRB/DRB is more of a concept running through full stack (i.e, PHY to Core Network), but Active User is more for MAC/PHY concept. Even when a UE is assinged SRB/DRB, there can be a certain moment (Subframe) in which no MAC/PHY resource is allocated for it, meaning no PHY/MAC data transfer happens. In this case (i.e, No PHY/MAC data transfer), we can say that the UE is in RRC Connected Status but is not in the Active Status for that specific subframe. We can call it 'Active user' in another subfrme if it get granted for data transmission in that subframe.

RRC Connection Setup brings the UE into RRC_CONNECTED : it establishes SRB1.
RRC Connection Reconfiguration adds SRB2 and the DRBs : and it does so only after AS security is active.
A UE that already has a connection skips the setup : an additional bearer needs only a reconfiguration.
Having a DRB does not make a UE active : the UE is active in a subframe only when it is scheduled, or in the 36.314 sense only when its DRBs have buffered data.

What did later releases add to the RRC states ?

Figure 1 shows LTE as it was defined for EPC, with two states and GERAN and UTRAN as the only neighbours. The current 36.331 clause 4.2.1, in v19.3.0, still carries Figure 4.2.1-1 with the same two states. But it adds a third state and a longer list of tasks inside the old two, so the callouts in Figure 1 are no longer complete.

The third state is RRC_INACTIVE, and it exists only when the LTE cell is connected to 5GC. A UE in RRC_CONNECTED enters RRC_INACTIVE when the network suspends the connection in the RRCConnectionRelease message. The UE then stores the UE Inactive AS context. It follows the RRC_IDLE procedures unless 36.331 says otherwise, but the RRC layer can also configure its DRX. The network gives it a RAN-based notification area, and the UE performs a RAN-based notification area update periodically and whenever it moves out of that area. The UE monitors paging for both CN paging with the 5G-S-TMSI and RAN paging with the fullI-RNTI.

The way back to RRC_CONNECTED is a resume rather than a new setup. The resume procedure re-activates security and re-establishes the SRBs and DRBs from the stored context. The network does not have to accept the request. It can resume the connection, reject it with a wait time, suspend the UE again, release it to RRC_IDLE, or instruct the UE to start NAS level recovery. A UE in RRC_INACTIVE also enters RRC_IDLE when it moves to another RAT or switches to another CN type.

For EPC, a similar suspension exists without a new state. The E-UTRAN can suspend the RRC connection, and the UE stores the UE AS context and its resumeIdentity but moves to RRC_IDLE. Suspension needs at least one DRB that was successfully established.

The two old states also carry more tasks than Figure 1 lists. In RRC_IDLE, the UE may perform EDT, may transmit using PUR, and performs idle/inactive measurements when it is configured for them. With EDT or PUR, a small amount of data can travel during the connection attempt itself, and the network may then keep the UE out of RRC_CONNECTED altogether. In RRC_CONNECTED, the list now includes DC with an SCG, (NG)EN-DC with an NR SCG, and NE-DC with an NR MCG, next to Carrier Aggregation. Clause 4.2.1 also adds figures for mobility between E-UTRA/EPC, E-UTRA/5GC and NR, and it allows connection release with redirection to NR.

RRC_INACTIVE is the third LTE state : it applies only when the UE is connected to 5GC.
RRCConnectionRelease with suspension moves a UE to RRC_INACTIVE : and the UE keeps the UE Inactive AS context.
Resume replaces setup on the way back : it re-activates security and re-establishes the SRBs and DRBs.
With EPC, a suspended UE is in RRC_IDLE : it keeps its context but has no third state.
EDT and PUR send data from RRC_IDLE : so data transfer is no longer limited to RRC_CONNECTED.

Reference

36.331 v19.3.0 : E-UTRA Radio Resource Control - RRC; Protocol specification. Clause 4.2.1 UE states and state transitions including inter RAT, clause 5.3.1.1 RRC connection control, clause 5.3.8.7 UE actions upon entering RRC_INACTIVE.
36.314 v19.0.0 : E-UTRA Layer 2 - Measurements. Clause 4.1.3 Number of active UEs.