JP2018507655A - Transport self-organizing network framework that understands the quality of experience - Google Patents

Abstract

Various networks can benefit from appropriate management techniques and systems. For example, long-term evolution networks and other wireless communication networks can benefit from a transport self-organizing network framework with a clear experience quality. The method includes monitoring a transport connection for at least one base station (eg, eNB) across the mobile backhaul. The method also includes detecting at least one deterioration or anomaly in the transport connection of at least one base station. The method further includes taking appropriate network management actions in response to the detected deterioration or anomaly. [Selection] Figure 4

Description

Cross-reference of related applications : This application is a “Context based correlated QoS measurement and by Peter Siragi and Saba Vulkan, filed Jan. 27, 2015 as PCT / EP2015 / 051563, which is incorporated herein by reference in its entirety. It is related to “QoE monitoring framework”. This application also claims the benefit and priority of US Provisional Patent Application No. 62 / 127,280, filed March 2, 2015, which is incorporated herein by reference in its entirety.

  Various networks can benefit from appropriate management techniques and systems. For example, long-term evolution networks and other wireless communication networks can benefit from a quality of experience aware transport self-organizing network framework.

  Mobile backhaul (MBH) is a transport that can provide connectivity between radio access network (RAN) elements such as evolved Node B (eNB), serving gateway (S-GW), mobility management entity (MME), etc. It is a network. For communication between such elements, all traffic, including user plane, control plane and management plane, is forwarded via one or more mobile backhauls. Typically, MBH is a complex and heterogeneous system that includes multiple technical layers from multiple sellers. Also, MBH typically covers a large area such as all states or countries. In addition, MBH typically can collect and aggregate traffic for all mobile networks.

  Capital expenditure (CAPEX) and operational expenditure (OPEX) represent a significant proportion of the total cost of ownership of MBH. In order to keep these costs low, careful planning by automation and reduction of operating costs are required. However, planning is typically an inaccurate process because resource needs are calculated based on traffic expectations and simple network models. Traffic prediction is not accurate because it is originally based on historical measurements at best. Traditionally, simplification is required to keep numerical complexity and processing requirements at a reasonably low level. During planning, the parameters and configuration of each network element can be calculated and their values are eventually downloaded to the network element. Due to inaccurate inputs and rough models, these parameters may not yield optimal system operation under traffic loads.

  A common feature of alternative / complementary transport solutions is that in each case a long-lasting transport tunnel is configured between the radio access nodes and a quality of service (QoS) scheme is applied at the packet level. It is. When the network is extended with a new eNB, the transport tunnel can be configured manually or via a provisioning tool that provides some level of automation. During the provisioning process, transport tunnels can be configured one on top of existing tunnels while computing routes in a locally optimal manner during network expansion.

  The results are sub-optimal at the system level, and all existing and new transport tunnels on the system are known in advance, taking into account the total network, total demand, allocation granularity vs. resource granularity. However, it is inefficient compared to the case where the configuration is calculated by applying a multi-layer optimization (MLO) technique. The gap increases with the size of the transport network and the amount of connections configured, opening up a significant CAPEX saving path.

  As noted above, resource allocation and transport QoS parameters are statically configured using recommended values or based on expected traffic. There is no globally suitable configuration and the demand for traffic can change dynamically. Due to the complexity of the system and the large number of parameters that must be configured in each case, reconfiguration and reparameterization are rarely performed. Efficient operation requires the transport parameters to self-adapt to continuously changing traffic. Cost and resource efficiency are required when a transport connection is provided by a third party via a transport service accessed through a user network interface (UNI) based on a pre-agreed service level agreement (SLA). This is a significant aspect of defining / calculating transport services.

  Since MBH plays a prominent role in end-to-end performance, the inefficient operation of MBH has a significant negative impact on the user experience. This negative user experience affects the revenue that the operator can realize. For example, bad service results in a high churn rate.

  Self-organizing networks (SONs) have been successfully deployed in the long-term evolution (LTE) of the third generation partnership project (3GPP). SONs can reduce the risk of manual errors, enable optimal resource utilization, and reduce energy usage. Standard SON functionality can address self-healing, self-configuration and self-optimization of the LTE radio network layer.

  Currently, mobile network planning, dimensioning and commissioning is done by extrapolating traffic measurements, configuring planning results with static parameters, monitoring network performance, and manually replanning and reconfiguring as needed Based on traffic expectations. The effectiveness of the configured parameters depends on the expected traffic mixing and planning accuracy. Static parameters also do not provide optimal operation over a sufficiently large traffic range.

  The eNB commissioning is based on LTE base transceiver station (BTS) auto-connection and LTE BTS auto-configuration. These feature ranges allow the eNB to connect to the network management server and download configuration file. The conventional assumption is that as a result of the planning process, the transport connection is configured before the eNB is commissioned. Thus, transport resources can be pre-assigned to eNBs and LTE BTS automatic connections, and LTE BTS automatic configuration does not serve to establish and configure whatever the eNB's transport connection is. These features do not work if the transport configuration is not obtained in advance or is not consistent. Thus, there is no true plug and play solution that eliminates the need for pre-configured transport services.

  The method according to the first embodiment includes monitoring a transport connection to at least one base station (eg, eNB) over a mobile backhaul. The method also includes detecting at least one deterioration or anomaly in the transport connection of at least one base station. The method further includes taking appropriate network management actions in response to the detected deterioration or anomaly.

  In a variation, the appropriate network management action determines whether the detected deterioration or anomaly is due to a local problem, and if the detected deterioration or anomaly is not due to a local problem, the network Includes triggering the manager.

  In a variation, the appropriate network management action determines whether the local problem can be resolved by reconfiguration when the detected deterioration or anomaly is determined to be due to a local problem, and the local problem. Includes reconfiguring when can be resolved by reconfiguration.

  In a variation, the appropriate network management action includes sending an alarm or report to the operational support system when it is determined that the detected deterioration or anomaly is due to a local problem that cannot be resolved by reconfiguration. .

  The method according to the second embodiment includes monitoring a mobile backhaul transport related trigger for at least one base station (eg, eNB). The method also includes detecting whether the deterioration or anomaly corresponding to the trigger persists. The method further includes taking appropriate network management actions in response to the detected deterioration or anomaly.

  In a variant, the method further comprises at least one of filtering, correlation or strictness level evaluation of the trigger.

  In a variation, when the deterioration or anomaly does not persist, the appropriate network management action includes entering a monitoring mode for the trigger.

  In a variation, when the deterioration or abnormality persists, the appropriate network management action includes determining whether the deterioration or abnormality can be resolved by the manager.

  In a variation, when the deterioration or anomaly cannot be resolved by the manager, appropriate network management actions include sending an alarm to the operational support system.

  In a variant, when the deterioration or anomaly can be resolved by the manager, appropriate network management actions include initiating reconfiguration.

  In a variant, the reconfiguration is subject to approval from the operator.

  According to the third and fourth embodiments, the apparatus comprises means for performing the methods according to the first and second embodiments, respectively, in their variants.

  According to the fifth and sixth embodiments, the apparatus comprises at least one processor, at least one memory and computer program code. At least one memory and computer program code are configured with at least one processor to cause the apparatus to perform at least the methods according to the first and second embodiments, respectively, in their variations.

  According to the seventh and eighth embodiments, the computer program product encodes instructions for performing the processes including the methods according to the first and second embodiments, respectively in their variations.

  According to the ninth and tenth embodiments, the non-transitory computer readable medium is a variation of each of the processes including the method according to the first and second embodiments when executed in hardware. Encode instructions to perform in.

  According to the tenth and eleventh embodiments, the system comprises at least one device according to the third or fifth embodiment, in communication with at least one device according to the fourth or sixth embodiment, respectively in their variants I have.

  For a proper understanding of the present invention, reference is made to the accompanying drawings.

