November 27, 2018

By the 3GPP RAN and RAN WG Chairs

Following the freeze of 5G Non-Standalone (NSA) specifications in March 2018 and 5G Standalone (SA) specifications in September 2018 3GPP has been continuing its efforts to ensure full functional integrity and interoperability of 5G NR specifications, especially in light of the imminent first deployments.

There has recently been a lot of industry interest in some of the corrections to the 5G NR specifications, on whether they are backwards compatible (BC) or non backwards compatible (NBC), and possible consequences for network deployment plans and chipset/device plans. Here is a summary from the 3GPP RAN and RAN WG Chairmen on how 5G NR corrections are being handled in 3GPP.

After completion of every release of the 3GPP specifications there is an ongoing process to fix “bugs” in the standards. The process uses Change Requests (CRs) submitted by member companies to the RAN working group meetings. CRs are discussed, often modified to address feedback from other companies, and then agreed or rejected. Four times a year the agreed CRs are approved by the TSG RAN plenary meetings and then included in the next version of the specifications.

Candidate CRs are discussed and agreed strictly based on technical merit. On top of the technical merit, the group must decide whether the correction is “essential” for this release of the specification or it could be considered for the next release (in which case, for example, a different solution to address the particular issue might be considered). It is also important to understand that agreements in 3GPP are made by consensus and that the vast majority of the companies involved in making and deploying products for 5G participate in the consensus-building process. Therefore, all CRs will have been very carefully considered in terms of their foreseen impact on development and deployment, and CRs are only approved if every company in 3GPP accepts it.

When discussing BC vs NBC CRs it is important to distinguish different types of correction:

1 - Corrections to the ASN.1

ASN.1 is an established standard notation. It is used to define message syntax of certain protocols between the network and the UE (e.g. RRC protocol), or between network nodes (e.g. F1AP, the CU-DU application protocol). ASN.1 has been used in 3GPP protocols since 3G, and its mechanisms are well understood. It is easy to categorise changes to the ASN.1 as being BC or NBC from the notation point of view. The consequence of an NBC change can be very severe, for example it could mean that a UE that does not implement the ASN.1 change will fail to decode the entire message, which will likely lead to a connection failure (i.e. a 'call drop'). Furthermore, the impact of an NBC change to the ASN.1 could go far beyond the piece of functionality addressed by the correction; for example, an apparently small change to the ASN.1 to fix a feature that may not even be on any operator's initial deployment plans could potentially lead to connection failures or call drops (i.e. the change is not 'isolated impact').

These changes are what is commonly referred to as BC or NBC changes, but one should be precise and refer to BC/NBC changes to the ASN.1.

There is often a choice whether to make a correction as a BC or NBC change to the ASN.1. The NBC change might be easier and cleaner, for example giving a more optimal coding, but it might have the consequences described above. The BC change leverages the ASN.1 extension mechanism which is used to add functionality to new releases. For TSG RAN #82 meeting and the resulting December 2018 version of the specification, there is no CR containing NBC changes to the ASN.1 of the NR RRC protocol.

2 - Functional corrections

For corrections that do not touch the ASN.1 at all, as well as those that might include BC ASN.1 changes, we can also consider whether the correction is BC or NBC from a functional point of view. Unfortunately, in this case determining whether a change is BC or NBC is much less straightforward. To fully understand the impact of such a CR on the network or on the UE, a deeper evaluation is necessary. In particular, the impact analysis on the CR coversheet always provides the following information:

1. The functionality affected by the CR;
2. The impact if only the UE or only the network side implements the CR;
3. The consequences if the CR is not agreed at all

For example, the impact analysis might show that the functionality affected will not work without some correction, it will not work if only the UE implements the CR, and it will not work if only the network implements the CR. In this case, then, this CR will be essential for both UE and network to implement in order to use the functionality. This might be seen as 'NBC' because it will never happen that, for this specific functionality, a new UE might work with an older network or the other way around, but on the other hand without such a CR the functionality will also not work. For these changes there is generally little choice about BC or NBC: it is simply necessary to fix the problem and understand the consequences. Hence, designation of such changes into BC or NBC categories is never done; the focus is instead on understanding all the details and ensuring the right decision is made in light of the implementation and deployment plans.

These changes typically have 'isolated impact', meaning that it is only the impacted functionality that is affected - i.e. fixing the error in this functionality will have no consequences on other functionality. This is also indicated on the CR coversheet. So, if the correction relates to an advanced/optional feature that might not be on initial deployment plans nor implemented/supported by early UEs, then it will not impact those plans and UEs.

All of the above also applies to network interfaces and protocols (e.g. NG, Xn, F1, E1), with some additional considerations. For example, it is typically possible for an operator to update the software on already deployed network nodes without impact on UEs, in order to comply with the latest 3GPP protocol release. This alignment is generally considered beneficial, because it enables an operator to manage a homogeneous set of features across all network nodes and interfaces.

Finally, it is also worth noting that some corrections are of a 'clarification' nature. This means that without them the specification may not be completely clear and hence there is a risk of incorrect implementation by UE or network vendors. Such unclarity is of course still worth fixing, but it is quite likely that network and chipset vendors who are engaged in the 3GPP process have well understood the specification as it was intended, so their implementations may be already aligned to that CR regardless of whether it is agreed or not.

In summary, it is well understood in 3GPP that the September 2018 version of the NR specifications at large constitutes the basis for initial 5G deployments around the globe. For any functionality that has been identified as needing a correction, the corresponding CRs will be very carefully analysed as per the above to ensure that implementation and deployment plans are not adversely impacted.

[END]

The following 3GPP RAN leaders (working on 5G NR) have contributed:

• Balazs Bertenyi, RAN Chairman, Nokia
• Wanshi Chen, RAN 1 Chairman, Qualcomm
• Richard Burbidge, RAN 2 Chairman, Intel
• Gino Masini, RAN 3 Chairman, Ericsson
• Xutao Zhou, RAN 4 Chairman, Samsung
• Jacob John, RAN 5 Chairman, Motorola

Acronyms

(For Information, added by web editor for clarification - not reviewed by authors)

BC - Backwards compatible
CR - Change request
NBC - Non backwards compatible
WG - Working Group
RAN - Radio Access Network
ASN.1 - Abstract syntax notation one. See http://www.3gpp.org/specifications/61-asn-1 and https://www.itu.int/en/ITU-T/asn1/Pages/introduction.aspx for more detail.
UE - User Equipment
RRC - Radio Resource Control
F1AP – See ‘NG-RAN; F1 Application Protocol’ (TS38.473)
CU-DU - Centralized baseband Units and Distributed radio Units - See ‘NG-RAN; Architecture description’ (TS 38.401)

Contact for this article: Kevin FLYNN, Marketing and Communications Officer, 3GPP