Subscriber Data Management

BSS in Need of Virtualization Overhaul

Billing support systems must become more flexible, more granular, and more able to deliver real-time results to function in the coming era of SDN and NFV, according to the latest Heavy Reading report, "BSS Requirements for SDN & NFV."

Heavy Reading Senior Analyst Ari Banerjee and Analyst Sarah Wallace looked at what the new breed of services will look like if -- or maybe we should say "when" -- the virtualization transformation occurs, and also asked network operators for their expectations of billing in the era of NFV and SDN. (See Defining SDN & NFV.)

They note that services will be more personalized and will draw from capabilities provided by third parties, which will need to be compensated, thus creating new levels of complexity for billing systems, which must both monitor usage and assess compensation. The explosion in the number of services to be offered is what produces the need for greater granularity in billing systems, which today only have to consider a limited number of almost completely static service options, the report notes.

In particular, operators need to be able to monetize the use of virtualized functions by their enterprise customers or by service partners, such as over-the-top (OTT) content providers. That means paying more attention to the billing systems that will enable that monetization, the report states.

Service providers are already recognizing the need for improved billing, Banerjee and Wallace note. In a Heavy Reading survey, 14% of service providers said they have already started evaluating the impact of NFV on their BSSs, 20% said they planned to do that evaluation in the next six months, and 30% said they would do it in the next one to two years.

Vendors need to be prepared to offer a virtualized BSS ecosystem that has the flexibility to allow network operators to monetize new services in an efficient way, the Heavy Reading analysts note. This will mean a major shift away from today's more rigid and static BSSs.

Architectural changes are also afoot. The expectation is that systems in use today to track usage and deliver application-specific performance, such as policy management and deep packet inspection, will be closely tied to the SDN controllers which will be orchestrating network resources.

The report also notes changes needed in how billing and charging are handled to enable full capture of metered records and support for self-service portals to deliver on-demand services as well.

— Carol Wilson, Editor-at-Large, Light Reading

Want to learn more about NFV, SDN and smarter telco operations? Check out the agenda for Light Reading's Big Telecom Event (BTE), which will take place on June 17 and 18 at the Sheraton Chicago Hotel and Towers. The event combines the educational power of interactive conference sessions devised and hosted by Heavy Reading's experienced industry analysts with multi-vendor interoperability and proof-of-concept networking and application showcases. For more on the event, the topics, and the stellar service provider speaker lineup, see Telecommunication Luminaries to Discuss the Hottest Industry Trends at Light Reading's Big Telecom Event in June.

Page 1 / 2   >   >>
EsmeraldaSwartz 3/18/2014 | 10:10:46 AM
Re: Even tougher than the networking part of SDN/NFV

SDN with NFV enables CSPs to break out of their inflexible business models and do business differently. Talk to any carrier and they will tell you that launching new services, bundling digital services and managing time-to-market delays are huge obstacles with existing silos and traditional OSS/BSS systems. With SDN and NFV, the process of service creation and delivery is accelerated by bringing cloud capabilities into the network. SDN/NFV transform carrier businesses to a state where services are provided in a manner that resembles cloud computing services, and infrastructure is purchased and provisioned similar to PODs used in cloud data center services. Starting in data centers, networking services and business policies will be instantiated as needed over common infrastructure. With SDN's control and NFV's flexibility, CSPs can develop business models that are based on elastic/tiered services, such as security-as-a-service solutions using on-demand DPI functions or video and UCaaS on demand. Carriers can deploy, modify or remove services and applications in a matter of minutes.


CSPs are also looking at new procurement models that may include paying network equipment providers on a per-use basis for network functions versus capital expenditure tied to under-used equipment. Lastly, the types of services enabled are by their very nature going to be multi-party and may include a number of physical and logical services. This requires that the OSS/BSS determines how to best deliver the service. If additional capacity or function is required, it must broker the capacity from the choice of vendors or partners, assess the contractual relationship (payment terms, profit margin impact, SLA terms), provide the commitment in real-time, receive requested capacity and manage any violations of customer SLAs.

brookseven 3/17/2014 | 4:26:19 PM
Re: Even tougher than the networking part of SDN/NFV  

Okay Esmeralda,

Can you outline an example service that you have described?

And everyone,

Why does nobody seem to want to talk about how the NFV is going to be billed the other way around (i.e. turning up an instance and how billing is going to be tracked?)?


