Section: A.2 Monitoring of E-RAB release
Content: E-RAB is the key and limited resource for E-UTRAN to deliver services. The release of the E-RAB needs to be monitored as: - an abnormal release of the E-RAB will cause the call(/session) drop, which directly impacts the QoS delivered by the networks, and the satisfaction degree of the end user; - a successfully released E-RAB can be used to setup other requested calls(/sessions). The E-RAB failed to be released will still occupy the limited resource and hence it can not be used to admit other requested calls(/sessions). However, the abnormal release of the E-RAB has potential scenario where, regardless of receiving the UE Context Release Command with the cause related to abnormal release, the end user does not perceive it as abnormal. This scenario is explicitly related to VoLTE calls, for other services it is not possible to determine the reason behind the cause code. It is typical to encounter such scenario, a so called "double UE Context", when Radio Link Failure occurs during an ongoing VoLTE call and RRC Connection Re-establishment attempt fails on target or other cell. If then the UE does a new RRC Connection the QCI1 bearer is set-up during Initial Context Setup in the target or other cell. However, when MME receives that service request with the Initial UE message through the target or other cell, it realize that it already has the same UE Context but from the source cell (it has not been released yet). In such case, MME sends UE Context Release Command to the source cell. As the QCI1 E-RAB has been successfully setup in the target or other cell, the QCI1 E-RAB release in the source cell may not be perceived as a drop (abnormal release) by the end user, as the service has been sustained with some interruption time, and cannot be considered as a drop in the QCI1 E-RAB flow Drop Ratio. From a retainability measurement aspect, E-RABs do not need to be released because they are inactive, they can be kept to give fast access when new data arrives. To define (from an E-RAB release measurement point of view) if an E-RAB is considered active or not, the E-RABs can be divided into two groups: a) Continuous flow, E-RABs that are always considered active, i.e. independent of if there is ongoing traffic or not at the moment. Examples: VoIP sessions, Real-time sessions, Live streaming sessions. b) Bursty flow, E-RABs that are only considered active when there is data in UL/DL buffer. Example: Web sessions. How to decide for a particular QCI if the E-RAB is of type bursty flow or continuous flow is outside the scope of this document. The specific reason causing the abnormal and failed release of the E-RAB is required in order to find out the problem and ascertain the solutions. And due to different priority and tolerance for different service type with different OoS level in the networks, the monitor needs to be opened on each service type with OoS level. The E-RAB can be released by E-RAB Release procedure (See 3GPP TS 36.413[ Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP) ] [9]) , UE Context Release procedure (See 3GPP TS 36.413[ Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP) ] [9] and 3GPP TS 36.423[ Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2 Application Protocol (X2AP) ] [10]) procedure, Reset procedure(See 3GPP TS 36.413[ Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP) ] [9]) either initiated by eNodeB or MM, Path Switch procedure (See 3GPP TS 36.413[ Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP) ] [9]) and Intra-eNB HO procedure (See 3GPP TS 36.331[ Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification ] [8])E. So performance measurements related to E-RAB Release (See 3GPP TS 36.413[ Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP) ] [9]) and UE Context Release (See 3GPP TS 36.413[ Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP) ] [9]) procedure for each service type with QoS level are necessary to support the monitor of E-RAB release. The QCI1 E-RABs normally released on reception of the E-RAB Release Command message from MME with the RLF detected on eNB side in the last predefined time interval are recommended to be monitored via dedicated measurement as may help operator to optimize the network from retainability perspective. It is because in such a case the end user may perceive it as not a drop but as a gap in provided services which may present a room for optimization from QoS perspective.