cnSGW-C supports Asynchronous BG-IPC call from GTPC-EP to cnSGW-C, by consuming less resources of the GTPC-EP pod.

For Async BG-IPC call, the GTPC-EP pod uses:

• SendRequestWithCallbackAsResponseWithRequestId API of app-infra to send request messages to the SGW-service.

• GetIPCRequestCallbackResponseWithRequestId API to receive response from the SGW-service.

The cnSGW-C supports the cache pod optimization to reduce the cache pod query at the GTPC endpoint.

The get affinity query is used to receive the affinity information in an outgoing request or response message toward the GTPC endpoint. With this optimization, the GTPC endpoint pod doesn't send the query to the cache pod for the upcoming request messages.

To receive this affinity information, an affinity query is used in an outgoing request or response message toward the GTPC endpoint. With this optimization, the GTPC endpoint pod doesn't send the query to the cache pod for the upcoming request messages.

In the previous releases, after the cnSGW-C sent out the DDN and received the MBR from the MME, the GTPC endpoint had to send the query to the cache pod to get affinity information. Later, the cnSGW-C used the affinity information so that an MBR can be forwarded to the correct service pod.

With this optimization, you can prevent the extra cache pod query.

SMF and cnSGW-C support domain-based user authorization using the Ops Center. To control the access on a per-user basis, use the TACACS protocol in Ops Center AAA. This protocol provides centralized validation of users who attempt to gain access to a router or NAS.

Configure the NETCONF Access Control (NACM) rules in the rule list. Then, map these rules in the Ops center configuration to map the group to appropriate operational authorization. Use the configurations that are based on the following criteria and products:

• With the NACM rules and SMF domain-based group, configure the Ops center to allow only access or update SMF-based configuration.

• With the NACM rules and cSGW-C domain-based group, configure the Ops center to allow only access or update cSGW-C-based configuration.

• With the NACM rules and cSGW-C domain-based group, configure the Ops center to allow only access or update CCG-based configuration.

Note	The NSO service account can access the entire configuration.

To support this feature configuration in Ops Center, the domain-based-services configuration is added in the TACACS security configuration. The TACACS flow change works in the following way:

• If you have configured the domain-based-services parameter, then the configured user name that is sent to the TACACS process, splits user ID into user ID and domain. The split character, which is a domain delimiter, is configured in domain-based-services. These split characters can be "@", "/", or "\" and are used in the following format to get the domain and user ID information.

  • @ — <user id>@<domain>

  • / — <domain>/<user id>

  • \ — <domain>\<user id>

• The TACACS authenticates and authorizes as per the existing flow. However, if the domain-based-services feature is enabled and TACACS authenticates and authorizes the user, following steps are added to the TACACS flow procedure.

  • If Network Services Orchestrator (NSO) logs in as the NSO service account, then that session receives a specific NACM group that you configured in domain-based-services nso-service-account group group-name . This functionally is the same as the way NSO works.

  • If the specified domain exists in the group mapping, then the NACM group that you configured in domain-based-services domain-service domain group group-name is applied.

  • If the user does not have a domain or the domain does not exist in the domain to group mapping, then no-domain NACM group that you configured in domain-based-services no-domain group group-name is applied. If the no-domain configuration does not exist, then the user value is rejected.

To enable this feature, you must configure the domain-based-services CLI command with the following options:

• NSO service account

• Domain service

• Domain delimiter

• No domain

To enable domain-based user authorization using Ops Center, use the following sample configuration:

config 
   tacacs-security domain-based-services [ domain-delimiter delimiter_option | domain-service domain_service_name [ group service_group_name  ] | no-domain group service_group_name | nso-service-account [ group service_group_name | id service_account_id ] ] 
   end 

NOTES:

• domain-based-services [ domain-delimiter delimiter_option | domain-service domain_service_name [ group service_group_name ] | no-domain group service_group_name | nso-service-account [ group service_group_name | id service_account_id ] ] : Configure the required domain-based-services value. The domain-based-services includes the following options:

  • domain-delimiter : Specify the delimiter to use to determine domain. This option is mandatory and allows the following values:

    • @—If domain-delimiter is "@", the user value is in the format: <user>@<domain>.

    • /—If domain-delimiter is "/", the user value is in the format: <domain>/<user>.

    • \—If domain-delimiter is "\", the user value is in the format: <domain>\<user>.

  • domain-service : Specify the list of domains and their group mapping. The key is the name of the domain and group is the group that is assigned to the domain. You must configure at least one option in this list.

  • no-domain : Specify the group that has no domain or if the domain is unavailable in the domain-service mapping, then this group is sent in the accept response.

  • nso-service-account : Specify the NSO service account that has the ID and group. If you configure this parameter, then you must configure the ID and group fields. The ID and group must have string values.

When large numbers of GTPC peers are connected with SMF or cnSGW-C, the performance of ETCD is impacted. Each peer is a considered as a record in the ETCD, and the timestamp is updated every 30 seconds for each peer. This causes continuous updates on ETCD and generates huge traffic that impacts the overall system performance.

The ETCD Peer Optimization feature facilitates optimization in peer management and enables reduced performance impact on ETCD.

This section describes how this feature works.

Instead of considering each peer as an ETCD record entry, several peers are grouped as a peer group based on the hash value of the IP address of each peer. This reduces the number of entries in ETCD. By default, a maximum of 200 peer groups can be created. For any changes related to a peer in a peer group:

• For a new peer, the peer group is persisted immediately in ETCD.

• For the change in timestamp for existing peers, the peer group is updated once every 3 seconds. This update:

  • Results in a cumulative group update for many peers that have undergone timestamp change within each peer group.

  • Reduces frequent updates to ETCD.

cnSGW-C provides an optimized GTPv2 encoder and decoder for:

• Modify Bearer Request and Response messages when the subscriber is moving to ACTIVE state after receiving the Modify Bearer Request message.

• Release Access Bearer Request and Response messages when the subscriber is moving to IDLE state on receiving the Release Access Bearer Request message.

The optimized GTPv2 encoder and decoder is provided for the following messages:

• Bearer Resource Command

• Change Notification Request and Response

• Create Bearer Request and Response

• Create IDFT Request and Response

• Create Session Request and Response

• Delete Bearer Command

• Delete Bearer Failure Indication

• Delete Bearer Request and Response

• Delete IDFT Request and Response

• Delete Session Request and Response

• Downlink Data Notification Acknowledgment

• Downlink Data Notification Failure Indication

• Download Datalink Notification Request

• Echo Request and Response

• Modify Bearer Request and Response

• Modify Bearer Command

• Modify Bearer Failure Indication

• Update Bearer Request and Response

To configure this feature on S11, S5, and S5e interfaces, use the following configuration:

config 
   instance instance-id instance_id 
      endpoint gtp  
         replicas replica_count 
         vip-ip ipv4_address  vip-port ipv4_port_number 
         vip-ipv6 ipv6_address  vip-ipv6-port ipv6_port_number  
         dual-stack-transport { true | false }  
         enable-go-encdec { true | false } 
         interface interface_name 
            enable-go-encdec { true | false } 
            end 

NOTES:

• enable-go-encdec { true | false } —Enable the Go language-based GTPv2 encoder and decoder for the interface.

• dual-stack-transport { true | false } —Enable the dual stack feature that allows you to specify IPv6 or IPv4 address. Specify true to enable this feature.

This section describes operations, administration, and maintenance support for this feature.

The GR Split feature enables handling the scaled GTP traffic and facilitates the optimal use of the CPU. The GR Split feature starts multiple active instances of GTPC-EP and performs traffic split which is based on GR instances. This helps in aiding the UDP proxy bypass feature.

This section describes how this feature works.

The UDP Proxy merge mode is a prerequisite for this feature.

• For a sunny-day scenario, RACK1 (GTPC-EP Active Instance-1) and RACK2 (GTPC-EP Active Instance-2) handle the traffic from GR-Instance-1 and GR Instance-2, respectively.

• For a rainy-day scenario, the GR Instance-1 (S11, S5E, S5) and GR Instance-2 (S11, S5E, S5) traffic splits between two GTPC-EP instances.

  In the rainy-day scenario, assuming RACK2 is down, RACK1 handles all the traffic for GR Instance-1 and GR Instance-2. With the GR Split implementation, the GTPC-EP Active Instance-1 handles GTP traffic for all the interfaces for GR Instance-1, and GTPC-EP Active Instance-2 handles all the GTP traffic for GR Instance-2.

