Delete Dedicated Bearer Procedure Failure Handling
This section covers the PGW-initiated dedicated bearer deletion procedure failure scenarios.
The following table summarizes cnSGW-C behavior during different stages of the call processing for various failure types:
Note | During processing of delete dedicated Bearer Request and Response if SGW receives Context Not Found from peer (MME/UP), it deletes the PDN without performing any signaling towards the peer which sent this cause. |
Scenarios |
SGW-Service Behavior |
Signaling |
Output |
---|---|---|---|
Delete Bearer Request advance validation failure |
Send failure/No Signaling over Sx/MME |
Negative - Delete Bearer Response to PGW |
Dedicated Bearer is not deleted. |
Partial Accepted: Delete Bearer Request received with multiple EBI’s, where:
|
Continue DBR Procedure and delete all existing bearers for which Delete Bearer Request is received. S11 Delete Bearer Request should carry only existing EBIs information Sx Session Modification Request should carry existing EBIs information (Remove Traffic Endpoint) |
S5 Delete Bearer Response (Cause = Partially Accepted ) |
S5 Delete Bearer Response where message level cause is Partially Accepted and bearer level cause is:
CDL is updated (Remove all existing bearers) |
Sx Session Modify to set action as DROP |
Skip failure and continue |
S5 Delete Bearer Response (Cause = Accepted) |
Skip failure and continue with DBR Procedure Call Flow: Yes S5 Delete Bearer Response (Cause = Accepted) CDL is updated |
S11 Delete Bearer Request Failure |
Skip failure and continue |
S5 Delete Bearer Response (Cause) = Accepted |
Skip failure and continue with DBR Procedure Call Flow: Yes CDL is updated |
Sx Session Modify Request failure (Request to remove traffic endpoint on UP) |
Skip failure and continue |
S5 Delete Bearer Response (Cause = Accepted) |
Skip failure and continue with DBR Procedure Call Flow: Yes CDL is updated |