Home Archives for 2019

Year: 2019

If Data is the New Oil, Why Have Your Mobile Network Analytics Efforts Stalled?

by Sean O’Donoghue Sean O’Donoghue No Comments

It’s been said that data is the new oil. If that’s true, communications service providers (CSPs) have struck it rich. Their networks collect a vast amount of data on customers, all of which can be used to deliver better customer experiences and new, revenue-generating services.  Mobile network analytics is the opportunity that CSPs have waited for, as they look to transform their business model from communications providers to digital service providers.

In order to deliver better digital engagement and personalized experiences, CSPs need more than real-time accurate data. They need robust mobile network analytics to gain valuable customer insights, identify operational efficiencies, predict future demand and create new services that customers want. There’s just one small problem with all that: Very few CSPs are actually analyzing their network data to do any of those things.

Shortcomings on Current Approaches to Network Analytics

From the beginning, mobile networks were designed as tightly coupled systems that featured hardware-based probes to collect data and deliver insights. With the move to NFV-based networks, the physical probe paradigm became obsolete. Physical probes didn’t scale well, and they weren’t designed to monitor virtual infrastructures, which are dynamic in nature.

To address these shortcomings, passive virtual probes were introduced. These were implemented as separate network functions but, as network traffic loads increased, virtual probes began to take a heavy toll on network performance. A virtual packet gateway, for example, might spend more than half its resources just performing data copy operations for the passive virtual probe.

As if cutting performance in half weren’t bad enough, CSPs now had to double the amount of hardware just to get the same performance from the packet gateway and other functions. Faced with the added complexity and cost of virtual probes, many CSPs opted to either abandon mobile network analytics initiatives altogether or limit them to very specific areas such as service assurance. And so the opportunity to drive new revenue streams fueled by network data analytics was lost.

A New Era of Integrated Virtual Probes and Analytics Arrives

Affirmed Networks did more than radically change how mobile networks were designed and delivered; we also pioneered the first integrated virtual probe and analytics solution. With Affirmed’s virtual probe solution, vProbe, CSPs can get real-time mobile network analytics and intelligence in a highly scalable manner without the performance degradation that results with physical or traditional virtual probes.

How did we create a network probe solution that could scale simply across global networks and still cut costs by more than half? By following these five guiding design principles:

  1. Integrate the probing function with the network function
  2. Simplify with single-touch packet handling
  3. Create finely grained, intelligent event data records
  4. Enable real-time analytics
  5. Embrace open standards

 

1. Integrate the probing function with the network function.

Most virtual probes add packet latency, complexity, and cost – and drain computer resources – because they add an extra step in the network as data packets move from the network function to the probe function. But the best source of network data is the actual network function itself, so we integrated vProbe with it. Now, as the network functions scales, the probing function scales with it, cutting probing costs in half.

2. Simplify with single-touch packet handling.

You can think of a data packet as information sealed in an envelope, complete with a destination address. Most systems open the packet each time they need to perform a function such as content inspection or optimization. Affirmed vProbe opens the packet once to perform everything – heuristics, video optimization, content filtering, CG-NAT forwarding, etc. – then closes the packet and sends it on its way. Single touch is simply more efficient.

3. Create finely grained, intelligent event data records.

In order to better harness, mine, and gain insights from the information collected by a probe, data records must be delivered in an open, consistent, and granular fashion. This applies to both control plane and user plane information, on a per-flow and individual customer level. Finely grained mobile network data leads to more precision.

4. Enable real-time analytics.

As customers access content, watch videos, and make calls, they’re sharing invaluable, real-time information about their behavior and interests, as well as about your network – information that can be used to capitalize on revenue-generating opportunities, identify network performance bottlenecks, ferret out fraud and more. The reality is that opportunities and issues happen in real-time, and you either have the information you need to drive intelligent decision-making, or you don’t.

5. Embrace open standards.

Architectural openness is vital for modern software platforms. Affirmed vProbe provides open access to session information using Google’s standards-based protocol buffers to create data records. These can easily be integrated with a variety of third-party network analytics tools to deliver real-time insight into network operations, network security, network planning, and marketing activities.

 

Digital leaders leverage data to deliver engaging customer experiences, which is why they’re the world’s most valued companies. Legacy infrastructure and approaches, meanwhile, have stunted CSPs’ ability to capture, see and act on the wealth of information that flows through their networks. To take advantage of the next generation of business opportunities such as IoT, 5G services, and AI-driven customer engagement, real-time mobile network analytics are an absolute must. With Affirmed vProbe, CSPs no longer have an excuse not to dive deeply into data analytics.

In a world where everyone is competing to deliver digital services, CSPs need to leverage their data for a competitive advantage. Now, more than ever, it’s oil or nothing.

10 Tips for a Successful NFV Deployment

by Affirmed Affirmed No Comments

Over the past eight years, Affirmed Networks has helped leading service providers successfully transition to NFV based architectures and realize exceptional returns. Along the way, we’ve learned some valuable NFV deployment lessons on how providers can avoid underwhelming NFV results and realize the technology’s full transformative benefits.

 

Some telecommunications network equipment vendors think that Network Functions Virtualization (NFV) is a byproduct of 5G and that the one shouldn’t arrive before the other. Reality says otherwise; many communication service providers are deriving value from NFV initiatives right now, primarily in the form of CAPEX/OPEX savings and network agility. Yet many service providers, in our experience, still only tap into 30 to 40 percent of NFV’s true potential. 

What are the challenges that providers from realizing NFV’s full potential? There is no single reason for preventing NFV’s full potential; rather, it’s likely a combination of missed opportunities and misunderstanding as to NFV’s architectural requirements. 

Affirmed has helped many service providers transition to NFV-based architectures and realize the great returns. We’ve learned some valuable lessons on how providers can avoid the challenges of NFV deployments and underwhelming NFV results and realize the technology’s full transformative benefits.

 

Our Tips for NFV Deployment Success

To help CSPs across the world ensure success for NFV deployments as they prepare for 5G, we have identified 10 key lessons for a successful NFV deployment that we are now sharing in a new paper titled “Lessons Learned on the NFV Front Lines,” that we recently published. The paper highlights many key areas that service providers should take note of as they continue to transform their networks, including:

  1. Not all hardware is created equal
  2. The packet forwarding architecture and hypervisor need attention too
  3. Don’t oversubscribe the application
  4. NFV isn’t a simple plug-and-play solution
  5. Redundancy needs to be built into the application and not just the NFVI architecture
  6. Telecom applications require built-in load balancing
  7. VMs need to scale independently
  8. The packet forwarding architecture and hypervisor need attention too
  9. Ownership is important
  10. One EMS is better than two (or three)

 

#1 Not all hardware is created equal:

The belief that you can run virtualized telecom applications on any vendor’s server is only a half-truth. There is one hardware dependency that always needs to be considered: the hardware must have a network interface card (NIC) that supports the data plane development kit (DPDK) in order to function properly.

In our experience, we’ve found it’s often better to bundle the virtual network function (VNF) with hardware providers that support this NIC requirement rather than deploy the VNF in a hardware-agnostic environment.

 

#2 The packet forwarding architecture and hypervisor need attention too

While choosing the appropriate hardware can aid in the performance of your virtualized network, the packet forwarding architecture requires attention as well. The main function of the evolved packet core (EPC) is to move a large number of packets through the data plane. This means you need very high performance in the data plane. 

Typically, packets travel through the vSwitch function within the hypervisor, which queues them for the virtual machines (VMs). The vSwitch function uses a great deal of computing power, which limits the performance that VMs can achieve. This creates a need for single-root input/output virtualization (SR-IOV) technology to get around this limitation. SR-IOV technology allows the packets to bypass the hypervisor layer and travel directly from the PCI on the server to the VMs, giving the VMs full use of all CPU power and significantly increasing performance.