The GTPC Interface Split feature enables splitting the GTPC endpoint based on the interface. cnSGW-C splits the GTPC pod into two interfaces, S11 and S5 which enables handling all GTPC incoming and outgoing traffic for S11 (SGW-Ingress), S5E (SGW-Egress), and S5 (SMF-Ingress).

This section describes how this feature works.

The GR Instance Split or UDP Proxy merge mode is a prerequisite for this feature.

This feature is disabled by default. While configuring this feature, provide separate internal and external VIP addresses for S11 and S5 GTPC endpoints, and deploy two GTPC-EP pods.

On configuring the feature, cnSGW-C sends the IPC call from SMF-service, SGW-service, and the Node Manager to the GTPC pod based on the GTPC interface and the GR instance ID.

The following are the recommendations for the GTPC interface split feature:

• CPU Core:

  • S5 Interface: 6

  • S11 Interface: 18

  • UDP Proxy: 2

• VIP Configuration: Separate internal and external VIP for S5 and S11 interfaces

• The Dispatcher configuration must be the same configuration as existing before upgrade.

The following diagram indicates the GTPC Interface Split pod layout.

To configure this feature, use the following configuration:

config 
   instance instance-id instance_id  
      endpoint gtp 
      interface s11 
         standalone true 
         cpu max-process cpu_core_value 
         internal-vip internal_vip_address 
         vip-ip ipv4_address vip-port ipv4_port_number 
         vip-ipv6 ipv6_address vip-ipv6-port ipv6_port_number 
         dual-stack-transport { true | false }  
         vip-interface vip_interface_value 
         exit 
      exit 
      interface s5 
         vip-ip ipv4_address vip-port ipv4_port_number 
         vip-ipv6 ipv6_address vip-ipv6-port ipv6_port_number 
         dual-stack-transport { true | false }  
         vip-interface vip_interface_value 
         end 

NOTES:

• standalone true : Configures the interface to run in standalone mode with a separate pod for the interface.

• cpu max-process cpu_core_value : Specify the CPU core value for the CPU for the interface. This sets the GO_MAX_PROCS parameter value for the pod.

• dual-stack-transport { true | false } —Enable the dual stack feature that allows you to specify IPv6 or IPv4 address. Specify true to enable this feature.

cnSGW-C supports optimization of Modify Bearer Request and Modify Bearer Response (MBR) call flows to reduce I/O operation, reduce transaction wait time, and improve performance in multi-PDN scenarios.

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.

To configure this feature, use the following sample configuration:

config 
   instance istance-id instance_id  
      endpoint endpoint_name 
         mbr-optimization [ enable { false | true } | mbr-cache-expiry mbr_cache | teid-cache-expiry teid_cache ] 
         exit 
      exit 
   exit 

NOTES:

• mbr-optimization [ enable { false | true } | mbr-cache-expiry mbr_cache | teid-cache-expiry teid_cache ] : Specify the MBR optimization configuration.

  • enable { false | true } : Enable or disable MBR optimization. Default: Disabled.

  • mbr-cache-expiry mbr_cache : Specify the MBR cache expiry time interval in milliseconds, as an integer from 1 millisecond to 6 seconds. Default: 50 milliseconds.

    Note that the value of mbr-cache-expiry can be changed during the runtime.

  • teid-cache-expiry teid_cache : Specify the TEID cache expiry time interval in milliseconds, as an integer from 1000 milliseconds to 1 hour. Default: 120000 milliseconds.

This section describes operations, administration, and maintenance support for the MBR Optimization feature.

cnSGW-C supports partial CDL update of the subscriber data. Partial CDL update helps in saving the CPU requirement in the CDL pod for processing the subscriber data.

With each transition of the subscriber from Idle-to-Active state and Active-to-Idle state, cnSGW-C updates only the following fields:

• eNodeB FTEID

• Subscriber state

• Bearer state

This section describes how this feature works.

cnSGW-C stores the update bearer information in the Flags database in the CDL.

cnSGW-C uses partial CDL update when the subscriber moves from:

• Active state to Idle state on receiving Release Access Bearer Request

• Idle state to Active state on receiving Modify Bearer Request

With partial CDL update, the session-state-flag displays the following value in the cdl show sessions summary slice-name <n> CLI output:

• sgw_active: when the session is Active

• sgw_inactive: when the session is Idle

The following is a sample output for an Active session:

