Skip navigation

As we talk with telecom service providers about their plans for deploying Network Functions Virtualization (NFV), another topic invariably comes up. Depending on who you listen to, the Internet of Things (IoT) represents either a drag on network resources that leads to unrecoverable costs or else an opportunity for revenue growth through innovative new services. Or maybe both.

This post will highlight some of the implications of IoT for service providers, outlining potential upsides and downsides. This is hot industry topic and we’d welcome your thoughts on how service providers can best exploit this opportunity.

Frequently-quoted forecasts for IoT devices active by 2020 range from 25 billion (Gartner) to 75 billion (Morgan Stanley), with Cisco taking the middle ground at 50 billion. Regardless of which number is most defensible, there’s no doubt that the number of devices connected to service provider networks will be exponentially greater in five years than it is today.

So what’s the implication for the network itself of all these IoT devices that will be coming online?

First of all, it’s important to understand that the majority of “IoT-enabled” devices actually have no need for an Internet connection at all, though of course they may each be generating data which potentially requires additional network capacity. Sensors used in applications like home security, industrial control, connected cars and health monitoring systems typically connect locally with peer devices and/or with gateways. Mostly, it’s only the control systems which require an Internet connection back to the cloud (though some connected car applications are notable exceptions). This reduces the number of devices connecting to service provider networks by at least an order of magnitude, though we’re still talking about billions of new connections by 2020.

Once it reaches a service provider network, IOT traffic will present some unique challenges for the network infrastructure. Compared to regular Internet traffic, IoT will support so many different use cases that service providers will need to cater for a range of use cases spanning chatty, low-bandwidth connections all the way through to high-bandwidth persistent connections. The flexibility of NFV is key to providing the flexibility to address these diverse networking requirements.

Industry experts disagree widely on the expected bandwidth impact of IoT. On the conservative side, some are projecting that the overall amount of IoT traffic will be negligible compared to today’s Internet bandwidth, which is dominated by video and growing exponentially. Others take a more aggressive position, pointing out that once IoT becomes pervasive new use cases will emerge and traffic will explode.

Rather than raw bandwidth, the biggest network-related issues for IoT traffic are security, privacy, availability and latency.

Security and privacy will likely receive the most attention, at least in the media. As IoT devices become more and more prevalent in our lives, their usefulness for applications like healthcare, energy and home monitoring will demand their awareness of increasingly personal information, or at least information that easily be profiled back to you once it’s analyzed as “big data’ in the cloud. Service providers will need to implement sophisticated network security systems that meet the expectations of both consumer and enterprise customers.

Network availability will be critical for many IoT applications. If critical infrastructure systems like industrial control, emergency, healthcare and security are going to be sending time-critical traffic over a service provider network, they need to have a very high degree of confidence that the network will be up and all the networking services will be working. Enterprise-class availability (three-nines or 99.9% up uptime) won’t be adequate: these services will demand the six-nines reliability (99.9999% uptime) that today is only achieved by telco-grade networks. Again, there will be a wide diversity of requirements for network availability, reliability and resiliency: some IoT applications will tolerate packet loss while others will demand maximum fault tolerance.

The latency (and jitter) of service provider networks will have a strong impact on the usefulness of many projected IoT applications. If you’re driving a connected car with the expectation that traffic lights or sensors are going to react to your presence, a one second delay at 70 miles an hour means that you’ve travelled 100 feet. A lot can go wrong over that time and distance. Quality-of-Service (QoS) segmentation will allow service providers to position (and price) different service levels for different use cases.

All these issues point to the need for highly-reliable, low-latency, secure infrastructure platforms in service provider networks optimized for IoT traffic.

So how can the network be more than a “dumb pipe” and add real value to the enterprises consuming all this data that originates from IoT devices? One way is by intelligently determining what data is upstreamed and when that happens. Sophisticated gateways will segment their IoT traffic between information that needs to be transmitted to the cloud in real-time and data that can be stored and then transmitted when low-cost bandwidth is available, for offline analysis. This allows intelligent gateways to avoid constantly pumping massive amount of data “northbound”, overwhelming both the network and the storage infrastructure. It also enables them to provide different QoS for different payloads.

Software Defined Networking (SDN) technologies will use network Quality-of-Service (QoS) to manage traffic flows based on an awareness of the application or service, as well as the type of traffic. This awareness would come from the use of Deep Packet Inspection (DPI) and content inspection within an SDN framework. Essentially, SDN manages path capacity while NFV provides dynamic scaling of processing and networking resources.

