Transition Rate KPIs

This chapter describes the following topics:

Feature Description

Session Events Per Second, key performance indicators (KPIs) did not differentiate between successful or unsuccessful PDN session activations and deactivations. In addition, the KPIs did not provide any information related to the Voice-over-LTE (VoLTE) service.

To calculate CEPS(Call Event Per Second) which measures the signaling load on the system, operator needs to use historical data (via bulkstats) collected periodically. Also, the meaning of CEPS is defined as setting up and tearing down a call (PDN session, not VoLTE calls) along with all the interactions (messages) on ePDG interfaces ( SWu, SWm and S2b). In StarOS release 20, Session Events Per Second (SEPS) KPIs have been implemented to address these issues.
  1. Session Events Per Second (SEPS)

    New KPI that measures a total number of session setup (IKE session setup) and session tear down (IKE SA Delete Request from peer) events (both successful and unsuccessful) per second. SEPS KPI will be calculated at ePDG and provided using CLI show commands and bulkstats data.

    The SEPS KPI have the following counters:

    • Session Events: Increments when a new IKE_SA_INIT Request and IKE_SA_DELETE Request received from peer. It will not increment for retry messages and IKE_SA_DELETE Request received for rekeyed IKE_SA.

    • Successful Session Events: Increments when a successful session creation (when final IKE_AUTH rsp is sent after PGW allocates UE's internal IP address). It also increments for successful IKE_SA_DELETE response sent for peer initiated delete request received.

    • Unsuccessful Session Events: Increments to an unsuccessful session creation attempt which failed at IKE_SA_INIT, IKE_AUTH or PGW PDN allocation phase. In summary, any session deletion before it was successfully created. ( Failure sent by peer, setup timer expiry etc). The counter also increments if IKE_SA_DELETE Request was dropped, or response was sent with error notify, if any.

  2. Call Events Per Second (CEPS)

    New KPI that measures a total number voice VoLTE (QCI=1, configurable) calls setup (Create Bearer Request) and tear down (Delete Bearer Request) events (both successful and unsuccessful) per second. CEPS KPI will be calculated at ePDG and provided using CLI show commands and bulkstats data.

    The CEPS KPI have the following counters:

    • Call Events: Increments when Create Bearer Req received for QCI-1. It also increments when Delete Bearer Request received for QCI-1. Delete session Request received, where a dedicated bearer with QCI-1 was present.

    • Successful Call Events: Increments when Created Bearer Response sent successfully for QCI-1 and Delete Bearer Response sent successfully for QCI-1. Delete session Rsp sent successfully, where dedicated bearer with QCI-1 was present.

    • Unsuccessful Call Events: Increments when Create Bearer Response and Delete Bearer Response was sent with cause IE not equal to "Request Accepted" or either of messages was dropped due to any reason. (for QCI-1).

Assumptions and Limitations

  1. The SEPS or CEPS counter do not incremented if the packet is dropped at npu.

  2. Change in bucket interval using CLI will reset all(both SEPS and CEPS) the pegged counters to zero including historical data.

  3. Change in QCI value to peg CEPS counters will reset all historical data for CEPS.

  4. SR will reset the counters for respective ipsecmgr or sessmgr.

  5. Unplanned card migration will reset the counters for all sessmgr and ipsecmgrs on the card.

  6. The SEPS/CEPS values will sync on ICSR standby chassis, so there is no impacts for ICSR upgrade or downgrade scenarios.

  7. The SEPS statistics is not collected from ipsecdemux (if dropped), so some SEPS attempts would be lost if it is a non Cisco ASR 5500 platform.

  8. If the final IKE_AUTH resp is rejected by peer due to invalid syntax or authentication failure etc are not taken into consideration for unsuccessful SEPS event. It would be counted as successful SEPS event for session creation and session deletion separately.