While SR-IOV is not a requirement for an NFV deployment, its role and impact are sometimes misunderstood by service providers. If a provider requires very high throughput, then SR-IOV is necessary. Furthermore, applications are very sensitive to how the hypervisor is configured and the specific settings it uses. In order to reach maximum performance, service providers must also tune the hypervisor to meet the specific requirements of their application (e.g., tuning how the hypervisor schedules the CPUs, CPU pinning, etc.).

 

#3 Don’t oversubscribe the application

Another important NFV deployment tip is to never oversubscribe a virtual application or the application’s CPU. Even though the technology allows for oversubscription of the application, this ends up degrading the performance of the application and causes problems down the road.

 

#4 NFV isn’t a plug-and-play solution

Virtualization is often marketed as plug and play, but in reality, it requires some tuning in the ecosystem for telecom applications to run at maximum performance. For example, in one customer deployment, they experienced a denial-of-service attack that featured a lot of “burstiness” in the traffic. The DPDK driver was indiscriminately dropping packets and causing packet loss because it didn’t have any concept of quality of service (QoS). This required modification of the driver to avoid latency and packet loss. While this may seem like a minor detail, it can have a major impact on performance.

 

#5 – Redundancy needs to be built into the application and not just the NFVI architecture

In the enterprise world, redundancy is a relatively simple matter of spinning up a new VM when one VM fails. This works well for stateless, transaction-based applications, but telecom applications are stateful. When you lose the state of the VM, you lose the service. Also, when a VM fails, the time it requires to spin up a new VM is far too long for telecommunications applications and extends the problem of service disruption. In order to provide stateful redundancy in a telecom environment, operators cannot rely only on NFVI redundancy; statefulness needs to be built directly into the virtual application itself or maintained in an externalized database. That’s the approach we took when building our virtualized EPC solution, and it is a very important lesson to remember when talking about NFV.

 

#6 – Telecom applications require built-in load balancing

One of the main benefits of a virtual environment is the ability to scale up or scale down your processing power as workload demands change. When decommissioning a VM, however, you lose the state of that VM. In an enterprise environment featuring stateless, transaction-based applications, this is not an issue—but it is an issue in a telecom environment where stateful applications are the norm. 

Telecom applications that support dynamic scaling need load balancing; this way, when new resources are available, the application can load-balance across the new resources to prevent dropping service during a call/session. We believe load balancing should be built into the application, as the application knows better how to use the resources than an external load balancer.

 

#7 – VMs need to scale independently

NFV vendors need to be thinking about scalability before they build their solutions, not after. Specifically, vendors need to ensure that their VNFs can scale independently across different dimensions. In a telecom application, the data plane, management plane and control (i.e., signaling) plane each need to be scaled independently to avoid paying for stranded capacity. 

In a blade-based architecture, the signaling, data, and management capacity are added in fixed ratios; as more signaling capacity is needed, more blades are added. The result is that service providers end up with more data capacity as well, whether they need it or not. In a virtualized architecture, independent scaling is supported, meaning providers can scale up signaling capacity without affecting the data or management dimensions. This is the reason we chose to decompose each plane when we built our vEPC.

Applications need to be designed in a flexible way, allowing the scaling of VMs based on the specific call model or application (e.g., IoT, enterprise, consumer) and the availability of resources. By doing this, service providers can right-size the capacity for the specific call model.

 

#8 – Ownership is important

Service providers have traditionally relied upon their vendors to provide all the layers of a solution. NFV architecture is different. There’s a hardware layer, a hypervisor layer, and an application layer to consider, with each vendor bringing their own perspective to the solution. Instead of one finger to point when things go wrong, service providers must now point several fingers. This creates a challenge for providers in managing NFV deployments, as there is no clear accountability. 

At Affirmed, we’ve encountered this problem by taking “ownership” of the NFV experience and ultimate responsibility for the way our vEPC solution behaves in the NFV infrastructure (NFVI) environment. Our customers appreciate having an experienced vendor as a lead implementor who can work with ecosystem partners to resolve any issues.

 

#9 – One EMS is better than two (or three)

