How it Works
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.