Access Bearer Release Support

Feature Summary and Revision History

Summary Data

Table 1. Summary Data

Applicable Product(s) or Functional Area

cnSGW-C

Applicable Platform(s)

SMI

Feature Default Setting

Enabled - Always-on

Related Documentation

Not Applicable

Revision History

Table 2. Revision History

Revision Details

Release

First introduced.

2020.03.0

Feature Description

cnSGW-C supports the handling of the Release Access Bearer (RAB) request procedure. It’s a UE-level message. In multiple PDN scenarios, the MME sends only one RAB message, which applies to all the PDNs.

cnSGW-C brings all the bearers of all the PDNs to the IDLE state.

How it Works

This section describes how this feature works.

cnSGW-C sends the Sx Modification Request message per PDN to the corresponding User Plane. After receiving the Sx Modification response message from all user planes (for all PDNs), cnSGW-C sends the response message to MME.

cnSGW-C updates the state as IDLE for all the bearers in CDL.

Call Flows

This section describes the key call flow for the Access Bearer Release Support feature.

Release Access Bearer (Active to IDLE Transaction) Call Flow

This section describes the Release Access Bearer call flow.

Figure 1. Release Access Bearer (Active to IDLE Transaction) Call Flow
Table 3. Release Access Bearer (Active to IDLE Transaction) Call Flow Description

Step

Description

1

MME sends Release Access Bearer (RAB) request to S11-GTP-EP to release all S1-U bearers for the UE.

2

S11-GTP EP decodes the received UDP message and converts it into gRPC. The converted gRPC message then sent to the SGW-Service pod, using the TEID value, which can handle this UE session.

SGW-Service pod performs the following activities:

  • Finds out Subscriber Context using local ingress TEID

  • Validates the RAB request content

  • Moves UE to the IDLE state

  • Builds the Sx Modify request message with the downlink apply action as DROP, to drop all downlink packets at SGW-U

3

 SGW-Service pod sends the Sx Mod request message using the background IPC async call for PDN1 to PFCP-EP.

4

PFCP-EP forwards the Sx Modify Request (PDN1) message to UPF1 through the UDP proxy.

UPF1 processes the Sx Modify Request (PDN1) message.

5

SGW-Service pod sends the Sx Modify Request message using the background IPC async call for PDN2.

PFCP-EP forwards the Sx Modify Request (PDN2) message to UPF2 through the UDP proxy.

6

UPF2 processes the Sx Modify Request (PDN2) message.

7

UPF1 sends the Sx Modify response (PDN1) message to PFCP-EP.

8

PFCP-EP sends the Async Sx Modify response message to cnSGW-C service for PDN1.

SGW-Service pod waits for the PDN2 Sx Modify response message.

9

UPF2 sends the Sx Modify response (PDN2) message to PFCP-EP.

10

PFCP-EP sends the Async Sx Modify response message to cnSGW-C service for PDN2.

11

The SGW-Service pod sends the following, after receiving the PDN (PDN1, PDN2) responses:

  • RAB response message to S11-GTP-EP using the gRPC protocol.

  • Updates to the CDL module

12

SGW-Service pod sends Update Subscriber Context state to CDL, which moves all the bearers to the IDLE state.

CDL module updates the information in the database.

13

S11-GTP-EP forwards the RAB response message to MME.

MME process the RAB response message.