Thursday, June 7, 2012
Do you like this Article?
A set of common performance counters for accessibility, retainability, and mobility KPIs is generated by network elements like eNB and MME. Hence, these performance counters are also named network element counters or OMC counters.
The disadvantage of such network element counters is that their trigger point definitions often follow proprietary standards so that, for example, a set of Nokia Siemens Network MME counters will never be 100% identical to a set from an Ericsson MME. And the differences are growing in the field of KPI formula definition that is in large portions not covered by any international standard although a comprehensive set of KPIs for the E-UTRAN is defined in 3GPP 32.450. This set of standard KPIs is quite sophisticated and almost impossible to be implemented by external measurement equipment, because check of user plane buffer status is mandatory and external measurement equipment cannot check the user plane buffer inside the network elements. However, even implementation inside the network element is not easy and significant processing resources are required to compute such sophisticated KPIs in the network elements.
A “call” in the environment of the all-IP always-on E-UTRAN can only be defined as a single radio connection between a UE and the network. When this connection is interrupted due to a suddenly occurring exception (e.g., signal lost on the radio interface), the definition of “call drop” is fulfilled.
The drop events can be found in the S1AP UE context release request message sent by the eNB to the MME (see the illustration below).
When this message is sent, the radio connection with the UE is already terminated on the RRC layer, so UE and eNB go back to the E-UTRA RRC IDLE state. However, the PDN connection between the UE and the server hosting application contents on the IP network will typically remain active.
The “call drop” in the all-IP world of E-UTRAN and EPC will not always be perceived as a dropped connection by the subscriber. For non-real-time services like web-browsing or e-mail, user perception is described as rather a temporary interruption of data transport, a delay in accessing the next web site, or a significant downturn of the data transmission rate of an ongoing download. If the network can re-establish the lost radio connection fast enough (and this is an important KPI for RRC retainability) the drop of the radio connection will not be recognized by the subscriber.
It is a different situation if real-time services are used by the subscriber. In this case the user will immediately recognize the loss of connection, because the ongoing conversation with the peer party, for example, in a VoIP call is suddenly interrupted and it would require extremely fast RRC re-establishment procedures (successful re-establishment within 1 or 2 seconds) to save the situation. Knowing this difference, it appears that it is mandatory not just to compute a call drop ratio per cell, but also to have a call drop ratio per service (per QCI is sufficient) within the cell to measure the user-perceived QoE.
The root causes for call drops are varied and cannot be unambiguously identified just by looking at the cause value in the S1AP UE context release request message. In fact the identification of the root cause requires an in-depth analysis of all transport and signaling protocols involved in the call, with a focus on call state transitions and changing radio quality parameters. The illustration below gives an overview of which different root causes can be revealed from common call drop S1AP causes like “failure in the radio interface procedure” and “radio connection with UE lost.”
Subscribe via Email
This post was written by: Alex Wanda