5G RRC Protocol And How It Compares to 4G RRC

Recently I’ve been looking a bit at the 5G NR Radio Resource Control (RRC) protocol in 3GPP TS 38.311 to get an idea how it is structured and how it compares to the LTE RRC protocol specified in 3GPP TS 36.331. As Ralf points out in the comments below (thanks very much!) some parts of it are already used today to embed 5G configuration information in 4G RRC messages for EN-DC, while other parts will become relevant with 5G NR Standalone, i.e. once a 5G core network is available and devices and the gNBs have implemented standalone operation.

Fortunately, the NR RRC protocol pretty much looks like the LTE RRC protocol from a procedural point of view. The procedure names are still pretty much the same, one still does RRC connection establishments, RRC re-configurations, authentication, ciphering, bearer establishments, etc. Some information elements of course differ a bit as 5G equivalents of 4G parameters are necessary in some places. But apart from that, everything looks pretty familiar. Measurement configurations are still done in the same way with measurement object and report configurations, and actual measurement instructions that bind these together are also still there. Events A1 to A6 and B1 + B2 look very familiar and serve the same purpose as in LTE.

The MIB and the SIBs also serve the same purpose, but their handling is a bit different. While MIB and SIB1 are always periodically broadcast, all other MIBs do not necessarily have to be broadcast but can be requested by mobile devices once they are connected to the cell. If cells will actually be configured this way or if they will just also be broadcast, which seems to be allowed, I guess only time will tell.

One big new thing that did not exist in LTE is the RRC-Inactive state which sits between the RRC-Idle and RRC-Connected states already known from LTE. The state is interesting because it allows to take down the radio bearers while leaving the signaling connection and the user data tunnel of a user to the core network in place. I can imagine that this will be used quite a bit as core network connectivity today is frequently established and torn down in the modern smartphone world, were many apps run in the background and require keep-alives for their TCP connections to stay open.

One little thing I’ve come across that I haven’t noticed in the LTE spec so far (*)  is the “Counter Check” procedure. The specification states that the procedure can be used by the network to check how much data the device thinks it has transmitted so far and then compare with the same network based counters. This allows to detect packet insertion attacks. The spec doesn’t say if and how this procedure shall actually be used but I nevertheless found it interesting that somebody took the time to specify this.

And that’s pretty much it. Anything revolutionary that is new compared to LTE RRC I have missed?

(*) As Ralf points out below, it’s also there in 36.331 for LTE, even since Release 8 actually!