How it Works

This section describes how this feature works.

Perform the following steps to implement this feature.

  1. Identify the deployment type of SMF and cnSGW-C.

    To identify the deployment type, the SMF or cnSGW-C compares the target GTPC peer IP address of the message with the locally configured IP address of S5e or S5 interface for the concerned GR instance. The SMF or cnSGW-C marks the subscriber session as collocated service based on the comparison result.

  2. Identify the target service pod

    SMF uses session affinity in cnSGW namespace based on TEID, which is derived from Common ID to appropriately route the message towards cnSGW service pod instance.

  3. Route the messages to the appropriate peers based on the identified deployment type and target service pod.

    Interservice pod communication uses the existing framework along with protocol buffer to carry the signaling message content.

    The interservice communication between SMF and cnSGW-C happens with the following exceptions:

    • GTPC messages cannot be captured using the packet sniffer tool and monitor subscriber command.

    • Path management is not performed for collocated GTPC peers.

    • GTPC message level metrics (at GTPC endpoint) will not be pegged for interservice GTPC messages as GTPC endpoint is bypassed for such messages.

    • Existing interservice metrics will be pegged for interservice messages.

    • UBR and DBR initiated on Command Messages follow the existing message flow path. That is, the SMF sends the command messages to cnSGW service through gtpc-ep pod.