AT&T CEO Randall Stephenson says, "If you have deployed Huawei as your 4G network, Huawei is not allowing interoperability to 5G." I can't confirm whether Huawei or others are causing the problem, but there has been minimal interoperability testing. I've reached out to all the vendors to make sure I haven't missed important data in for interoperability, but they have none to offer. I infer from that interop is an important problem in 5G, although I haven't found any evidence Huawei is the main problem. Nokia, Ericsson, Samsung - please get me data.
Some problems are inevitable in 5G. It's so complicated that over 5,000 patents have been issued. In DSL, all the vendors bring their boxes to the University of New Hampshire, where they are carefully tested to solve problems. The engineers involved work in the spirit of "Let's fix things." CableLabs serves a similar function.
Hans Vestberg of Verizon boasts 5G is being delivered two years faster than expected. But his network and all others have been severely affected by the speed-up. Verizon has basically frozen their fixed wireless 5G Home for six months.
Other than Randall's comment, I've heard nothing about interop problems. There almost certainly are some developing, given the complexity. With Huawei, Nokia, Ericsson and others with at least 5,000 engineers working on 5G, there's a good chance most problems will be quickly solved.
Saudi Arabia Telecom has performed a Multi-Vendor-Integration-Verification (MVIV) using STC's Huawei and Cisco core infrastructure with Ericsson and Nokia-supplied 5G radio networks. SK in Korea tested E&N with a Samsung core in the lab. While welcome, neither indicated they used a substantial interop test suite.
Ericsson is not using the standard definition of "interoperability" for the following statement. To most, "Interoperability" implies a robust interconnection that will have few problems in the field. The examples they offer include, "Ericsson and Qualcomm complete 5G data call on 2.6 GHz band." A single data call proves very little, especially if a mobile system hasn't been tested moving. For example, timing problems in the handoff between cells are a problem that needs to be ruled out, especially at gigabit speeds.
Technology milestones: showcasing 5G NR interoperability
Essential parts of the 5G standard have been completed with the approval of 5G New Radio (NR) specifications for non-standalone and standalone deployments of 5G. Ericsson is a key contributor to the standardization process. We are committed to rapidly applying these standards to our technology development and accelerate the commercial deployment of standard-based 5G networks. We have achieved interoperability between Ericsson Radio System commercial radios and the 5G test devices of our ecosystem partners on all main spectrum bands, including 3.5, 28 and 39 GHz for initial 5G launches.
Interoperability and compatibility of 5G specifications
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:
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.
The following 3GPP RAN leaders (working on 5G NR) have contributed: