HK1234250B - Method and apparatus for coordination of self-optimization functions in a wireless network - Google Patents

Description

Method and apparatus for coordinating self-optimization functions in a wireless network

Technical Field

Embodiments relate to wireless communications. More specifically, embodiments relate to coordination between self-optimization functions of cells within a wireless communication system. Some embodiments relate to 3rd Generation Partnership Project, Technical Specification Group Services and System Aspects, Telecommunication Management, Self-Organizing Network (SON) Policy Network Resource Model (NRM) Integration Reference Point (IRP), Information Service (IS) 3GPP TS 32.522.

Background Art

In the context of wireless networks, self-optimization is the process of analyzing enhanced NodeB (eNodeB) measurement data and then tuning the eNodeB's radio and transmission parameters to achieve optimal network performance, coverage, and capacity. A self-optimizing network (SON) can implement various SON functions, including, for example, load balancing, handover optimization (HO), coverage and capacity optimization (CCO), cell outage compensation (COC), and energy saving management (ESM). These optimization functions modify the coverage and capacity of a cell by configuring eNodeB parameters. Example parameters include transmit power, antenna tilt, and azimuth parameters for downlink transmissions.

In current 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) systems, SON functions can operate independently to change these and other parameters for one or more eNodeBs. However, current 3GPP LTE-Advanced systems do not support coordination between SON functions. Consequently, two or more SON functions can operate simultaneously to change the same configuration parameter for the same eNodeB. This can cause conflicts and, consequently, instability in the affected eNodeBs.

Thus, there exists a general need for systems and methods for coordinating SON function operations within a wireless network.

Summary of the Invention

A first aspect of the present disclosure is a network management apparatus comprising: an interface for communicating with a plurality of enhanced Node Bs (eNodeBs), the interface being configured to receive a request to change the coverage or capacity of the enhanced Node Bs (eNodeBs); and one or more processors being configured to determine whether to grant or deny the request based on a coordination policy and a SON coordination state, the SON coordination state being a state of a SON function.

A second aspect of the present disclosure is an enhanced Node B (eNodeB), comprising: an interface for communicating with a network management device, the interface configured to: transmit a request to change a coverage or capacity state, and receive a permission notification, the permission notification indicating whether the request to change the coverage or capacity state has been granted or denied; and one or more processors configured to: store a SON coordination state in an associated memory, and change the coverage or capacity state based on the permission notification.

A third aspect of the present disclosure is a method for coordinating coverage and capacity changes in a self-optimizing network (SON), the method comprising: receiving a request to change the coverage or capacity of an enhanced Node B (eNodeB); and determining whether to grant or deny the request based on a coordination policy and a SON coordination state, the SON coordination state being a state of a SON function.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 illustrates an example portion of a wireless communication network in which example embodiments are implemented.

FIG2 illustrates an example block diagram showing a system architecture for implementing coordination of self-optimizing network functions according to some embodiments.

3 illustrates an example block diagram showing details of an eNodeB included in the wireless communication network of FIG. 1 or 2 according to some embodiments.

4 illustrates an example block diagram showing details of a network manager (NM) included in the system architecture of FIG. 2 , according to some example embodiments.

FIG5 illustrates a signal flow diagram describing the signals and messages used to implement coordination of self-optimizing network functions.

DETAILED DESCRIPTION

The following description is provided to enable one skilled in the art to create and use computer system configurations, and related methods and articles of manufacture, for coordinating self-optimizing network (SON) functions performed by a domain manager (DM) or an enhanced NodeB (eNodeB) within a wireless communication network. Coordination policies are implemented to determine the circumstances under which the eNodeB can implement different SON functions. In at least one example embodiment, these coordination policies take into account the current state of the eNodeB. These coordination policies may also be based on the identity of a desired SON function to which the eNodeB can change, or other inputs related to the desired SON function.

Various modifications to the embodiments will be apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the scope of the invention. In addition, in the following description, many details are set forth for illustrative purposes. However, those skilled in the art will appreciate that embodiments of the present invention may be implemented without using these specific details. In other cases, well-known structures and processes are not shown in block diagram form to avoid obscuring the description of the embodiments of the invention with unnecessary details. Thus, the present disclosure is not intended to be limited to the embodiments shown, but rather to be consistent with the broadest scope consistent with the principles and features disclosed herein.