2 illustrates a Tra-SON architecture according to some embodiments. 2 illustrates an enhanced Tra-SON architecture according to some embodiments. FIG. 6 illustrates an alternative example of an eNB-side TSA according to some embodiments. Fig. 4 illustrates the operation of a TSA according to some embodiments. FIG. 6 illustrates Tra-SON manager interworking according to some embodiments. FIG. FIG. 6 illustrates transport service optimization by a manager based on a TSA trigger, according to some embodiments. FIG. Fig. 4 illustrates a normative judgment by a manager, according to some embodiments. Fig. 4 illustrates another normative judgment by a manager, according to some embodiments. FIG. 6 shows an analysis of the deterioration that occurs with a poorly configured transport device, according to some embodiments. FIG. 6 illustrates optimization of system level resource allocation according to some embodiments. FIG. 1 illustrates a system according to some embodiments.

  Some embodiments, for example, reduce OPEX and increase resource usage efficiency to reduce CAPEX, and introduce a self-organizing network (SON) into the mobile backhaul (MBH) for other purposes. In particular, some embodiments provide an SON framework across MBH that can improve the level of automation, simplify the planning and configuration process, and maximize network efficiency through improved optimization and automation techniques.

  Some embodiments can be applied to LTE and 3G MBH. For similarity, the following description is directed to LTE. However, the same technology and features can also be applied directly to 3G sharing (3G and LTE) environments. Other changes and adjustments are allowed.

  Some embodiments address various issues. For example, some embodiments may handle high system complexity such as a large amount of network elements, complex topologies, multi-technology environments in MBH which means that the system is difficult to dimension, commission and manage. it can.

  Furthermore, some embodiments can handle complex and dynamic traffic mixing that cannot be handled efficiently with static parameter sets. For example, some embodiments can handle situations where there is no globally valid configuration that can be downloaded to each network element. Furthermore, some embodiments can handle situations where adaptability and context-specific parameterization is required.

  Some embodiments can handle inaccurate planning based on traffic prediction and simple network models. Even the most accurate traffic forecasts can quickly become outdated. In order to prevent planning (not only the configuration, but also physical capacity and resource allocation) from becoming obsolete, in some embodiments, overdimensioning can be provided.

  Some embodiments can also handle situations where there is no aligned transport and wireless QoS. The former is the aggregate center, while the latter is the bearer center. When the transport is congested, the end-to-end QoS target is not satisfied. Some embodiments can handle such a lack of QoS problem.

  In addition, some embodiments can address issues related to time wasting, failure-prone nodes, network commissioning, operations, and management. Similarly, some embodiments can handle the need for rapid delivery of mobile services, including coverage, connectivity, capacity, and access to applications.

  Some embodiments introduce solutions to MBH that can extend SON, including self-healing, self-configuration, and self-optimization. Thus, some embodiments enhance automation, simplify the planning and commissioning process, harmonize transport and wireless QoS, increase system efficiency, reduce total cost of ownership (TCO), and troubleshooting Can provide valuable insights, reduce energy consumption, and keep resource allocation at an optimal system level.

  The scope of the Transport SON (Tra-SON) framework includes increasing the level of automation within the mobile backhaul (MBH) by applying true plug and play, self-configuration and self-optimization mechanisms. Framework operation relies on advanced critical performance indicator (KPI) collection, anomaly and deterioration detection mechanisms, and network management solutions such as software defined networking (SDN). Tra-SON enables simple planning and minimal touch commissioning, as well as automatic and adaptive network operation.

  Some embodiments ensure harmony between efficient network resource utilization, radio and transport quality of service (QoS) architecture, and quality of experience (QoE) driven operations. Furthermore, some embodiments provide a significant reduction in CAPEX and OPEX. Also, some embodiments are versatile and can function in a merchant radio access (RA) environment and / or an MBH environment. Although the operation of some embodiments is described for Long Term Evolution (LTE), some embodiments can also be applied directly to 3G / High Speed Packet Access (HSPA) systems.

  FIG. 1 illustrates a Tra-SON architecture according to some embodiments. As shown in FIG. 1, in some embodiments, a Tra-SON agent can be deployed in an eNB and / or S-GW and / or SAE-GW. Further, a Tra-SON manager is arranged in the core network.

  The Tra-SON agent, whether in the eNB or SAE-GW, can perform QoS / QoE measurements and provide analysis, degradation detection and localization, and transport interface self-configuration and optimization. The Tra-SON agent is also configured to receive configuration information from the Tra-SON manager and provide triggers, alarms, measurements and other reports to the manager. The Tra-SON manager is configured for anomaly detection, prediction and analysis, and end-to-end optimization. The Tra-SON manager is configured to send triggers, alarms and reports to the OSS / NMS server and to send a transport service configuration request to the SDN controller.

  FIG. 2 illustrates an enhanced Tra-SON architecture according to some embodiments. For example, this architecture may include a Tra-SON agent deployed on the FlexiZone controller if there is a micro / picomesh in the system and / or a Tra-SON daemon is installed on top of the selected transport device. Can be extended with Tra-SON elements can have various roles and functions.

  For example, the eNB-side Tra-SON agent (TSA) is a software entity that is attached to or executed by the eNB as a site device. The role of the TSA is to maintain a harmonized QoS and consistent end-to-end transport configuration on the RA system. Furthermore, the eNB-side TSA helps in completing the eNB commissioning by creating and configuring the eNB transport connection. Similarly, the TSA can detect automatic adjacency (ANR) origin activation / configuration of the X2 interface and automatically establish a corresponding transport connection.

  To detect anomalies and deterioration on the transport layer or for other reasons, the TSA can monitor and profile all eNB traffic. When an anomaly / deterioration is detected, the TSA can first identify the reason for the deterioration and first isolate the radio and transport side problems. If the problem is deeply rooted in the transport network, the TSA can further localize the transport segment in question. Finally, if necessary (eg, to eliminate degradation or maintain QoS), the TSA can perform or trigger a reconfiguration and / or optimization. The reconfiguration can be targeted to the transport interface, the eNB's site router (if such a device exists), or an end-to-end transport service.

  The TSA is a measurement point that extracts real-time QoS and QoE KPI and intercepts / detects related events from / within the user, eNB control and management plane traffic. In addition, the TSA can monitor transport network control plane traffic / messages and detect such changes in network / link / path, etc. status. The anomaly detection and localization procedure used by the TSA can use the mechanism described in “Context based correlated QoS measurement and QoE monitoring framework” filed as PCT / EP2015 / 051563 on Jan. 27, 2015. . The TSAs can communicate with each other and with the Tra-SON manager through an in-band, such as header enrichment, or an out-of-band (eg, JSON / IPFIX) interface. Based on the implementation of network element resident agents, stand-alone boxes, etc., the TSA can use an internal interface for eNB-side transport configuration, or a legacy management interface, eg, SNMP, CLI, etc.

  The S-GW / SAE-GW side TSA is a software entity attached to or executed on the S-GW / SAE-GW. The S-GW / SAE-GW side TSA works as a counterpart part of the eNB side TSA having the same role as them. Through cooperative measurements with the eNB-side TSA, the S-GW / SAE-GW-side TSA can provide an efficient framework for anomaly / deterioration detection and localization.

  The FlexiZone controller side TSA has the same function as other TSAs, that is, is placed at the terminal end of the S1 interface serving the micromesh and plays a role in managing the transport connection corresponding thereto. Because of this similarity, this option is not described further here and is described as a valid use case.

  The Tra-SON manager is a software entity that is attached to an existing OSS tool in the form of a content pack or executed on a standalone node. Managers can use system-level optimization to help eliminate degradation related to end-to-end transport services or affecting multiple network elements, eg, congestion of transport links shared by multiple eNB traffic And can act as a constituent entity.

  In addition, the manager is responsible for trend analysis and forecasting based on relevant KPIs collected by the TSA. Such a role allows precautionary actions such as triggering a reconfiguration before incurring severe negative faults. The KPI collected by the TSA is upstream to the manager in raw or processing / aggregate format through an out-of-band interface such as JSON or IPFIX based on the user's case.

  The TSA can also trigger a manager when a detected anomaly cannot be resolved through the local configuration or when it is due to a problem with the transport service, for example, if there is no proper resource allocation. . The TSA also triggers the manager when the detected anomalies are clearly in the MBH and thus affect other eNBs.

  The manager collects those triggers, merges them to filter out false positives (or for other reasons), and finally correlates the triggers to cause the same failure / problem Incidents reported by individual TSAs can be identified. The manager operates in real time to implement a closed control loop as an entity that resolves a single or temporary incident, eg, in MBH, and / or, for example, eliminates a persistent deterioration or is negative It can be implemented through a long control loop as an entity that prevents failures caused by trends.

  Furthermore, the manager is configured to configure the system a priori to follow the eNB's typical traffic profile and load changes between network domains caused by the user's travel route. In addition to resolving temporary or pathological failures, the manager is responsible for maintaining system efficiency and maintaining system operation and resource usage / allocation at the optimal point of action. Thus, in addition to being triggered by the TSA, the manager may trigger an action on its own when it detects inefficient resource usage / allocation or system behavior through analysis of collected KPIs. it can.

  To accomplish such self-triggering (or for other reasons), managers can integrate with existing OSS and customer experience management (CEM) tools and access the KPI database of such tools can do. Based on the environment, such as the presence of an SDN controller, PCE or other transport provisioning tools, the manager can connect directly to some or all transport nodes through existing / standard management and configuration interfaces. Or can act as a user of an SDN controller, PCE or other transport provisioning tool.

  In the following description, the operation of the manager will be described as an application executed as a client of the SDN controller. However, similar operations are possible and permitted in the case of PCE or other provisioning / transport management tools. Furthermore, the manager can act as an integrator if the scope of the SDN controller is limited to a certain domain or there are many SDN controllers that manage individual network domains. For example, the manager can reconfigure or optimize by addressing individual SDN controllers separately or by configuring network elements directly from the range of SDN controllers to achieve a coherent end-to-end system configuration / state Can be triggered. Manager integration into the OSS ecosystem allows the reporting of actual network conditions, the distribution of special KPIs collected by the Tra-SON infrastructure, and / or the generation of alarms in case of problems / failures that cannot be resolved by the manager . For example, the manager may not be able to perform the required capacity expansion.

  An optional Tra-SON daemon is a software entity that runs on the transport node. The daemon can act as a KPI collection point that can detect anomalies. The daemon can also serve as a measurement point involved in cooperative measurements, thus allowing more accurate anomaly / fault localization. In addition, the daemon can act as a KPI source that can transfer the collected rows or aggregated KPIs to the manager via a standard management interface. In addition, the daemon can act as an entity that executes configuration commands generated by the manager or the master TSA of the daemon.

  It is not absolutely necessary to install a daemon. For example, due to MBH specificity, it is not essential to install a daemon on each and each transport node, even if the daemon can add values to the operation of the Tra-SON framework. Rather, daemons are installed to select transport nodes such as those that act as ingress / egress nodes between separate network domains or that aggregate traffic for multiple eNBs.

  The transport SON framework according to some embodiments can be used in various ways. For example, in a first use case, the transport SON framework according to some embodiments may be used for plug and play eNB commissioning. This use case can greatly simplify transport planning and increase the level of automation of the eNB commissioning process. Current eNB commissioning requires that the transport service be pre-planned and pre-configured prior to the provisioning process. In contrast, the transport SON framework according to some embodiments may eliminate the need for pre-planning and pre-configuration of each and each eNB. The eNB-side TSA can detect the start of the commissioning process and can automatically trigger the transport configuration through the manager. By the time the first user plane connection is established, the transport connection can be utilized. As a second step, the transport SON framework according to some embodiments may optimize eNB resource allocation for traffic demands served by the eNB.

  In the second use case, the transport SON framework according to some embodiments can be used for automatic transport configuration for the X2 interface as a complementary mechanism for ANR. Similar to the use case described above, the Tra-SON framework detects newly activated / established X2 interfaces and transports them in an optimal manner such as reduced hop count, efficient resource allocation, etc. It is comprised so that it may comprise.

  In a third use case, the transport SON framework according to some embodiments may be used for eNB and / or SAE-GW transport interfaces and transport router self-configuration and parameter optimization. This use case not only simplifies the planning and configuration process, but also enables harmonized radio and transport QoS and ensures a coherent end-to-end transport configuration. Through TSA, Tra-SON allows dynamic adaptive configuration of transport parameters that best serve a given practical traffic mix. Thus, the TSA can monitor the traffic and detect if the target QoS is not satisfied. The reason that the target QoS is not satisfied is, for example, that the radio and transport configurations are not harmonized. The TSA can also monitor traffic to detect if the configured resources are not sufficient for proper QoS. If such a case of QoS shortage or resource shortage is detected, the TSA can automatically reconfigure the transport parameters as a self-configuration process or solve the problem, for example through local reconfiguration Trigger managers for actions when they can't. This use case allows the deployment of network elements in a default configuration, as it can be noted that the solution itself finds the best parameters for a given eNB.

  In a fourth use case, the transport SON framework according to some embodiments may provide transport service self-optimization. Tra-SON can detect if the transport service is not configured with optimal resource allocation and trigger a reconfiguration. Thus, the TSA triggers the manager if the detected deterioration is due to insufficient transport service configuration. As a result, the manager selects one of the next actions. For example, the manager can increase the bandwidth allocation if there are enough free resources on the existing path. In another option, if there are not enough transport resources, the manager identifies low-use transport services that share the same resources with those that do not have sufficient bandwidth allocation, and the low-use The transport service can be downsized to make room for expanding the transport service assignment in question. In another option, the manager may reroute transport services at the same time, for example, if there are not enough resources in the path of a congested transport service and the size of other services may free up sufficient bandwidth. If not, uniform load and optimal system resource utilization can be maintained. According to yet another option, the manager can trigger an operation with an alarm message associated with the recommended configuration if none of the actions are considered.

  In a fifth use case, the transport SON framework according to some embodiments can detect transport elements that are not properly configured. For example, the TSA (s) can perform end-to-end measurements continuously. Therefore, it is possible to detect transport elements having a configuration that deteriorates QoS or system efficiency. Based on the settings, the manager is configured to identify those elements and modify their configuration.

  In the sixth use case, the transport SON framework according to some embodiments can perform traffic trend analysis and proactive optimization. For example, the manager can continuously monitor traffic to detect traffic trends and identify potential future resource limits / narrow points in the system. As a result, the manager can update the system configuration to prevent those incidents. In order to leverage the benefits of geographical diversity and the user's daily commute routine, when the topology allows, the manager releases resources allocated to serve suburban cells and during work hours, such as the downtown area. Resource allocation can be increased and the configuration can be reverted after working hours are over. In addition, the manager can delay reconfiguration to avoid prevention of planned network expansion or to operate based on allocation and retention priorities, cost functions, etc.

  In the seventh use case, the transport SON framework according to some embodiments can maintain optimal system level configuration and resource allocation. During network deployment, when the system is expanded during eNB commissioning, the transport resources are provisioned one by one to the new eNB, so the system state drifts from the optimal state. This is because the newly provisioned eNB transport service can be generated by taking into account the actual state, i.e. already configured services, and the need for new transport service resources being established. It is. This solution can provide local optimization. As the number of newly configured eNBs increases, this solution leads to sub-optimal configurations at the system level. The manager can continuously monitor existing assignments, eg, resource assignments / pairs / available capacity, transport tunnel paths / pairs / topologies, etc. When sufficient gain can be achieved by system level optimization, for example, higher than the threshold gain amount can be achieved, the manager calculates and reconfigures the optimal path for each service by considering system level optimization. A step-by-step plan can be generated for and a reconfiguration can be triggered by this plan.

  In an eighth use case, the transport SON framework according to some embodiments includes SLA monitoring. The Tra-SON network monitors the SLA when transport services are provided via a dedicated line, identifies resources that are underutilized, and / or anticipates resource limitations, and quantifies requested resources Can be used to

  In the ninth use case, the transport SON framework according to some embodiments can be used, for example, to measure KPIs. The Tra-SON framework can serve as a measurement mechanism that can provide detailed and accurate KPIs and identify and localize faults. Thus, some embodiments may improve network monitoring, management and troubleshooting capabilities.

  The above use cases can be accomplished individually or in combination with each other. These are just normative use cases and other uses are allowed.

  Tra-SON can operate across heterogeneous MBH environments. Various embodiments are possible, the following are some examples.

  FIG. 3 illustrates an alternative example of an eNB-side TSA according to some embodiments. Effective embodiments of the eNB-side TSA include software entities that run on the eNB itself, run on a standalone device located at the eNB site, or run on a site router. The latter embodiment corresponds to the TSA daemon. A possible embodiment of a daemon is to deploy a daemon on the router SDK if it is available. In each alternative embodiment, the TSA is an inline entity that can monitor all eNB traffic, including, for example, user plane, control plane, and management plane traffic.

  The TSA can manage the transport connection of the eNB during its entire lifetime as follows. The TSA uses the internal management interface to configure the eNB transport interface card if it is a software entity that runs on the eNB and uses a common management interface such as SNMP, Netconf, CLI, etc. If there is an element like a site router in the site, the site router can be managed. If the TSA is a stand-alone entity, the TSA can configure the relevant transport parameters of the eNB and site router using the available management interface. In a third alternative, the daemon can manage the site router through the internal interface. In each case, the TSA can access the eNB's QoS parameters used as input to the self-configuration / self-optimization process. Yet another useful alternative is to configure / configure eNB-side transport parameters through an SDN controller (eg, via the OpenFlow southbound interface) or via an existing common management interface (eg, SNMP, Netconf, CLI, etc.). Delegate all management responsibilities to the manager to be optimized. In this alternative, the TSA can act as a KPI collection and analysis entity that triggers the manager for action if an anomaly is detected.

  When the eNB is commissioned, the TSA that monitors all eNB traffic detects that the commissioning process has started, and the tracking area code (TAC) and associated transport configuration parameters, eg, VLAN ID, etc. Can be extracted from a configuration file downloaded from a management server such as a NetAct entity. This is possible when the commissioning file is not encrypted.

  An alternative method is that the eNB can inform the TSA about TAC and other such information. This is useful when the commissioning file is encrypted. Yet another useful alternative is that the TSA can detect the commissioning process itself and inform the manager about the commissioning process. This alternative is useful when TSA is not performed at the eNB. They are alternative embodiments. In general, transport connections are created by the Tra-SON framework during the commissioning process and can therefore increase the level of automation regardless of special implementation.

  The extracted information or otherwise obtained information is forwarded to a manager configured to maintain an S-GW database designated for each TAC. This information can be obtained from NetAct and updated continuously. Alternatively or in addition, if a list of S-GWs is provided as part of the optional configuration file, the TSA extracts this information and forwards this information to the manager as well. Based on the received information, the manager can establish a transport connection through existing network management tools such as SDN controller, PCE, etc. If no such network management tool is available, the manager can extract the configuration on its own.

  For example, the first manager may set the initial bandwidth to the transport service generated for a newly commissioned eNB to a value that is set as the average resource allocation for eNBs already operating in its surrounding area. Can be assigned. When the eNB begins operation, for example, when user traffic appears in the transport layer, the TSA can begin monitoring and profiling to adjust the bandwidth allocation to traffic demand.

  The commissioning process can be considered completed by those elements when the manager informs the eNB and NetAct that a transport connection has been established. If the TSA is implemented with the ability to detect only the commissioning process, the manager gets the requested information from NetAct. An effective alternative is that as part of the commissioning process, NetACT triggers the manager to create the necessary connections. This operation corresponds to the first use case described above.

  Similarly, the TSA detects a new X2 interface activation when the ANR is turned on. When a corresponding procedure is detected, the TSA can trigger the manager to create the necessary connections between the associated eNBs. The manager considers the optimal resource utilization across MBHs and special X2 requirements, eg, the shortest path between eNBs for the minimum number of intermediate transport hops, so that the transport connection (eg, point-to-pair)・ A point tunnel can be established. Resource allocation can be performed as in the eNB commissioning process. That is, the manager first allocates resources by considering the resources allocated to the already established X2 interfaces, and then performs a monitoring and continuous adaptation process for traffic needs and trends. The TSA can detect whether X2 is no longer used and trigger the manager to release the allocated resources. This is an example of the operation of the second use case described above.

  FIG. 4 illustrates the operation of a TSA according to some embodiments. As mentioned above, TSA was described in “Context based correlated QoS measurement and QoE monitoring framework” filed January 27, 2015 as PCT / EP2015 / 051563 for anomaly and exacerbation detection and localization. A mechanism can be used. In addition, the TSA continuously monitors the level of QoS provided to the bearer at 410 to detect deviations from expected behavior caused by transport layer issues such as insufficient configuration, resource limitations, etc. . When a deterioration or deviation from the target QoS is detected, at 420, the TSA localizes the problem. For example, the TSA checks whether the problem is due to the eNB transport interface or the site router. If the problem is local, the TSA checks at 440 whether the problem can be resolved by reconfiguration and at 450 initiates the necessary reconfiguration or optimization. Locally configurable parameters include scheduling weights, RED / AQM parameters, shaping rate and shaping parameters, and so on. If the problem is local but cannot be resolved by parameter reconfiguration, at 460 the TSA issues an alarm to the OSS. If the degradation is caused by an end-to-end transport connection (eg, insufficient physical capacity, congested transport, or transport service with low bandwidth allocation, etc.), at 430, the TSA Trigger the manager for This gives an implementation of the operation of the Tra-SON framework according to the third use case described above.

  FIG. 5 illustrates Tra-SON manager interworking according to some embodiments. As shown in FIG. 5, the TSA serves as a measurement / KPI collection point that can upstream the collected KPIs in a raw or aggregate format to a manager or OSS tool.

  Valid embodiments of the S-GW / SAE-GW / FlexiZone controller TSA include, for example, software running on a FlexiNG / FlexiZone controller, or a stand-alone entity or site router (s) at the FlexiNG / FlexiZone controller site Includes daemons that run on In each case, the TSA can access all MBH traffic of the S-GW / SAE-GW / FlexiZone controller. The rest of the functions and operations of the TSA are the same as those described for the eNB-side TSA.

  Effective examples of Tra-SON managers include software entities that are deployed on a core network or that run on a stand-alone server attached to an existing network management tool, such as, for example, a NetAct content pack.

  FIG. 6 illustrates transport service optimization by a manager based on a TSA trigger, according to some embodiments. As shown in FIG. 6, the manager may take action based on a trigger received from the TSA or detect a sub-optimal system configuration, or may expect a deterioration based on a trend analysis performed by the manager. Work as a level manager / optimizer.

  The manager is connected to each TSA in the network via a management interface such as JSON or IPFEX. This interface is used to trigger the manager by the TSA when a deterioration that cannot be resolved by local reconfiguration or parameter optimization is detected, as described above.

  Those triggers are collected at 610, filtered by the manager at 615 to eliminate false positive alarms, and ultimately correlated to identify failures / deteriorations affecting multiple eNBs. Having obtained the failure / deterioration correlation list, the manager first assesses their severity level, eg, the amount of affected eNBs, affected services, temporary versus persistent deterioration. Severe failures / deteriorations, such as those determined to be persistent at 620, first identify possible actions, check available resources, and trigger the required reconfiguration / optimization Handled by. In the case of a reason such as a worsening of resource limits that are determined not to be resolved by the manager at 630, an alarm is sent to the OSS system / operator at 635.

  At 625, the temporary deterioration may not be resolved by the action and is monitored to detect whether the temporary problem changes to a persistent problem. If the degradation can be resolved, the manager evaluates the required action (eg, amount of extra resources, new configuration of affected network elements, alternative routes, etc.) and at 640 transport management / Generate a request to a configuration tool, eg, an SDN controller.

  If the MBH contains multiple domains managed by separate SDN controllers and requests changes to multiple domains to resolve the degradation, the manager sends a domain specific request to the corresponding SDN controller. By integrating the reconfiguration. If there are network elements that are not managed by any existing SDN controller, or if no SDN controller domain or other management tools are available in the MBH, then the manager can use an available management and control interface (eg, SNMP , Netconf, CLI, etc.) or a daemon if available to perform the requested action.

  A valid alternative is that the manager is responsible for configuring the transport parameters of the eNB / S-GW / SAE-GW / FlexiZone controller / site router. In this case, when a trigger is received from the TSA for such an action or the manager itself detects a deterioration caused by those network elements, the manager identifies the requested action and configures a new configuration. If defined, and the network element is managed by an SDN controller, a reconfiguration can be created through the corresponding SDN controller or by using an available management interface such as SNMP, Netconf, CLI, etc.

  After the request, the manager determines at 645 whether an approval has been received. If not, the manager records the incident at 650. If approval is received, the manager initiates reconfiguration at 655, monitors efficiency, and records the incident. Thus, the Tra-SON framework is deployed so that operators can follow, monitor and approve / reject actions created / proposed by the framework. These procedures correspond to the fourth use case described above.

  FIG. 7 illustrates an example judgment by a manager, according to some embodiments. As described above, before resolving the deterioration, the manager identifies the requested action, calculates the required resources (eg, if the problem is rooted in resource allocation), and sufficient free resources Is evaluated end-to-end. One possible outcome of the evaluation / analysis is that there are enough free resources on each link of the end-to-end path, as shown in FIG. In this case, the manager initiates an increase in resource allocation through the SDN controller and / or provisioning tool, or reconfigures when the network domain / element is not managed by the SDN controller or other appropriate tool, for example. Run directly. Note that in each case, the required resources are calculated based on KPIs collected by the TSA using an improved analysis method.

  FIG. 8 illustrates another example judgment by a manager, according to some embodiments. If there are not enough resources end-to-end, the manager looks for possible alternative actions. One possibility is that there are other transport services that share the same resources with the service in which the deterioration is detected and that have a low utilization rate. Therefore, the manager can identify services that share resources with resource-restricted services and can check usage levels using historical data collected through the TSA. If there are enough underutilized resources that can be reallocated, the manager can resolve the deterioration in two stages. That is, firstly, the resource allocation of the transport service with low utilization is scaled down, and secondly, the resource allocation of the eNB accompanied by deterioration is increased.

  FIG. 9 illustrates the resolution of the degradation caused by poorly configured transport devices, according to some embodiments. In the absence of a low utilization transport service that can be scaled down to eliminate degradation, the manager attempts to find an alternative route for a service that has sufficient free resources available. If such a path exists, the manager can reroute the service and increase the resource allocation across the new path. Alternatively, the manager can create free resources by re-routing services without resource problems and keep the problematic services in their original path. This action can be taken when it saves the system operation to an optimal level.

  In addition to resource limitations, poorly configured transport nodes can also result in degradation of efficiency or QoS / QoE. Anomaly / aggravation detection and problem localization performed by the TSA detects the presence of such network elements. If such an element is detected at 1 in FIG. 9, the TSA triggers the manager for action by also providing the relevant context. The manager at 2 identifies the poorly configured transport node with the help of the SDN controller and initiates reconfiguration. This operation of the Tra-SON framework corresponds to the fifth use case described above.

  The manager uses KPIs and analysis results collected / executed by TSA or received from a common OSS KPI database to detect trends and assess overall system efficiency. Based on the available information, the manager detects an alarm trend, which ultimately leads to worse or sub-optimal system operation. In addition, the manager analyzes the eNB's daily profile (including traffic, user demand, resource needs, etc.) to identify potential resources for geographic diversity or daily resource needs To do.

  Geographic diversity allows managers to dynamically shift resources back from the suburbs to the city center or business area, for example, when a user starts commuting from his home to the workplace. The eNB's daily traffic pattern can be used to release unused resources and only those that are appropriate for the appropriate service level at the eNB can be allocated for a given period of the day. In this way, the user's daily routine can be followed and significant resource and energy consumption gains / savings can be achieved if the infrastructure allows.

  Thus, based on the results of the trend analysis, the manager can initiate the configuration necessary to prevent negative trends from getting worse / failed or leading to insufficient network configuration. If there is a capacity limit that prevents these actions, the manager can alert the OSS tool / operator. If the topology allows for the incorporation of geographical diversity, for example, if suburban and urban cells share a common transport link, the manager may configure the desired dynamic configuration according to the learned traffic pattern / profile / demand. Can start. Finally, the manager can increase / decrease resource allocation according to the eNB's daily profile. This corresponds to the operation according to the sixth use case described above.

  FIG. 10 illustrates optimization of system level resource allocation according to some embodiments. As shown in FIG. 10, the manager periodically checks system conditions such as topology versus resource allocation to detect whether the system is in an optimal state. When a network is expanded as part of the eNB commissioning process, typically new resources are provisioned, so the starting point for the resource allocation mechanism is the network topology, available resources, already provisioned services, and Requests for new services, such as protection, dismantling standards, etc.

  With the use of initial provisioning criteria, only local optimal configurations are achieved because resources are provisioned one by one. The overall system state drifts gradually from the optimal system level. Therefore, when the system analysis performed by the manager shows significant gains in performing system level optimization, the manager initiates a step-by-step reconfiguration process where the optimal path for each service is first calculated. And then the requested intermediate configuration stage is also identified, allowing uninterrupted service transition.

  This reconfiguration plan can be executed automatically or under the supervision of an operator who can approve / reject a partial or complete plan. This handling of the plan can be performed by transferring the plan to the OSS and making it visible. This mechanism leads to a significant efficiency gain, as shown in FIG. To achieve such a gain, the manager can optimize the MBH resource allocation by considering all transport technology layers (eg, optical, Ethernet, IP-MPLS, etc.). A layer optimization (MLO) program can be executed. This is the operation of the manager under the seventh use case described above.

  When transport services are provided over a leased line, the Tra-SON framework operates as described above, but the manager itself cannot trigger end-to-end service reconfiguration, and the SLA monitoring tool And can evaluate whether the leased line SLA is satisfied based on measurements collected through the TSA. This evaluation is used to identify low-use leased lines and leased lines that should have a larger bandwidth allocation, or end-to-end QoS is not satisfied due to misconfiguration in the leased line service provider. Used to detect if. These operations correspond to the operations of the eighth use case described above.

  The Tra-SON framework serves as an efficient mechanism that gathers high insights on network performance and efficiency, and TSA measures and measurements that can provide OSS systems with accurate and detailed KPIs, incident reports, root causes, etc. Works as an anomaly detection point. In this case, the manager can collect measurements, perform additional analysis on the KPI, and transfer the data to the relevant OSS database. This therefore corresponds to several possible embodiments of the ninth use case described above.

  Currently, there are no solutions on the market that can efficiently implement the use cases provided by the Tra-SON framework. In contrast, some embodiments may provide simple plug-and-play eNB service, on-demand X2 service generation, QoE-driven transport network reconfiguration, radio / transport QoS coordination, and so on. For example, in some embodiments, operations can be performed using, for example, daemon-assisted implementations across devices that cannot be managed across heterogeneous MBH device deployments or via an SDN controller.

  Further, in some embodiments, intelligent MBH configuration actions are provided, such as a priori or responsive actions against QoE degradation, daily traffic fluctuations, long-term trends, automatic parameter tuning, etc. These are provided via an insight-driven MBH management system that can obtain measurements, insights, analysis, profiling and anomaly detection capabilities from the TSA and manager as described above.

  The self-configuring MBH responds to parameters that are deliberately misconfigured according to the third use case described above (eg, parameters configured in a way that results in unbalanced radio and transport QoS settings). (One or more) can be automatically tuned to their optimal values.

  Similarly, in some embodiments, a change in the eNB's transport service is made that has no detectable change in the eNB's own traffic profile. Such a change is performed through performing a system level reconfiguration or redistributing resources to another eNB requesting more resources, as described in the fourth use case above. .

  In some embodiments, the agent can communicate between the TSA and the manager using a packet on an associated interface, such as the S1 interface. Also, traffic can be exchanged between the manager and the OSS / NetAct tool, for example when no integration is performed via the internal interface.

  Various embodiments have benefits or effects. For example, in some embodiments, in a global manner (eg, individual values vs. predefined thresholds) through user and control plane KPIs (eg, directly and derived / configured). Rather than continuously monitoring network status (with levels / constellations / patterns / evolution vs profiled behavior in the context of system status) to detect anomalies and define whether anomalies mean worsening There is always a mechanism that can do this. In the latter case, yet another proprietary method is to identify the location as accurate as possible after identifying transport-related degradations (eg, congestion, insufficient buffers, path switches, incorrect network node parameterization, etc.) For example, it is used to identify the location of a RA node's transport interface, site router, leased line or transport service. Once the transport deterioration, its location, and reason are identified, it identifies the necessary actions, for example, calculates the necessary resources and checks if it is available in the relevant network domain and automatically The mechanism to execute automatically is applied. SDN is an example of a possible tool for implementation. The framework can perform management actions on its own through existing management platforms such as SDN.

  FIG. 11 illustrates a system according to some embodiments of the invention. In an embodiment, the system is configured with multiple devices, eg, evolved Node B, SAE-GW or at least one Tra-SON agent 1110 provided as a stand-alone device, at least one Tra-SON manager 1120. , And at least one core network element 1130 that is an SDN controller or server configured to form an OSS / NMS tool.

  Each of these devices comprises at least one processor, each indicated at 1114, 1124 and 1134. Each device is provided with at least one memory and is indicated at 1115, 1125 and 1135, respectively. The memory includes computer program instructions or computer code. Processors 1114, 1124 and 1134 and memories 1115, 1125 and 1135, or subsets thereof, are configured to provide means corresponding to the various blocks of FIGS.

  As shown in FIG. 11, transceivers 1116, 1126, and 1136 are provided, each of which also includes an antenna, shown as 1117, 1127, and 1137, respectively. For example, other configurations of these devices may be provided. For example, the core network element 1130 is configured for wired communication rather than wireless communication, and in such a case, the antenna 1137 represents any form of communication hardware without requiring a conventional antenna.

  Processors 1114, 1124, and 1134 are implemented by computing or data processing devices such as a central processing unit (CPU), application specific integrated circuit (ASIC), or equivalent device. The processor is implemented as a single controller or multiple controllers or processors.

  Memories 1115, 1125 and 1135 are each suitable storage devices such as non-transitory computer readable media. A hard disk drive (HDD), random access memory (RAM), flash memory, or other suitable memory may be used. The memory can be combined as a processor on a single integrated circuit, or it can be separated from one or more processors. Further, the computer program instructions stored in the memory and processed by the processor are any form of computer program code, for example a compiled or interpreted computer program written in a suitable programming language.

  The memory and computer program instructions are a processor for a particular device, and hardware devices such as the Tra-SON agent 1110, Tra-SON manager 1120, and core network element 1130 may use any of the processes described herein ( For example, see FIG. 4, 6 and 9). Thus, in some embodiments, non-transitory computer readable media is encoded with computer instructions that, when executed in hardware, perform a process such as one of the processes described herein. Alternatively, some embodiments of the invention may be performed entirely in hardware.

  Further, FIG. 11 shows a system including a Tra-SON agent, a Tra-SON manager, and a core network element, but the embodiment of the present invention can be applied to other configurations and configurations including additional elements. For example, although not shown, there may be additional Tra-SON agents and additional core network elements, for example as shown in FIGS.

  One skilled in the art will readily appreciate that the present invention described above may be implemented in a different order of steps and / or with hardware elements configured differently than those disclosed herein. Thus, although the invention has been described based on these preferred embodiments, several changes, modifications and alternative constructions will be apparent to those skilled in the art without departing from the spirit and scope of the invention. I will.

