Cellwize are an independent C-SON (Centralised SON) software company, one of a few emerging from the crowd and positioning themselves to mastermind HetNet optimisation. We asked their CEO, Ofir Zemer, how he saw C-SON fitting in with the evolution of small cells.
He outlined the steps towards a mature HetNet, and shared his views on how this will need partnerships and interoperability with both D-SON and equipment vendors.
Where does Centralised SON fit in the industry?
As mobile networks enter a period of densification using small cells, we believe vendor interoperability is key. This comes in many forms and shapes, and is one of the most challenging topics right now. We see the industry as being forward looking at the moment, and there is no doubt that small cells will be widely adopted, but there are some questions about the technology.
We envisage SON technology maturing through a three stage adoption process:
1) Small cell awareness
The simplest solution is a static mode. You simply block out resources (e.g. a set of scrambling codes etc.) for use by the small cell layer nationwide. All macrocells have these configured in their neighbour lists, so that any femtocell or small cell is seen and can be used.
However this isn't the most efficient and wastes potential resources. We have a trigger based mechanism that identifies where and when small cells have been deployed, and increases the allocation dynamically. Our focus is mainly on the macrocell side for ANR (Automatic Neighbour Relations), and is something we are very comfortable with.
This means we don't need tight co-ordination between the C-SON and small cell providers. The same principle is used for both 3G and LTE.
2) Bi-Directional Interface
This next stage is still not full interoperability, but allows some two-way dialog through the small cell gateway. We can interact with the small cells to access specific configuration management data.
There is quite a variation in the degree to which different small cell vendors allow eternal systems to modify their configuration. For example ip.access, Airspan, Alcatel-Lucent, Samsung are all at different stages. I'd pick out ip.access to be the most open from our perspective, and they have a clear view that they need to interact with a C-SON system for maximum overall benefit. This can even override some of their own D-SON functionality where necessary.
Typical small cell parameters which could be remotely set by the C-SON include ANR (neighbour lists), 3G scrambling codes and LTE PCI (Physical Cell Identifiers).
3) Mature HetNet Partnerships
This is the most sophisticated stage, where C-SON and D-SON truly co-exist. Specific LTE-Advanced features such as eICIC need real-time interaction through the X.2 interface with other small cells and the macrocell layer to work most efficiently. This is perhaps the most important feature for an LTE small cell to have embedded, and is a key capability for equipment vendors and D-SON software to address.
Once the real-time efficiency of the HetNet has been addressed, then SON features such as MLB (Mobility Load Balancing) and MRO (Mobility Robustness Optimisation) have a role to play. These balance and direct traffic loads across the Hetnet, both in terms of small cell and macrocell layers as well as between 3G and LTE.
When looking deeper at MLB, we don't just want to look at distributing traffic within a frequency band or technology, but look at each individual data session and what type of service is being handled. M2M should be dealt with differently to YouTube videos. We allow operators to define a policy and orchestrate that across the whole network. This can take into account of implications for features such as CSFB (Circuit Switched Fall-Back for voice calls).
Indeed, there are many sophisticated optimisations that could be taken advantage of here, but it will need closer interworking between vendors - a partner ecosystem between C-SON, D-SON and Small Cell vendors. The industry is still far away from completing that, but we are looking to expand our partner relationships further.
How does SON fit into the current industry hype around SDN and NFV?
Our software can already run in a virtual machine, meaning it is hardware independent. We already have many engagements where this has been done.
Whether you call this SDN or NFV depends on your own perspective.
We've also recently announced joining Alcatel-Lucent's CloudBand ecosystem, and are actively testing at their NFV development centre.
As the Cloud RAN ecosystem evolves, we could see the OSS (Operations Support system) also become virtualised, allowing some fantastic things to happen using C-SON. We could have much more control and be able to determine which small cells and/or which central baseband units are up and running at any one time – turning equipment on and off during the day to save energy.
Our challenge is that until we understand the business case for Cloud RAN, then we wont push forward too much on that but we are having ongoing discussions. In the long term, C-SON would play a much more significant role and we'd need to clarify the borders and overlap between SON and SDN.
How does SON impact the introduction of VoLTE? Any implications for Small Cells?
We are working with a major Tier 1 in North America as they work towards launching VoLTE. Their major concern is CSFB (fallback of voice calls to 3G), where we can use SON to reduce delays and ensure CFSB will happen without dropping calls. We don't implement the CSFB feature directly ourselves, but do help tune the network to optimise it. We've worked with other operators elsewhere who have extensively tested VoLTE and told us they've put it on hold for now.
What we see is that CSFB is a very critical issue and important for VoLTE from launch. There are a lot of LTE deployments using 800MHz bands alongside 3G/UMTS at 2100MHz, meaning the coverage footprints of each differ significantly. Small cells may have a role to play to expand and ensure service continuity in these otherwise poorly served areas. This could use 3G as much as LTE.