How it Works

S-GW service, GTPC-EP, and SMF protocol are the primary nodes involved in the the retransmission and timeout handling.

The SGW-serice is responsible for:

  • Handling the timeout event from GTPC-EP and SMF protocol

  • Ignoring the inbound retransmitted message

The GTPC-EP and SMF protocol is responsible for:

  • Retransmission and timeout handling

  • Reading the N3/T3 configuration

  • Updating the N3/T3 on configuration change

The retransmission and timeout handling is applicable for both outbound and inbound messages.

Outbound Message

To supports retransmission and timeout of outgoing GTP and PFCP messages, you must configure an interface specific N3 (maximum number of retries) and T3 (retransmission timeout) timer values in accordance to network response time/delay time.

The MME/S11 peers can have different retransmission timeout as compared to PGW/S5 or UPF/SXA.

The GTPC-EP/Protocol pod retries the outgoing request messages based on configured N3T3 values until the response is received or N3T3 is exhausted. In case of N3T3 gets exhausted, the GTPC-EP/Protocol pod sends the failure response with cause peer no response to service pod to indicate that no response has been received for outgoing request message.

Inbound Message

At each N4 and GTP endpoint, there’s a set of queues for incoming and outgoing traffic. Each queue has a dispatcher thread running that pulls the message from the queue. It dispatches the message to the application for further processing.

Each dispatcher references a retransmission cache to check if the incoming request is already in service. It further performs the following actions:

  • If it’s a retry request, the dispatcher drops the incoming request.

  • If the retransmission cache reaches the threshold for outstanding requests, the incoming request is dropped.

Each dispatcher has a separate retransmission cache. This cache is also updated with the response of the request sent. It’s for the retransmission request received after the response is sent.