Take the time to also do small refactorings to clarify and simplify the
function, by using rts_next_fn() already available in pcu_utils.h and
getting rid of poll_tbf from tbf_candidates, which clearly follows
another objective.
Using PDCH UL Controller has the advantage that we don't need to check
poll_scheduled() on each TBF, but only do the query once.
Related: OS#5020
Change-Id: Ia60bb5249a9837dec1f42180e44d9848334d86d6
Right now we handle different types of UL allocations in different
classes like PollAllocator and SBAllocator, and they usually don't take
into account the other one in most cases. Furthermore, those objects are
usually per-BTS object, instead of per PDCH object.
This is a first step towards having a unified per-PDCH controller which
takes care of controlling what is scheduled and hence expected on the
uplink. Each PDCH has a UL Controller which keeps track of all reserved
uplink frame, be it SB, RRBP poll or USF assigned, all under the same
API.
As a first step, only the SBA part is fully implemented and used (being
it the easiest part to replace); TBF poll+usf will come in follow-up
patches later on. As a result, the SBAllocator per-BTS class dissappears
but some of its code is refactored/reused to provide more features to the
gprs_rlcmac_sba object, which is also further integrated into the new UL
Controller.
Related: OS#5020
Change-Id: I84b24beea4a1aa2c1528f41435f77bd16df2b947
The DL NACC related message (PKT Cell Neighbor Data/Change Continue)
are filled with the TFI of the target TBF. Hence, only select the tbf
for NACC transmission if the related TBF already has a TFI assigned.
Otherwise, "OSMO_ASSERT(tbf_is_tfi_assigned(tbf));" in nacc_fsm.c when
generating messages may be hit.
Related: SYS#4909
Change-Id: I72b2dff28aacdb04909c098c94834ff79f55b31d
Use the fact that the MS must answer the RRBP of the Pkt Cell Change
Continue with a CTRL ACK to find out whether the message was received
successfuly or a retransmission is potentially required.
3GPP TS 44.060:
"""
When the mobile station receives the PACKET CELL CHANGE ORDER or
the PACKET CELL CHANGE CONTINUE message the mobile station shall
transmit a PACKET CONTROL ACKNOWLEDGMENT message in the specified
uplink radio block if a valid RRBP field is received as part of the
message; the mobile station may then switch to a new cell.
"""
Related: SYS#4909
Change-Id: I7cc28922e71699598da0ef6eb90136a47d3c002f
A new nacc_fsm is introduced per MS object, with its partner priv
structure struct nacc_fsm_ctx, which exists and is available in the MS
object only during the duration of the NACC procedure.
The NACC context is created on an MS whenever a Pkt Cell Change
Notification is received on Uplink RLCMAC, which asks for neighbor
information of a given ARFCN+BSIC.
First, the target ARFCN+BSIC needs to be translated into a CGI-PS
(RAC+CI) address. That's done by asking the BSC through the Neighbour
Resolution Service available in osmo-bsc using the CTRL interface.
Once the CGI-PS of the target cell is known, PCU starts a RIM RAN-INFO
request against the SGSN (which will route the request as needed), and
wait for a response containing the SI bits from the target cell.
After the SI are received, the scheduler is instructed to eventually
poll a TBF for the MS originating the CCN, so that we can send the SI
encapsulated into multiple Packet Neighbor Cell Data messages on the
downlink.
One all the SI bits are sent, the scheduler is instructed to send a
Packet Cell Change Continue message.
Once the message above has been sent, the FSM autodestroys itself.
Caches are also introduced in this patch which allows for re-using
recently known translations ARFCN+BSIC -> CGI-PS and CGI-PS -> SI_INFO
respectively.
Change-Id: Id35f40d05f3e081f32fddbf1fa34cb338db452ca
Sine we don't yet implement properly all resegmentation of blocks from
same MCS family type, when requiring a GMSK DL block (due to GPRS+EGPRS
multiplexing limitations) we need to skip retransmitions, otherwise we'd
be incorrectly picking a DL block which was already built with a
potentially higher MCS value.
The "DL_PRIO_NEW_DATA" prio serves two purposes:
* There's new data to send
* There's some nacked data to be retransmitted
The 2nd purpose has, later on, more priority over the 1st one when the tbf
is selected (see gprs_rlcmac_dl_tbf::take_next_bsn()).
Until now we were handling correctly the case where the tbf was skipped
in case the prio was to resend unacked data (DL_PRIO_SENT_DATA), but
was incorrectly selected when it'd send nacked data. Let's fix it by
specifically checking w->resend_needed() < 0.
Change-Id: I253de8e1a190a9adb56160f38892c9e43e2c0272
It could happen as of current implementation that a TBF was created as
GPRS due to the MS being non-egprs, and later on the MS was upgraded to
EGPRS due to newly received information from the MS.
Hence, in order to infer if the data block is EGPRS or GPRS, let's
better check for the TBF info, which is the one really mandating the
kind of dl block to generate.
Change-Id: I49720fb3a69ca972cd1973de937ac8ee77615431
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
Before, we used tho have a BTs object split into 2 parts, a C
gprs_rlcmac_bts struct and a C++ BTS struct, and "bts_data" naming was
used to distinguish them in variable names. Nowadays the struct is
finally combined into one, so there's no point in using this "bts_data"
terminology, we use always "bts".
Change-Id: I9852bf439292d1abc70711bea65698b21bde0ee8
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
Let's use usual osmocom rate_ctr instead of having one variable +
setter/getter functions, so we can easily add new counters and also
because it makes code more clear (no need to look at what the "update"
function is doing).
Using rate counter also provides info about how recently the MS has been
interacting with the network.
Related: OS#4907
Change-Id: I744507fde4291955c1dbbb9739b18a12a80145b1
There is a big difference between:
if ((a = foo() != 0xffffffff)) { ... }
and
if ((a = foo()) != 0xffffffff) { ... }
In the first case, 'a' is the result of '!=' operation, i.e. either
0 (false) or 1 (true). In the second case, 'a' will hold the value
returned by foo(), and this is exactly what must have been used in
gprs_rlcmac_rcv_rts_block().
The bug was there since SBA allocation feature was added in 2012.
Change-Id: Ifd607ae8a33382e48f9d9e50a28a4bdf4eaf73a2
Fixes: 07e97cf8a5
Related: CID#215835
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
The resulting code is cleaner since it becomes clear the relation
between all those pointers, which are set in one function and used in
another one, passed through the caller of the former two.
Moreover, if more tbf candidates are to be added for other type of
actions, having them in a struct is much easier since only one pointer
is passed.
Change-Id: I55482aa5af7be5a176a7b4879a672ad37e618020
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
There are some restrictions to have both GPRS-only and EGPRS MS attached
to the same MS:
* Any MS needs to be able to successfully decode a DL block at least
every 18 DL blocks (360 ms). That means a Dl block with CS1-4 must be
sent at least once during that time.
* Any MS needs to be able to decode USF targeting it. GPRS-only MS can
successfully decode USF from DL blocks using GMSK: CS1-4 and MCS1-4.
In this patch, if USF of a GPRS-only MS is selected, then all DL EGPRS
TBFs are discarded from data block selection. However, this logic can be
further improved later by still allowing selection of DL EGPRS TBFs and
then forcing construction of a DL EGPRS data block using MCS1-4.
Sources:
* 3GPP TS 03.64 version 8.12.0 "6.6.4.1.1.2 Multiplexing of GPRS and EGPRS MSs"
* 3GPP TS 05.08 version 8.23.0 "10.2.2 BTS output power"
Related: OS#4544
Change-Id: Ib4991c864eda6864533363443f76ae5d999532ae
Return an interface to the window base class so that the tbf base class
can access the common window methods, such as set_ws(). It will be used
in next commit to get rid of duplicated function enable_egprs in both
dl_tbf and ul_tbf subclasses.
The user of the function can then decide to access more specific
functionaltiites of the window class by static casting it to the
specific direction (which is known by the caller since it operates on a
ul_tbf or a dl_tbf).
Change-Id: Ia2e1decf91be1184668e28297c2126affb9c7ae4
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
define_pattern="^CREATE_COUNT_ADD_INLINE"
generic_func="do_rate_ctr_add"
grep -r -l "${define_pattern}" . | xargs cat | grep "${define_pattern}("| 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}(#${generic_func}(${ctr_name}, #g" $f
done;
done < /tmp/hello
grep -r -l "void ${generic_func}" | xargs sed -i "/void ${generic_func}(CTR/d"
grep -r -l "$define_pattern" | xargs sed -i "/$define_pattern/d"
"""
Change-Id: I966221d6f9fb9bb4f6068bf45ca2978008a0efed
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
Receive an Application Information Request from the BTS via PCU
interface. Construct a Packet Application Information message from it
(3GPP TS 44.060 11.2.47) and send it to all MS with active TBF.
The TTCN-3 test infrastructure to test this feature is not quite ready
yet, so I've added C unit tests instead.
Related: OS#4048
Change-Id: Ie35959f833f46bde5f2126314b6f96763f863b36
The PDCH class and corresponding functions are rather self-contained and
independent from BTS implementation. Let's move them into separate file
to make bts.cpp more manageable. As additional benefit it allow us to
somewhat untangle all the different cross-dependent includes.
Change-Id: Ie05e25361e6741a81b024679f9675c98d4923683
Related: OS#1539
Many files include unnecessary headers and don't include headers which
are actually used. Because of that combined with the fact that OsmoPCU
is a mixture of C and C++, it makes it hard to modularize code. Fix
this (using iwyu [1] tool):
* add missing headers
* remove unused headers
[1] https://include-what-you-use.org/
Related: OS#1539
Change-Id: I8c9f488a43b099c72b2d30d3245e7ba50872fc00
* add functions/macros for setting TBF's poll state
* add function for checking TBF's poll state
Change-Id: I6db1c4e7bd0a49aeb5e391afe371c36b96c6a702
Related: OS#1539
* add functions/macros for setting TBF's UL ack state
* add functions for checking TBF's UL ack state
N. B: this should not be confused with TBF-UL state.
Change-Id: I144483447d4b0b93e775da0e926ee45eb8ab39f3
Related: OS#1539
* add functions/macros for setting TBF's UL/DL state
* add functions for checking TBF's UL/DL state
* move pre-free check into separate function
N. B: this should not be confused with TBF-UL or TBF-DL state.
Change-Id: Idcbf5775d17b1247f2ed01788f9b0788ce66e871
Related: OS#1539
We do not use this style (#warning as an issue tracker replacement) in
any other Osmocom project. Also those warnings clutter compiler output
making it harder to spot warnings for the actual code.
Change-Id: I72070e2a027e60e8b80c12ccfa23ff075434689f
When looking at GSMTAP output so far, one is easily overwhelmed by way
too much information being presented. A lot of is consists of DUMMY
frames, which are probably of lowest interest, ever.
A concept similar to the "gsmtap-sapi" of OsmoBTS is introduced, by
which the user can configure which particular categories (uplink or
downlink control or data, gprs or egprs, ...) he actually wants to
see in his logs.
Change-Id: I297183690e98a7234dfc1608c18847d8981306e4
Commit b78a4a6dfe tried to fix a NULL dereference
error, but apparently was overly eager to return, because it looked like all
code paths would dereference the tbf.
In fact the code path further above, for msg != NULL, has "always" dereferenced
the tbf, but the lower code path, the one effecting the paging, has only
started to dereference tbf since shortly before the overly eager fix: in
da7250ad2c, to "update the dl ctrl msg counter
for ms". It seems that this tbf dereference in the paging path is bogus and the
cause for the segfault that made me write the early exit fix.
Fix that fix:
Do not exit early if tbf == NULL, stay in there to be able to reach the paging
path below.
In case of a message to be sent, assume that tbf is present, and verify: print
an error message and abort if there is a msg but no tbf, so that we will see
the error if I'm wrong there. If a tbf is missing, free the msg.
In case of no message, go on to send pending pagings, but do not attempt to
count ctrl messages for a tbf -- IIUC there will never be a tbf if we're
paging.
This should avoid segfaults while keeping PACCH paging intact.
Tweak a comment for and add a blank line above the paging section.
Related: OS#2176 CID#158969
Change-Id: Ib79f4a945e211a13ac7d1e511cc37b0940ac6202
When Packet resource request is received, PCU will generate the
packet access reject if no resources are present. The encoding is done
based on section 7.1.3.2.1 and 8.1.2.5 of 44.060 version 7.27.0 Release 7.
This patch also includes the test case to validate the generated
packet access reject message.
This patch is integration tested on Osmo-trx setup with Ettus B210 board
and LG F70 MS with some simulation code changes in Osmo-pcu.
Change-Id: I05ff25124b58905586caa0c0c37023d69724f121
Adds spb counters at BTS level(show bts statistics).
Adds RLC/MAC downlink control msg at ms level(show ms imsi <imsi_val>).
Adds the number of coding schemes counter for UL at TBF level.
Change-Id: Icbe4ba95e34bea89ee36f532d099db68204b7c38
When PDAN/EPDAN with channel description is received, PCU will generate the
packet access reject if no resources are present. The encoding is done
based on section 7.1.3.2.1 and 8.1.2.5 of 44.060 version 7.27.0 Release 7.
This patch also includes the test case to validate the generated
packet access reject message.
This patch is integration tested on Osmo-trx setup with Ettus B210 board
and LG F70 MS with some simulation code changes in Osmo-pcu.
Change-Id: I096a3bb44a65533b9e9b091925dd5f70a8696d6
ARFCN is already part of TRX struct so there's no need to supply it
explicitly in a separate parameter. I've tested and those are the same
anyway.
Change-Id: I8e975c52cbc819427880093b1e5371fe1f8ce460