5G Standalone Architecture – RRC Inactive State

The show must go on, so at some point, network operators will start putting 5G core networks in place which means that mobile devices will use the 5G NR Standalone (SA) air interface for signaling instead of LTE anchor cells. So I had a look at 3GPP TS 38.331 which contains the Radio Resource Control (RRC) specification to see how RRC is done in 5G.

Unlike many other things that 5G touches, it seems that the 5G RRC protocol still very much looks like its 4G ancestor. Some terms were slightly changed, e.g. RRC Connection Reconfiguration has become RRC Reconfiguration, but the basic procedures I found in the spec are still the same. That said, there are a number of new things that have been added for 5G. One thing that might become quite useful is the new RRC_Inactive state: It sits between the RRC_Idle and RRC_Connected state already known from LTE and is similar to the 3G Cell/URA_PCH state. The idea behind this new state is to hide the radio connection state from the core network to reduce the number of signaling and tunnel establishments and tear-downs between the radio network and the core network. This happens very frequently especially with devices such as smartphones. Even when the screen is turned-off, background applications such as messengers continue to exchange data with the Internet to keep the TCP connections alive on a frequent basis. Typically, keep alive messages are sent every few minutes, which in LTE always requires a new tunnel setup because the radio has been put into RRC_Idle state to conserve energy.

The 5G radio network can instruct a mobile device to go to RRC_Inactive state with an RRC Release message that contains a ‘suspendConfig’. The radio link is then taken down to conserve energy but the logical signalling link to the AMF in the core network and the user data tunnel to the UPF remain in place. When new data arrives from the network side for a mobile device, the core network just forwards it to the gNB to which the user data tunnel is connected to. The gNB then organizes a RAN-based paging on all gNBs that are in same RAN notification area in which the mobile device is free to roam without having to inform the network about its new location. To the core network, the paging process is transparent. If the mobile device responds to the RAN based paging with an RRC Resume Request from a different gNB, the radio bearer and signaling context has to be transferred to the other gNB, In a subsequent step, the signaling link and user data tunnel need to be moved as well.

In case the mobile device moves to a cell that is outside the configured RAN Notification Area (RNA) it has to establish an RRC connection and send an RNA Update message. The gNB then contacts the previous gNB and the user’s context is transferred to the new gNB. The RRC connection can then be set to RRC_Inactive again and a new RAN notification area is configured in the mobile device in which it can roam freely without notifying the network.

Looks very useful to me and I wouldn’t be surprised to see it being used in practice once standalone mode gains traction.