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.”