FIG1 illustrates an example portion of a wireless communication network 100 in which example embodiments may be implemented. In one embodiment, wireless communication network 100 comprises an Evolved Universal Terrestrial Radio Access Network (EUTRAN) utilizing the Third Generation Partnership Project (3GPP) Long Term Evolution (LTE) standard. In one embodiment, wireless communication network 100 includes a first eNodeB 101, a second eNodeB 102, a third eNodeB 103, and a fourth eNodeB 104 (also referred to as first base station 101, second base station 102, and third base station 103). First eNodeB 101 serves a geographic area, Cell 1. Similarly, second eNodeB 102 serves geographic area Cell 2, third eNodeB 103 serves geographic area Cell 3, and fourth eNodeB 104 serves geographic area Cell 4.

It is understood that the wireless communication network 100 may include more than 4 eNodeBs or less than 4 eNodeBs. It is also understood that each eNodeB may have multiple neighboring eNodeBs. As an example, the eNodeB 103 may have 6 or more neighboring eNodeBs.

Capacity and Coverage Optimization (CCO), Cell Outage Compensation (COC), and Energy Saving Management (ESM) are SON functions that can change the coverage or capacity of one or more cells in a wireless network. The CCO SON function seeks to maximize the coverage of an eNodeB while optimizing capacity and minimizing inter-cell interference. The COC SON function configures an eNodeB to compensate for another eNodeB experiencing an outage. The ESM function extends the coverage of a neighboring eNodeB to cover an eNodeB configured to enter energy-saving mode. If one of these SON functions changes an eNodeB while another SON function changes the same eNodeB, a conflict may occur.

As an illustrative example, referring to Figure 1, if cell 1 experiences a service outage, the COC SON function will attempt to compensate for the outage in cell 1 by reconfiguring parameters of potential candidate cells. For example, the COC may attempt to reconfigure the transmit power, antenna tilt, and antenna orientation of eNodeBs 102 and 103 serving cells 2 and 3 so that eNodeBs 102 and 103 can compensate for the eNodeB serving cell 1. However, at the same time, the ESM SON function may operate on cell 2 to compensate for the coverage of neighboring cell 4 as it enters an energy-saving state. Thus, in this example, the COC SON function and the ESM SON function may attempt to operate simultaneously on cell 2.

In this illustrative example, from the time that cell 1 outage is detected until cell 1 has been compensated by cells 2 and 3, unless there is coordination between the SON functions, the COC SON function and the ESM SON function may each attempt to configure eNodeB 102 with different settings for transmit power, antenna tilt, and antenna orientation. For example, the COC may attempt to tilt the eNodeB 102 antenna downward while the ESM attempts to tilt the eNodeB 102 antenna upward, thereby causing instability in the eNodeB 102.

In an example embodiment, a network management device or network manager (NM) may incorporate a SON coordination mechanism to coordinate coverage and capacity changes of eNodeBs in network 100 and thereby provide conflict prevention or conflict resolution between SON functions. The network management device may include an interface that receives requests to change the coverage and capacity of eNodeBs in network 100. This interface may also transmit queries to the eNodeBs to obtain the SON coordination status of the eNodeBs. The network management device may also include one or more processors. These processors may execute an algorithm that determines whether to grant or deny the request based on a coordination policy and the SON coordination status. Based on the coordination policy and the SON coordination status, the network management device coordinates the coverage and capacity changes of the eNodeBs in network 100 according to the coverage and capacity requirements of the coordination policy, while minimizing inter-cell interference and energy usage according to the coordination policy.

According to an example embodiment, a NM supporting SON coordination reads and writes the value of the SON coordination state attribute, sonCoordinationState, of the eNodeBs in the network 100. Table 1 shows the values of this attribute:

Table 1: Values of the sonCoordinationState attribute

Figure 2 illustrates the architecture of a system 200 for providing SON coordination functionality, according to at least one example embodiment. As shown in Figure 2 , a standard interface, Itf-N, is located between a network manager (NM) and a domain manager (DM). Itf-N can be used to transmit performance measurement data generated in the network and to transmit performance alerts or notifications.

Network elements such as eNodeBs 201, 202, and 203 provide data to support network performance evaluation. This data may include quality of service (QoS) measurements, network configuration verification, or other parameters. Element managers (EMs) 206, 207 manage the generation of measurement data by, for example, managing the performance measurement collection process and generating performance measurements.

EM 206 may reside in DM. Example tasks of DM include configuring eNodeBs, fault management, and performance monitoring. Performance monitoring may include tasks such as receiving performance data from eNodeBs 203, 204, and 205.

The eNode Bs 203 and 204 may communicate with the NM 201 through the DM 202. Alternatively, the eNodeB 203 may implement its own EM 207 to communicate directly with the NM 201. In some embodiments, the NM and these SON functions may operate according to 3GPP TS 32.522, but this is not a requirement.

FIG3 illustrates an example block diagram showing details of an eNodeB 301 that may be suitable for use as any of eNodeBs 101, 102, 103, 104, 203, 204, and 205 according to an example embodiment, although other configurations may also be suitable. The eNodeB 301 may include a processor 300, a memory 302, a transceiver 304, instructions 306, and other components (not shown). The eNodeBs 101, 102, 103, 104, 203, 204, and 205 may be similar to each other in terms of hardware, firmware, software, configuration, and/or operating parameters.

The processor 300 includes one or more central processing units (CPUs), graphics processing units (GPUs), or both. The processor 300 provides processing and control functionality for the eNodeB. The memory 302 includes one or more transient and static memory units configured to store instructions and data for the eNodeB. The transceiver 304 includes one or more transceivers that include multiple-input and multiple-output (MIMO) antennas to support MIMO communications. The transceiver 304 receives uplink transmissions and transmits downlink transmissions, particularly to user equipment (UE). In some embodiments, the transceiver 304 transmits a request to change the coverage and capacity status of the eNodeB. In some embodiments, in response to the request, the transceiver receives a grant notification indicating whether the request to change the coverage status has been granted or denied. In some embodiments, based on whether the grant has been granted, the processor 300 stores the SON coordination state in the associated memory 302 and changes the coverage and capacity status of the eNodeB.

Instructions 306 include one or more sets of instructions or software executed on a computing device (or machine) to cause such computing device (or machine) to perform any of the methods discussed herein. Instructions 306 (also referred to as computer-executable instructions or machine-executable instructions) may reside completely or at least partially within processor 300 and/or memory 302 during execution by the eNodeB. Processor 300 and memory 302 also include machine-readable media.

FIG4 illustrates a block diagram of an example machine 400 on which any one or more of the operations performed by a network manager (NM) discussed herein may be performed. In alternative embodiments, machine 400 may operate as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, machine 400 may operate in the capacity of a server machine, a client machine, or both in a server-client network environment. In one example, machine 400 may function as a peer machine in a peer-to-peer (P2P) (or other distributed) network environment.

The machine (e.g., a computer system) 400 may include a hardware processor 402 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), a main memory 404, and a static memory 406, some or all of which may communicate with each other via an interconnection link (e.g., a bus) 408. The machine 400 may also include a display unit 410, an alphanumeric input device 412 (e.g., a keyboard), and a user interface (UI) navigation device 414 (e.g., a mouse). In one example, the display unit 410, the input device 412, and the UI navigation device 414 may be a touch screen display. The machine 400 may also include a storage device (e.g., a drive unit) 416, a signal generating device 418 (e.g., a speaker), a network interface device 420, and one or more sensors 421 (e.g., a global positioning system (GPS) sensor, a compass, an accelerometer, or other sensors). The machine 400 may include an output controller 428, such as a serial (e.g., Universal Serial Bus (USB), parallel, or other wired or wireless (e.g., infrared (IR)) connection) to communicate with or control one or more peripheral devices (e.g., printer, card reader, etc.).

The storage device 416 may include a machine-readable medium 422 having stored thereon one or more data structures or one or more sets of instructions 424 (e.g., software) implemented or utilized by any one or more of the techniques or functionality described herein. The instructions 424 may also reside, completely or at least partially, within the main memory 404, within the static storage 406, or within the hardware processor 402 during execution by the machine 400. In one example, one or any combination of the hardware processor 402, the main memory 404, the static storage 406, or the storage device 416 may constitute a machine-readable medium.

Although machine-readable medium 422 is illustrated as a single medium, the term “machine-readable medium” may encompass a single medium or multiple media (eg, a centralized or distributed database and/or associated caches and servers) configured to store one or more instructions 424 .

Instructions 424 may also be transmitted or received over a communication network 426 using a transmission medium via network interface device 420 using any of a number of transmission protocols (e.g., Frame Relay, Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP), etc.). The term "transmission medium" will be taken to include any intangible medium capable of storing, encoding, or carrying instructions for execution by machine 400, and includes digital or analog communication signals or other intangible media that facilitate such software communication. Instructions 424 may implement an algorithm for a SON coordination mechanism according to the example embodiments described below.

2 , the SON coordination function for implementing SON coordination according to an example embodiment resides above the Itf-N and is implemented on the processor 402 of the NM 201 through instructions 424. However, it will be understood that the SON coordination function may reside below the Itf-N. For example, the SON coordination function may reside in the DM 202 to coordinate the eNodeBs 203 and 204 or other eNodeBs (not shown) managed by the DM 202.

FIG5 illustrates a signal flow diagram depicting signals passing between the EM and NM 201 in order to implement the SON coordination function to prevent conflicts between the ESM, COC, and CCO SON functions according to an example embodiment.

In signal 1, the SON coordination entity receives a request to change the coverage and capacity of an eNodeB of the network. In an example embodiment, the SON coordination entity is NM 201. The request may be received from DM 202. Alternatively, the request may be received directly from the eNodeB if the eNodeB contains an embedded EM.

In message 2, the NM queries the DM or eNodeB to obtain the SON coordination status. The SON coordination status indicates the cell's behavior in supporting CCO, COC, and ESM functions and can contain one of the following values: EsmCompensating, EsmEnergySaving, CocCompensating, CocOutage, CcoUpdating, and None.

The NM 201 then determines whether to grant or deny the request based on the SON coordination policy and the SON coordination status. The SON coordination policy is described below. In an example embodiment, the SON coordination policy is based on one or more inputs from the SON function, a priority level assigned to the SON function by the network operator, and the network operator policy.

If the eNodeB is in the EsmCompensating SON coordination state and NM 201 is notified that a cell served by the eNodeB has experienced an outage, the SON coordination policy, according to an example embodiment, provides that NM 201 notifies the ESM function to find another cell to compensate for the energy-saving cell. If the ESM function cannot find another cell, the ESM function deactivates energy saving on the cell compensated by the eNodeB. NM 201 then changes the eNodeB's SON coordination state to CocOutage.

If NM 201 receives a COC request requesting the eNodeB to compensate for an outage in a neighboring cell while the eNodeB is in the EsmCompensating SON coordination state, the SON coordination policy, according to an example embodiment, provides that NM 201 prioritizes the COC and ESM SON functions based on network operator policy. If the ESM SON function has a higher priority, the COC request is rejected. If the COC SON function has a higher priority, NM 201 notifies the ESM SON function to find another neighboring cell to compensate for the energy-saving cell. If the ESM SON function cannot find another cell to compensate for the energy-saving cell, NM 201 notifies the ESM SON function to deactivate energy saving on the cell compensated by the eNodeB. NM 201 then accepts the COC request and changes the eNodeB's SON coordination state to None.

If the eNodeB is in the EsmEnergySaving state and NM 201 receives a COC request to compensate for an outage in a neighboring cell, the SON coordination policy, according to an example embodiment, specifies that NM 201 should notify the ESM SON function to request the eNodeB to exit energy conservation. If the ESM SON function is unable to request the eNodeB to exit energy conservation, NM 201 rejects the COC request. If the ESM SON function is able to request the eNodeB to exit energy conservation, NM 201 accepts the COC request and changes the SON coordination state to None.

If the eNodeB is in the CocCompensating state and the NM 201 is notified that the eNodeB is experiencing an outage condition, the SON coordination policy provides that the NM 201 notifies the COC SON function to find one or more neighboring eNodeBs to compensate the requesting eNodeB and cells previously compensated by the requesting eNodeB. The NM 201 further changes the SON coordination state of the requesting eNodeB to CocOutage.

If the eNodeB is in the CocOutage state, the NM 201 rejects all requests. If the eNodeB is in the CcoUpdating state, the NM 201 postpones all ESM and COC requests until the SON coordination state changes to None. If the eNodeB is in the None state, the NM 201 accepts any request from the CCO, COC, or ESM SON function.

If the eNodeB is in EsmCompensating, EsmEnergySaving or CocCompensating state and NM 201 receives a CCO request to change the coverage and capacity of the eNodeB, NM 201 determines whether to accept the request based on the network operator policy. If the CCO request is to be accepted, NM 201 changes the SON coordination state to CcoUpdating.

Furthermore, the NM 201 does not allow any request that is not specified in the SON coordination policy, or rejects any request that is not specified in the SON coordination policy.

NM 201 may use one or more pieces of additional data to help prevent conflicts between SON functions. One or more parameters may be inputs from one or more of the ESM SON function, CCO SON function, or COC SON function. These inputs may include identification information for the SON function requesting permission to modify eNodeB configuration parameters. This identity may include information about the vendor, release number, version, and other aspects of the SON function. These inputs may also include the duration for which any newly updated eNodeB configuration parameters should remain unchanged by other or identical SON functions. Furthermore, these inputs may include SON objectives that justify the configuration change. For example, a key performance indicator (KPI) may be reported by an eNodeB that has recently undergone a configuration parameter change. This KPI is compared to the SON objective value to verify whether the previous change has achieved an improvement in the KPI. If this evaluation indicates that sufficient improvement has not been achieved, this may indicate that further optimization and configuration changes should be performed, at least for the reporting eNodeB. These inputs may also include any information about the potential impact of the parameter change on other objects in the network, i.e., the impact area of the parameter change.

To prevent conflicts, NM 201 may rely on additional information such as the possible impact of parameter changes on key performance indicators (KPIs).NM 201 may also rely on information about the current state of the eNodeB, the state of certain managed objects in the network, the priorities of SON functions and the SON coordination policy.

Based on the SON coordination strategy described above, NM 201 returns either message 3 (rejecting the request) or message 4 (granting the request). If the decision is to reject the request, no further processing occurs, and no configuration change is made. On the other hand, if the decision is to grant the request, the eNodeB or DM changes the coverage and capacity and, in message 5, notifies NM 201 that the coverage and capacity changes have been completed. The eNodeB or DM may also transmit information regarding the success or failure of the parameter change, or the parameter values before and after the parameter change.

After the SON function has been completed on the eNodeB, the SON coordination state should change to one of EsmCompensating, EsmEnergySaving, or CocCompensating. For example, after the ESM activates a cell to perform energy saving compensation, the SON coordination state of such a cell should change to EsmCompensating. In message 6, the NM 201 notifies the eNodeB or DMeNodeB that the SON coordination state should change, and the DM or eNodeB stores the new SON coordination state in memory 302.

In other example embodiments, in addition to or in lieu of the SON function denying or granting the request, the NM may configure a specific parameter of at least one eNodeB with a specific value. In an example embodiment, the NM may prevent one or more SON functions from changing the parameter within a specific time after the parameter has already been changed by another SON function. The NM may also notify the SON function of a state change that may affect the calculation of a performance indicator.

In other example embodiments, NM 201 detects conflicts between SON functions and proactively resolves them. NM 201 may implement this conflict resolution in parallel with, and in addition to, the conflict prevention process described above. To detect conflicts, the SON coordination function implemented on NM 201 analyzes data such as, for example, key performance indicators (KPIs), measurements indicating whether SON functions are meeting their objectives, and unacceptable oscillations or changes in eNodeB configuration parameters over time. Anomalies in any of these measurements or data may indicate that SON functions are operating in conflict with each other.

To resolve the detected conflict, the NM 201 may enable, disable or suspend the SON function. The SON configuration function may modify the configuration of certain SON functions, or the SON configuration function may modify the configuration parameters of the eNodeB.

It will be appreciated that, for purposes of clarity, the above description describes some embodiments with reference to different functional units or processors. However, it will be appreciated that any suitable distribution of functionality between different functional units, processors, or domains may be used without departing from embodiments of the present invention. For example, functionality illustrated as being performed by separate processors or controllers may be performed by the same processor or controller. Therefore, references to specific functional units are to be viewed merely as references to suitable means for providing the described functionality, and not as an indication of a strict logical or physical structure or organization.

Although the present invention has been described in conjunction with certain embodiments, it is not intended to be limited to the specific forms set forth herein. Those skilled in the art will recognize that the various features of the described embodiments may be combined in accordance with the present invention. Furthermore, it will be recognized that various modifications and variations may be made by those skilled in the art without departing from the spirit and scope of the present invention.

This Abstract of the Disclosure is provided to quickly ascertain the nature of the technical disclosure. It is presented with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Furthermore, in the foregoing Detailed Description, it can be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, the subject matter of the invention lies in less than all features of a single disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment.

Claims (30)

1. A network manager NM for a cellular system, comprising: The self-optimizing network SON coordination function prevents conflicts caused by one SON function operating on the base station BS simultaneously with another SON function, and provides a solution to the conflict. The SON coordination function is used to coordinate SON functions, which include at least an Energy Management (ESM) function, a Cell Outage Compensation (COC) function, or a Coverage and Capacity Optimization (CCO) function. The SON coordination function is configured to prevent the conflict by preventing one or more SON functions from changing the same parameter within a predetermined time period after another SON function has changed a parameter. The SON coordination function is also configured to prevent the conflict by relying on information about the potential impact of changes in the indicator parameter on key performance indicators (KPIs). 2. The NM as described in claim 1, wherein the SON coordination function resides above Itf-N, wherein Itf-N is the interface located between the NM and the Domain Manager DM. 3. The NM as described in claim 1, wherein the SON coordination function resides below Itf-N, wherein Itf-N is the interface located between the NM and the Domain Manager DM. 4. The NM as claimed in claim 1, wherein the SON coordination function is configured to detect the conflict and resolve the conflict based on the detection. 5. The NM as claimed in claim 1, wherein the SON coordination function is configured to detect the conflict by analyzing data, wherein the data includes at least one of the key performance indicator (KPI) measurements. 6. The NM as claimed in claim 1, wherein the SON coordination function is configured to resolve the conflict by enabling, disabling, or suspending the SON function. 7. A method for coordinating between two or more self-optimizing network SON functions, comprising: The SON coordination function is implemented through the Network Manager (NM) of the cellular system. The SON coordination function prevents conflicts caused by one SON function operating on the base station (BS) at the same time as another SON function, and provides a solution to the conflict. The SON coordination function is used to coordinate SON functions, which include at least Energy Management (ESM) function, Cell Outage Compensation (COC) function, or Coverage and Capacity Optimization (CCO) function. The method further includes: The conflict is prevented by preventing one or more SON functions from changing the same parameter within a predetermined time period after another SON function has changed a parameter. Preventing includes: information that depends on changes in indicator parameters that may affect key performance indicators (KPIs). 8. The method of claim 7, wherein the SON coordination function resides above Itf-N, wherein Itf-N is an interface located between the NM and the Domain Manager DM. 9. The method of claim 7, wherein the SON coordination function resides below Itf-N, wherein Itf-N is an interface located between the NM and the Domain Manager DM. 10. The method of claim 7, comprising: The conflict is detected by analyzing data, wherein the data includes at least one of the key performance indicators (KPIs). 11. The method of claim 10, comprising: The conflict is resolved based on the detection of the conflict. 12. The method of claim 7, comprising: The conflict can be resolved by enabling, disabling, or suspending the SON function. 13. A system for wireless communication, comprising: BS in multiple enhanced base stations; In this system, the multiple BSs are coordinated through a self-optimizing network SON coordination function. This SON coordination function is configured to prevent conflicts caused by simultaneous operations of one SON function on each of the multiple BSs by another SON function, and to provide solutions to such conflicts. The SON coordination function coordinates SON functions, which include at least Energy Management (ESM), Cell Outage Compensation (COC), or Coverage and Capacity Optimization (CCO) functions. The SON coordination state is the state of the SON functions. Furthermore, the SON coordination function is configured to prevent conflicts by preventing one or more SON functions from changing the same parameter within a predetermined time period after another SON function has changed a certain parameter. The SON coordination function is configured to prevent the conflict by relying on information about the potential impact of changes in indicator parameters on key performance indicators (KPIs). 14. The system of claim 13, wherein the SON coordination function resides above Itf-N, wherein Itf-N is an interface located between the Network Manager and the Domain Manager (DM). 15. The system of claim 13, wherein the SON coordination function resides below Itf-N, wherein Itf-N is an interface located between the Network Manager and the Domain Manager (DM). 16. The system of claim 13, wherein the SON coordination function detects the conflict and resolves the conflict based on the detection. 17. The system of claim 13, wherein the SON coordination function is used to... Analyze data to detect conflicts, wherein the data includes at least one of the key performance indicators (KPIs). 18. The system of claim 13, wherein the SON coordination function is configured to resolve the conflict by enabling, disabling, or suspending the SON function. 19. A machine for communication, comprising: a non-transitory computer-readable medium containing program instructions for a self-optimizing network SON coordination function, the instructions, when executed by a network manager NM, causing: To prevent conflicts caused by one SON function operating on a base station (BS) simultaneously with another SON function, and to provide solutions to such conflicts; The SON coordination function is used to coordinate SON functions, which include at least Energy Management (ESM) function, Cell Outage Compensation (COC) function, or Coverage and Capacity Optimization (CCO) function. When the instruction is executed by the NM, it causes: This prevents one or more SON functions from changing the same parameter within a predetermined time period after another SON function has changed a parameter, by relying on information about the potential impact of parameter changes on key performance indicators (KPIs). 20. The machine of claim 19, wherein the SON coordination function resides above Itf-N, wherein Itf-N is an interface located between the NM and the domain manager DM. 21. The machine of claim 19, wherein the SON coordination function resides below Itf-N, wherein Itf-N is an interface located between the NM and the domain manager DM. 22. The machine of claim 19, wherein, when the instruction is executed by the NM, it causes: Detect conflicts and resolve them based on the detection. 23. The machine of claim 22, wherein, when the instruction is executed by the NM, it causes: The conflict is detected by analyzing data, wherein the data includes at least one of the key performance indicators (KPIs). 24. The machine of claim 19, wherein, when the instruction is executed by the NM, it causes: The conflict can be resolved by enabling, disabling, or suspending the SON function. 25. A base station (BS) configured to operate according to a self-optimizing network coordination function (SON), wherein the SON coordination function prevents conflicts caused by one SON function simultaneously operating on one of the plurality of BSs by another SON function, and provides a solution to the conflicts; and The SON coordination function is used to coordinate SON functions, which include at least Energy Management (ESM) function, Cell Outage Compensation (COC) function, or Coverage and Capacity Optimization (CCO) function. The SON coordination function is configured to prevent the conflict by preventing one or more SON functions from changing the same parameter within a predetermined time period after another SON function has changed a parameter. The SON coordination function is configured to prevent the conflict by relying on information about the potential impact of indicator parameter changes on Key Performance Indicators (KPIs). 26. The BS as claimed in claim 25, wherein the SON coordination function resides above Itf-N, wherein Itf-N is an interface located between the Network Manager NM and the Domain Manager DM. 27. The BS as claimed in claim 25, wherein the SON coordination function resides below Itf-N, wherein Itf-N is an interface located between the Network Manager (NM) and the Domain Manager (DM). 28. The BS of claim 25, wherein the SON coordination function is configured to detect the conflict and resolve the conflict based on the detection. 29. The BS of claim 25, wherein the SON coordination function is configured to detect the conflict by analyzing data, wherein the data includes at least one of key performance indicator (KPI) measurements. 30. The BS of claim 25, wherein the SON coordination function is configured to resolve the conflict by enabling, disabling, or suspending the SON function.