EsmeraldaSwartz 3/17/2014 | 4:15:11 PM
Re: Even tougher than the networking part of SDN/NFV While the concepts of bandwidth on-demand and who-to-bill are certainly key concerns that need to be addressed by service providers (sooner rather than later), these are issues that are part of a bigger conversation. It's true that you can't "NFV or SDN bandwidth," but NFV and SDN will enable the services and partnerships that will ultimately drive the more complex relationships and business models. It is these enhanced services that will result in a need for greater bandwidth, and ultimately a desire for more consumption-based and flexible monetization platforms. Service providers can only meet that expectation when they've implemented the necessary software right from the start that can adapt to these new developments across the industry.
RitchBlasi 3/17/2014 | 2:45:02 PM
BSS I might be in the wrong ballpark, and someone might have alluded to this, but I can see the need for enhanced BSS on NFV or SDN when it comes to offering sponsored data services.  I don't look at that as bandwidth-on-demand but rather a wholesale pricing strategy for when Netflix, Hulu and others go big-time into offering video downloads directly to mobile devices.
danielcawrey 3/17/2014 | 2:05:57 PM
Re: Even tougher than the networking part of SDN/NFV Despite any snags that telcos might find in terms of billing, at least they will be bringing in revenue. If their biggest problem is who to bill for a service, then that doesn't really sound like such an insurmoutable issue going forward. 
brookseven 3/17/2014 | 2:01:45 PM
Re: Even tougher than the networking part of SDN/NFV Carol/Mitch,

I think we need to think of another service other than Bandwidth on Demand to be the poster child here.  I first worked on a Bandwidth on Demand service for Teleconferencing back in 1990 (using bonded DS0s over PRI).

Part of the problem with this service as an example is that in some ways you can't "NFV or SDN" bandwidth.  The bandwidth is either available or it is not.  You can look at reallocating your bandwidth but if you are on a full network then there is simply nothing that can be done.

In a highly connected place like a datacenter, this may not be an issue.  But if you want to ramp up the bandwidth to a cell site and you have a GigE installed, you can't "SDN or NFV" your way to 10G or even 2G.

What I am suggesting insteasd is that we could up with a service that dynamically adds processing to an existing pipe.  I don't have a great example in mind, but maybe something like encryption for some type of connections for certain folks (like say sending files to your lawyers).


Carol Wilson 3/17/2014 | 1:11:04 PM
Re: Even tougher than the networking part of SDN/NFV Absolutely right, Mitch, but I think they are going to have the bandwidth on demand part to be among the easier things, because at least they know how to measure and bill for bandwdith. 

By contrast, offering BoD to support a specific piece of video content and allowing the consumer to self-provision his level of service (collect more money for highest level of service right now, or the least amount to download during offpeak, plus something in the middle for immediate streaming at a lower QoS) and then billing the consumer correctly and carving out the piece owed to the content partner will be even more daunting. 
Mitch Wagner 3/17/2014 | 12:59:03 PM
Re: Even tougher than the networking part of SDN/NFV Makes sense. The potential for SDN/NFV is to allow service providers to spin up new services and configurations on the fly. For example, an enterprise customer might need a burst of bandwidth for a few hours, to make a backup or migrate a datacenter. Service providers need to be able to meet that kind of demand, and billing systems need to be able to bill for it. 
Carol Wilson 3/17/2014 | 12:28:14 PM
Re: Even tougher than the networking part of SDN/NFV I agree, Ray. I think the billing stuff winds up becoming more important than originally thought because of the shift away from virtualization as a way to save money and toward virtualization as a way to deliver new services more quickly and compete more effectively.
brookseven 3/17/2014 | 12:21:59 PM
Re: Even tougher than the networking part of SDN/NFV Ray,

There are lots of challenges here.  Let me give you one example from an NFV standpoint (note this is solved in the IT world but people may be unhappy with the way this was done for telcos).

When you turn up an instance of a function, that is going to cost you money.  Let's say as an example (from my past) the customer turns up a new E-mail Spam Filter going from a maximum of 5 to a maximum of 6.  Okay - under what granularity am I billing him?  If he leaves up a 6th instance permanently, he is definitely getting a bill for the new one.  How about 15 minutes?  How about 24 hours?  How does the customer control the startup and teardown so that they stay in budget?

As you can imagine, I have seen this go horribly wrong.  Another part of the company I was working for was doing VMs for web filtering.  There was a bug that forgot to turn down instances and poof at the end of the month there was a huge bill from AWS.  

My take is that beyond all the functionality that this stuff needs to get to be "standardized" into packages that people can understand and manage.  The rules that one vendor puts out better be the same as or similar to others or this is going to be a huge mess.


Page 1 / 2   >   >>
Sign In