Home BLOG Page 2

BLOG

Going Native: Why Carriers Need to Embrace Cloud-Native Technologies Right Now

by Ron Parker Ron Parker No Comments

The cloud isn’t an if. It’s a when. And it will probably start like this: a few forward-thinking carriers will begin moving large portions of their network functions into the cloud and realize that the savings are almost shocking. Not the 2X magnitude CapEx savings we’ve seen from replacing physical servers with cloud-based servers, but a 10X magnitude CapEx+OpEx savings that will occur when carriers move network hardware, applications and a significant portion of operations into the cloud. And when that happens, the rush to the cloud will be deafening.

Right now, the migration to the cloud seems relatively restrained, almost quiet. 5G still feels far off in the future. (In reality, 5G’s arrival is imminent.) Meanwhile, carriers are looking to get more mileage out of their existing infrastructure, and replacing it with cloud servers isn’t a compelling narrative. The compulsion will come when early adopters start proving that the cloud is a game-changer. At that moment, carriers will need to move quickly or be left behind. If they don’t already have a cloud-ready network architecture in place, they can forget about coming in first, second or third place in the race to deliver 5G services. That may sound like a dire prediction, but it doesn’t have to be.

 

What Cloud Native Technologies Hold for Carriers

A cloud-native network architecture can be had today—without ripping and replacing current infrastructure and without waiting for 5G to realize a return on investment. We see this as a phased approach to 5G: start investing in cloud-native technologies capabilities, with examples like control and user plane separation (CUPS), containers, Kubernetes and cloud-native network functions (CNFs) today to run your existing network more efficiently, and seamlessly shift those capabilities into the cloud when you’re ready.

Benefits of Going Cloud-Native

There are several important benefits of using cloud-native technologies now.

  • It delivers network agility by allowing carriers to quickly create and turn up new services, particularly private networks that will serve an increasing number of enterprises.
  • It offers automation of operations, which can dramatically reduce costs and accelerate time to market.
  • It provides network flexibility as carriers can deploy the same cloud-native architecture on their private infrastructure to serve millions of existing subscribers, for example, while spinning up new enterprise services in the cloud to avoid impacting those subscriber services.

This hybrid approach, by the way, is how we expect most carriers will consume the cloud initially. It’s critical as carriers pursue more enterprise opportunities and use cases that they continue to deliver the same or better levels of service to their existing subscriber base—it is, after all, where the bulk of their revenues come from today. Focusing on enterprise services in the cloud reduces risk and allows carriers to easily spin up new network slices for each enterprise customer. This may have been less of an issue in the past when carriers were managing private LTE networks for a handful of large customers, but it becomes unmanageable in a traditional network architecture when you have thousands of enterprise customers.

As you would expect, of course, the benefits of a cloud-native architecture are most apparent in the cloud. That’s especially true when the cloud-native architecture and the cloud architecture are managed by the same company, as they are today with Affirmed Networks and Microsoft Azure. Whether you deploy our cloud-native architecture in your own private network or in the public cloud, you’re getting the same code—tested and hardened in both environments—for a solution that is fully prepared for CI/CD environments from day one. No other company today can say that.

And, rest assured, day one is coming sooner than you think.

The Greatly Exaggerated Death of 4G

by Paul Phillips Paul Phillips No Comments

Everybody’s talking about 5G. But how close are we really to a 5G revolution?

According to GlobalData’s Global Mobile Broadband Forecast, 5G subscribers currently account for less than one percent of the global market. Even with steady growth, 5G subscribers are still expected to represent less than 20 percent of the global market by 2023. In other words, don’t throw out that 4G network just yet.

The reality is that 5G-ready devices are only now beginning to enter the market. 5G use cases are mostly speculative at this point. As with most technological transitions, operators should anticipate the long tail of 4G and expect to support 4G devices for years to come. And that brings up an interesting question: When should you start making the transition to 5G? The answer, surprisingly, is right now.

Transitioning to 5G

The path to 5G is irreversible, just as 4G and 3G before it eventually became the industry standard. For now, however, 4G subscribers and services are the main revenue drivers for operators. 4G networks will need to be updated, enhanced, grown, and maintained for years to come, even as current network infrastructure reaches its end of lifecycle and EPC vendors and products invariably disappear from the market. And here’s where operators have a choice: Do they simply limp along with their existing 4G technology, with the hopes that it will support the remaining subscriber growth, or invest in newer technology that can efficiently support the 4G growth offer many of the technological advancements and cost-saving features of 5G, and enable a smooth transition to pure 5G core?

Why a 5G Non-Standalone Architecture Works

Using 5G NSA (non-standalone architecture) combines existing 4G technology and the technological advances and cost-saving features of 5G networks.

A Best of Both Worlds Approach