One of the revenue-generating opportunities that service providers are discussing is the use of analytics to monitor and predict customer behavior, while assessing the state of the network. This can lead to automating the upselling and pricing of network services, such as temporary bandwidth expansion or ultra-low latency connections.

Finally, several service providers have talked to us about the value of “contextual knowledge” about their customers. Between their network infrastructure and their OSS/BSS systems (Operations Support / Billing Support), they capture continuous information about their customers’ location (if mobile), their characteristics of their network traffic and even the applications that they run. They have a unique business opportunity to turn this knowledge into value-added services.

What do you think? Is the explosion in IoT devices an opportunity or a threat for service providers? We’d be delighted to hear your thoughts.

Lunchtime “debating tables” seem to be all the rage at telecom conferences recently. At certain tables during the lunch break, an industry guru (often, of course, a sponsor’s representative) is assigned to chair a discussion about a specific industry topic. In theory it’s a great opportunity for a lively exchange of opinions between conference attendees with a shared interest in that subject.

In practice, I confess that I usually head for the table chaired by someone who appears to be a promising sales lead and exchange business cards as soon as possible. Then I spend the lunch break catching up on the morning’s emails and checking Cricinfo for the latest news on the world’s most popular sport. Because pretty much everyone else is doing the same thing.

At a recent event, though, I was drawn to a table where the conversation was unusually animated even though no-one was talking about sports. The subject was “CRAN” and I was intrigued to find out what aspect of this topic was generating so much disagreement. It didn’t take long to determine that, out of the eight or nine people at the table, there were at least four or five different interpretations of exactly what the term CRAN means. So we had four or five opinions on trends, issues and benefits, all of which were individually correct but appeared to be widely divergent.

In this post, I’ll attempt to summarize the various definitions of CRAN that I heard during this interesting lunch. I’ll provide a perspective on where we are as an industry that is clearly deploying this technology in multiple phases, with adoption rates varying widely across different geographies. I’ll also touch on some of the major challenges that need to be addressed, both technical and commercial, before service providers worldwide can reap the full benefits of this aspect of network virtualization.

CRAN.pngFrom a business perspective, all the approaches to CRAN are intended to reduce CAPEX and OPEX for telecom service providers. By centralizing and then virtualizing processing functions that were traditionally performed by dedicated networking equipment located at the antenna sites (cell sites), CRAN enables the cell site to be simplified to the point where it’s just the radio unit comprising power amplifiers, filters etc. and the antenna. The cost of the baseband and call processing functions drops dramatically thanks to COTS hardware and virtualization. At the same time the risk of network downtime is reduced and the overall experience for subscribers is improved. All very worthy objectives……

If we consider the installed base of CRAN equipment, it’s clear that this technology already represents a significant share of overall telecom spending. A recent report by Infonetics estimates that revenue from CRAN architecture equipment was $4.9B in 2014, up from $4.1B the previous year, while projecting that it will reach $10B by 2018. So far, the majority of deployments are in Asia (primarily Japan and South Korea), with Infonetics expecting rollouts to start in Europe, Latin America and North America this year. The business benefits are compelling: SNS Research reports that China Mobile has shown a 30% reduction in CAPEX and a 53% reduction in OPEX in its CRAN trials.

The flavor of CRAN most widely deployed today is the traditional Centralized RAN architecture. In this approach, the basestation (BTS) is decomposed by decoupling its remote radio head (RRH) at the cell site from its baseband unit (BBU). Multiple RRHs are connected to a single, shared BBU over dark fiber, via a “fronthaul” interface that is either Common Protocol Radio Interface (CPRI) or Open Basestation Architecture Initiative (OBSAI). On average there are three RRHs (typically installed on rooftops) per BBU (usually in the basement of a building) for a macro cell site, as well as a few RRH micro and pico sites connected to the BBU. Separating the RRHs from the BBUs reduces the cost (both CAPEX and OPEX) of the equipment at the cell site. Depending on the level of aggregation, it brings some economies of scale to the BBU, the cost of which is also reduced whenever it’s located indoors.

