Introduction
As every mobile network, LTE (Long Term Evolution) system also needs to be managed. Since LTE is an evolvement of UMTS, the management should also evolve from UMTS. There is a trend to simplify the management by auto-configuration and auto-optimization. However, the complexity of LTE system also place new demands on the Operations and Maintenances of the network. Self-Organizing Networks (SON) is seen as one of the promising area for an operator to save operational expenditures. SON is therefore currently discussed in 3GPP standardisation. This paper provides some background on SON principles, introduces different architectures that are considered and describes some exemplary procedures.
Main Drivers for SON
The main drivers for SON are [1]:
1. The number and structure of network parameters have become large and complex;
2. Quick evolution of wireless networks has led to parallel operation of 2G, 3G, EPC infrastructures;
3. The rapidly expanding number of Base Stations (especially Home eNB) needs to be configured and managed with the least possible human interaction.
SON aims to configure and optimize the network automatically, so that the interaction of human can be reduced and the capacity of the network can be increased.
Main Functionality of SON
The main functionality of SON includes: self-configuration, self-optimization and self-healing. Figure 1 shows a basic framework for SON. Refer to [2] and [3].
• Self-configuration
Self-configuration process is defined as the process where newly deployed nodes (eNBs) are configured by automatic installation procedures to get the necessary basic configuration for system operation.
Self-configuration process works in preoperational state, which starts from when the eNB is powered up and has backbone connectivity until the RF transmitter is switched on.
As shown in Figure 1, self-configuration includes two stages: basic setup and initial radio configuration. The whole procedure is shown in Figure 2:
1. An IP address is allocated to the new eNB and the information of the Self-configuration Subsystem of OAM (Operation and Management) is given to the eNB.
2. A GW is configured for the new eNB so that the eNB can exchange IP packets with other internet nodes.
3. The new eNB provides its information, including type, hardware and etc., to the Self-configuration Subsystem for
authentication. Necessary software and configuration data are downloaded from the Self-configuration Subsystem.
4. The new eNB is configured based on the transport and radio configuration data.
1/15
5. The new eNB connects to the normal OAM subsystems for other management functions.
eNB Power on
6. S 1 and necessary X2 interfaces are established
Basic Setup
Configuration of IP addressAssociation with a GW
Authentication
Software and configuration data download
Figure 1: Framework of SON
Figure 2: Self-configuration Procedure
• Self-optimization
Self-optimization process is defined as the process where UE & eNB measurements and performance measurements are used to auto-tune the network.
This process works in operational state, which starts when the RF interface is switched on. The self-optimization process collects measurement information from UE and eNB and then with the help of external optimization tool, it auto-tune the configuration data to optimize the network. A
typical example is neighbour list optimization.
- Self-healing
Self-healing function aims at automatic detection and localization of most of the failures and applies self-healing mechanisms to solve several failure classes, such as reducing the output power in case of temperature failure or automatic fallback to previous software version. Refer to [4].
SON Architecture
A Self-configuration Subsystem will be created in OAM to be responsible for the self-configuration of eNB. For self-optimisation functions, they can be located in OAM or eNB or both of them. So according to the location of optimisation algorithms, SON can be divided into three classes: Centralised SON, Distributed SON and Hybrid SON.
- Centralized SON
In Centralized SON, optimisation algorithms are executed in the OAM System. In such solutions SON functionality resides in a small number of locations, at a high level in the architecture. Figure 3 shows an example of Centralized SON.
Figure 3: Centralized SON Example
In Centralized SON, all SON functions are located in OAM systems, so it is easy to deploy them. But since different vendors have their own OAM systems, there is low support for optimization cases among different vendors. And it also does not support those simple and quick optimization cases.
To implement Centralized SON, existing ItfN interface needs to be extended.
- Distributed SON
In Distributed SON, optimisation algorithms are executed in eNB. In such solutions SON functionality resides in many locations at a relatively low level in the architecture.
Figure 4 shows an example of Distributed SON.
Figure 4: Distributed SON Example
In Distributed SON, all SON functions are located in eNB, so it causes a lot of deployment work. And it is also difficult to support complex optimization schemes, which require the coordination of lots of eNBs. But in Distributed SON it is easy to support those cases, which only concern one or two eNBs and require quick optimization responses.
For Distributed SON, X2 interface needs to be extended.
- Hybrid SON
In Hybrid SON, part of the optimisation algorithms are executed in the OAM system, while others are executed in eNB.
Figure 5 shows an example of Hybrid SON.
Figure 5: Hybrid SON Example
In Hybrid SON, simple and quick optimization schemes are implemented in eNB and complex optimization schemes are implemented in OAM. So it is very flexible to support different kinds of optimization cases. And it also supports the optimization between different vendors through X2 interface. But on the other hand, it costs lots of deployment effort and interface extension work.
SON Use Cases
Up to April 20, 2008, there are already eight use cases approved on 3GPP meetings. Most of them are included in 3GPP TR36.902. The use cases are defined but solutions are still in discussion. Here the nine use cases will be described and possible solutions will be given.
1. Automatic Neighbor Relation (ANR)
In the context of LTE, it is necessary to set up the neighbour relation automatically as much as possible. Because the next generation mobile network is growing more and more complex, it will cause a lot of efforts to configure the neighbour relation relying on traditional configuration methods. ANR function aims at automatic setting of neighbour relation.
ANR function relies on UE to report the cells that it has detected but not in the neighbour list. According to the standards, the UE measures and reports the following types of cells:
- The serving cell.
- Listed cells, i.e. cells that are indicated by the E-UTRAN as part of the list of neighbouring cells (i.e. as measurement object).
- Detected cells, i.e. cells that are not indicated by the E-UTRAN but detected by the UE. However, E-UTRAN does indicate the carrier frequency.
So the detected cell can be a LTE cell within the same frequency or a LTE cell with a different frequency or even a cell belonging to another RAT. To detect inter-frequency cells or inter-RAT cells, eNB needs to instruct UE to do the measurement on that frequency.
- ANR Procedure
Figure 6 gives an example of intra-RAT ANR procedure.
1. UE does the measurement according to the measurement configuration set by EUTRAN. In this example, UE detects an EUTRAN cell with Physical ID 3.
2. UE sends the measurement report to the serving cell, using Physical ID to identify
different E-UTRAN cells. Here, UE includes the measurements of the cell with Physical ID 3.
3. eNB receives the report and instructs the UE to report Global Cell ID for the cell with Physical ID 3.
4. UE gets the Global Cell ID by reading the BCCH (Broadcast Control Channel) of the detected cell.
5. UE reports the Global Cell ID to the serving cell.
6. The serving eNB updates the neighbour cell list.
Figure 6: ANR Procedure
7.The serving eNB sends the updated neighbour list to OAM and gets the IP address of the new detected cell from OAM.
8.If required, the serving eNB will establish a new X2 interface with the target eNB.
• Possible ANR Architecture
The goal of ANR is to manage neighbour relation. Since OAM also has some restrictions on neighbour relation due to the requirements of operators, ANR also needs to consider the restrictions from OAM. So how to describe the neighbour relation based on the restrictions and how to manage the neighbour relation is a question of implementation.
Figure 7 gives an example of possible ANR
solutions. The details can refer to [5]. Here
the neighbour relation is described by
Neighbour Relation Table. The table composes of two parts. The left part is the list of Neighbour Relation according to the measurement report. The right part is the Neighbour Relation Attributes controlled by OAM. The attributes include: No Remove, No Handover and No X2. The left part will be updated according to measurement report and the right part will be updated according to OAM commands.
Within ANR, it is divided into three functions: Neighbour Removal Function, Neighbour Detection Function and Neighbour Relation Table Management Function. The first two functions decide whether to remove an existing Neighbour Relation or to add a new Neighbour Relation. The third one is responsible for updating the Neighbour Relation Table according to the input of the previous two functions and OAM.
obtained from official 3GPP meeting reports, is assumed to be reliable, but does not necessarily reflect the view of Nomor Research GmbH. This report is provided for informational purpose only. We do not accept any responsibility for the content of this newsletter. Nomor Research GmbH has no obligation to update, modify or amend or to otherwise notify the reader thereof in the event that any matter stated herein, or any opinion, projection, forecast or estimate set forth herein, changes or subsequently becomes inaccurate.
Tidak ada komentar:
Posting Komentar