Home Archives for Ron Parker

Author: Ron Parker

Hyperscale Cloud and Mobile Core: Why They’re Better Together

by Ron Parker Ron Parker No Comments

What happens when you put a mobile core in a hyperscale cloud? Awesomeness.

For years, even before the cloud, there was software-as-a-service. Then followed a sort of “service mania” as vendors offered infrastructure-as-a-service, network-as-a-service, storage-as-a-service, ad nauseum. In the telco world, however, networks were still built primarily with dedicated boxes running proprietary software. It wasn’t cheap or easy to scale these networks, but they were reliable. This article outlines mobile-core-as-a-service solutions and the advantages of a fully integrated hyperscale cloud and mobile core.

Cloudification & Mobile Core

Today, many elements of the telco network have been virtualized and even cloudified. The result has been cheaper, more scalable, yet still reliable networks. One area that resisted this sweeping cloudification was the mobile core. Though virtualized, the mobile core remained very much an on-prem solution. That is, until Affirmed announced UnityCloud, the world’s first 5G mobile core that can be fully deployed in the cloud as a mobile-core-as-a-service, and integrates with a hyperscale cloud platform.

Benefits: Mobile Core on a Hyperscale Cloud

Running a mobile core in a hyperscale cloud has a number of benefits:

  • The deployment can be fully automated to increase service velocity and accelerate the time to revenue for new 5G services
  • Operators can orchestrate cloud workloads and private workloads using Kubernetes to compose new services in any configuration
  • Network functions can be scaled up or down automatically based on network demand
  • Operators can automate their continuous integration/delivery (CI/CD) pipeline through automated software upgrades
  • Network fault detection can also be automated and enhanced through AI and machine learning tools

Managing your mobile core with ARM and ARC

UnityCloud can run on the Microsoft Azure cloud platform as well as private cloud environments or on premise-based equipment. Within UnityCloud is a complete set of cloud-native functions (CNFs) built on a stateless microservices architecture. These CNFs provide both the control and user plane functions and can be separated in different environments; for example, with the control plane functions hosted in the Azure cloud and the user plane functions hosted on premise-based, bare metal servers.

The UnityCloud services reside in the platform-as-a-service layer, where they perform service assurance, CNF lifecycle management, security, and edge functions. One of the great features of deploying UnityCloud on Azure is the Azure Resource Manager (ARM), which serves as a GUI portal and an API layer. ARM lets you easily manage everything in the Azure environment and create templates to automate and orchestrate services.

Automation and unified management are critical to operating a 5G mobile core, but what happens when elements of the core are split between Azure and non-Azure environments?

With Azure Resource Center (ARC), you can manage non-Azure infrastructure from the same GUI portal. So, we’re not just allowing operators to deploy their mobile core any way and anywhere they want, but we’re doing it in a way that doesn’t add any complexity to the management of that mobile core.

Real-world use cases for mobile-core-as-a-service

UnityCloud is already helping some of the world’s most sophisticated mobile operators deploy 5G networks. For example, in Finland, a leading operator is using UnityCloud to deploy both 5G smartphone service and fixed broadband wireless using a mix of 4G and 5G radio access networks. In Latin America, a tier-one operator with 50 million subscribers is deploying its network services closer to the edge with UnityCloud, providing a better customer experience to subscribers across a widely dispersed geographic area. And, in the UK, a tier-one operator has dramatically reduced its network complexity with UnityCloud.

While mobile core efficiencies are a big part of UnityCloud’s story, content optimization is also important. UnityCloud includes a host of value-added content optimization services including TCP optimization, video optimization, firewall, carrier-grade NAT, and more. Consolidating these services, which were typically purchased from different vendors, into a single-vendor solution further simplifies the 5G network.

We expect that other mobile-core-as-a-service solutions will follow from other vendors, but even so, UnityCloud will have a unique advantage: full integration with a hyperscale cloud platform, Microsoft Azure. While accelerated deployment is one obvious advantage of this, UnityCloud can also now take advantage of all the features and benefits of the Azure cloud ecosystem including AI and machine learning. In fact, you could say UnityCloud has taken the concept of “cloud native” to a whole new level.

The Five Key Traits of Highly Successful 5G Networks

by Ron Parker Ron Parker No Comments

The new year gives each of us an opportunity to reflect on self-improvements for the future, and maybe networks are no different. Right now, your network could be telling itself that 2021 is the year it’ll finally get serious about IoT or stop talking about cloud-native and take the plunge. In which case, your network has its work cut out for it. For operators looking to get their networks in shape, this blog outlines key elements for successful 5G networks.


5G Requirements

Getting your network in shape for the 5G applications of the future isn’t a simple matter of reducing operational fat and running more hardware. It’s a completely different approach that requires unlearning some unhealthy habits, such as:

  • Gaining too much weight (in the form of new hardware) every time the network needs to expand
  • Avoiding network automation because it’s too expensive, too exotic, or too scary
  • Limiting major software releases once a year, while the competition is continuously innovating and improving
  • Accepting downtime during maintenance windows as a necessary evil
  • Piecing network visibility together from different tools that you know will never work together perfectly

