Project

General

Profile

Actions

Bug #5485

closed

Make T3-RESPONSE and N3-REQUESTS configurable

Added by pespin about 2 years ago. Updated 12 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
libgtp
Target version:
-
Start date:
03/07/2022
Due date:
% Done:

100%

Spec Reference:

Description

Right now, those are hardcoded in libgtp gtp.c:

/* According to section 14.2 of 3GPP TS 29.006 version 6.9.0 */
#define N3_REQUESTS    5

#define T3_REQUEST    3

According to TS 29.060 7.6 Reliable Delivery of Signalling Messages:

The T3-RESPONSE timer shall be started when a signalling request message (for which a response has been defined) is
sent. A signalling message request or response has probably been lost if a response has not been received before the
T3-RESPONSE timer expires. The request is then retransmitted if the total number of request attempts is less than
N3-REQUESTS times. The timer shall be implemented in the control plane application as well as user plane application
for Echo Request / Echo Response. The wait time for a response (T3-RESPONSE timer value) and the number of
retries (N3-REQUESTS) shall be configurable per procedure
. The total wait time shall be shorter than the MS wait time
between retries of Attach and RA Update messages.

So according to spec it should be configurable. When it says per "per procedure", I guess it means by message type (req+resp), but I think we are fine at least having them as 1 configurable timer used for all messages.
This would be helpful for instance in TTCN3 tests, were we ideally need to wait for the retransmit resp queue (duplicate req detector) in order to avoid falling in the situation where same seqnum is reused in different tests.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)