cdl show sessions summary slice-name 1
message params: {session-summary cli session {0 100  0 [] 0 0 false 4096 [] []} 1}
session {
    primary-key 2#/#imsi-123456789012348
    unique-keys [ "2#/#16777229" ]
    non-unique-keys [ "2#/#id-index:1:0:32768" "2#/#id-value:16777229"
    "2#/#imsi:imsi-123456789012348" "2#/#msisdn:msisdn-223310101010101"
    "2#/#imei:imei-123456786666660" "2#/#upf:209.165.201.1"
    "2#/#upfEpKey:209.165.201.1:209.165.201.30" "2#/#s5s8Ipv4:209.165.202.129" "2#/#s11Ipv4:209.165.201.1"
    "2#/#namespace:sgw" ]
    flags [ byte-flag1:00:13:03:53:00:00:06:85:0A:01:01:1B session-state-flag:sgw_active ]
    map-id 1
    instance-id 1
    app-instance-id 1
    version 1
    create-time 2022-01-20 11:37:15.181259564 +0000 UTC
    last-updated-time 2022-01-20 11:37:15.703032336 +0000 UTC
    purge-on-eval false
    next-eval-time 2022-01-27 11:37:26 +0000 UTC
    session-types [ SGW:rat_type:EUTRAN ]
    data-size 925

The following is a sample output for an Idle session:

cdl show sessions summary slice-name 1
message params: {session-summary cli session {0 100  0 [] 0 0 false 4096 [] []} 1}
session {
    primary-key 2#/#imsi-123456789012348
    unique-keys [ "2#/#16777229" ]
    non-unique-keys [ "2#/#id-index:1:0:32768" "2#/#id-value:16777229"
    "2#/#imsi:imsi-123456789012348" "2#/#msisdn:msisdn-223310101010101"
    "2#/#imei:imei-123456786666660" "2#/#upf:209.165.201.1" "2#/#upfEpKey:209.165.201.1:209.165.201.30"
    "2#/#s5s8Ipv4:209.165.202.129" "2#/#s11Ipv4:209.165.201.1" "2#/#namespace:sgw" ]
    flags [ byte-flag1:00:25:00:55:00:65 session-state-flag:sgw_inactive ]
    map-id 1
    instance-id 1
    app-instance-id 1
    version 3
    create-time 2022-01-20 11:37:15.181259564 +0000 UTC
    last-updated-time 2022-01-20 11:37:18.102852792 +0000 UTC
    purge-on-eval false
    next-eval-time 2022-01-27 11:37:28 +0000 UTC
    session-types [ SGW:rat_type:EUTRAN ]
    data-size 1644

To configure this feature, use the following configuration:

config 
   cdl 
      datastore datastore_session_name 
         slot metrics report-idle-session-type { true | false } 
         end 

NOTES:

• slot metrics report-idle-session-type { true | false } —Enable or disable Idle or Active session count in CDL db_records_total.

This section describes operations, administration, and maintenance support for this feature.

In a live network deployment, due to some external events, all or most of the idle sessions become active at the same time. When idle sessions become active, the UPF sends the session report request with the report type DLDR to the cnSGW-C.

When the cnSGW-C receives the session report with the report type as DLDR, the cnSGW-C sends the DDN message to page UE. To turn the UE active, the MME initiates the paging procedure for the UE. If paging is successful, the MME initiates the service request Modify Bearer Request. On delivering data to the UE, the UE initiates the Release Access Bearer Request and turns idle. This call flow increases an overall load on the system. When the entire call flow occurs for all subscribers in a short time, there’s a huge process overhead on the system.

The PFCP Session Report with the DLDR Throttling Support feature enables the cnSGW-C to limit the number of session report requests that enter the system to prevent the process overload on the system.

This section describes how this feature works.

The cnSGW-C uses the app-infra feature for SBA overload control to throttle the incoming messages.

The system takes appropriate action for the incoming messages that are based on the interface-level threshold configuration. The incoming messages get added to different queues and they are processed based on the message-level priority configuration.

For more information on Overload Support, see the SMF Overload Support chapter, in the UCC 5G Session Management Function Configuration and Administration Guide.

You can exclude session reports for emergency call, voice calls, and empty calls from throttling.

To exclude these session reports, configure the ddn delay-exclude-arplist configuration in profile sgw. If the session report is received for one of the configured ARPs, the cnSGW-C omits that session report from the session report throttling.

To configure this feature, use the following configuration:

config 
    instance instance-id instance_id 
        endpoint pfcp 
            interface sxa 
                overload-control msg-type session-report 
                rate-limit rate_limit 
                queue-size queue_size 
                reject-threshold reject_threshold 
                pending-request pending_request 
                exit 
config 
    profile sgw sgw_name 
        ddn delay-exclude-arplist number_priorities 
        end 

NOTES:

• overload-control msg-type session-report —Configure the virtual message specifications for interface overload.

• rate-limit rate_limit —Specify the rate limit for the virtual queue.

• queue-size queue_size —Specify the packet count or capacity of each virtual queue.

• reject-threshold reject_threshold —Specify the limit to reject incoming messages when this threshold percentage of pending requests is reached.

• pending-request pending_request —Specify the pending requests count in the virtual queue.

• ddn delay-exclude-arplist number_priorities —Specify the priority-level for allocation and retention priorities [1-15] that must be excluded from delaying the DDN/Session report throttling.

This section describes operations, administration, and maintenance support for this feature.

The Resiliency Handling feature introduces a CLI-controlled framework to support the service pod recovery, when you observe a system fault or a reported crash. It helps in recovering one of the following service pods:

• sgw-service pod

• smf-service pod

• gtpc-ep pod

• protocol pod

• diameter-ep pod

These service pods are software modules containing the logic to handle several session messages. The service pods are fault-prone due to any one of the following or a combination of multiple scenarios:

• Complex call flow and collision handling

• Inconsistent session state

• Incorrect processing of inbound messages against the session state

• Unexpected and unhandled content in the inbound messages

Whenever you observe the system fault or a crash, the fault behavior results into a forced restart of the service pod. It impacts the ongoing transaction processing of other sessions. The crash reoccurs even after the pod restart.

To mitigate this risk, use the CLI-based framework with actions defined to clean up subscriber sessions or terminate the current processing.

This section describes how you can use the fault recovery framework to define actions for the crash. The framework allows you to define any of the following actions:

• Terminate—When a fault occurs, this action terminates the faulty transactions, and clears the subscriber session cache. It’s applicable for smf-service and sgw-service pods.

  Note	The pod doesn't get restarted. The database doesn't get cleared during this action.

• Cleanup—When a fault occurs, this action clears the faulty subscriber session and releases the call. It’s applicable for smf-service and sgw-service pods.

• Graceful reload—When a fault occurs, this action restarts the pod. It’s applicable for gtpc-ep, protocol, and diameter-ep pods. It handles the fault signals to clean up resources, such as the keepalive port and closes it early. It also allows the checkport script to detect the pod state and initiates the VIP switch processing for the corresponding pods.

• Reload—When the pod crashes, it initiates the reloading activity. It’s a default setting or value applicable for all the pods.

To configure this feature and to enable the system fault recovery, use the following sample configuration:

config 
    system-diagnostics { diameter |  gtp | pfcp | service | sgw-service } 
        fault 
            action { abort | cleanup { file-detail | interval | num | skip { ims | emergency | wps } } | graceful-Reload | reload } 
            end 

NOTES:

• system-diagnostics { diameter | gtp | pfcp | service | sgw-service } —Specify the required type of service pods for system diagnostics. The available pod options are diameter, gtp, pfcp, smf-service, and sgw-service.

• fault —Enables fault recovery while processing sessions.

• action { abort | cleanup | graceful-Reload | reload } —Specify one of the following actions to take on fault occurrence. The default action is reload.

  • abort —Deletes the faulty transaction and clears its session cache. The database doesn't get cleared.

    Note	It's an exclusive option to the smf-service pod.

  • cleanup { file-detail | interval | num | skip } —Enable the cleanup activity. It has the following selections to mitigate the fault action:

    • file-detail —Lists the file names with line numbers. It excludes the file name details from the recovery.

    • interval —Specifies the duration of the interval in minutes. This duration specifies the permissible interval within which it allows the maximum number of faults. Must be an integer in the range 1–3600.

    • num —Specifies the maximum number of tolerable faults in an interval. Must be an integer in the range 0–50.

    • skip { ims | emergency | wps } —Enable the skip cleanup of a subscriber session for an active voice call, or the WPS, or an emergency call.

      • To detect the active voice calls, use the following command:

        profile dnn dnn_name ims mark qci qos_class_id 

      • When you enable the skip cleanup configuration, the SMF deletes the faulty transaction, and clears its session cache.

      • When a fault occurs during the session setup or the release state, the SMF performs the following:

        – Deletes the transactions on the session end.

        – Overrides the configured fault action during these states.

        – Clears the session cache and database entries for the faulty transaction.

      • It allows the dynamic configuration change.

    Note	It's an exclusive option to smf-service and sgw-service pods.

  • graceful-Reload —Specify the option to gracefully reload the pod. The service pod handles fault signals to clean up resources like the keepalive port and continues with crash processing (pod restart processing).

    Note	It's an exclusive option to diameter-ep, gtpc-ep, and protocol service pods.

  • reload —Reloads the pod, when it crashes due to a faulty behavior. It's an option applicable to all the service pods. It’s also the default option.

This section describes operations, administration, and maintenance support for this feature.

cnSGW-C supports inbound roaming. When inbound roaming is enabled, cnSGW-C communicates with remote PGW which is located in the roamer home network.

cnSGW-C generates Echo Request messages towards the roaming peers and detects path failure, thereby handling echo request messages from the roaming peers.

This section describes how this feature works.

cnSGW-C uses subscriber policy and operator policy to categorize peer as a roamer or a home peer. cnSGW-C applies the following functionalities to the roaming peer:

• cnSGW-C responds immediately to the echo request message received from the roaming peer. If the restart counter value changes in the echo request, cnSGW-C doesn't detect path failure towards the peer.

• cnSGW-C continues to generate echo request towards the roaming peer after reaching the configured echo interval. If the restart counter value changes in the echo response, cnSGW-C detects path failure towards the peer.

• If the restart counter value changes in the first Create Session Response message and the SGW Relocation Modify Bearer Response message, cnSGW-C detects path failure towards the peer.

• cnSGW-C doesn't update the last activity time of roaming when it receives echo request from the roaming peer.

• In the NodeMgr pod, the variable ROAMING_PEER_ECHO_MODULATOR controls the echo request generation towards the roaming peer. The default value for ROAMING_PEER_ECHO_MODULATOR is 3. cnSGW-C generates echo request towards the roaming peer after reaching ROAMING_PEER_ECHO_MODULATOR * Echo Interval.

  For example, if the ROAMING_PEER_ECHO_MODULATOR is 3, and the Echo Interval is 60, the cnSGW-C generates the Echo Request after 180 seconds. Similarly, if the ROAMING_PEER_ECHO_MODULATOR is 0, cnSGW-C doesn't generate the echo request towards the roaming peer.

• In the GTPC-EP pod, the variable GTPC_UPDATE_LAST_MSG_RECV_TIME_AFTER controls the last activity time updates. The default value for this variable is 30 seconds. The cnSGW-C updates the last activity time for the peer after 30 seconds. You can increase this value to reduce the last activity time update notifications towards the NodeMgr.

Configuring this feature involves the following steps:

• Configure the operator policy with the roaming status as roamer, and associate the operator policy with the subscriber policy to identify the operator as roaming peer. For more information, see Configuring the Operator Policy and Subscriber Policy.

• Configure the default gateway to be used, while adding the BGP route dynamically. For more information, see Configuring the Default Gateway.

This section describes operations, administration, and maintenance support for this feature.

The UDP proxy microservices provide UDP transport termination for protocols (PFCP, GTPC, and RADIUS) that require UDP protocol as the transport layer protocol. The UDP proxy provides user space packet forwarding and IPC communication to protocol microservices. It uses host networking for source IP address observability and operates in Active-Standby mode.

Multiple protocol microservices depend on UDP proxy for UDP transport. Therefore, UDP proxy is a scaling bottleneck. A surge of messages can lead to packet drop.

The incoming and outgoing messages use the UDP proxy pod for forwarding messages. With minimal packet processing, the UDP proxy forwards the messages to the GTPC-EP pod. This requires the IPC communication for message forwarding, along with marshal or unmarshal of the packet.

The UDP proxy functionality merges into the respective protocol microservice to mitigate the scaling bottleneck. The protocol pod receives the messages directly, and avoids forwarding the messages and IPC communication.

The UDP proxy bypass improves the CPU usage by reducing one hop across microservices in the signaling path. cnSGW-C supports UDP proxy bypass for the PFCP and GTPC protocols.