List of abbreviations ANR: Auto Adjacency AQM: Active Queue Management BTS: Base Transceiver Station CAPEX: Capital Expenditure CEM: Customer Experience Management CLI: Command Line Interface E2E: End-to-End eNB: Evolved Node B
FlexiNG: Flexi network gateway GW: Gateway HSPA: High-speed packet access JSON: JavaScript (registered trademark) object notation KPI: Critical performance indicator LTE: Long-term evolution MBH: Mobile backhaul MLO: Multi-layer optimization NAT: Network address translation OPEX: Operating Expenditure OSS: Operation Support System PCE: Route Calculation Element QoE: Experience Quality QoS: Quality of Service RA: Radio Access RED: Random Early Detection SDN: Software-defined Networking SAE-GW: System Architecture Evolution Gateway SDK: Software Development Kit S- GW: Serving gateway SLA: Service level agreement SNMP: Simple network Click Management Protocol SON: self-organizing network TAC: Tracking Area Code Tra-SON: Transport SON
TSA: Tra-SON Agent

1110: Tra-SON agent 1120: Tra-SON manager 1130: Core network element 1114, 1124 and 1134: Processor 1115, 1125 and 1135: Memory 1116, 1126 and 1136: Transceiver 1117, 1127 and 1137: Antenna