In the next phase of consolidation, several such BBUs are grouped together and aggregated to form a Centralized BBU “C-BBU”, using a CPRI/OBSAI switch, cross connects and load balancers. As one example, this architecture has been deployed by KT in South Korea. Within the C-BBU, processing resources are pooled and allocated based on RRH traffic. Often, a C-BBU will support both residential and business areas, with resource allocation adjusted dynamically as traffic patterns change during the day. This solution is limited to small clusters of RRHs because complexity increases exponentially with larger clusters of RRHs. It yields significant some cost savings compared to the basic centralized RAN approach where BBUs in both residential and business areas must be sized for peak traffic in their respective locations. Note, in both these approaches, the BBU hardware is still custom because these approaches can’t leverage the cost advantage of COTS hardware.

The next step is a true Cloud RAN architecture in which the centralized BBUs supporting large clusters of cell sites are virtualized. These “vBBUs” can be instantiated on standard COTS server platforms rather than on dedicated custom, fixed-function equipment from traditional RAN vendors. Several telecom RAN infrastructure vendors are working on vBBU solutions. Depending on the approach, the fronthaul transport provisioning may require very high bandwidth and ultra-low latency, or nominal bandwidth and low latency or nominal bandwidth and relaxed latency. Also, computational efficiency is a major concern in some of the approaches. Various PoCs are either in progress or completed.

The challenge of computational efficiency was addressed in an ETSI Proof-of-Concept involving Alcatel-Lucent, China Mobile, Intel and Wind River, which was completed last year and subsequently demonstrated at various industry events (details here). This showed that it’s possible to meet the stringent real-time requirements of both TD-LTE and GSM systems using virtualized infrastructure. It also illustrated that it’s possible for cloud RAN to maintain the level of reliability required for telecom infrastructure, which was demonstrated by performing functions such as the live migration of LTE streams without service a viirements of both not onl stringent real-time requirements ofequipment. and business areas must be sized for peak traffic

There are several approaches to the challenge of fronthaul efficiency. Some service providers are exploring compression to reduce the CPRI/OBSAI bandwidth required for each RRH, while others are investigating the use of WDM, with multiple carriers on the same fiber. These options, though, still require a dedicated fiber connection between each RRH and the vBBU, which is not always available or practical in many locations.

Altiostar is one company with an innovative approach to the fronthaul connection. They have developed technology that allows the use of Ethernet for fronthaul, enabling very high density NFV CRAN to be deployed anywhere that a standard Ethernet connection can be provided to the RRH. Altiostar’s portfolio contains macro, micro and pico eNodeBs based on its innovative NFV CRAN architecture. In partnership with Wind River,

Altiostar showcased their virtualized intelligent basestation at Mobile World Congress in March 2015. The solution leverages the low cost and scale of COTS hardware ecosystem to achieve 90% cost savings over Centralized RAN approaches based on custom hardware. Their CRAN solution is commercially deployed in a dense urban area in North America, with other deployments and trials in progress in Europe.

The next major step in operational efficiency will come from the integration of virtualized Cloud RAN “vRAN” into the system-wide Network Functions Virtualization (NFV) architecture standardized by leading service providers through the ETSI initiative. vRAN resources can be dynamically optimized, scaled and orchestrated as part of the overall NFV cloud. This brings service providers the benefits of service agility and OPEX reductions, along with the resilient infrastructure that is expected from telecom networks. This evolution of the network aligns with the industry’s vision for 5G.


Companies like ASOCS, with a complete virtualized basestation “vBS”, are launching solutions that target specific vRAN use cases such as large venues (e.g. stadiums, skyscrapers and malls) and high-density urban areas with wide variations in traffic patterns and subscriber density. These solutions enable service providers to deploy distributed NFV clouds for the vBS and other Mobile Edge Computing “MEC” applications at the metro and network edge

So it’s no surprise that the discussion at my lunch table was so animated. Essentially we were having parallel discussions about Centralized RAN, Centralized BBU, Cloud RAN and virtualized Cloud RAN, all under the umbrella topic of “CRAN”. And if we hadn’t spent so much time clarifying what everyone was actually referring to, the conversation might well have progressed to Coordinated RAN, Collaborative RAN, Clean RAN and Advanced CRAN, all of which are additional vendor-specific approaches that could possibly be subjects for another article.

It’s clear that all these variants of the CRAN concept have the potential to deliver major CAPEX and OPEX savings in the network, while ensuring that end users experience the seamless coverage and high bandwidth that they expect. Each of these approaches can help to reduce customer churn and keep network costs under control, while NFV promises the agility that will enable the delivery of new, value-added services to drive revenue growth for service providers.

What are your thoughts on this? Which of these CRAN approaches to you expect to be most effective and when do you expect to see them deployed?

Filter Blog

By date: By tag: