Pages

Subscribe:
Showing posts with label 3GPP. Show all posts
Showing posts with label 3GPP. Show all posts

How LTE RRC (4G) and NR RRC (5G) Protocols are used in Parallel in EN-DC (5G NSA)

Last week I had a fruitful discussion with a fellow blogger on the web, Martin Sauter (@mobilesociety) regarding a post in which he compared features of LTE RRC (3GPP 36.331) and NR RRC (3GPP 38.331).

It was Martin's impression that the NR RRC protocol is primarily designed to be used in the 5G standalone mode. However, as I wrote in a comment to his post the NR RRC protocol is already used in EN-DC radio connections.

The reason is that the UE must be informed about Hundreds of lower layer 5G parameters (physical, MAC, RLC) that are needed for the payload transmission over 5G frequencies. Indeed, when it comes to user plane data transmission the gNB works almost independently and the UE must handle LTE and NR radio links in parallel.So it has two different radio units (even if combined into a single radio chip set). This double-functionality is also one important reason why 5G smartphones are quite expensive. It is a lot of software and know-how that sits inside these chips.

How much surplus code is really necessary to enable 5G technology becomes visible when looking at trace data using a state-of-the-art protocol test and monitoring tool.

When reading the 3GPP 36.331 (LTE RRC) standard document one might have the impression that just a few 5G parameters have been incorporated into this protocol to support EN-DC connections.

However, when looking into the details of e.g. the nr-SecondaryCellGroupConfig-r15 it turns out that some this single information element is indeed a huge block of NR information (total size: 1111 Byte)

It is an entire 5G RRC message (rRCReconfiguration) that is piggybacked by the LTE rrcConnectionReconfiguration message, because in 5G non-standalone mode this is the only way to transmit 5G signaling information to the UE. And as highlighted in the upper part of the screenshot there are a couple of NR RRC messages transported in so-called NR-RRCContainers* during the EN-DC Establishment Procedure.

And what about 5G standalone mode? For this radio access technology the 3GPP 38.331 Rel. 15 protocol is suitable as well. Hence, some parameters mentioned in the standard paper will never be seen in EN-DC. A perfect example is S-NSSAI (Single Network Slice Selection Assistance Information), because network slicing requires the connection with a 5G core network as a prerequisite. 


(click on image for larger version)

* This is not an 3GPP term, but coined by the developers of the decoding engine.

How MOCN RAN-Sharing Works


Shared RAN deployment scenarios are an excellent opportunity for mobile network operators to lower their investments on both, network hardware and operational costs by sharing resources.

The MORAN approach where each operator continues to have its dedicated spectrum (= radio network cells) is easy to understand.

However, the Multi-Operator Core Network (MOCN) is a bit more complex, especially if one of the involved operators asks for service assurance KPIs that apply to its - and only its - subscribers. In this case it is a prerequisite to find out which "call" belongs to which core network operator to enable further KPI correlation and aggregation.

The figure below illustrates how this works:

(click on picture for larger version)

In the System Information Block (SIB) 1 of the cell a list of PLMN-IDs is broadcasted followed by a single Tracking Area Code (which can be combined each of the PLMN-IDs to get multiple TAIs) and a single Cell Identity.

Encoding is specified in 3GPP 36.331 (RRC) as follows:

SystemInformationBlockType1 ::=     SEQUENCE {
    cellAccessRelatedInfo              SEQUENCE {
       plmn-IdentityList                 PLMN-IdentityList,
       trackingAreaCode                  TrackingAreaCode,
       cellIdentity                      CellIdentity,

The spec further defines that the ECGI is the CellIdentiy combined with the first (!!!) PLMN-ID from the PLMN-ID List:

CellGlobalIdEUTRA field descriptions
cellIdentity
Identity of the cell within the context of the PLMN.
plmn-Identity
Identifies the PLMN of the cell as given by the first PLMN entry in the plmn-IdentityList in SystemInformationBlockType1.

So there is one and only 1 ECGI per radio cell in the network, but multiple PLMN-IDs and hence, multiple TAI, one fore each core network operator, are broadcasted.

During RRC establishement a particular UE signals on behalf on the selected PLMN-ID information element in the RRC Connection Setup Complete message to which core network operator shall be used.

This information is "translated" by the eNB into ECGI and TAI with different PLMN-IDs. While the ECGI displays the PLMN-ID of the operator that owns the RAN equipment the TAI shows the selected PLMN-ID of the UE's core network operator. 

5G Evolution with Matthew Baker, Nokia


I wrote a summary of CW (Cambridge Wireless) TEC conference here a couple of months back. The last session was on "Getting ready for Beyond-5G Era". Matthew Baker, Head of Radio Physical Layer & Co-existence Standardization, Nokia Bell Labs was one of the speakers. His talk provided a summary of 3GPP Rel-15 and then gave a nice and short summary of all the interesting things coming in Rel-16 and being planned for Rel-17. The slides from his presentation is embedded below:



Nokia also created a short video where Matthew talks about these new features. It's embedded below:



Related Posts: