Email a colleague    

March 2016

Monetizing NFV/SDN: How Policy Will Allow Virtual Networks to Play in the Big Leagues

Monetizing NFV/SDN: How Policy Will Allow Virtual Networks to Play in the Big Leagues

From a technical standpoint, virtual networks have clearly moved beyond the labs.

Network functions have been taken off specific hardware platforms and put on general purpose processors in the cloud — and run as virtual machines in live networks.  VNFs are also rapidly emerging in key areas such firewalls, routers, session border control, and security.

But what’s it going to take to transform a bunch of VNFs into a large, synchronized network of VNFs that delivers a huge commercial advantage for operators?

Today’s NFV is like a ragtag federation of city football teams.  Each city team makes some money selling popcorn, hotdogs, and beer at its home games — and that’s a great start.  But there’s no established league quite yet.  There’s no National Football League (NFL) that leverages national TV and promotes Super Bowls into huge money makers.

Well, Netcracker Technology, a leading systems integrator and BSS/OSS software firm, has big plans on helping operators play NFV/SDN in the big leagues.  And joining us to discuss that is Ari Banerjee, Netcracker’s Senior Director of Strategy.

Dan Baker, Black Swan Editor: Ari, to begin, what progress has telecom made in virtualization so far?

Ari Banerjee: Dan, the prevailing use case for NFV today is in vCPE, virtualized CPE.  This makes sense because vCPE services can be implemented in a contained domain at a level of scale and scope determined by the service provider.  You can take one market and one service and neatly test it in a controlled environment to prove it can be operationalized.

In the next few years we’ll see more and more service providers implementing vCPE services and as they succeed, they will replicate them across a larger customer base.

Other places like the Evolved Packet Core (EPC) and the intersection of the RAN and IMS also justify NFV.  For instance, a customer of ours, NTT DOCOMO, has virtualized their EPC and we are a key part of the orchestration solution there.

Where does Netcracker fit in the larger ecosystem that’s emerging around virtualization?

Well, Netcracker’s expertise is in operationalizing and bringing services to market and helping customers generate revenue from them.  Our modernized OSS and BSS solutions enable operators to migrate to the orchestration solutions they need for new virtual services.

Different industry players excel at different things.  Network equipment providers allow operators to move traffic from point A to point B.  But today that’s a very small part of operationalizing and commercializing NFV-based services.

Another strength is we leverage the networking and global reach of our parent company, NEC.  We also work with a broad ecosystem of virtual infrastructure partners.  That’s why we are in a good position to deliver an end-to-end SDN/NFV architectural solution.

I recently attended the 2015 Metro Ethernet Forum’s GEN15 conference in Dallas.  It was a great conference with a strong focus on the transition from OSS to service virtualization.  However, I did not hear much discussion about the BSS side.

MEF focuses on the service provider network infrastructure layer.  And to their credit they are starting to look at the operational layer.  That’s the whole conversation about LSO.

Going forward, they need to articulate a stronger operational vision beyond lifecycle service orchestration (LSO) as it’s defined today.  And by that I mean the system not only needs to know how to provision services from orchestration down through the network, but also how to implement a full SDN/NFV service commercialization solution that includes billing, rating and charging, partner management, policy and analytics and self-care.

A virtualized environment will require an innovative BSS solution that is flexible but also programmable and able to immediately capture any type of chargeable event or trigger.  Modern BSS systems should be able to respond in real time and accommodate new types of billing events.  It also needs to anticipate and support a wide range of charging and rating scenarios, such as usage-based consumption regardless of metric; chargeback; end-to-end subscriber management and more.

All those things are important if you expect to bring services to market in a real commercial way.  So I think that’s the next step.

Now maybe, from the standpoint of an organization originally focused on Metro Ethernet alone, that’s out of scope.  But in the larger picture, I’d argue they need to expand their vision.

Let’s drill down on the topic of “policy”.  When people talk about policy in the network, it’s often around PCRF, a central place to store rules to carry out rules.  But what you’re talking about is a policy that’s more pervasive.

Yes, going forward, we need policy management throughout all orchestration layers.  You need it in cloud (or data center) orchestration, resource layer orchestration (or NFV-O), as well as the service orchestration layer.

The power of policy is combining it with monitoring, analytics and orchestration to create a full closed loop system.  And the reason that is needed is customers ultimately want to automate service fulfillment and assurance in real-time — or at least in a much shorter timeframe that what’s traditionally been weeks, if not months of time.

What an automated closed loop does is monitor traffic in real time and then provision and assure services based on a dynamic policy engine.

You can look at what’s happening in the network, and even predict future conditions, but you can’t really make the right operational modifications unless you know what the customer requires and what the network constraints are.  And that’s where the policy engine comes in.

The closed loop I’m describing is not available today in an NFV environment.  This is a very complex challenge to address that the vendor community is working on collaboratively with their customers.

What are the consequences of not having that closed policy and analytics loop you talk about?

Without the closed loop, the vision of NFV and SDN won’t get fully realized.  On a large scale, we won’t be able to successfully change service characteristics in a very rapid timeframe, meet customer needs, or optimize the performance of the network.

Today’s approach is to simply throw bandwidth out there in the hope that it’s enough.  But as more and more applications move into the cloud, and as the Internet of Things takes off in a material way, the network architecture will need to evolve to support massive data growth and much more dynamic traffic requirements than what we have today.

We must get to the point where SDN and NFV serve as enablers of on-demand service models and the delivery of applications to end users and machines happens in a much shorter timeframe with automated operations.

Maybe it would be good to discuss some examples to get a better feel for how policy is going to be implemented and how things are going to change.

Let’s start with the fact that you need a policy engine in place that informs the orchestration layer how to fulfill and assure services, and how to manage the service’s lifecycle.  Otherwise, the customer’s performance needs — whether it’s a business or a residential user — are not going to be met.

Let’s say an operator is offering an “on-demand” optical or Ethernet private line service from a business site to a data center, where the enterprise customer maintains the majority of its business applications.  Many operators are starting to offer such services today.  AT&T, for example, has a Layer 2 Bandwidth on Demand service, and Colt has something similar.

Well, it’s likely that all of those business applications have different service attributes.  One application may be latency sensitive; another application might be sensitive to packet loss or require very little jitter; and another might need massive amounts of bandwidth (or no bandwidth at all) at particular times of day.

In order for the operator to meet customer SLAs, they need to have a robust policy control engine that can inform the orchestration layer how to make fulfillment and assurance changes as application behavior and network resources change.  Without policy control integrated throughout each layer of orchestration, there really is no way to create and sustain the “on-demand” experience.

Ari, thank you for this nice forward-looking perspective.  I like the idea that it ties in the world that exists today with where we need to go tomorrow.

The whole point of service level orchestration is to tie together the physical and virtual.  If you are an end user in a vCPE environment and you want to connect securely to Amazon’s AWS, that connection will transverse physical and virtual network boundaries.  That’s a given.  And to do that you need both service level orchestration and the existing OSS/BSS as well.  For a long time we need to operate in hybrid environments.

So this plays to Netcracker’s strength because we know the existing BSS/OSS environment very well, and that means we can really help our customers migrate to the new while maintaining the existing.

Copyright 2016 Black Swan Telecom Journal

 
Ari Banerjee

Ari Banerjee

Ari Banerjee is the Senior Director of Strategy at Netcracker Technology.  He is responsible for all aspects of Netcracker’s strategic initiatives across its BSS/OSS, CEM and Big Data Analytics business lines, including customer, product and technology management, market direction and corporate communications.

Before joining Netcracker, Ari was a Principal Analyst at Heavy Reading and led the company’s Service Provider IT Total Access research service, including all aspects of telecom software research.

Ari was also Vice President of Next-Generation Software Systems at Yankee Group.  He also worked for the billing and customer care division at Lucent Technologies, and subsequently the global software and services group at CSG Systems.

Black Swan Solution Guides & Papers

Related Articles