eBooks

These features can be managed by different functional entities (for example a SON server, or network OSS) within the network, and these functions can be sited according to the architectural choices the operator makes. This architectural choice will be influenced by what the operator is trying to achieve with SON, what use cases the operator is supporting, and what stage of network development the operator is at. How an operator implements SON is likely to be primarily influenced by the use case it is trying to support. A residential femtocell presents very different requirements compared to a multi-small cell enterprise deployment. Whereas the operator's priority for the femtocell is to ensure zero-touch installation and management, and to perform basic interference management, the enterprise deployment requires more sophisticated inter-cell interference and handoff management. A public access urban metrocell, deployed as part of a densification strategy within a city environment, requires highly targeted resource management, interference cancellation and management, load balancing and mobility robustness between 3G and LTE, as well as sensitivity to user profiles (mobility, velocity). As operators address these differing requirements, three main SON architectures have grown up. Centralized SON places the SON algorithms in a small number of network entities that could be central network or element management systems, or a dedicated SON server. While a centralized SON architecture gives the SON server control over a whole network, it can often require very high capacity servers to process the KPIs and element measurement information from the network. It can also introduce delays in the modification of network parameters as the central server manages information and statistics from different vendors. Distributed SON places the SON algorithms at the network elements (eNodeB's, HeNodeB's, NodeB's, HNodeB's) themselves. This provides functionality that is distributed across many locations, and so is able to react quickly to local conditions, without requiring resource or direction from a central entity – thereby reducing latency and load on central NMS or OAM servers. This provides a greater ability to scale, but as SON features are implemented directly by equipment manufacturers, less central control and overall visibility for the operator. To achieve co-ordination management, D-SON also either requires direct interfaces, often proprietary between nodes, or for interfaces to be managed through the core network. A Hybrid SON architecture incorporates elements of C-SON and D-SON – with part of the algorithms being executed in central entities, and others in small cell or other edge nodes. For example, operators can set network-wide configuration policies on the central server, with local SON algorithms taking care of more time-sensitive and location-dependent parameters. H-SON is therefore often regarded as the most efficient architecture for a use case such as an urban HetNet deployment – where operators have overall structural priorities as well as very dynamic local conditions. (Note, The Small Cell Forum, in its paper Urban SON Use Cases, adds a further definition – Localised SON. Localised SON is really a subset of Distributed SON, or a hyper version of it, in that it keeps all SON decisions local to the elements in which the algorithms are distributed. This sort of architecture would be best suited to an environment where decisions need to be implemented very quickly – say on local handovers or power levels – without being escalated up a SON hierarchy for reference with centralized parameters.) These differing architectures are of course often influenced by use case, but also by network equipment vendor strategy. At the macro level, some OEMs implement SON features right on to the eNodeBs themselves. This provides a simple implementation for operators in a single vendor environment, but it gives them little flexibility to manage multi-vendor, multi-layer HetNets. And it raises the possibility of SON becoming another item that could lead to vendor "lock-in". In response, we have seen some network operators develop their own SON capabilities. AT&T, for example, has a well-known centralized SON capability but has developed its own resource and planning tool to support its planned small cell deployments. T-Mobile is another carrier that has developed its own solution. In South Korea, SKT is one carrier that also developed its own SON capabilities as it embarked on a wide scale urban public access LTE small cell rollout. Vodafone Group has identified a centralized SON strategy as a goal, and has pooled its technical efforts to achieve its goal. This operator innovation shows that for small cell deployments, operators require a SON solution that can react more flexibly than macro-provided solutions. If front- end designers can cover SON use cases in the design stage, and small cell OEMs can harness the advantages of platforms that integrate key SON features, then mobile operators will have more freedom to deploy directly manageable SON solutions without SON ARCHITECTURE TAKING SON TO THE NETWORK A TMN eBOOK: BRINGING SON AND SMALL CELLS TOGETHER

• Cover