Cellular Network Infrastructure » Radio Access Network » OsmoBSC

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).

• 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

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).

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.

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];

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?

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

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.

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)?

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

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.

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.