3GPP SON Concepts and Requirements

August can be a quiet month on the project front. Its especially true on collaborative projects when partners tend to take vacation so organising project meetings involving all participants can prove to be difficult indeed. I find it a good time to take stock, and reflect on how the year is progressing and take the opportunity for a "heads up" to see what else is going on.

I've been doing just that, and have been taking a look at the latest developments in 3GPP or specifically the Self-Organising Networks (SON) specifications. I started with the TS 32.500 specification for Release 10 "Concepts and Requirements". Even for Release 10, you get the feeling that the requirements are only scratching the surface of what really is required to make SON a reality. Let's take a look at the business level requirements and assess the impact of them.

REQ-SON-CON-01 SON solutions shall provide an easy transition from operator controlled (open loop) to autonomous (closed loop) operation, as the network operator gains more trust in the reliability of the SON
The very first requirement hits on probably most difficult requirement of all. Can SON ever be delivered reliably? Well if it cannot, we may as well not go any further. What would be the point of SON if it wasn't reliable. As far as network management practices go, where network configuration was traditionally carefully planned and pushed out into the network in a controlled manner, the idea that a SON function can identify the changes and activate them automatically is a huge paradigm shift. The likelyhood is that introducing SON will be in the form of baby steps, and this requirement provides the training wheels.

REQ-SON-CON-02 The SON Architecture and implementation should support network sharing between network operators. The impact of individual shared network topographies on proposed SON solutions shall be decided on a case-by-case basis.

Network sharing is one method of reducing operating costs, so it comes as no surprise to see this here. How is it going to work though? It will require a bit of thought where traditionally the network operator planning personnel determined the network configuration to be deployed.

REQ-SON-CON-05 For operator controlled (open loop) SON function, the implementation of any update proposed by the SON function shall take effect only after a response by the Operator.

This is related to the first requirement providing the operator with the final say on whether the proposed configuration change from the SON application should be applied.

REQ-SON-CON-06 For closed loop SON function, the implementation of any update proposed by the SON function shall take effect without the need for response by the Operator

This goes without saying. It truely is SON, a simple and straightforward requirement with significant implications. What if the update proposed is incorrect and causes network performance degradation or worse, a network outage?

REQ-SON-CON-07 An NE can operate with SON function or without SON function and can easily be transferred between these two modes. The ability to suspend/ resume/ enable/ disable the SON function shall be determined on a case by case basis.

In otherwords, if the SON functions are not performing as hoped, lets turn it off and go back to managing the Network Element as before.

REQ-SON-CON-8 An IRPManager shall be able to monitor the specific results of each particular SON function

Even if the SON function operates smoothly and is effective, there is still a need for it to be monitored, if for nothing else to re-assure the operator that automatic reconfiguration has taking place and how often.

These are the general requirements defined for SON thus far. Granted it is early days and I would anticipate some changes. As you can see, these requirements are mostly defensive in nature and aimed to facilitate the operator in letting go of control, somewhat similiar to a parent reluctantly letting a child making their own way in the world.