In fairness, those habits were ingrained over years of operating a 2G/3G/4G network. But a 5G network doesn’t need telecom operators so much as telecom innovators, and innovation means embracing change. In order to support 5G innovation, telcos must learn to match the agility of over-the-top (OTT) providers, eliminate downtime, automate as much of their operations as possible and leverage both the cloud and edge computing to ensure they deliver amazing experiences to their users.


Five Key Elements of a 5G Network

At the heart of the 5G service experience is the 5G mobile core. There are a lot of different technology components that go into making a great 5G network, from virtualized RAN to container orchestration (Kubernetes), but there are five key elements that every successful 5G mobile core requires.

App Store Simplicity

“Plug” and “play” probably aren’t the first two words that come to mind when you think of a mobile network’s service architecture. Plug-and-play simplicity, however, is exactly what telco operators need to rapidly deploy and manage 5G services. Think of it as an internal app store, with portals and APIs that allow you to drag and click your way to creating new services.

Containerized Workloads

Virtualization was a great step forward. Now telcos need to take the next step, toward containerization. Containerized workloads provide the freedom to create services independent of hardware and software so they can run anywhere.

Network Slicing

We’ve been singing the praises of network slices for years, but 5G is where slicing really shines. That’s because 5G can serve so many different services to so many different businesses and consumers, which calls for the kind of network service differentiation that network slicing delivers.

Location Independence

In the past, the user and control planes sat on the same server/appliance. If you needed more of one, you got more of the other—even if you didn’t need it—because you couldn’t separate the two. Now, with control and user plane separation (CUPS), you can keep the user and control planes independent and finally scale network resources efficiently. CUPS opens up a range of deployment possibilities to improve 5G service delivery and reduce costs: local breakout at the edge, hybrid clouds, public cloud vs. on-prem edge, etc.

Access Independence

Wi-Fi and wireline technologies still have a role to play in 5G communications, which means they need to be able to access the 5G core (and vice versa). An effective 5G mobile core is one that allows telcos to manage and apply common policies to non-3GPP traffic such as Wi-Fi, cable/DSL, and fiber.


In Closing:

As you can see, 5G involves quite a “core” workout. Fortunately, there is an easier way to get your core in shape quickly: 5G mobile core as a service. It’s a new offering from Microsoft that’s based on Affirmed’s industry-leading 5G core technology and hosted in Microsoft’s new Azure for Operators environment. If that sounds like something in your future, tune in for my next blog on what “5G mobile as a service” means and why it’s a game-changer for 5G operators.

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 End of the ISV Era

by Ron Parker Ron Parker No Comments

It’s no secret that cloud services are on the rise. Gartner estimates that businesses will spend $266.4 billion on cloud services this year, growing to $354.6 billion by 2022. Why is cloud consumption rising so quickly? Because free-market economies hate inefficiencies, and the cloud is all about efficiency. But that’s not to suggest that cloud adoption didn’t create ripples in the industry, as we see when we look at its history and the impact on ISVs (Individual Software Vendors).


History of Cloud Services

In the early days of cloud, enterprises were primarily attracted to the cloud for data center outsourcing: servers, switches, storage, infrastructure-oriented software, and the expertise to manage it all. The premise was that the cloud provider could offer better economies of scale by hosting multiple customer data centers and streamlining their own operations through in-house expertise, particularly around automation. In exchange for a monthly fee, enterprises could eliminate the hardware, software and IT resources associated with maintaining their own data center environment.

Infrastructure Abstraction

Over time, enterprises (and their software suppliers) were able to focus more on the applications and less on the integration points of their legacy infrastructure—the value of infrastructure abstraction was profitably exploited. This soon led to enterprises embracing managed Software as a Service (SaaS) offerings for the supporting systems of their mission-critical applications.

Examples of this include observability-oriented systems (e.g., ElasticSearch, Logstash, Kibana, Prometheus, Grafana) and database systems (e.g., MongoDB, Cassandra). With the cloud provider now offering these systems as managed services, the enterprise no longer needed to worry about deploying and supporting these systems; they could just order them through the cloud provider’s portal.

As all this lower-layer abstraction was happening, however, the remaining applications and the business logic they contained grew more complex—so complex, in fact, that the traditional model of licensing application software to another organization for deployment and operation began to disappear. Modern software is consumed in one of two ways and operated only in one way. Operationally speaking, the organization that builds the software, operates it. Enterprises consume the software they write directly and consume anything else as a service via APIs over the Internet. It should be clear that the API service provider is indeed operating the software that they wrote.

Businesses Defined by Software

While this change was happening, an even more important transformation was taking place in the software industry. A growing number of businesses became defined by software, which created a greater need for improved agility. It was no longer acceptable to deliver only two or four upgrades per year; instead, businesses needed tens, hundreds and even thousands of software updates per day.

