Description
In 3GPP self-organizing networks (SON), a trigger condition is the specific set of circumstances or thresholds that cause a self-optimization function to initiate corrective or optimizing actions. Self-optimization is a key feature of SON, allowing the network to automatically adjust parameters such as antenna tilt, handover thresholds, or capacity settings to improve performance and reduce manual intervention. The trigger condition defines when the self-optimization process should start, based on measurements, events, or performance indicators. For example, a trigger condition might be a drop in handover success rate below a certain threshold, or an increase in call drop rate beyond a defined limit. Different self-optimization algorithms may use different trigger conditions even when pursuing the same objectives (e.g., improving coverage and capacity), because the algorithms may focus on different metrics or operate at different time scales.
The concept of trigger conditions is closely tied to the SON architecture defined in 3GPP specifications such as TS 28.627 (Self-organizing networks (SON) policy Network Resource Model (NRM) Integration Reference Point (IRP)) and TS 28.628 (SON coordination management). These specifications describe how SON functions are managed and coordinated, including the definition of trigger conditions and policies. A trigger condition is typically configured by the network operator or automatically derived from network performance data. It may be expressed as a combination of conditions, such as a specific event (e.g., a handover failure) occurring a certain number of times within a time window, or a performance metric crossing a threshold. Once the trigger condition is met, the self-optimization algorithm executes its optimization logic, which may involve adjusting parameters, reconfiguring network elements, or initiating other SON functions.
Trigger conditions are essential for ensuring that self-optimization actions are taken only when necessary and appropriate. Without well-defined trigger conditions, SON functions might oscillate or interfere with each other, leading to unstable network behavior. Therefore, 3GPP specifications emphasize the need for coordination between different SON functions, including the management of conflicting trigger conditions. For instance, TS 28.628 defines mechanisms for SON coordination, such as prioritizing certain SON functions over others or resolving conflicts when multiple trigger conditions are met simultaneously. The trigger condition thus serves as a gatekeeper for self-optimization, ensuring that actions are initiated based on reliable and relevant network observations.
In practice, trigger conditions are implemented in the network management system (NMS) or element management system (EMS) and may be distributed across network elements. They can be based on a variety of inputs, including performance measurements (e.g., from the Performance Management (PM) IRP), fault management alarms, or configuration data. The flexibility to define different trigger conditions for different algorithms allows operators to tailor SON behavior to their specific network deployment and optimization goals. For example, a coverage and capacity optimization (CCO) function might use a trigger condition based on reference signal received power (RSRP) statistics, while a mobility robustness optimization (MRO) function might use a trigger condition based on handover failure rates. This diversity is explicitly acknowledged in the definition: different self-optimization algorithms may have different trigger conditions for achieving the same objectives and targets.
As networks evolve towards 5G and beyond, the role of trigger conditions remains critical, especially with the introduction of network slicing and more dynamic environments. The 3GPP specifications continue to refine the management of trigger conditions, ensuring that SON functions can operate autonomously while maintaining network stability and performance. The trigger condition is thus a fundamental concept in the management of self-optimizing networks, enabling automated optimization while preventing unintended consequences.
Purpose & Motivation
The trigger condition exists to provide a clear and controlled mechanism for initiating self-optimization actions in a self-organizing network (SON). In early mobile networks, optimization was largely manual, requiring engineers to monitor performance and adjust parameters based on drive tests and alarms. This approach was slow, costly, and unable to keep up with the increasing complexity of networks, especially with the introduction of multiple radio access technologies and denser deployments. SON was introduced in 3GPP Release 8 and later to automate these tasks, but automation without proper safeguards could lead to instability. The trigger condition solves this by defining the specific circumstances under which an optimization algorithm should act, ensuring that actions are taken only when there is a clear need and that they are based on reliable data.
Historically, the concept of trigger conditions emerged as part of the SON framework in Release 9, although earlier releases laid the groundwork for self-configuration and self-optimization. The need for trigger conditions became apparent as multiple SON functions were deployed in the same network, potentially conflicting with each other. For example, a mobility load balancing (MLB) function might adjust handover thresholds to balance load, while a mobility robustness optimization (MRO) function might adjust the same thresholds to reduce handover failures. Without coordination, these functions could oscillate or counteract each other. Trigger conditions, along with SON coordination mechanisms, help to manage such interactions by defining when each function should activate and how conflicts should be resolved.
The trigger condition also addresses the limitation of static thresholds. In dynamic networks, fixed thresholds may not be suitable for all scenarios; trigger conditions can be adaptive, based on statistical analysis or machine learning, allowing the network to respond to changing conditions. This adaptability is essential for 5G networks, which are expected to support diverse services with varying requirements. By defining trigger conditions, operators can ensure that self-optimization is both responsive and stable, ultimately improving network performance and reducing operational costs.
What changed in its specifications
The latest release-to-release comparison of specifications that define Trigger condition. Each summary describes the whole specification, not only this term.
Added SON for AAS management clauses, new attributes for AAS switches/load rates, and performance measurement support.
Full comparison in TS 28.628 →Rel-10 added capacity and coverage optimization requirements, coordination policies, and a new CCO term.
Full comparison in TS 32.521 →Release Timeline
Evolution Across Releases
An overview written from the defining specifications, not a verified change history. For the exact text, open the specifications listed below.
Defining Specifications
3GPP specifications that define or reference Trigger condition, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 28.627 vj00 | SON Policy NRM IRP: Requirements | Rel-19 read |
| TS 28.628 vj00 | SON Policy NRM IRP Information Service | Rel-19 read |
| TS 32.521 vb10 | SON Policy NRM IRP Requirements | Rel-11 read |
| TS 32.522 vb70 | SON Policy NRM IRP Information Service | Rel-11 read |