Claims (39)

Monitor transport connections to at least one base station across the mobile backhaul,
Detecting at least one deterioration or anomaly in the transport connection of at least one base station and taking appropriate network management actions in response to the detected deterioration or anomaly;
A method involving that.   The method of claim 1, wherein the at least one base station comprises an evolved Node B.   The appropriate network management action determines whether the detected deterioration or anomaly is due to a local problem and triggers a network manager if the detected deterioration or anomaly is not due to a local problem The method of claim 1, comprising:   When the appropriate network management action determines that the detected deterioration or anomaly is due to a local problem, it determines whether the local problem can be resolved by reconfiguration, and reconfigures the local problem. The method of claim 1, comprising performing a reconfiguration when it can be resolved.   2. The appropriate network management action includes sending an alarm or report to an operational support system when it is determined that the detected deterioration or anomaly is due to a local problem that cannot be resolved by reconfiguration. The method described in 1. Monitor mobile backhaul transport related triggers for at least one base station,
Detecting whether a deterioration or anomaly corresponding to the trigger persists, and taking appropriate network management actions in response to the detected worsening or anomaly;
A method involving that.   The method of claim 6, wherein the at least one base station comprises an evolved Node B.   The method of claim 6, further comprising at least one of filtering, correlation, or severity level evaluation of the trigger.   7. The method of claim 6, wherein when the deterioration or anomaly does not persist, the appropriate network management action includes entering a monitoring mode for a trigger.   7. The method of claim 6, wherein when the deterioration or anomaly persists, the appropriate network management action includes determining whether the deterioration or anomaly can be resolved by a manager.   7. The method of claim 6, wherein when the deterioration or anomaly cannot be resolved by a manager, the appropriate network management action includes sending an alarm to an operational support system.   7. The method of claim 6, wherein when the deterioration or anomaly can be resolved by a manager, the appropriate network management action includes initiating a reconfiguration.   The method of claim 12, wherein the reconfiguration is subject to approval from an operator. At least one processor and at least one memory containing computer program code;
At least one memory and computer program code with at least one processor, wherein the device is at least
Monitor transport connections to at least one base station across the mobile backhaul,
Detecting at least one deterioration or anomaly in the transport connection of at least one base station and taking appropriate network management actions in response to the detected deterioration or anomaly;
A device configured to cause   The apparatus of claim 14, wherein the at least one base station comprises an evolved Node B.   The appropriate network management action determines whether the detected deterioration or anomaly is due to a local problem and triggers a network manager if the detected deterioration or anomaly is not due to a local problem 15. The apparatus of claim 14, comprising:   When the appropriate network management action determines that the detected deterioration or anomaly is due to a local problem, it determines whether the local problem can be resolved by reconfiguration, and reconfigures the local problem. 15. The apparatus of claim 14, comprising reconfiguring when it can be resolved.   15. The appropriate network management action includes sending an alarm or report to an operational support system when it is determined that the detected deterioration or anomaly is due to a local problem that cannot be resolved by reconfiguration. The device described in 1. At least one processor and at least one memory containing computer program code;
At least one memory and computer program code with at least one processor, wherein the device is at least
Monitor mobile backhaul transport related triggers for at least one base station,
Detecting whether a deterioration or anomaly corresponding to the trigger persists, and taking appropriate network management actions in response to the detected worsening or anomaly;
A device configured to cause   The apparatus of claim 19, wherein the at least one base station comprises an evolved Node B. The at least one memory and the computer program code are at least one processor and the device is at least
21. The apparatus of claim 19, wherein the apparatus is configured to perform at least one of filtering, correlation, or severity level evaluation of the trigger.   20. The apparatus of claim 19, wherein when the deterioration or anomaly does not persist, the appropriate network management action includes entering a monitoring mode for a trigger.   20. The apparatus of claim 19, wherein when the deterioration or anomaly persists, the appropriate network management action includes determining whether the deterioration or anomaly can be resolved by a manager.   20. The apparatus of claim 19, wherein when the deterioration or anomaly cannot be resolved by a manager, the appropriate network management action includes sending an alarm to an operational support system.   20. The apparatus of claim 19, wherein when the deterioration or anomaly can be resolved by a manager, the appropriate network management action includes initiating a reconfiguration.   26. The apparatus of claim 25, wherein the reconfiguration is subject to approval from an operator. Means for monitoring transport connections to at least one base station across the mobile backhaul;
Means for detecting at least one deterioration or anomaly in the transport connection of at least one base station; and means for taking appropriate network management actions in response to the detected deterioration or anomaly;
With a device.   28. The apparatus of claim 27, wherein the at least one base station includes an evolved Node B.   The appropriate network management action determines whether the detected deterioration or anomaly is due to a local problem and triggers a network manager if the detected deterioration or anomaly is not due to a local problem 28. The apparatus of claim 27, comprising:   When the appropriate network management action determines that the detected deterioration or anomaly is due to a local problem, it determines whether the local problem can be resolved by reconfiguration, and reconfigures the local problem. 28. The apparatus of claim 27, comprising reconfiguring when resolvable.   28. The appropriate network management action includes sending an alarm or report to an operational support system when it is determined that the detected deterioration or anomaly is due to a local problem that cannot be resolved by reconfiguration. The device described in 1. Means for monitoring mobile backhaul transport related triggers for at least one base station;
Means for detecting whether the deterioration or abnormality corresponding to the trigger persists, and means for taking appropriate network management actions in response to the detected deterioration or abnormality;
With a device.   The apparatus of claim 32, wherein the at least one base station comprises an evolved Node B.   35. The apparatus of claim 32, further comprising means for performing at least one of filtering, correlation, or stringency level evaluation of the trigger.   33. The apparatus of claim 32, wherein when the deterioration or anomaly does not persist, the appropriate network management action includes entering a monitoring mode for a trigger.   35. The apparatus of claim 32, wherein when the deterioration or abnormality persists, the appropriate network management action includes determining whether the deterioration or abnormality can be resolved by a manager.   33. The apparatus of claim 32, wherein the appropriate network management action includes sending an alarm to an operational support system when the deterioration or anomaly cannot be resolved by a manager.   35. The apparatus of claim 32, wherein when the deterioration or anomaly can be resolved by a manager, the appropriate network management action includes initiating a reconfiguration.   40. The apparatus of claim 38, wherein the reconfiguration is subject to approval from an operator.