CI/CD (Continuous Integration/Continuous Deployment)

In 2010, responding to this need, Jez Humble and David Farley devised an extension to the existing concept of continuous integration, calling it Continuous Integration/Continuous Deployment (CI/CD). CI/CD proposed combining the previously separate functions of development and operations into a single function, DevOps. The DevOps team would be responsible for feature development, test automation and production operations. CI/CD maintained that only by breaking down internal barriers could an enterprise reach the point of executing 10 or more updates per day.

There was only one problem with CI/CD: existing software architectures were poorly suited to frequent releases because virtually all software was released monolithically. The software code may have been modularized, but the release needed to include all the functionality, fully tested. How fast could enterprises update a complex, monolithic application?


As enterprises were struggling to answer this question, the idea of microservices—which had been floating around since 2007—began to take hold in architectural circles in 2011. Microservices maintained the idea that, by breaking larger applications into bite-size pieces that were developed and released independently, application development teams could release tens, hundreds and even thousands of software updates per day using a fully automated CI/CD pipeline.

This meant that no human intervention would be required between the time the developer committed the code and the time they ran the code in a production environment. Microservices—particularly stateless microservices—bring their own complexities, however: API version controls, DB schema controls, observability, and more. Fortunately, in CI/CD’s DevOps team model, all the necessary expertise is contained in a single group.


The Impact on ISVs

So how does all this impact ISVs? Remember, these are the entities that produce applications and license them for use by others. Whether the licensing is annual or perpetual, the main issue is that the purchaser is ultimately responsible for the deployment and operation of that software. ISVs often supplement their licensing with extensive professional services and training as a means to achieve the requisite knowledge transfer. But that knowledge transfer is never complete, and the ultimate experts on the vendor’s software remain in the vendor’s organization.

What’s the natural consequence of this? The customer consumes hosted or fully managed services. It is a change in the way telcos have done things in the past, and change is never easy, but the efficiency and agility benefits of moving to a modern, cloud-native model can have a profoundly positive impact on telcos going forward.

Think You’ve Got 5G Security Issues Protected? Think Again.

by Ron Parker Ron Parker No Comments

As interest in 5G continues to heat up, you’re likely to hear a lot more about 5G security. You may not, however, be hearing the whole story. Most conversations around 5G security centers on the standards put forward by 3GPP last year. Those standards are a good starting point, don’t get me wrong, but they’re not the last word on 5G security issues by a longshot. Why? Because they completely leave container security out of the conversation.


5G Security and Containers

There are a lot of new network elements to consider in a 5G architecture, but the biggest change in 5G is the fact that almost everything is now running on containerized software. In terms of 5G security threats, containers are prime targets for cybercriminals because they contain sensitive data such as passwords and private keys. Understanding how to protect containers from security threats is just as important as protecting the transport layers and gateways in a 5G network. Building on what 3GPP has proposed, we believe that protection from 5G security issues and threats has four main objectives, only two of which are currently addressed by the 3GPP’s recommendations.


A Four-point Approach to 5G Security

Let’s start with what 3GPP has already proposed for 5g security standards:

1. A trust model with two distinct, onion-layered approaches for roaming and non-roaming networks. In the non-roaming network, this model features an Access Management Function (AMF) and Unified Data Management (UDM) in the core, wrapped by the Authentication Server Function (AUSF). For roaming networks, 3GPP introduces the Security Protection Proxy (SEPP) for secure connectivity between the home and roaming networks, and the Network Exposure Function (NEF) to protect core services from inappropriate enterprise requests.

2. Encryption and authentication via Transport Layer Security (TLS), certificate management and OAuth2.

But what about security for the 5G services themselves? As the network shifts from hardware to software, telco operators need to have software security provisions in place to protect their data and their customers. At Affirmed, we see this as involving two distinct but complementary initiatives:

3. Secure software development. App developers need to ensure they’re writing secure code, validating it securely (i.e., using static code analysis), drawing from secure repositories and building everything on a secure base layer foundation (e.g., Fedora).

4. Secure containers. Containers represent attractive attack vectors for cybercriminals. 5G operators need to protect these containers by securing the orchestration engine (Kubernetes) with proper role-based access controls, guarding containers in use (through runtime container security) and managing access permissions between the containers via automated policy-driven networking and service mesh controls.


The need for container security isn’t unique to telcos, and that’s actually a good thing because they can now leverage existing security tools that have already been developed for other cloud-native applications. Unfortunately, a lot of telco vendors aren’t familiar with open-source tools like Aqua (for container security) and Falco (for orchestration engine security). Instead, these vendors leave software out of the security discussion, and that leaves telco operators with some big security holes to fill.


The Bottom Line on 5G Security

If telco operators expect to dominate the 5G landscape, they’ll need to stand on the shoulders of some pretty big cloud companies, particularly where containerization and security are concerned. 3GPP’s security recommendations are a good introduction to 5G security needs, but software security is half of the 5G story. If your vendor is telling you only about that part of the story, talk to Affirmed Networks.