Service providers are accustomed to a single element management system (EMS) that displays the state of the system (e.g., alarms, traps, etc.) across all solution layers. In an NFV architecture, however, there are separate element managers for each layer. Having an overarching EMS that extends visibility into all layers and manages them as a single pane of glass” is an important capability for any NFV architecture.

 

Take the time to learn from the leaders

Perhaps the most important lesson there is to be learned from the leaders in the NFV journey is not to wait. There are those vendors who will tell you that NFV isn’t ready for prime time. What they’re really saying is that their solutions aren’t ready yet. 

At Affirmed, we’re building virtualized solutions that give the leading operators of today the competitive advantage they need to remain the leaders of tomorrow. Our cloud-native, 5G core solution, UnityCloud, not only reduces CAPEX and OPEX but also provides the capabilities for new revenue-generating services including service automation and microservices creation.

Learn more about NFV deployments with this whitepaper we published.

Innovation at the Core: Standalone 5G Core Architecture

by Sean O’Donoghue Sean O’Donoghue No Comments

Whenever 5G is mentioned, the conversation seems to inevitably shift to 5GNR (New Radio) as the driver for the diverse use cases that will come. Meanwhile, all those 5G core innovations are pushed to the margins, with maybe a mention of network slicing. These same pundits like to tell people that 5G is still years away and to keep building out their 4G cores until it arrives. In reality, what should actually be talked about is standalone 5G core architecture. Sinking investments into a sub-optimal, closed 4G network isn’t biding your time wisely – it’s burying an opportunity.

Let me explain. Traditional mobile cores were designed to support a “one size fits all” model where voice and data services dominated the landscape. And that was understandable in a world where most networks had few service differentiations. When NFV arrived, communications service providers (CSPs) began to look more closely at cost-saving opportunities – but not at the service opportunities – presented by a virtualized Evolved Packet Core (vEPC). What they missed was the fact that next-generation services would require a radical transformation in the mobile core architecture beyond virtualization, specifically around areas that address high throughput, low latency, and high reliability. This radical transformation led to the idea of a standalone 5G core architecture.

Your cloud vendor matters… a lot

On the road to the future, CSPs need to question if their current network strategy is open to the changes and disruption that 5G will bring. For example, are they partnering with cloud-native companies or with legacy vendors whose cloud strategies are mostly air? If you’re working with a true cloud partner, you should already have a standalone 5G network in place or in process. Otherwise, you won’t be able to support the new DevOps models that will drive the revenue streams for 5G services.

Beyond that, a bigger question is whether your network is ready for 5G. Is your network infrastructure optimized and adaptable to change? 5G network should be flexible enough to deploy on public clouds, hybrid clouds, VMs or bare metal. If your 5G strategy isn’t prepared for all those scenarios, you’re seriously limiting your future. I cover this subject of cloud vendor preparedness in my blog, “It’s Time to Come Clean About Cloud-Washing.”

Five ways that a standalone 5G core can drive revenue

Network slicing is just one slice of the 5G pie. There are plenty of ways that a standalone 5G core architecture can drive revenue:

#1. Network Slicing

This is a frequently talked-about capability in 5G where a network is logically “sliced” into different segments with unique policies and capabilities to deliver customized services to an enterprise or group of customers. While network slicing is important in realizing new revenue streams – particularly for enterprise use cases – it can also serve a range of additional use cases such as the accelerated transition to virtualization, operational maintenance or new service rollouts.

#2. The Service Based Architecture (SBA)

The SBA enables network functions and external systems to communicate using web-based APIs. For a CSP making the transition from telco-native to cloud-native, this can be a seismic shift. Forget about the days when you needed to understand dozens of telecommunications protocols in order to make a simple connection. In SBA, services can register themselves and subscribe to other services, or new services can be introduced, using the same API patterns. For the first time, a network’s data and services can be exposed in a standard, secure and comprehensible way to innovative third-parties in order to create better services.

#3. Integrated Gi-LAN Services

