Project

General

Profile

Actions

Bug #5335

open

osmo-bsc: Add VTY commands to configure T3.. and N3.. timers counters for gprs

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

Status:
In Progress
Priority:
Normal
Assignee:
Category:
PCU Interface
Target version:
-
Start date:
11/30/2021
Due date:
% Done:

70%

Spec Reference:
Tags:

Description

nanobts_attr_cell_get() in src/osmo-bsc/bts_ipaccess_nanobts_omlattr.c:

    /* all timers in seconds, unless otherwise stated */
    buf[0] = 20;    /* T3142 */
    buf[1] = 5;    /* T3169 */
    buf[2] = 5;    /* T3191 */
    buf[3] = 160;    /* T3193 (units of 10ms) */
    buf[4] = 5;    /* T3195 */
    buf[5] = 10;    /* N3101 */
    buf[6] = 4;    /* N3103 */
    buf[7] = 8;    /* N3105 */
    buf[8] = 15;    /* RLC CV countdown */

Similarly for the NS side of the PCU in nanobts_attr_nse_get():

    /* all timers in seconds */
    buf[0] = 3;    /* blockimg timer (T1) */
    buf[1] = 3;    /* blocking retries */
    buf[2] = 3;    /* unblocking retries */
    buf[3] = 3;    /* reset timer (T2) */
    buf[4] = 3;    /* reset retries */
    buf[5] = 10;    /* suspend timer (T3) in 100ms */
    buf[6] = 3;    /* suspend retries */
    buf[7] = 10;    /* resume timer (T4) in 100ms */
    buf[8] = 3;    /* resume retries */
    buf[9] = 10;    /* capability update timer (T5) */
    buf[10] = 3;    /* capability update retries */

Some of those are already being applied by osmo-pcu from what it receives in PCUIF INFO.ind, see T_defs_bts in osmo-pcu.git/src/src/bts.cpp and pcu_rx_info_ind().


Related issues

Related to libosmocore - Bug #5915: gprs: ns2: convert timers into osmo-timersNewjolly02/20/2023

Actions
Related to OsmoBSC - Bug #5991: Forward TSNS-PROV bsc->[bts->]pcuNewjolly03/31/2023

Actions
Actions #1

Updated by laforge over 1 year ago

  • Tags set to simple
  • Status changed from New to Feedback

This could be somethin for @arehbein to look into, but I think the description of the task needs to be much more verbose. I think even for somebody as experience as me it is rather ... brief.

Actions #2

Updated by pespin over 1 year ago

Hi, sorry for not providing more documentation here, since most of the task is really looking at the details of the counters and I was probably busy with other stuff when I wrote this ticket, probably as a reminder to avoid forgetting about it.

[A] The first group of counters is defined in TS 44.060 section 13 "Timers and counters" [1]. They are used by osmo-pcu to control retransmissions, timeouts, etc towards the MS in GPRS (RLC/MAC). They are to be configured in osmo-bsc VTY (currently hardcoded) and they are already being forwarded osmo-bsc=>osmo-bts=>osmo-pcu. The array is documented in osmo-bts/doc/manuals/abis/oml.adoc NM_ATT_IPACC_RLC_CFG

The array fields actually have an enum describing where each timer position is. This enum is actually duplicated in osmo-bsc.git and osmo-bts.git, and should be moved to a shared place (libosmo-abis or libosmocore):

enum gprs_rlc_par {
    RLC_T3142,
    RLC_T3169,
    RLC_T3191,
    RLC_T3193,
    RLC_T3195,
    RLC_N3101,
    RLC_N3103,
    RLC_N3105,
    CV_COUNTDOWN,
    T_DL_TBF_EXT,    /* ms */
    T_UL_TBF_EXT,    /* ms */
    _NUM_RLC_PAR
};

The values are initialized per-bts with default values in osmo-bsc.git gsm_bts_alloc():

    memcpy(&bts->gprs.cell.rlc_cfg, &rlc_cfg_default,
        sizeof(bts->gprs.cell.rlc_cfg));

The enum above and is not used in osmo-bsc.git nanobts_gen_set_cell_attr() but it is used other places already, which means nanobts_gen_set_cell_attr() should be updated to make use of the enum, and actually forward the values set in bts->gprs.cell.rlc_cfg rather than re-applyig hardcoded values.

