How it Works

This section describes how this feature works.

The following functions explain the optimization of MBR call flows:

  • To reduce I/O operations, cnSGW-C combines all Modify Bearer Requests towards SGW-service into a single GRPC call, and Sx Modify Requests from SGW-service pod to protocol pod in a single GRPC call.

  • To reduce transaction wait time in GTPC-EP, cnSGW-C sends Modify Bearer Response immediately from GTPC-EP (except last MBR) after receiving Modify Bearer Request.

    GTPC-EP combines all Modify Bearer Requests in a single Modify Bearer Request List message and sends to SGW-service.

  • SGW-service combines all Modify Bearer Responses into a single Modify Bearer Response List message and sends to GTPC-EP.

    SGW-service combines all Sx Modify Requests towards UPF into a single Sx Modify Request List message and sends to protocol pod. The protocol pod sends individual Sx Modify Requests to UPF.

  • The protocol pod waits for all Sx Modify Responses from UPF and combines them into a single Sx Modify Response List and sends it to SGW-service.

  • In non-merged mode, UDP proxy maintains the local TEID and remote TEID cache information. In merged mode, GTPC-EP maintains the local TEID and remote TEID cache information.

  • If GTPC-EP does not find the TEID cache entry for the received Modify Bearer Request, the Modify Bearer Request will be forwarded to the SGW-service immediately.

    If all expected Modify Bearer Requests are not received within the MBR cache expiry, only the Modify Bearer Requests that are received will be sent to the SGW-service.