I wrote about the value of an integrated virtual probe and analytics solution in an earlier blog (“The Intelligent Data-Centric Network”). With powerful, actionable customer insight, CSPs can rapidly create personalized targeted offers, promotions, and service bundles to attract new customers and grow revenue. Affirmed is unique in this space, as we’re the only company to provide a single platform for value-added services such as security, video optimization, TCP acceleration, and parental control that enables a unique and differentiated experience on a per-flow basis.

#4. Multi-Access Edge Computing (MEC)

Formerly known as mobile edge computing, multi-access edge computing (MEC) is yet another exciting area for growth that requires a high-performance, reliable, and scalable mobile 5g core. Affirmed’s Cloud Edge (ACE) is a MEC-based solution that allows CSPs to rapidly deploy and monetize use cases such as content delivery networks (CDNs), augmented/virtual reality, autonomous vehicles, drones, IoT, private LTE/5G for enterprise and location-specific services (e.g., in-store retail, advertising, etc.).

#5. Automation

This will be critical in the future, as CSPs will need to scale in the hyper-connected societies of tomorrow. The CSPs that execute automated service provisioning and service assurance well will reap the benefits of faster time-to-revenue and higher customer lifetime value.

Not all mobile core vendors can deliver on the promise of 5G in the form of ultra-reliable, low latency, high-throughput networks. In fact, most of them cannot deliver this because of fundamental limitations in their technology, operational challenges, and the double-sided desire to protect their legacy revenue streams. But all this raises an interesting question: If your vendor has an agenda that doesn’t align with your vision of the future, where are you headed?

 

Make no mistake: 5G is still up for grabs. Someone is going to make a lot of money on new 5G services. It could be the Googles and Amazons of the world – and it probably will be, to some extent – but CSPs have the potential to be the real winners in the battle for 5G services revenue. So what’s your competitive advantage: a network experience that feels like a slightly faster version of 4G or one that completely transforms the user experience by delivering better experiences and driving innovative new services to market quickly? When you need a standalone 5G network, only one truly stands alone: Affirmed Networks.

A Moment of Reflection on the 5G Revolution in 2019

by Ashwin Moranganti Ashwin Moranganti No Comments

The iPhone 11 was released on September 20th, 2019. Take a look at it 1, and you’ll quickly notice the extra camera and the lower price tag. What you won’t see is any mention of native support for 5G. The new iPhone doesn’t have it.

If you’re looking for the seeds of a 5G revolution, don’t look to Apple. Look to the core. There, you’ll find the revolution is right on schedule, as telco operators and enterprises continue to embrace 5G technology in their mobile network cores. Next year, analysts expect that 5G services will break big, and many of the leading telco companies are banking on it.

As an early visionary in the field of network virtualization, Affirmed has a front-row seat to the 5G revolution, and what we see is an industry-wide push toward 5G. At the early-adopter end of the spectrum, we see operators embracing cloud-native solutions that behave like the webscale networks of Amazon and Google. As the 5G rollout continues, we see operators understanding that virtualization is the only viable path to the future. In both cases, 5G is the endgame, even if their timetables are different.

 

The transition from 4G to 5G

With 2020 around the corner, one of the big questions we hear from operators and enterprises is “How do we get to 5G from here?” For most operators, the answer is to build a non-standalone 5G network using the existing 4G core and transport networks you have today.

At Affirmed, the seamless transformation between 4G and 5G has always been the core mission We’ve done this by building a virtualized evolved packet core (vEPC) solution that could gracefully transition to 5G. For example, operators can easily add network slicing capabilities, video optimization, CGNAT firewall security, and other value-added services to our vEPC solution to create 5G services. It’s part of what we call our native cloud approach, meaning that everything we’ve built is designed to run in a cloud architecture for optimal scale, speed/performance, and resiliency.

 

What’s Next for the 5G Revolution?

The immediate future of the revolution will be “pure” 5G networks or what the industry calls 5G standalone networks. Our UnityCloud solution is one of the industry’s first standalone 5G platforms, designed for environments where new 5G services can be quickly created, deployed, and (if needed) decommissioned. The same “fail fast” environment that companies like Amazon and Google use—to level the playing field between telco operators and their cloud-based competitors.

