Home Archives for Seshadri Sathyanarayan

Author: Seshadri Sathyanarayan

Standalone (SA) and Non-Standalone (NSA) 5G Architectures: The various paths to 5G revenues and profitability

by Seshadri Sathyanarayan Seshadri Sathyanarayan No Comments

A Telecom Transformation is underway. With 5G, a whole new generation of networks is being built to connect 50+ Billion Devices, creating more than a $12 trillion-dollar market opportunity for Mobile Network Operators. The road to 5G, it turns out though, isn’t a straight line. This leads us to a discussion of non-standalone architectures (NSA) and standalone architectures (SA). Here are the differences and benefits of NSA and SA and how MNOs can take advantage.

 

Differences Between NSA and SA 

The main difference of NSA (Non-Standalone Architecture) and SA (Standalone Architecture) is that NSA anchors the control signaling of 5G Radio Networks to the 4G Core, while the SA scheme connects the 5G Radio directly to the 5G core network, and the control signaling does not depend on the 4G network at all. NSA, as the name suggests, is a 5G service that does not ‘stand alone’ but is built over an existing 4G network. SA, on the other hand, allows completely independent operation of a 5G service without any interaction with an existing 4G core.

 

Per 3GPP TR 21.915, Two deployment options are defined for 5G: 

  1. The “Non-Stand Alone” (NSA) architecture, where the 5G Radio Access Network (AN) and its New Radio (NR) interface is used in conjunction with the existing LTE and EPC infrastructure Core Network (respectively 4G Radio and 4G Core), thus making the NR technology available without network replacement. In this configuration, only the 4G services are supported, but enjoying the capacities offered by the 5G New Radio (lower latency, etc). The NSA is also known as “E-UTRA-NR Dual Connectivity (EN-DC)” or “Architecture Option 3”.
  2. The “Stand-Alone” (SA) architecture, where the NR is connected to the 5G CN. Only in this configuration, the full set of 5G Phase 1 services are supported. 
5G NSA SA diagram

Image from GSMA

 

Non-Standalone Architectures for MNOs

The path that mobile network operators (MNOs) follow to 5G will depend a lot on how they plan to pay for that journey. During the deployment of 4G from 2010-2015, virtualization was not a mandate. Operators took many different approaches to deploying 4G architectures utilizing proprietary and virtualized solutions. With 5G, virtualization is a must. MNOs now have an opportunity to transform the way they build and operate their networks. 

For MNOs that are looking to deliver mainly high-speed connectivity to consumers with 5G-enabled devices, a non-standalone architecture (NSA) makes the most sense, because it enables them to leverage their existing network investments in transport and mobile core —rather than deploy a completely new end to end 5G network. This can be combined with efforts to reduce network operating costs by adopting virtualization and CUPS (Control and User plane separation) using software-defined networking (SDN). These initial steps toward 5G, enable MNOs to begin offering 5G services providing faster data speeds and capture additional revenue streams.

Benefits of 5G NSA:

  • deliver high-speed connectivity to consumers with 5G-enabled devices
  • leverage existing network investments in transport and mobile core

 

Standalone Architectures (SA) for MNOs

For some MNOs, however, who have their sights set on new enterprise 5G services such as smart cities, smart factories, or other vertical market solutions, a standalone architecture (SA) could make more sense. In this scenario, which 3GPP has now standardized, MNOs can build an entirely new fully virtualized 5G network that includes new radio access network, new transport network, and new 5G mobile core and edge networks – standing alone and separate from their existing 4G and legacy networks. 5G standalone architecture is a fully virtualized, cloud-native architecture (CNA) that introduces new ways to develop, deploy, and manage services. CNA includes concepts of microservices and service-based interfaces that greatly simplify services, dramatically reducing the cost of operation and speeding up the introduction of new revenue-generating services. With 5G SA, the distinct advantage here is end-to-end support for 5G speeds and services. And the true promise of 5G is enterprise-driven revenue – it changes the business model from consumer-driven to enterprise-focused opening up entirely new use cases and revenue streams.

