4G Self-Organizing/Optimization Networks (SON)

Last week I found the 4G Self-Organizing/Optimization Networks (SON) group on LinkedIn. I was browsing through some of the discussions. Lots of interesting information posted here but one document in particular did catch my eye: The Benefits of SON in LTE from 3G Americas December 2009.

The idea of self-organising networks is great - in principle, but when you start asking what self-organising capability do you mean exactly then this is where it starts getting a bit more tricky. That's when you need to start getting into the business logic. In an ideal world, you might like it to mean fully automated with no manual intervention required, but when you are coming from an environment where most configuration processes involve some element, if not all, of manual intervention then you need to start defining exactly which processes can be automated.

That's where the above article gets interesting. It introduces the technology and market drivers for SON and the reasons for automation. Then it describes the key LTE Release 8 and Release 9 SON features as defined by 3GPP including how they can be supported and what the benefits are. These include:

• Base Station Self-Configuration
• Automatic Neighbour Relations
• Tracking Area Planning
• PCI Planning
• Load Balancing
• Mobility Robustness / Handover Optimisation
  

Wireless Network Optimisation

Following on from my last post on monitoring network performance, I attended a webinar called Wireless Network Optimisation from Alcatel-Lucent. It outlined some of the main concerns for a wireless network operator once a network is deployed, although this really boils down to just one thing: How can the bottom line be improved from the exiting network infrastructure? The answer is to optimise the network configuration. The webinar described a 4-step methodology for network optimisation:

1. End-to-End Audit. Collect data from the network such as network topology capture or performance monitoring.
2. Traffic Profile Analysis. Correlating current network capacity and projected traffic forecasting.
3. Recommendation. Develop a new planned configuration change.
4. Execution. Deploy and activate the new network configuration.

Alcatel-Lucent claim 10-63% in actual cash flow savings from optimisation project customers. I assume one objective of the webinar was to promote the Alcatel-Lucent managed service business which is not just for outsourcing management of Alcatel-Lucent supplied network equipment but also multi-vendor networks.

How big is this business for Alcatel-Lucent? According to their Q2 2010 Earnings Report, in the quarter Alcatel-Lucent had total revenues of €3.813 billion and a net loss of €183 million. The Services division had revenues of €883 million, making a profit €19 million in Q2. In the webinar, Alcatel-Lucent stated that have 60 optimisation tools built in-house and another 20 co-developed with Bell-Labs. They have 800+ design and optimisation experts to perform the work for their 250+ customers.

I think this gives a picture of the scale the business, but also an idea that once the network equipment is purchased and installed, the work if far from done. It should come as no surprise then that the network operators, the customers for the network equipment vendors such as Alcatel-Lucent, would desire that the vendors bring to markets network equipment that are capable of Self-Organising Networks (SON).

Monitoring IP Traffic

Monitoring the performance of the network is essential for an operator to verify that the network is performing as expected and also to identify new configuration changes in order to optimise the network configuration. For example, mobile network operators gather millions of raw statistics 24/7 365 days a year. The statistics are used to calculate Key Performance Indicators (KPIs) that quantify the network performance and to determine an improved planned configuration.

For IP networks, many tools are available for collecting performance data from the network which itself can be problematic. An enterprise may undertake to develop its own bespoke management system that integrates the tools it wants to use to monitor the performance of the network, or purchase off-the shelf tools from a vendor that may have already integrated some 3rd party tools. Integation of the tools is one thing, how you visual the information is another.

Last week, I become aware of one such tool, DangNetworks that uses SNMP and NetFlow that can, according to its website, "Monitor saturated links with SNMP, and find out who's causing it with NetFlow". Through using the two mechanisms together, an network operator can derive more value with what's going on in the network. Afterall what's of primary importance to an operator or enterprise manager is that the services or applications that are of most value to their business are performing as expected.

While the number of monitoring tools available continues to grow, it should be noted that collecting large volumes of network performance data can in itself degrade network performance so for the network operator, monitoring the network is a balancing act.

One aspect of the work that we are undertaking in EFIPSANS is that performance monitoring of the network can be set at a minimal level under normal operating conditions. Through monitoring of certain metrics, the performance level can be autonomously adjusted to gather more data to determine the reason for a performance degradation than can ultimately result in a self-configuration of the network. Normal performance monitoring can be restored once the criteria of normal operating conditions have been met.

We developed a tool for path monitoring, called a Path Management Element, for monitoring the performance of a path. For example, if the PathME detects that the latency for a particular flow has exceeded a predetermined threshold at an endpoint, the PathME can turn on additional monitoring along the path from the source to destination to identify where the latency is being incurred along the path.

The PathME integrates tools such as ping and traceroute to measure the performance of a path. We have also developed an experimental intrinsic monitoring protocol, that uses the Router Alert feature as defined by RFC 2711, that is able to collect performance metrics in-line at each node in a Hop-By-Hop manner as a packet traverses the network along a path. This is currently being integrated into the PathME, as is support for One Way Active Measurement Protocol (OWAMP), defined by RFC 4656, and IP Flow Information Export (IPFIX), defined by RFC 3917.

The PathME uses a common model that defines the managed objects, their attributes and relationships that are supported for a path. The user of the PathME can customise what performance information is required, and how often a measurement report should be generated. The PathME uses a mediation function to abstract the actual tools used to collect the data. The performance report is an XML file that complies with the XML schema that describes the common model.

The intrinisic monitoring aspect of this work will be presented at CNSM 2010 later this month at Niagara Falls, Canada.