This best-of-both-worlds approach is the idea behind the 5G non-standalone (NSA) network architecture. With 5G NSA, operators can support 5G radio networks and 4G networks from a single, enhanced 4G core. This allows operators to make 5G investments where they make the most sense—initially, in the RAN to deliver 5G speeds and performance to users whose devices support that—and still support 4G services, incrementally transitioning their network from 4G to 5G until they’re ready to make the move to a 5G standalone (SA) architecture.

Moving to 5G NSA Means Moving to vEPC

Moving to a 5G NSA architecture also means moving to a virtualized evolved packet core (vEPC). There are many operators that are already running their 4G networks with a vEPC. You don’t need a 5G network to reap the benefits of a vEPC, such as lower OpEx and CapEx costs, and better scalability. In fact, many operators have taken the stance of implementing a vEPC as a way to reduce costs and redirect those savings to fund their 5G investments. That’s smart, because the same GlobalData report I mentioned at the beginning of this blog also found that the average revenue per user (ARPU) is expected to drop by 50 percent over the next three years, even as 4G traffic doubles over the same period. Given that trend, operators need to find a way to do more 4G with less money, which plays right into the vEPC’s strengths.

A 5G Service Without a 5G Network

Now, you may still be asking yourself: Why invest in a 5G NSA architecture if 5G services haven’t even arrived? Not every “5G” service requires a 5G network. For example, low-latency multi-access edge computing (MEC) applications are often touted as part of 5G’s value proposition, but operators can deploy those services today with LTE. Similarly, operators can use a vEPC to roll out new services faster using a microservices-based architecture. And, with the right vEPC in place, operators will already have the skills and technology in place to make a smooth transition to a completely 5G network.

How Will You Transition to 5G?

It’s human nature to get excited about new technology. How many of us, for example, purchased an ultra-high-definition 4K television just to watch 1080p movies? We know 5G will get here eventually. The real question is: How will you get there? Preparing for 5G now by investing in a vEPC is the smartest way to support your current (and future) 4G subscribers while preparing for the 5G subscribers that are coming tomorrow.

That said, simply deploying a vEPC isn’t enough. You need to choose one with the right capabilities that will not only support the remaining subscriber growth, but also the enhancements which will enable a seamless transition from 4G to 5G. What are those capabilities? Find out in my next blog on the Four things to look for in a 5G epc.

If you plan on serving up network slices quickly, you’ll need the right cooks in the kitchen

by Adam Dorenter Adam Dorenter No Comments

If you look at most telecommunications networks today, they’re divided into a kind of vanilla/chocolate/strawberry mix of services where you may have an enterprise flavor, a standard consumer flavor, and a high-usage consumer flavor. When 5G arrives, however, those networks will need to look a lot more like Baskin-Robbins’ 1,300 flavors. What telcos will do to create those flavors is customize the network experience using thousands of different policy-driven network slices with unique SLAs, security features, latency and bandwidth requirements, pricing, and so on. This blog outlines what network slice management solutions for telco operators and what it should look like in 5G.

Benefits of Network Slicing for Telco Operators

The benefit of network slicing is twofold: to create differentiated services that people will pay for (e.g., high-bandwidth virtual reality slices, low-latency mobile healthcare slices) and more effectively manage network traffic and costs (e.g., IoT and online gaming will clearly have different pricing and priorities). The challenge of network slicing is that this is largely unknown territory for telcos, which are accustomed to cautiously rolling out new services and managing just a handful of pricing models (e.g., unlimited plans, per-gigabyte pricing).

The concept of a network slice technically dates back to 3G, when it was called an access point name (APN). In those days, APNs worked like a giant, best-effort bucket: telco operators would pour their water into a single bucket, poke a bunch of holes in the bottom and customers would get more or less water depending on how big a hole in the bucket they had. From that perspective, I guess you could say that APNs “pail” in comparison to today’s network slicing capabilities.

Network slicing gives operators a much more granular level of control over how they allocate their bandwidth, arguably their greatest asset. They can deliver higher SLAs around revenue-generating apps, give lower priority to video streaming that doesn’t generate revenue for them (ahem, Netflix), wrap security policies around enterprise traffic for added privacy, and so on. Actually, a lot of “so ons” – like thousands of them.

This is very different from the way bandwidth is managed in the 4G world. For example, in a 4G network, there might be one big slice for all consumer services. We’ve even seen telco operators adopt this same model for their initial 5G rollouts. But once you get past the trial stage for 5G, the goal is to increase the number of slices on day two, three, etc. until you have network slices for nearly every imaginable scenario: video gamers, casual users, small business e-commerce, healthcare apps, etc.

Network Slice Management Functions