Benefits of 5G SA:

  • MNOs can launch new enterprise 5G services such as smart cities, and smart factories
  • It is fully virtualized, cloud-native architecture (CNA), which introduces new ways to develop, deploy and manage services
  • The architecture enables end to end slicing to logically separate services
  • Automation drives up efficiencies while driving down the cost of operating the networks. 
  • By standardizing on a cloud-native approach, MNOs can also rely on best of breed innovation from both vendors and the open-source communities 
  • By choosing a cloud-native microservices-based architecture, MNOs can also decide on a variety of deployment models such as on-prem private cloud, public cloud, or hybrid to meet their business objectives

 

The Future of 5G Includes NSA and SA

It’s worth noting that NSA and SA aren’t an either/or proposition, but more of a “sooner or later” consideration. MNOs that begin with NSA can gradually add or migrate to SA over time. What we’ve seen at Affirmed from early 5G adopters are primarily NSA deployments as MNOs compete for the bragging rights (and the competitive advantage) of being the first to offer 5G speeds. These MNOs were typically the first to adopt 4G/LTE technologies as well, and so are fairly advanced in terms of network virtualization. Many of them are still using Affirmed’s solution as their virtual Evolved Packet Core (vEPC) solution. One of the advantages of Affirmed’s NSA-based solution is its ability to handle both 4G and 5G-based traffic as MNOs transform their networks.

At some point, of course, NSA and SA will converge as MNOs move to a full 5G architecture. Recognizing that, MNOs would do well to look for a mobile core platform that can transition easily from non-standalone to standalone. Having a completely virtualized 5G architecture will offer MNOs the flexibility to migrate select functionality of their existing NSA solution to the 5G core platform over time, as new 5G services are enabled, allowing them to monetize their investment gradually rather than go all-in and hope to recoup their costs later.

With a clear path to evolving their networks from NSA to SA, Mobile Network Operators can win the race to revenues by operating their networks at webscale. Learn more about our 5G core solution.

 

 

Source for market reference

https://www.qualcomm.com/media/documents/files/fierce-wireless-ebrief-5g-release-16.pdf

The Traditional Telecom Vendor Is Dead. Long Live the Continuous Innovation Partner!

by Seshadri Sathyanarayan Seshadri Sathyanarayan No Comments

For years, the traditional telecom vendor has been the leviathan on the landscape, generating billions of dollars in revenue through hardware, software, and network-related services. But those vendors are going the way of the dinosaur—that is, toward extinction. Telecom operators (i.e. Communication Service Providers, or CSPs) are looking for a new kind of partner, one that can help them innovate and evolve to compete in a cloud-based world that they didn’t create and can’t easily control. It’s a frightening world for many CSPs, one teeming with exotically named inhabitants like Kubernetes, Jaeger, Docker, Elastic and Istio. And it’s the reason why the role of telecom vendors, more than ever, is to help CSPs tame this new world.

What has become increasingly apparent in my conversations with customers around 5G and the future is that CSPs aren’t looking for network vendors. They’re looking for Continuous Innovation Partners (CIPs). In other words, they’re seeking partners who can help them effectively leverage cloud-native, microservices-based technology to drive innovation and service creation.  Telecom operators understand that the fast-fail, webscale development mode popularized by Amazon, Google and others is the future, but they also realize that they don’t have the skill sets and expertise to seamlessly shift to a service creation environment based on containers, microservices, NoSQL databases, and other advanced technologies. That’s where CIPs enter the picture.

The CIP effectively splits the DevOps process by focusing on the development side of the equation, allowing CSPs to focus on the more familiar operational side of managing networks and subscribers. In an environment where services are constantly being created and updated, this looks like a Continuous Innovation/Continuous Development (CI/CD) process. In the CI/CD framework, the CIP is responsible for:

  • Synching code between developers (a/k/a “checking in” code) and building it out
  • Testing the individual service/microservice components
  • Performing quality control
  • Deploying new code to a test environment
  • Fetching the latest builds
  • Service integration and regression testing
  • Packaging and archiving

