How it Works

This section provides information on how the resiliency and HA can be achieved.

The cnSGW-C enables inter-pod communication during the pod failure or restart.

During graceful pod restart:

  • Ongoing processing is not impacted.

  • New messages are not sent to the pod through Kubernetes service.

  • Messages with session affinity continue to be received by the pod.

  • Existing call flow expected to complete within 30 seconds.

After pod restart:

  • All Prometheus metrics of the pod are reset.

  • When internal diagnostics is green, the pod status changes to Ready.

  • Pod is ready to process the new messages.

When the cnSGW-C VM reboots or the VM is unavailable:

  • All pods on the VM are lost.

  • Pods on the other available VM continue processing, thus providing high availability.

  • VIP, if present, is switched to the other available node.

  • It takes about 5 minutes of the node unreachability for Kubernetes to detect the node as down.

  • Pods on the node are thereafter not discoverable through Kubernetes service.

After the pod restarts, pods on the VM are scheduled one after another. This operation is similar to the pod restart.

During the VIP and VM reboot, virtual IP is associated with a single VM. UDP proxy binds to N4 VIP address for communication with UPF. UDP proxy binds to S5 VIP address for communication with cnSGW-C.

Reboot of VM with active VIP causes VIP to switch to the other protocol VM. The active UDP proxy failure causes VIP to switch to other protocol VM.

Before the Subscriber Microservices Infrastructure (SMI) handles the VIP monitoring and switchover, make sure that appropriate VIP configuration is available in the SMI deployer. Also, check if the port is set to 28000 and the host priority is equal.