As you might imagine, how telcos will stand up and manage these slices is a topic of much conversation. Industry organizations such as 3GPP, GSM and ONAP have all weighed in on what they believe slice management should look like in 5G. Basically, it boils down to three key network functions (and you might want to have your alphabet-soup decoder ring on hand for this):

  • CSMF (Communication Service Management Function), which acts as the user interface for slice management;
  • NSMF (Network Slice Management Function), which controls the slice, end to end, across the RAN, transport and core domains (also referred to as subnets);
  • NSSMF (Network Slice Subnet Management Function), which applies the NSMF’s lifecycle management commands (e.g., instantiate, scale, terminate, move) within a particular subnet.

The NSSMF is where most of the slice intelligence resides. It takes a command from the NSMF, such as “build a slice,” and activates it by doing all the behind-the-scenes work of function selection, storage, configuration, and communication. And this brings up another important point that industry organizations have focused on: creating API standards that dictate how all this communication and interaction should take place between the NSSMF and other network elements.

Within 3GPP is a group known as SA5 that is working on a reference architecture for network slice management. We believe it’s in the best interest of every NSSMF vendor to follow these standards (it’s something we’ve done from the beginning with our own NSSMF solution for the mobile core subnet). Why? Because a best-of-breed approach to slice management is the best course of action for most telco operators. Yes, there are vendors that offer a soup-to-nuts solution, but in our experience, no two operators have the same slicing requirements. A one-size-fits-all approach to slicing just doesn’t fit that reality.

We view the best-of-breed approach as following one of two courses. There’s the multi-vendor approach, where operators engage with a bunch of different vendors to populate a complete slice management solution: a RAN NSSMF from vendor A, a transport NSSMF from vendor B, a CSMF from vendor C, etc. And then there’s the standards-driven approach, where an operator engages with an organization like the ONAP Project to build their own network slice management solution. This last approach may have the most potential for success, as we’ve seen in some of our own customer projects.

The Impact of Network Slice Management

Network slice management will have a significant impact on how quickly and effectively operators can monetize their 5G investments. Automation, orchestration, and observability also have important roles to play in the number and kinds of slices your network can spin up. The appetite for customized slices is clearly there. The question is: Do you have the right tools in your kitchen to handle the demand? It’s a topic I’ll discuss further in my continuing series of network slicing blogs.

Red Hat and Affirmed Networks collaborate to help accelerate 5G deployments on Red Hat OpenShift

by Affirmed Affirmed No Comments

Service providers are transforming and virtualizing their networks in response to an increasingly dynamic market and rapid technology changes. As new opportunities for services grow, 5G has also given service providers the opportunity to increase efficiency, flexibility and elastic scale with microservices-based cloud native architectures. 

As these shifts take place, Red Hat and Affirmed are working together to help service providers adopt cloud native network functions (CNFs) for 5G Cores. Building on the foundation of Red Hat OpenShift, we’re enabling the Affirmed UnityCloud “Any G” solution to be deployed more broadly on a supported, cloud-native backbone, making it easier for telecommunications companies to more efficiently deploy 5G, 4G and 3G services backed by a common telco cloud infrastructure.  

Red Hat and Affirmed are no strangers to collaboration, with Affirmed’s virtual evolved packet core solutions (vEPC) and virtual network functions (VNFs) already deployed and supported around the world on Red Hat OpenStack Platform. Now, our relationship has expanded to include 5G on Red Hat OpenShift, with the OpenShift certification expected to complete this summer.

UnityCloud Platform is a platform of innovation and is designed to deliver automatic, self-observable and non-stop networks. UnityCloud Platform combines the strength of open source technologies with Affirmed’s carrier-grade telco and virtualization expertise. The platform provides a variety of CNF dependencies and automation frameworks to enable cloud-native functions to run seamlessly. UnityCloud Platform was designed to work on bare metal, VM based IaaS, container-based IaaS in both public and private environments.

With the extension of our collaboration, Affirmed now supports UnityCloud from the core to the edge and across public, private and hybrid cloud environments. This enables telecommunications providers to use “Any G” solutions on a broad spectrum of platforms, including Red Hat OpenShift on bare metal, Red Hat OpenShift on Red Hat OpenStack Platform and Red Hat OpenShift in the public cloud, like Microsoft Azure.

Cloud-native collaboration: Address a broad spectrum of telco needs

Through this collaboration, customers will have additional flexibility to tackle an extended set of technology scenarios, including:

  • Network Functions on Red Hat OpenShift and Red Hat OpenStack Platform: A customer or operator seeking to administer a virtual machine (VM)-based Infrastructure-as-a-Service (IaaS) that supports multiple VNFs and containerized network functions (CNFs) from different suppliers. Ideally, this deployment is based on Red Hat OpenStack Platform, where Affirmed provides UnityCloud Platform on Red Hat OpenShift and CNFs provided by Affirmed Networks and other ecosystem partners.
  • CNFs on OpenShift on baremetal: An operator wants to deploy a containerized Kubernetes-based IaaS that supports multiple CNFs from different vendors. This baremetal deployment is best suited for Red Hat OpenShift, running Affirmed Network’s UnityCloud Platform LITE and CNFs provided by Affirmed Networks and other ecosystem partners.

