Project

General

Profile

Actions

Bug #5212

open

apparently T3193 is by default not set to its defined default value

Added by neels about 1 year ago. Updated 11 months ago.

Status:
New
Priority:
Low
Assignee:
Target version:
-
Start date:
08/12/2021
Due date:
% Done:

0%

Spec Reference:

Description

When I run osmo-pcu and launch a ttcn3 test (PCU_Tests.TC_mt_ping_pong) so that a BTS is present,
'show bts-timers' lists:

OsmoPCU# show bts-timer
BTS0:
...
T3193 = 1600 ms Reuse of TFI(s) after reception of final PACKET DOWNLINK ACK/NACK from MS for TBF (default: 100 ms)
...

Notice that T3193 is set to 1600 ms, although its default says 100 ms.
I looked for anything that might alter the timeout in the ttcn3 code, but could not find anything.

Actions #1

Updated by pespin 12 months ago

It is set by ts_PCUIF_INFO_default, so osmo-bts (TTCN3) is setting it through PCUIF:

t3193_10ms := 160,

Actions #2

Updated by pespin 12 months ago

  • Assignee set to pespin

It's been 100ms since at least:

commit 28f160e76c3c53029bc6e8de101b2d7ee26eea16
Author: Pau Espin Pedrol <pespin@sysmocom.de>
Date:   Thu Sep 5 14:48:35 2019 +0200

And also even a lot prior to that it was already defaulting to 100ms:

commit dfa563cd3bba9b6214289bc63c84b00f1f7676cd
Author: Andreas Eversberg <jolly@eversberg.eu>
Date:   Fri Jul 6 08:13:59 2012 +0200

    RLC/MAC process makes use from attributes, received from PCU socket

    For OpenBTS interface and BSSGP, fixed values are still used.

And being 1600 in TTCN3 is there since at least:

commit e1fd916b2110e0282f3d9320958c27876b7d91e1
Author: Harald Welte <laforge@gnumonks.org>
Date:   Mon Feb 18 19:47:53 2019 +0100

The problem seems to be that it's defined as 100ms by default in osmo-pcu since ever, but it is also defined as 1600ms in osmo-bts since ever (osmo-bts passes it to osmo-pcu throuygh PCUIF):

src/common/bts.c
159:            [RLC_T3193] = 160, /* 10ms */src/common/pcu_sock.c
289:    info_ind->t3193_10ms = rlcc->parameter[RLC_T3193];

Same in osmo-bsc:

src/osmo-bsc/bts_ipaccess_nanobts_omlattr.c
169:    buf[3] = 160;    /* T3193 (units of 10ms) */

src/osmo-bsc/bts.c
131:            [RLC_T3193] = 160, /* 10ms */

src/osmo-bsc/pcu_sock.c
167:    info_ind->t3193_10ms = rlcc->parameter[RLC_T3193];

So we need to find which is actually the best default value there, either 1600ms or 100ms (or some other value), and set it consistently everywhere.

Actions #3

Updated by pespin 11 months ago

TS 44.060 Table 13.2.1 "Specification of timers used in GPRS on the Network side" states in "typical value" column:

Greater than T3192

Also in description:

This timer is used on the network side to define when timer T3192 on the mobile station side has 
surely expired so that the TFI can be reused

Then, for T3192, it says in the same column:

assigned in  system  information

So specs are not really useful here at first glance.

Actions #4

Updated by pespin 11 months ago

T3192 seems to be defined as 1500 in osmo-bsc:

osmo-bsc/src/osmo-bsc/system_information.c
1214:            .t3192            = 1500,

So at least using T3193=1600 seems to accomplish being greater than T3192.

Actions #5

Updated by pespin 11 months ago

This one suggests 500ms as default for T3192:
https://rfmw.em.keysight.com/rfcomms/refdocs/gsm/gprsla_gen_bse_config_timer.html

According to google, https://www.scribd.com/document/139651205/GPRS-Parameters suggests:

ter terrestrial links in the serving cell:i) T3192 = 1000 ms if ...

Indeed 1500 as default looks like a lot to me. It is indeed the maximum value it can take according to the documentation above as well as encode_t3192() in libosmocore.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)