Feature #5475
closedSupport configuring counter Ny1
100%
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
Updated by arehbein over 1 year 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.
Updated by pespin over 1 year 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.
Updated by arehbein over 1 year ago
- Status changed from New to In Progress
- % Done changed from 0 to 40
Updated by arehbein over 1 year 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: ...)
Updated by arehbein over 1 year ago
- File expout expout added
- File run run added
- File testsuite.log testsuite.log added
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.
Updated by arehbein over 1 year ago
I think it's related to the test code substituting some variable initializations (e.g. the T_def array...).
Updated by arehbein over 1 year ago
Fixed some possible problem causes from the testcode, but tests still fail...
Updated by arehbein about 1 year ago
- Status changed from In Progress to Resolved
- % Done changed from 90 to 100