Red Hat OpenShift is available for a variety of cloud environments, from major public clouds including Microsoft Azure, AWS, Google Cloud Platform and IBM Cloud to private cloud and virtualized infrastructure such as Red Hat OpenStack Platform and VMware. More than just availability, the industry’s most comprehensive enterprise Kubernetes platform provides the flexibility to combine public and private resources for hybrid cloud deployments.

Running Affirmed UnityCloud on Red Hat OpenShift provides the flexibility to deploy on a myriad of private, public cloud, or hybrid cloud environments to shift or scale workloads as business needs dictate. We hear from our customers that hybrid cloud combines the flexibility to innovate more quickly with the control of on-premises datacenters, while still enabling them to use and extend existing public cloud infrastructure investments. 

With a public or hybrid cloud environment based on Red Hat OpenShift, customers can have a much higher level of agility, making it easier to move between and across different types of private and public cloud footprints. With open source software, enterprises can benefit from the continuous community innovation, a generally lower operational cost and less vendor lock-in.

 

You don’t need to wait for 5G. Monetize your network now with Private LTE.

by Tim Irwin Tim Irwin No Comments

You’ve heard it all before. Telcos are trapped between rising traffic, shrinking margins, and flat revenue but—wait!—5G will come to the rescue with new revenue-generating services. And while 5G does have a world of potential, telcos can’t afford to wait for a future that may take years to arrive – but you don’t need to wait any longer, thanks to private LTE networks. 

 

We believe that 5G will be a game-changer. But it could initially play out like a waiting game, as mobile operators analyze various business cases. Autonomous vehicles, for example, are a great idea, but who makes the first move? Is it companies that put 5G chips in their cars in anticipation of a ubiquitous 5G network, or operators that need to unroll a reliable 5G fabric before car manufacturers commit to wireless control?

 

While the world waits for 5G to arrive—in networks, smartphones, IoT devices, etc.—LTE is already in place. So, here’s food for thought: What if operators and enterprises could monetize Private LTE networks right now in the same way they plan to monetize 5G networks? That is, by partnering to create value-added services for its customers through a private LTE network.

 

Private LTE Networks Presents an Opportunity for MNOs

Think about it: Private LTE networks present a great opportunity. Right now, network demands are on an upward curve and they’re only going to get higher. Mobile network operators find themselves in the middle, a pipeline between ravenous content consumers and profitable over-the-top content providers. As the air interface technology increases bandwidth at one end of the pipe (i.e., higher consumption or more product to consume), operators have to increase the size of their pipe between the radio and the content, which means more coverage, more capacity, more complexity, etc. But, importantly, not more money for the telco operators.

 

What if telco operators could create a better network experience by pushing network communications out to the edge of the network? Then operators would only need to expand capacity at the edge to deliver high-speed, low-latency services, rather than upgrading their entire network from end to end. Then, when 5G finally does arrive, the private LTE services can be seamlessly integrated into the 5G architecture to continue monetizing those services.

 

Private LTE Networks vs. Wi-Fi Networks

Private LTE networks are similar to Wi-Fi networks in some ways but with a few very important distinctions. Here are the differences between Private LTE vs. Wi-Fi:

  1. Unlicensed Spectrum: Wi-Fi uses unlicensed spectrum, which opens the door to all sorts of RF pollution and compromised quality.
  2. Security: A mobile LTE network delivers a higher level of security than a Wi-Fi network.
  3. Time & Effort: Running a large-scale W-Fi network is hard work; most enterprises don’t want to get into the business of RF planning.

 

Enterprises understand the value of having a better mobile experience closer to their end users, whether that user is in a store or in their home. That experience should include enforceable SLAs—something that you can’t get with unlicensed Wi-Fi spectrum but you can get with licensed LTE spectrum—as well as security and managed services.

 

Unlike consumer smartphone services, enterprise services are easier for operators to monetize, particularly when they’re aligned with a clear business case. For example, a private LTE network that delivers a better video experience would be valuable to a content provider’s audience and, thus, potentially profitable. An operator could deploy that extra edge capacity for HD video consumers as part of a revenue-sharing plan with the content provider. Best of all, when 5G finally does arrive, you’re already engaged with enterprises in delivering next-gen services—a relationship you can build on with the advances that 5G will bring.

 

There’s actually a lot that enterprises can do with a private LTE network right now—and that’s the topic of my next blog. Learn more about Affirmed Networks solutions.