[B] The second group of counters/timers follows similar context as the first one: hardcoded (to be configurable) in osmo-bsc and forwarded to osmo-pcu, which then uses them when speaking against osmo-sgsn. The array is documented in osmo-bts/doc/manuals/abis/oml.adoc "NM_ATT_IPACC_BSSGP_CFG".
The timers are probably specificed in TS 48.108 [2].
If there's no enum for this group of timers, it may make sense to add one, like in group A.
This group seems to already have VTY commands, see osmo-bsc.git cfg_bts_gprs_cell_timer() and cfg_bts_gprs_ns_timer(), but the values we send over OML don't seem to be taking the VTY config into account, instead it sends hardcoded stuff, see osmo-bsc.git nanobts_gen_set_nse_attr() (it actually memcpies them afterwards, so I think we can simply drop the hardocded sett part which is anyways erased).

Both groups of values mentioned above (A and B) follow the following path:
  • They are currently hardcoded in osmo-bsc.
  • osmo-bsc sends the values to osmo-bts through OML during BTS startup:
    • Set Atrributes on NSE object, see osmo-bsc.git nanobts_gen_set_nse_attr().
    • Set Atributes of CELL object, see oml_ipa_mo_set_attr_cell
  • osmo-bts receives the values and then forwards the values to osmo-pcu through the PCUIF (unix socket) interface using the INFO.ind primitive.
    • oml_ipa_mo_set_attr_nse()
    • oml_ipa_mo_set_attr_cell()
    • pcu_tx_info_ind()
  • osmo-pcu finally applies those values
    • see T_defs_bts in osmo-pcu.git/src/src/bts.cpp and pcu_rx_info_ind())

So in general the path to set the values is already there, the problem is that those values are currently hardcoded in osmo-bsc and it'd be nice to have them configurable through VTY in osmo-bsc, similar to what we already have for other timers.

Feel free to reach me here or by IM if you need support with any part of this.

[1] https://www.etsi.org/deliver/etsi_ts/144000_144099/144060/09.03.00_60/ts_144060v090300p.pdf
[2] https://www.etsi.org/deliver/etsi_ts/148000_148099/148018/16.00.00_60/ts_148018v160000p.pdf

Actions #3

Updated by pespin over 1 year ago

  • Assignee changed from pespin to laforge
Actions #4

Updated by arehbein about 1 year ago

  • Status changed from Feedback to In Progress
  • Assignee changed from laforge to arehbein
Actions #5

Updated by arehbein about 1 year ago

pespin wrote in #note-2:

The array fields actually have an enum describing where each timer position is. This enum is actually duplicated in osmo-bsc.git and osmo-bts.git, and should be moved to a shared place (libosmo-abis or libosmocore):
[...]

Hi pespin ,

thank you for the detailed information. I have pushed patches to move the enum defs.
I set the patches to WIP, because I'm not sure what the best procedure is for integrating these changes, since all patches have to be merged at the same time in different projects at the time of compilation (otherwise compilation will break I think due to either missing enum defs or redefinition of enums).

See topic OS_5335 for the patch moving the enums (again, it's in WIP, so adjust your filter).

Actions #6

Updated by arehbein about 1 year ago

  • % Done changed from 0 to 20
Actions #7

Updated by arehbein about 1 year ago

  • % Done changed from 20 to 40

Hi pespin,

am I overlooking something or is the osmo-pcu indeed not yet processing the arrays cell_timer and nse_timer received from the osmo-bts? If I look for the array names in the pcu code, all I find is debug logs.

osmo-pcu$ ag cell_timer
include/osmocom/pcu/pcuif_proto.h
160:    uint8_t        cell_timer[11];

src/pcu_l1_if.cpp
760:    LOGP(DL1IF, LOGL_DEBUG, " cell_timer=%d %d %d %d %d %d %d %d %d %d " 
762:        info_ind->cell_timer[0], info_ind->cell_timer[1],
763:        info_ind->cell_timer[2], info_ind->cell_timer[3],
764:        info_ind->cell_timer[4], info_ind->cell_timer[5],
765:        info_ind->cell_timer[6], info_ind->cell_timer[7],
766:        info_ind->cell_timer[8], info_ind->cell_timer[9],
767:        info_ind->cell_timer[10]);
osmo-pcu$ ag nse_timer
include/osmocom/pcu/pcuif_proto.h
159:    uint8_t        nse_timer[7];

src/pcu_l1_if.cpp
755:    LOGP(DL1IF, LOGL_DEBUG, " nse_timer=%d %d %d %d %d %d %d\n",
756:        info_ind->nse_timer[0], info_ind->nse_timer[1],
757:        info_ind->nse_timer[2], info_ind->nse_timer[3],
758:        info_ind->nse_timer[4], info_ind->nse_timer[5],
759:        info_ind->nse_timer[6]);
Actions #8

Updated by pespin about 1 year ago

Hi @arehbein ,

Indeed, omo-pcu is only using so far the timers in what I described as "[A]", aka RLC/MAC timers (TS 44.060):

static int pcu_rx_info_ind(struct gprs_rlcmac_bts *bts, const struct gsm_pcu_if_info_ind *info_ind)
{
    if (info_ind->t3142) { /* if timer values are set */
        osmo_tdef_set(bts->T_defs_bts, 3142, info_ind->t3142, OSMO_TDEF_S);
        osmo_tdef_set(bts->T_defs_bts, 3169, info_ind->t3169, OSMO_TDEF_S);
        osmo_tdef_set(bts->T_defs_bts, 3191, info_ind->t3191, OSMO_TDEF_S);
        osmo_tdef_set(bts->T_defs_bts, 3193, info_ind->t3193_10ms * 10, OSMO_TDEF_MS);
        osmo_tdef_set(bts->T_defs_bts, 3195, info_ind->t3195, OSMO_TDEF_S);
        bts->n3101 = info_ind->n3101;
        bts->n3103 = info_ind->n3103;
        bts->n3105 = info_ind->n3105;
    }

The timers in the "[B]" group, which are basically NS / BSSGP related timers, are left unused.

I think the first thing to do regarding that topic, as per this task, is to make sure we properly describe those arrays with enums, etc. everywhere (osmo-bsc, osmo-bts, osmo-pcu). Then, once those are identified, we can start thinking on using them.

lynxis and daniel probably know better about those timers since they know BSSGP/NS far better than I. Using the timers in osmo-pcu is probably another task/step though, as mentioned. That may be a bit of work since the code handling BSSGP/NS in osmo-pcu is quite rotten currently.

Actions #9

Updated by arehbein about 1 year ago

Something to add:
in src/osmo-bsc/pcu_sock.c:
memcpy(info_ind->nse_timer, bts_sm->gprs.nse.timer, 7);

So the timer array would benefit from the same treatment I suppose, currently it's just magic numbers; the only semantics are in references to gprs_ns_timer_strs

Same with code in osmo-pcu/include/osmocom/pcu/pcuif_proto.h:

        uint8_t         nse_timer[7];
        uint8_t         cell_timer[11];
Actions #10

Updated by arehbein about 1 year ago

pespin not sure what to make of this

In osmo-bsc/src/osmo-bsc/net_init.c as part of the timer defs:

{ .T = 4, .default_val = 5, .desc = "Timeout to receive BSSMAP RESET ACKNOWLEDGE from the MSC" }

I assume it's the same T4 as in 3GPP TS 48 018 (the description sounds very different so it threw me off and since I don't know the entire procedure...), however if that's the case then we already have a different default (10 instead of 5) set in

osmo-bsc/src/osmo-bsc/bts_ipaccess_nanobts_omlattr.c:

          /* all timers in seconds */
          ...
          buf[7] = 10;    /* resume timer (T4) in 100ms */

Probably doesn't make a difference for now since the PCU doesn't make anything of the array yet if I'm not confusing arrays here, but should be fixed to be either of both values (unless of course the timer 4 in the tdef array is actually not the T4 from 3GPP TS 48 018...).

Which value to pick, or am I mistaken?

Actions #11

Updated by arehbein about 1 year ago

  • % Done changed from 40 to 50
Actions #12

Updated by pespin about 1 year ago

BSSGP/Gb side of things: lynxis or daniel can you provide feedback?

Actions #13

Updated by lynxis about 1 year ago

For the NS side:

    buf[0] = 3;    /* blocking timer (T1) */
    buf[1] = 3;    /* blocking retries */
    buf[2] = 3;    /* unblocking retries */
    buf[3] = 3;    /* reset timer (T2) */
    buf[4] = 3;    /* reset retries */

we already have some sort of timers for those. But they should be converted into osmo-timers. (libosmocore/src/gb/gprs_ns2_vty.c:93)

After converting them into osmo-timers we will need a public api to change the values so the pcu can change it. Atm only the vty can change the values.

Actions #14

Updated by lynxis about 1 year ago

  • Related to Bug #5915: gprs: ns2: convert timers into osmo-timers added
Actions #15

Updated by arehbein 11 months ago

Hi there,

I have noticed that a couple of network variables (counters, timers) that are set to one specific value are configurable in our implementation (example: NS ALIVE timer, per spec it should be 3 seconds or something like that, up to now we have been exposing it as configurable in osmo-bsc and libosmocore).

Is that owing to some older specs that had those configurable and should that be changed to reflect the current specs, or do we want to keep exposing them as configurable/add those as timers through the tdef API (I'm not talking about 'legacy configurability', I understand that old commands should still be working like they used to)?

Actions #16

Updated by arehbein 11 months ago

  • % Done changed from 50 to 70
Actions #17

Updated by laforge 11 months ago

On Wed, Mar 22, 2023 at 10:29:04AM +0000, arehbein wrote:

I have noticed that a couple of network variables (counters, timers) that are set to one specific value are configurable in our implementation (example: NS ALIVE timer, per spec it should be 3 seconds or something like that, up to now we have been exposing it as configurable in osmo-bsc and libosmocore).

In reality many of those timers/counters will be adjusted by operators, even if the spec states (often
actually just recommends) a value. The reasons can be to work around different timers/counters in
the implementation we talk to. Or larger timeouts required due to slow satellite links (whereas the specs
always assume terrestrial links), etc.

Is that owing to some older specs that had those configurable and should that be changed to reflect the current specs, or do we want to keep exposing them as configurable/add those as timers through the tdef API (I'm not talking about 'legacy configurability', I understand that old commands should still be working like they used to)?

  • whatever we did expose in the past must continue to be exposed
  • old VTY commands must continue to work for compatibility
  • whatever we did not expose in the past may be additionally exposed
Actions #18

Updated by pespin 11 months ago

  • Related to Bug #5991: Forward TSNS-PROV bsc->[bts->]pcu added
Actions #19

Updated by pespin 6 months ago

I submitted packed structs for the related IPACC extension NM Attributes:
https://gerrit.osmocom.org/c/libosmocore/+/34290 gsm_12_21.h: Introduce packed structs for NM_ATT_IPACC_RLC_CFG{,_2,_3} values
https://gerrit.osmocom.org/c/libosmocore/+/34291 gsm_12_21.h: Introduce packed structs for NM_ATT_IPACC_BSSGP_CFG values [NEW]
https://gerrit.osmocom.org/c/libosmocore/+/34292 gsm_12_21.h: Introduce packed structs for NM_ATT_IPACC_NS_CFG values [NEW]

Although it's not 100% part of this task, now osmo-bsc and osmo-bts can be updated to use those when transmitting the values over the wire, instead of using internal array-based structures to build the messages.

Actions #20

Updated by pespin 6 months ago

I updated osmo-bsc to use those features so that the code becomes less untangled. Hopefully this will help in making the list of things to do for this task easier to follow after they are merged:
https://gerrit.osmocom.org/c/osmo-bsc/+/34293 oml: ipacc: Remove BSSGP value assignment being overwritten afterwards
https://gerrit.osmocom.org/c/osmo-bsc/+/34294 oml: ipacc: Use new packed struct abis_nm_ipacc_att_bssgp_cfg from libosmcore
https://gerrit.osmocom.org/c/osmo-bsc/+/34295 oml: ipacc: Use new packed struct abis_nm_ipacc_att_ns_cfg from libosmcore
https://gerrit.osmocom.org/c/osmo-bsc/+/34296 oml: ipacc: Use new packed struct abis_nm_ipacc_att_rlc_cfg from libosmcore

Similar changes as the above presented should also be done in osmo-bts.

Actions #21

Updated by laforge 2 months ago

  • Assignee changed from arehbein to jolly
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)