Commit Graph

4 Commits

Author SHA1 Message Date
Pau Espin ac3fd12026 Split PCU global PCU object from BTS object
Currently the BTS object (and gprs_rlcmac_bts struct) are used to hold
both PCU global fields and BTS specific fields, all mangled together.
The BTS is even accessed in lots of places by means of a singleton.

This patch introduces a new struct gprs_pcu object aimed at holding all
global state, and several fields are already moved from BTS to it. The
new object can be accessed as global variable "the_pcu", reusing and
including an already exisitng "the_pcu" global variable only used for
bssgp related purposes so far.

This is only a first step towards having a complete split global pcu and
BTS, some fields are still kept in BTS and will be moved over follow-up
smaller patches in the future (since this patch is already quite big).
So far, the code still only supports one BTS, which can be accessed
using the_pcu->bts. In the future that field will be replaced with a
list, and the BTS singletons will be removed.

The cur_fn output changes in TbfTest are actually a side effect fix,
since the singleton main_bts() now points internally to the_pcu->bts,
hence the same we allocate and assign in the test. Beforehand, "the_bts"
was allocated in the stack while main_bts() still returned an unrelated
singleton BTS object instance.

Related: OS#4935
Change-Id: I88e3c6471b80245ce3798223f1a61190f14aa840
2021-01-18 10:37:05 +00:00
Neels Hofmeyr 42f2d61ac9 use osmo_init_logging2() with proper talloc ctx
There is a duality of initialization: early_init() in bts.cpp wants to init
logging even before static instances get initialized. Make sure that
tall_pcu_ctx is initialized during early_init() as well. There is a build
context that does not seem to include bts.cpp (osmo-pcu-remote), so to be sure,
init tall_pcu_ctx as NULL and both in early_init() as well as pcu_main.cpp,
init both tall_pcu_ctx and logging if it is still NULL.

Change-Id: I2199b62d0270bd35dec2283e8f5b364b7c63915b
2018-04-01 16:57:42 +02:00
Neels Hofmeyr bdc55fad62 implement support for 3-digit MNC with leading zeros
Receive the mnc_3_digits flag from the PCU interface.

Bump the PCU interface to 9.
This is one part of the three identical pcuif_proto.h patches:
- I49cd762c3c9d7ee6a82451bdf3ffa2a060767947 (osmo-bts)
- I787fed84a7b613158a5618dd5cffafe4e4927234 (osmo-pcu)
- I78f30aef7aa224b2e9db54c3a844d8f520b3aee0 (osmo-bsc)

Add 3-digit flags and use the new RAI and LAI API from libosmocore throughout
the code base to be able to handle an MNC < 100 that has three digits (leading
zeros).

Depends: Id2240f7f518494c9df6c8bda52c0d5092f90f221 (libosmocore),
         Ib7176b1d65a03b76f41f94bc9d3293a8a07d24c6 (libosmocore)

Change-Id: I787fed84a7b613158a5618dd5cffafe4e4927234
2018-03-11 00:47:14 +01:00
Philipp Maier 1275a3f91a BTS: Convert relative frame numbers to absolute frame numbers
The implementation of the method rcv_rach() in class BTS, restores
the absolute frame number of the incoming RACH-Request by using
the relative frame number (RFn = Fn mod 42432) from the rach
request and the already known internal absolute frame number
m_cur_fn, which is continusly updated by the CCU interface.

In some rare cases, a RACH request might be received by the BTS,
a very short time before the frame number wraps in its 42432.
Depending on the PCU location, RACH request might be received
by the BSC, which forwards it to the PCU. It is then likely
that, while the RACH request is being forwarded to the PCU, the
PCU internal absolute frame number wraps before the RACH
can be processed. The relative frame number from the rach
request would then be interpreted as if it were received after
the wrapping of the internal frame number modulos.

This commit adds logic to detect and resolve this race condition.
Also a unit test is added to check some cornercases.

Change-Id: I74f00c11e5739d49f370ce6c357149e81d9aa759
2017-03-05 12:23:56 +00:00