describes several collision handling scenarios for the S-GW and P-GW.
The S-GW processes
additional collisions at the S-GW ingress interface for:
Create Bearer Request or Update Bearer Request messages with Inter-MME/Inter-RAT Modify Bearer Request messages (with and
without a ULI change).
Downlink Data Notification (DDN) message with Create Bearer Request or Update Bearer Request.
The S-GW behavior to
handle these collision scenarios are as follows:
A CBReq and MBReq [(Inter MME/Inter RAT (with or without ULI change)] collision at the S-GW ingress interface results in the
messages being handled in parallel. The CBReq will wait for a Create Bearer Response (CBRsp) from the peer. Additionally,
an MBReq is sent in parallel to the P-GW.
An UBReq and MBReq [(Inter MME/Inter RAT (with or without a ULI change)] collision at the SGW ingress interface is handled
with a suspend and resume procedure. The UBReq would be suspended and the MBReq would be processed. Once the MBRsp is sent
to the peer from the SGW ingress interface, the UBReq procedure is resumed.
Create Bearer Request (CBR) or Update Bearer Request (UBR) with Downlink Data Notification (DDN) messages are handled parallel.
As a result, no S-GW
initiated Cause Code message 110 (Temporarily rejected due to handover
procedure in progress) will be seen as a part of such collisions. Collisions
will be handled in parallel.
The following GTP-C
example collision handling scenarios may also be seen on the P-GW:
The P-GW enables
operators to configure the behavior of the P-GW for collision handling of the
Delete Bearer command (DBcmd) message when the Modify Bearer Request (MBreq)
message for the default bearer is pending at the P-GW.
There are three
CLI-controlled options to handle the collision between the DBCmd and MBReq
Queue the DBcmd message when the MBreq message is pending. The advantage of this option is that the DBCmd message is not lost
for most of the collisions. It will remain on the P-GW until the MBRsp is sent out.
Drop the DBCmd message when the MBreq message is pending. Note that with this option the S-GW must retry the DBCmd.
Use pre-StarOS 19.0 behavior: abort the MBreq message and handle the DBcmd message. The advantage of this option is that it
provides backward compatibility if the operator wants to retain pre-StarOS 19.0 functionality.
The CLI command
handling provides more flexibility in configuring the handling of
the DBCmd message and MBReq message collision scenario. Also refer to
Configuring DBcmd Message Behavior
in this document for instructions on how to configure the behavior for this
collision handling scenario.
Processing; Handling CBRsp:
The P-GW/S-GW handles the following example collision scenario:
The node queues the
CBRsp message and feeds the CBRsp message to the P-GW/S-GW session manager when
the MBRsp is sent out. As a result, operators will see no retransmission of
CBRsp messages from the MME.
Handling UBrsp when
Transaction is Suspended:
handles the following example collision scenario:
When the P-GW/S-GW
receives an UBRsp message, then the P-GW/S-GW handles the UBRsp message for the
suspended transaction. As a result, The UBRsp message will be buffered until
the MBRsp message is sent out.
Collision Handling of MBR over MBR for Drop and Retry
To avoid collision over Modify bearer request (mbreq) message over mbreq, the MME supports collision of MBR over MBR Drop
and Retry functionality through a
mbreq-over-mbreq drop CLI configuration under the egtp-service. The following functions occur:
MME sends modify bearer request when service request modify bearer request is in pending state
S-GW drops the E-RAB procedure modify bearer request message
MME retries the dropped MBR until first MBR response.