This process typically takes place in an isolated part of the network, away from production, so as not to impact existing network services. In this way, telecom partners can quickly decide whether to shelf the service or move it into their production network and scale it. By accelerating the service creation process, the CIP allows the telecom operator to adopt a fail-fast mode of deployment and more quickly monetize services that look profitable.

Of course, not every telecom equipment vendor is ready to take on the role of a CIP. At Affirmed, we had a significant head start with our cloud-native UnityCloud 5g core platform. To create UnityCloud, we analyzed hundreds of different cloud developer tools to find the best few dozen, then packaged and integrated them with our cloud-native, microservices-based architecture. Doing this required a deep understanding of cloud developer tools and concepts, something that lies outside the core competency of most CSPs and even most telecom vendors.

It’s not unusual for CSPs to register apprehension the first time they see UnityCloud up close, because many of the components are unfamiliar to them. But this apprehension soon becomes comprehension as CSPs realize that we’ve already done the heavy lifting for them by selecting and packaging these cloud-native tools together. By working with a continuous innovation partner like Affirmed, CSPs can leverage the cloud for a competitive advantage without retraining themselves or investing millions to update their software development skills.

The road to 5G is a journey, but it’s a journey that telecom vendors must be able to take with their customers. With a continuous innovation partner (CIP), telecom operators (CSPs) can reach their goals sooner and continue on a path of innovation and monetization for years to come.

Cloud Native: The Disaggregation of Software

by Seshadri Sathyanarayan Seshadri Sathyanarayan No Comments

“If virtualization is the disaggregation of hardware, then cloud-native is the disaggregation of software.”

As we stand on the cusp of 5G’s arrival next year (according to most analysts), it’s surprising to me how many people in the industry still don’t agree on what 5G will look like when it does arrive. You’ll hear the usual terms in a conversation about 5G —virtualization, cloud-native, the Internet of Things—but little consensus on what constitutes a true 5G network. Is virtualization enough or does a 5G network have to be cloud-native too? Is a cloud-native architecture simply one that features containerized software or is it something more?

 

What is Cloud-Native Architecture? Here’s a Simple Definition:

Part of the confusion around cloud-native architecture stems from our industry’s affection for making the simple complex. For example, the industry definition for cloud-native invokes a whole laundry list of requirements—containerization, microservices, network slicing, etc.—that many in the industry don’t fully understand. It was during one such conversation, at a recent panel session on 5G networks, where I finally discovered a simple way of defining cloud-native architectures. “If virtualization is the disaggregation of hardware,” I said, “then cloud-native is the disaggregation of software.”

 

Disaggregation & Cloud Native

For me, that’s the whole crux of the 5G discussion right there. Virtualization is a mandate for 5G, true, but there’s a higher purpose for 5G than squeezing more cost out of the network: a mandate to make money. This requires an innovation platform built on cloud-native architecture principles that can enable new network slices and fail fast modes of operation. And disaggregating software is the key to creating and managing such a platform and driving new revenue opportunities of the 5G future. Achieving the right level of disaggregation is the true art within the science of Cloud Native.

To be clear, cloud-native is more than disaggregated software. It involves, among other things, containerization, dynamic management, an externalized state, a service mesh and, perhaps most importantly, a microservices-based architecture. Unfortunately, many network equipment vendors are clouding the perception of cloud-native by limiting its scope to a few checked-off boxes. They build on a foundation of hardware virtualization by re-packaging their existing software in containers, provide some dynamic management tools and announce that their solution is cloud-native architecture. Not surprisingly, their 5G conversations also stop short of promising more revenue. Instead, their focus is on operational and capex savings. Let’s be very clear: If your 5G roadmap ends at network savings, you’ll be running out of road a lot sooner than you think.

Ultimately, 5G is defined by how you define success. If success is saving money and watching other people innovate, then stick to virtualization. But if you define success by shaping the future and embracing the opportunity, cloud-native is a must. There are a lot of roadmaps out there, but in the race to revenue, the path for 5G is clear: the winners will be those who figure out how to drive revenue through new services, faster than the competition.