Project

General

Profile

Actions

Feature #5475

closed

Support configuring counter Ny1

Added by pespin 11 months ago. Updated 6 days ago.

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

100%

Spec Reference:
Tags:

Description

src/osmo-bsc/bts_ipaccess_nanobts_omlattr.c nanobts_attr_bts_get():

    /* 10 milliseconds */
    msgb_tv_put(msgb, NM_ATT_BTS_AIR_TIMER, osmo_tdef_get(bts->network->T_defs, 3105, OSMO_TDEF_MS, -1)/10);

    /* 10 retransmissions of physical config */
    msgb_tv_put(msgb, NM_ATT_NY1, 10);             //<---- THIS IS RIGHT NOW HARDCODED

Right now, we allow configuring "T3105", but "Ny1" counter is hardcoded to 10. This is bad, because Ny1 needs to be adapted also based on T3105.
T3105 sets how often we reschedule a "Physical Information" message, eg sent BTS->MS during an incoming handover access.
Ny1 sets how many "Physicial information" messages are sent, aka how many times T3105 is rearmed before stopping.
If T3105 is set to low values (meaning it will retransmit quite quickly), the Ny maybe adapter to higher values to keep retrying for the same amount of time.

See some further explanations here: https://pcstelconext.wordpress.com/2011/05/02/2g-timer-explanations/ , grep for "T3105" and "Ny1" (4.10.3 IV. Precautions)

See also 3GPP TS 04.08 section 11.1.2 "Timers on the network side". Specially important when looking for a good T3105 default value candiate:

NOTE 3: This timer may be set to such a low value that the message is in fact continuously transmitted.


Files

run run 234 Bytes arehbein, 12/17/2022 01:31 PM
expout expout 1.07 KB arehbein, 12/17/2022 01:31 PM
testsuite.log testsuite.log 4.38 KB arehbein, 12/17/2022 01:31 PM
Actions #1

Updated by laforge 4 months ago

  • Tags set to simple
  • Assignee set to arehbein
Actions #2

Updated by arehbein about 2 months ago

pespin I've uploaded a patch: https://gerrit.osmocom.org/c/osmo-bsc/+/30539

Considering setting a reasonable default for ny1, I haven't added code for that. I'm entirely new to the entire GSM/GPRS ecosystem and I'm not sure how timers work (both concerning specs and osmo - osmo_timer* looked like what I'd need to use though)...
Anyways, apparently the value of T3124 is needed for setting ny1 to a reasonable value.
From my understanding, T3105 and ny1 are attributes of the BTS, but we configure them on the BSC which then sends those to the BTS, so somehow the goal should be to know (on the BSC):
- the value of T3124 (if I understand correctly, that information is on the MSC)
- when T3124 expires (" ")
- when the BTS (or the MSC?) receives the handover failure from the BSC ("by original BSC" in the link you gave)

I still need to adapt the tests.

Actions #3

Updated by pespin about 2 months ago

arehbein wrote in #note-2:

pespin I've uploaded a patch: https://gerrit.osmocom.org/c/osmo-bsc/+/30539

Considering setting a reasonable default for ny1, I haven't added code for that. I'm entirely new to the entire GSM/GPRS ecosystem and I'm not sure how timers work (both concerning specs and osmo - osmo_timer* looked like what I'd need to use though)...

osmo_timer_fd is to register events on the libosmocore mainloop. Have a look at osmo_tdef, it already has some stuff in osmo-bsc (grep for gsm_network_T_defs) (see libosmocore.git ./include/osmocom/core/tdef.h ./include/osmocom/vty/tdef_vty.h)

Anyways, apparently the value of T3124 is needed for setting ny1 to a reasonable value.
From my understanding, T3105 and ny1 are attributes of the BTS, but we configure them on the BSC which then sends those to the BTS, so somehow the goal should be to know (on the BSC):
- the value of T3124 (if I understand correctly, that information is on the MSC)

T3124 is used/et by the MS according to 3GPP TS 44.018:

T3124: This timer is used in the seizure procedure during a hand-over, when the two cells are not
synchronized.
Its purpose is to detect the lack of answer from the network to the special signal.
Its value is set to 675 ms if the channel type of the channel allocated in the HANDOVER
COMMAND is an SDCCH (+ SACCH); otherwise its value is set to 320 ms.

So it basically waits for 675ms for SDCCH and 320ms for other channel types (TCH?).

From https://pcstelconext.wordpress.com/2011/05/02/2g-timer-explanations/:

To avoid this, the T3105 must meet the following foulard: Ny * T3105 > T3124 + delta Wherein, delta is the time between expiration of T3124 and receiving HANDOVER FAILURE message by original BSC.

In any case, you cannot probably exactly now the mentioned "delta". So at most I'd add a check in nanobts_gen_set_bts_attr() to log a NOTICE line if configured "Ny * T3105" is lower or equal than 675ms.
This should be enough to provide at least some feedback. You could even add the check in gsm_bts_check_cfg() and close the conn with the osmo-bts if this condition is detected.

Actions #4

Updated by arehbein about 2 months ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 40
Actions #5

Updated by arehbein about 2 months ago

pespin thanks for your advice! I've created a new patch for the checks you mentioned: https://gerrit.osmocom.org/c/osmo-bsc/+/30602

Tests are failing, some assert that needs to be adapted because the default value has changed (it's at 7 now). I'll look into it later.

(nanobts_omlattr_test.c:46 test_nanobts_gen_set_bts_attr() L0 data mismatch: ...)

Actions #6

Updated by arehbein about 1 month ago

pespin

So I think I considered all your comments. However I don't know why the Jenkins job keeps failing. When I run tests/nanobtsomlattr/nanobts_omlattr_test, the process exits without any error indication.

When I run osmo-bsc/tests/testsuite, the testsuite script says it fails (as it does in Jenkins). I refrained from trying to understand what exactly is happening in that script since it's autogenerated and very cumbersome to read/understand.

Since you have more experience... any ideas what it could be/what I'm overlooking? I feel like I've gone through a lot of checks already. The problem is I don't get any indication of what's going wrong.

I attached the contents of osmo-bsc/tests/testsuit.dir/8 from my local machine.

It's from the latest patch from
https://gerrit.osmocom.org/c/osmo-bsc/+/30539
(Change-Id: I6318cceb4ebdce50005e39e2e9323c1c8433250a )
applied to origin/master at 19c70f1125443dc7af88d0a194575b4d26bdb2cd

Edit: This is old now, I guess it's better to ignore the logs... but maybe it's still indicative of the same error.

Actions #7

Updated by arehbein about 1 month ago

  • % Done changed from 40 to 80
Actions #8

Updated by arehbein about 1 month ago

I think it's related to the test code substituting some variable initializations (e.g. the T_def array...).

Actions #9

Updated by arehbein about 1 month ago

Fixed some possible problem causes from the testcode, but tests still fail...

Actions #10

Updated by arehbein 27 days ago

  • % Done changed from 80 to 90
Actions #11

Updated by arehbein 6 days ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)