This patch doesn't really tests whether osmo-pcu can work on a multi-bts
environment, but it prepares the data structures to be able to do so at
any later point in time.
Change-Id: I6b10913f46c19d438c4e250a436a7446694b725a
The bts_init/cleanup functions were kept during the C and C++ structure
merge process to make the patch simpler. It's not needed anymore,
let's move all the destructor logic into one function and keep that
together.
Change-Id: I73a9457d5c92f62261561ef6afe392953576aec4
There's no BTS single global object anymore, get rid of those APIs. Move
users to use "pcu->bts", which will evolve to a linked list in the
future.
Change-Id: I9cf762b0d3cb9e2cc3582727e07fa82c8e183ec5
Previous work on BTS class started to get stuff out of the C++ struct
into a C struct (BTS -> struct gprs_glcmac_bts) so that some parts of
it were accessible from C code. Doing so, however, ended up being messy
too, since all code needs to be switching from one object to another,
which actually refer to the same logical component.
Let's instead rejoin the structures and make sure the struct is
accessible and usable from both C and C++ code by rewriting all methods
to be C compatible and converting 3 allocated suboject as pointers.
This way BTS can internally still use those C++ objects while providing
a clean APi to both C and C++ code.
Change-Id: I7d12c896c5ded659ca9d3bff4cf3a3fc857db9dd
Both values (optionally) set (forced) by VTY and the values received
from PCUIF were stored in the same variable, meaning that for instance
the PCUIF values wouldn't really be used if someone applied eg "no cs"
during runtime.
This commit does something similar to what was already done for the
max_(m)cs fields. We store PCUIF values in one place and VTY ones in
another place, and then trigger a bts object internal process to find
out exactly which initial CS should it be using.
Change-Id: I80a6ba401f9c0c85bdf6e0cc99a9d2008d31e1b0
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
Unfortunately, RACH.ind on the PCU interface contains no Uplink
measurements: neiter RSSI nor C/I. In order to avoid sending
garbage, let's zero-initialize 'struct pcu_l1_meas'.
Change-Id: I8c3210c428da17d23d798f3ef9df941ded6e162a
Fixes: CID#216512
As we integrate osmo-pcu more and more with libosmocore features, it
becomes really hard to use them since libosmocore relies heavily on C
specific compilation features, which are not available in old C++
compilers (such as designated initializers for complex types in FSMs).
GprsMs is right now a quite simple object since initial design of
osmo-pcu made it optional and most of the logic was placed and stored
duplicated in TBF objects. However, that's changing as we introduce more
features, with the GprsMS class getting more weight. Hence, let's move
it now to be a C struct in order to be able to easily use libosmocore
features there, such as FSMs.
Some helper classes which GprsMs uses are also mostly move to C since
they are mostly structs with methods, so there's no point in having
duplicated APIs for C++ and C for such simple cases.
For some more complex classes, like (ul_,dl_)tbf, C API bindings are
added where needed so that GprsMs can use functionalitites from that
class. Most of those APIs can be kept afterwards and drop the C++ ones
since they provide no benefit in general.
Change-Id: I0b50e3367aaad9dcada76da97b438e452c8b230c
In previous status, if USF for GPRS-only MS was selected, then EGPRS
TBFs were skipped and either a GPRS TBF was selected or a Dummy Block
was sent. That means the behavior was unfair towards EGPRS TBFs, because
sometimes they were skipped in favor of GPRS ones.
This patch imporves the situation in the above mentioned USF scenario, by
first, under specific conditions, allowing selection of an EGPRS TBF and
then forcing it to transmit in EGPRS-GMSK (MCS1-4) so that the
USF-targeted MS can still decode the USF, while at the same time
providing more fairness by allowing the EGPRS TBF to transmit data.
The specific conditions mentioned above are, mainly, related to the fact
that once a DL data block has been sent, and hence a BSN was assigned to
it, it cannot be retransmitted later using another MCS, since lower
MCS1-4 wouldn't be able to contain higher MCS RLC payload.
The set of conditions could be expanded in the future by also selecting
the EGPRS TBF if retransmition is required and the block to be
retransmitted was originally transmitted as MCS1-4.
Related: OS#4544
Change-Id: I9af23e175435fe9ae7b0e4119ad52fcd4707b9ca
Recent commit removed the counter enum but forgot to remove the
description, so the descriptions were all shifted by 1 counter.
Fixes: 133fe4a852
Change-Id: I82ee9f36d60a1fd129ae3a864508fcd886e4bfef
Take into account the MCS values supported by the BTS. In osmo-bts,
in general all MCS are enabled if "mode egprs" is selected in BSC,
and none otherwise.
Change-Id: Ie8f0215ba17da1e545e98bec9325c02f1e8efaea
This way everytime any program or test initiates a BTS object, the
bts_data structure has the same values.
Change-Id: Iffd6eecb1f08bda0091f45e2ef7c9c63b42e10b3
Before this patch, it would always allocate all TBFs on the first TRX
until all TFIs were filled, then second, and so on. But it would
actually fail around 8th MS requesting an UL TBF because despite a TFI
was successfuly assigned, because all USFs were already exhausted for
that PDCH.
Related: OS#1775
Change-Id: Iccfc8acfbfdc258ed16cc5af01f12b376fe73b72
It seems that some gcc versions do not consider the priority of
"C" __attribute__((constructor)) definitions in the same order as
they do C++ static initializers, which are called in the order in which
they appear in the compile unit (source file).
The problem has been observed at least in a
environment based on T2 SDE with GCC 6.3.0 and binutils 2.28.
Let's work around this by making sure the __attribute__((constructor))
function always gets the highest priority value permitted by gcc (101).
Closes: SYS#5093
Change-Id: I65de69a32ac929e6ddd4e58980027f9e76813153
In order to be able to encode frequency hopping parameters, let's
pass a const pointer to 'gprs_rlcmac_pdch' (PDCH slot) directly,
instead of passing all related parameters separately.
Change-Id: I6bccad508f0fdccc4a763211008dd847a9111a8d
Related: SYS#4868, OS#4547
In get_paging_mi(), before this, an encoded buffer of Mobile Identity bytes is
returned. Code paths following this repeatedly decode the Mobile Identity
bytes, e.g. for logging. Also, in get_paging_mi(), since the TMSI is read in
from a different encoding than a typical Mobile Identity IE, the TMSI was
manually encoded into a typical Mobile Identity IE. This is essentially a code
dup of osmo_mobile_identity_encode(). Stop this madness.
Instead, in get_paging_mi(), return a decoded struct osmo_mobile_identity. Code
paths after this use the struct osmo_mobile_identity directly without repeated
decoding.
At the point of finally needing an encoded Mobile Identity IE (in
Encoding::write_paging_request()), do a proper osmo_mobile_identity_encode().
Since this may return errors, add an rc check for the caller of
write_paging_request(), gprs_rlcmac_paging_request().
A side effect is stricter validation of the Mobile Identity passing through the
Paging code path. Before, invalid MI might have passed through unnoticed.
Change-Id: Iad845acb0096b75dc453105c9c16b2252879b4ca
Note: subsequent patch Iad845acb0096b75dc453105c9c16b2252879b4ca will change to
passing a struct osmo_mobile_identity in the Paging code path, instead of
passing the encoded IE data.
Change-Id: Ibb03b8e601160427944f434761ca59811d1fc12f
According to 3GPP TS 44.004, section 7.4a, two alternative RACH
block formats are specified: 8 bit (1 octet) and 11 bit. The
bit order is LSB (right to left), byte order is MSB.
In PCUIF RACH.ind structure (see gsm_pcu_if_rach_ind) we use
a field of type uint16_t to store RA values regardles of the
block format. Thus when packing it to bytes, we cannot just
cast uint16_t* to uint8_t*, we need to do some bit shifting.
Change-Id: I08a0a908f855b0d8a002df732e02781126d27dfb
Let's finally use the API we introduced in [1].
[1] I96df3352856933c9140177b2801a2c71f4134183
Change-Id: Ia15761c33c8048d35c7f7bc93dbea781dd0894b7
Related: OS#1548
This patch is a set of tightly related changes:
- group all RACH.ind parameters into struct 'rach_ind_params';
- group Channel Request parameters into struct 'chan_req_params';
- get rid of egprs_mslot_class_from_ra(), priority_from_ra(),
and is_single_block(), introduce unified parse_rach_ind();
- improve logging, get rid of redundant information.
This is needed for proper EGPRS Packet Channel Request handling.
Change-Id: I5fe7e0f51bf5c9eac073935cc4f4edd667c67c6e
Related: OS#1548
It's super annoying seeing lots of functions being called everywhere
only to find out they are only incrementing a counter. Let's drop all
those functions and increment the counter so people looking at code
doesn't see dozens of code paths evyerwhere.
Most of the commit was generated by following sh snippet:
"""
#!/bin/bash
grep -r -l ^CREATE_COUNT_INLINE . | xargs cat | grep "^CREATE_COUNT_INLINE("| tr -d ",;" | tr "()" " " | awk '{ print $2 " " $3 }' >/tmp/hello
while read -r func_name ctr_name
do
#echo "$func_name -> $ctr_name"
files="$(grep -r -l "${func_name}()" .)"
for f in $files; do
echo "$f: $func_name -> $ctr_name";
sed -i "s#${func_name}()#do_rate_ctr_inc(${ctr_name})#g" $f
done;
done < /tmp/hello
grep -r -l "void do_rate_ctr_inc" | xargs sed -i "/void do_rate_ctr_inc(CTR/d"
grep -r -l "CREATE_COUNT_INLINE" | xargs sed -i "/^CREATE_COUNT_INLINE/d"
"""
Change-Id: I360e322a30edf639aefb3c0f0e4354d98c9035a3
It's really non-sense from architectural point of view to pass an
optional pointer to the MS holding the TBF and creating it otherwise.
TBFs shouldn't be creating MS they belong too.
This simple change requiring so many code line changes really exhibits
how badly entangled the object relationship is.
Another commit will follow doing the same for dl tbf.
Change-Id: I010aa5877902816ae246e09ad5ad87946f96855c
MultislotClass is 5 bit long, so an uint8_t is enough.
In most places we are already storing multislot class as uint8_t.
Change-Id: I1dcaff9d69379453a0b794e5f36b820f5f78531f
In osmo-pcu datatructures, the variables holding multislot classes
simply contain an integer referring to the multislot class number,
instead of coding from 3GPP TS 44.060 Table 11.2.5.3 and Table
11.2.5a.3.
So coding Multislot class 3 is stored as 0x03 in osmo-pcu variables,
while in 3GPP TS 44.060 coding it's coded as 0x02 (N-1).
This allows us using value 0x00 to designate a "yet unknown (EGPRS) Multislot
class".
Hence, we need to add 1 to the decoded value to match our data
structures.
Change-Id: Id3b121272bb7e84c0542ae9b4ce09598c6054edd
This function is actually returning an EGPRS multislot class, so let's
update naming. The variable using the return value was already being
passed as egprs_ms_class to tbf_alloc_ul_tbf().
Change-Id: Idb51836c8c9dd4e865bf2cb0b0c24155662f2ae8
It's not really needed to have those together in some function calls,
and makes it more difficult to follow the code. Furthermore, new callers
not having content already aligned (len+value) will be using these
functions in forthcoming commits.
Change-Id: Ifb9d3997bfb74b35366c3d1bc51ce458f19abf16
Pau Espin
Vadim Yanitskiy
Pau Espin Pedrol
Harald Welte