“Successful Deployment is a result of Close Co-operation” – SON Tzu
This is a humorous pseudo-quote put out on Twitter a month or so ago, parodying what the ancient Chinese military strategy master Sun Tzu, perhaps most famous for his book “The Art of War”, might have said about modern cellular network deployment.
Self Organising Networks (SON) is an over-abused term with many products claiming to support it, and there is much information on the web as to what it is, or might be, so I will only outline various aspects of it and then focus on some small cell aspects. SON can come in a number of forms that broadly relate to different stages in the deployment of a network, but the drivers remain keeping operator costs under control as the demands on improving the user experience get tougher.
1. Self Configuration – 'Zero Touch' Plug and Play, when a cell and network is first being set up. This involves doing things like
Femtocells were the pioneers in this approach, with the anticipated scale of their deployment demanding automation, with the AT&T Microcell from Cisco and ip.access being the leader in Zero Touch operation, whilst the ip.access nanoGSM 2G picocell has been listening out for over a decade now. The introduction of LTE has standardised many functions to assist with this, including getting measurements from the handset to discover neightbours, known as ANR (automatic neighbor relation)
2. Self Optimisation - This is the continued fine tuning of a network when things are up and running. Examples include improving key performance indicators such as call drop, or reducing ping-pong handover between two cells
3. Self Healing - this is where a network automatically moves to compensate for an event such as a cell shutting down.
Focusing on Self Optimisation for a while: as mentioned above one of the key things to try and prevent is call drop during a handover between two cells. One of the standards terms given for improving this is Mobility Robustness Optimisation (MRO). There are a whole range of things that can affect a handover, but one could be that the source cell just didn’t have enough downlink coverage in a particular region due to lack of power, whilst another could be that some of the handover parameters such as how long to wait before handing over after the signal in the source cell becomes much weaker than the target. The solutions could be different depending on the precise cause: one could lead to increasing the transmit power of certain channels on the source cell (or the targeted cell), the other could be tweaking the parameters in the source cell to handover earlier. In 3GPP certain parameters being used when the radio link fails are put into a Radio Link Failure message when the mobile device re-connects to the network, and sent back to the source cell.
The precise way that optimisation is decided isn’t specified, but there are a couple of points: if both cells are ‘greedy’ and don’t cooperate then they could both try and increase transmission power up to their maximum limits, solving nothing and just creating more interference for other cells nearby, and any “solution” could have a knock-on effect nearby. So, one takeout is that a single cell cannot alone completely optimise its own handover performance although it may be able to get some way, but in a dense deployment of different cells of different sizes and technologies, there can, and there needs to be, some higher level function making sure that one local approach or set of algorithms doesn't go off at a tangent and damage achieving overall network goals. The same need for an addtional level or an overall 'holistic' controller comes up again when you consider optimisation between different layers (small cell, macrocell) or different radio access technologies (2G, 3G, LTE, and possibly WiFi).
For this reason the model of SON deployment and control that the industry seems to be adopting is a hybrid model, where responsibility is devolved to the level where it can be dealt with most effectively.
Timeliness, Scalability and Cost
Effectiveness has to include timeliness as well as scalability and cost. For timeliness, this can range for a cell shutting down suddenly - where neighbours should start compensating by increasing coverage immediately - to the handover optimisation that I illustrated earlier, where many days could be needed to gather the necessary data to make a decision. Scalability is an issue that particularly affects the small cell space: if you have 1 Million small cells deployed then unplanned real-time communication with a single management node handling everything requires careful handling, but which can be alleviated by adding an extra layer to aggregate messages - the issue is more likely to affect already-deployed macro equipment rather than small cell network equipment which was designed from scratch with scalability in mind. A small macro 3G RNC might handle a few hundred cells and so expect to have to deal with accumulating radio link failure messages from, say up to 1000 cells neighbouring its coverage area. If each macro cell had 10 or 100 small cells in its area of coverage, then then the number of links to be maintained suddenly gets a lot bigger.
From the cost perspective small cells are, well, small(er), expected to scale, and be much more numerous than macrocells. Predictions have them being more numerous than macrocells worldwide in less than 5 years. Consequently there has to some focus on keeping their costs down and think carefully about the case for adding new functionality to the largest number of devices. There is a clearly a case for this when the device operates autonomously, as this can save backhaul signalling and limit the peak demand - the backhaul is an increasing consideration in both network deployment business and technical models. As noted above, things that have to happen nearly immediately should be dealt with as locally to the trigger problem as possible, and there is a case for doing more where gains can be shown.
The figure below illustrates a way of going about handling the issues, but, like devolved government, it is not the only way and many people will have views about it.
Figure 1: Illustrative multi-layer SON control architecture (click to enlarge)
One of the advantages of being a system provider rather than supplying a single element is that you have more choice in where to put the functionality and are better able to design it where the best engineering option. In the case shown, there is going always going to be some intelligence in a 3G HNB, at a minimum to carry out the initial self-configuration and detect when neighbouring cells undergo significant changes (like going offline or accidentally deploying clashing radio parameters). At the next level, if there is a dense deployment of small cells such as in an enterpris, or where an operator has decided to have major focus on small cell coverage, possibly because of the large costs of deploying macrocells, then some form of local cluster controller can be introduced as in region A - located either geographically close, or virtualised as part of a controller for the whole network. The cluster controller will aggregate messaging and talk to a higher layer control, as well as receive guidelines on how to optimise from it. In region B there isn't yet a dense small cell deployment, although there is potential inter-RAT optimisation. Consequently, apart from having a SON agent, would need to make its data available in the correct format to the macro-system or the main RAT / inter-RAT SON control. Clearly, as the deployment got denser, the case for a local controller becomes stronger.
In conclusion, SON is a key part of a mobile service provider's armoury in keeping the customer experience good whilst seeking to keep operational and capital expenditure under control. It has great prospects, but also many dimensions of deployment, and these will need to be addressed with careful system design. The innovations that small cells bring also create oppotunities for large scale self-organising networks and put the need for scalable, cost-effective system design into the limelight.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.