With many operators starting to launch 5G, it became clear that Enhanced Mobile Broadband (eMBB) coupled with 5G NSA architecture is the quick win. A comfort zone for CSPs Marketing mapping the technology to high internet speed & attractive Data Packages.

Furthermore, most of the Ultra Reliable & Low Latency communications (uRLLC) use cases are still in the PoC phase and the readiness of the Network is still unverified. 

On the ground, the adaptation for 5G NSA architecture required relatively minimal changes on the Network side.

CSPs found that 5G NSA would advocate Market leadership and provide more attractive data packages although it doesn't bring the full 5G Flavor.

Most of the CSPs have made the investments and I'd say that such investment may delay the 5G SA Adoption.

On the right-hand side, this is an example of 5G Data bundles offered by a Mobile Operator in Kuwait. <Copyrights reserved>

NSA stands for Non-Standalone and the term is commonly describing the 5G NR in the case where it needs an LTE eNB as an anchor for Control Plane Connectivity towards the Core. H

owever, the same concept applies for EUTRAN so one may see the term NSA EUTRAN (e.g. Option 4) while the SA, Standalone commonly describes the other scenario where the 5G NR (gNB) is connected directly to 5GC and it represents typically the target architecture and it is very common to have a migration path between the two architectures across multiple steups "options" listed below. (I am skipping options 1 and 7)

NSA NR Options (3, 3a, & 3x)

SA NR Options

Now, with Operators taking the second step towards a full-fledged 5G Architecture with wider use cases and a monetization framework.

The Concept of Network Slice as a Service has started to rise with the potential of the Network to expose NSaaS, Network Slice as a Service that can be leased to MVNOs and Enterprises with special QoS requirements & Characteristics.

Ideally, CSPs will start with three main Slices (eMBB, URLLC, & mMTC) and then start to sell NSaaS for multiple verticals & Enterprises.

This new concept has mandated the presence of an orchestration framework that governs the Network Slices Life Cycle Management providing the necessary Domain Orchestration capabilities.

Taking one step back, Orchestration is not a comfort zone for many of Telco vendors and actually, some colleagues & network vendors are allergic to the term "Orchestration", accidentally replacing that with the term "Automation”, sometimes misuse the term unintentionally or intentionally and sometimes claim the inexistence of such term. This is causing one of the widespread confusion in the Community.

However, it was difficult to avoid the orchestration framework in 5G. Basically, you need to handle the lifecycle management of Network Slices which is dynamic by nature across multiple Network domains (Access, Transmission, & Core) and this may include MEC (Edge Computing Environments) as well for uRLLC use cases. This is in addition to Slice modeling and testing and other orchestration aspects.

Network Slice Lifecycle Management
 

This is simply can't be achieved unless the CSP plans for an orchestration framework for 5G. This point was realized by 3GPP and introduced the framework as part of 5G R15.

Below are the key components of the 5G management & orchestration Framework as introduced by 3GPP.

• Communication Service Management Function (CSMF) - Responsible for translating the communication service related requirement to network slice related requirements.
• Network Slice Management Function (NSMF) - Responsible for the management (including lifecycle) of NSIs. It derives network slice subnet related requirements from the network slice related requirements.
• Network Slice Subnet Management Function (NSSMF) - Responsible for the management (including lifecycle) of NSSIs.
• NF Management Function (NFMF) - Responsible of application-level management of VNFs and PNFs and is a producer of the NF Provisioning service that includes Configuration Management (CM), Fault Management (FM) and Performance Management.

The mapping of these new functionalities & ETSI NFV Architecture is quite interesting. In a nutshell, all these new functionalities are on the northbound of NFVO.

Mapping these components to vendors solution will be very interesting as well. I do expect a new wave of confusion with Network vendors starting to introduce 5G Orchestration solution that are coupled to the 5G radio & Core Solutions playing the same game of NFV “This use case will not fly unless we provide an E2E full Stack” unlike Vendors who have already an experience working with NG OSS/BSS Solutions including Orchestration who will be providing a vendor-agnostic solution that host the new functionalities as part of their existing portfolio mapped to TMF Frameworks and Reference Architectures.

I hope that the community doesn’t repeat the mistakes of former technologies, investing and spending money on technologies without spending time working on deriving business cases and creating a monetization framework.

Let’s suppress the FUD, Fear, uncertainty, and doubt messages spread by individuals and companies that aim to get CSPs in a state of vendor-lock with no real vision on how the technology is evolving.

OpenRAN is a lesson. Who would think that a full radio solution for 4G/5G can be deployed using virtualized, open, SW-based platforms? The FUD didn’t succeed and the Operators are exploring the success stories and keen to follow the same path. The below snapshot is from a Public press release via Rakuten.

Happy 5G!

Waiting for your comments.

Useful References

3GPP TS 38.300 NR; Overall description; Stage-2
3GPP TS 28.530 5G Management & orchestration; Concepts, use cases & requirements 
3GPP TS 28.533 5G Management & orchestration; Architecture framework
ETSI GR NFV-EVE 012 Report on Network Slicing Support with ETSI NFV Architecture Framework