In a mobile environment, by its nature, the handover may occur while the user is engaged in a VoLTE call session. The UE periodically reports measurements of various parameters to the eNB and the eNB determines whether the handover is required. Once it is determined by the eNB to trigger the handover, the eNB will decide whether to perform X2 handover or the S1 handover. When there is an existing X2AP connection towards the target eNB, the source eNB performs X2 handover. If there is no X2AP connection or the X2 handover attempt has failed for some reasons, the source eNB may trigger the S1 handover.
As to the PGW initiated bearer related requests(e.g., Create/Update/Delete Bearer request) there is no cause-id defined in the 3GPP TS29.274(r8), Therefore, in this case, the MME may reject the request with the cause-id of reason unspecified. This cause-id will lead to the ripple effect towards the upstream forcing each node on the path to release the corresponding resources. This is shown in the following flow diagram.
Even though the handover is successful in this flow, the error cause of RESOURCE ALLOCATION FAILURE in the CCR over Gx will lead to the PCRF to send RAR(Re-Authentication Request) or ASR(Abort-Session-Request) over Rx with a cause-id of RESOURCE NOT AVAILABLE, and the process will end up with sending the 503 Service Unavailable by the P-CSCF. Upon receiving the 503 Service Unavailable, the UE releases all the resources for the call.
In a circumstance where the eNB is not optimized, the handover might occur relatively often. If this racing condition is not handled properly, the result will lead to bad user experiences for VoLTE as the rejection of the bearer related request may often lead to the VoLTE setup failure for QCI=1 bearer for voice.
In the 3GPP TS29.274(r9), the 3GPP has specified the proper cause value of "Temporarily rejected due to handover in progress" and in the 3GPP TS29.274(r11), "Temporarily rejected due to handover/TAU/RAU procedure in progress". This cause-id value is used by the MME rejecting the bearer related request when the handover results in the relocation of the Serving GW and/or MME. The PDN GW which initiated the bearer related request will be able to consider this error cause value to handle the rejection.
The following flow shows one example of how to handle the rejected bearer related request. In this flow, the Create Bearer Request is rejected by the MME. The PDN GW may retry the Create Bearer Request based on the operator's policy.
If there is no need of relocation of MME and/or Serving GW, the MME does not need to respond with the cause-id, rather it can perform store-and-forward way of message handling. In this case, the MME will temporarily store the message and wait for the handover to be completed and if it's done soon enough, the Create Bearer Request can be sent to the UE via the target eNB. How 'soon' is the 'soon enough' time is usually up to the operator's policy.
Red Mouse
This comment has been removed by the author.
ReplyDeleteYou mentioned that "PDN GW may retry the Create Bearer Request based on the operator's policy", I guess this is referring to the re-transmission from the P-GW as shown in the signalling flow. May I know this re-transmission is a feature or just a configuration setting to enable in P-GW? Thanks!
ReplyDelete