Telcos understand that they won’t be able to compete with the big cloud providers for new enterprise services revenue until their networks are competitive. That means adding network orchestration and automation capabilities, operating “non-stop” networks that remain online even during upgrades, and delivering service assurance to enterprises with deeper, real-time visibility into network traffic and performance.

It’s tempting to see the latest iPhone release of 2019 and think you’re witnessing the future of 5g. And in one sense, you are. But the real future of telecom isn’t happening on a stage. It’s happening behind the scenes, in the network cores of the world’s largest telco operators. And that future is worth keeping your eye on.

SmartNICs Give EPC/5G Services a Turbo Boost of Speed

by Harsha Kalkoti Harsha Kalkoti No Comments

5G has a need for speed, and just down the road is a host of new 5G services that will demand higher network performance, from augmented/virtual reality applications to connected cars. Where will that extra performance come from? There are two paths that mobile operators can take to boost network performance: they can upgrade and/or add more CPU horsepower to their servers—a costly option—or they can free up server CPU capacity using a SmartNIC.

 

What’s a SmartNIC?

As its name implies, SmartNIC (also called intelligent NICs) is a network interface card (NIC) that has built-in intelligence that allows it to process the data passing through it. SmartNICs are considered smarter than your average NIC.

SmartNICs something that everyone is talking about, however, at this point, there is not a complete understanding of its capabilities.

 

A standard NIC functions as an Ethernet network interface between a server and the network. NICs process basic TCP/IP information such as the source and destination IP address, port number, and the protocol being used (what we refer to in the industry as 5-tuple information). Because  SmartNICs, have built-in intelligence, they in effect performing those tasks reserved for the server CPU, such TCP checksum, load balancing, accelerating cryptography for IPsec and TLS, and other CPU-intensive tasks.

 

SmartNICs & EPC/5G Services

Okay, so maybe that definition of a SmartNIC doesn’t get your motor running. Let’s take a look under the hood for a particular load balancing use case and see how SmartNICs can really speed up EPC/5G services. The Evolved Packet Core (EPC) service—which is a software application—is used to implement special engines that create a virtual mesh of line cards inside of applications. For a given user session, traffic should be handled by a specific line card. If data was received by a different line card, it has to resend to that specified line card where the user session resides. This traffic approach is very expensive, as a large amount of east-west traffic can be generated.

This problem can be solved in multiple ways, depending on the deployed solution:

  • Specialized load balancers can be used, which will be specific to a particular application.
  • Standard Routers with ECMP could be used, but they have to be deployed very intelligently. Also, this approach doesn’t scale.
  • Operators can limit the number of servers acting as line cards by managing the server group using a Load Balancer as a Service (LBaaS) feature. This approach, however, wastes resources.
  • SmartNICs can be used for load balancing. This is the most effective and efficient option.

Typically, we would have assigned a specific number of cores to perform these functions to do a  GTP-U lookup (load balancer) on a standard NIC configuration. Because the SmartNIC is EPC aware, it can do the GTP-U header lookup automatically. But with a SmartNIC, the load balancer effectively goes away. We can shift CPU-intensive tasks such as GTP-U header lookups from the core to the SmartNIC, freeing up our server CPUs to perform other useful tasks. That means all cores can now focus on processing value-added services for EPC/5G applications: deep packet inspection, endpoint detection, and response, adaptive bitrate streaming, and so on.

 

It’s also important to note that SmartNICs aren’t just smarter than regular NICs; they’re faster too. Standard NICs support up to 40 Gbps, but SmartNICs typically support speeds of 100 Gbps and 200 Gbps.

 

SmartNICs Outlook for Mobile Operators

If you imagine that servers are the engines of your network, then using SmartNICs is like having an extra turbo-boost button on your network. And as EPC/5G services are right around the corner, the ability to accelerate network performance is exactly the kind of competitive advantage that mobile operators need.