Before this patch, when a PAGING-GS was received in PCU from SGSN, it
would always forward the paging request to all PDCHs in all TRXs of all
BTS (well, it did some heuristics to avoid sending it in some PDCHs
where onyl repeated TBFs would be listening).
The previous behavior, didn't make much sense in the case where the PCU
is asked to page an MS which it knows (ie in which PDCHs is listening
to). Hence, in that case it makes sense to simply send the paging
request on 1 PDCH where the MS is listening, instead of sending it in a
big set of different PDCHs.
This commit also splits the old get_paging_mi() helper which was
erroneously created to parseboth CS/PS-PAGING requesst, since they
actually use a different set of target subscriber information (for
instance, CS-PAGING provides optionally a TLLI, and one provides P-TMSI
while the other provides TMSI).
In this patch, the handling of CS paging request is split into 2 parts:
1- A new helper "struct paging_req_cs" is introduced, where incoming
CS-PAGING requests (from both SGSN over BSSGP and BTS/BSC over PCUIF)
are parsed and information stored. Then, from available information, it
tries to find a target MS if avaialable
2- bts_add_paging() is called from both BSSGP and PCUIF paths with the
helper struct and the target MS (NULL if not found). If MS exists,
paging is forwarding only on 1 PDCH that MS is attached to. If no MS
exists, then the old heursitics are used to forward the request to all
MS.
Change-Id: Iea46d5321a29d800813b1aa2bf4ce175ce45e2cf
This allows more easily finding when this specific scenario happens, and
can easily be compared against the PACCH one.
Change-Id: I609792a40fda2a798ca71a0e9f5639d0a0f011d7
Tbftest expectatins need to change because 5000/20 = 250 < 255, hence
the message is now sent as units of 20ms instead of seconds.
Related: OS#3928
Change-Id: I48b34b94b1a5dfb046a3a6cf8a0d944a7c9b6754
Now that we finally handle N3101 and N3103 correctly, we can fix abuse
of T3169 we were doing to make sure TBFs were freed.
According to 3GPP TS 44.060, T3169 should be armed:
* N3101_MAX reached
* N3103_MAX reached
Furthermore, when T3169 is enabled, the tbf should be in state
RELEASING so that its USF is not used.
See full description: https://osmocom.org/issues/5033#note-2
Related: OS#5033
Change-Id: I2cec531e2633281b88f69ba065c0105580c81076
That field is not needed anymore, and it works only under the assumption
that only 1 poll request can be active at a time per TBF, which is not
true.
Change-Id: I63a34a702f028b871530fb7caeb13e8ea1cc78ac
Value 'false' is always passed by all callers of the function, so
there's no need to pass it. Furthermore, since it's false, there's no
need to access poll_fn since RRBP will always be invalid.
Change-Id: Ia48ce2a021865e76e813dedb22aca9c2522c5693
There's no need for setting the FN in RA.ind since we anyway already
receive a DATA.ind beforehand.
Furthermore, the applied delay of 5 in the call is not really used at
all.
Change-Id: I437f4f95d054aea96bec3b9343e495451020ff3c
TbfTest is updated to submit empty blocks to have somehow meaningful
output (at least as meaningful test results as before, not much). That's
because we must update bts->curr_fn to have polls expire.
Related: OS#5020
Change-Id: I683ca738ce5a133c49c36a1d94439a942d64a831
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
This is specially useful to detect for instance if a cell is handling
too many users, ending up in TFI or USF exhaustions. This information
can be later in the future used to tune TBF allocation algorithm behavior
(either manually/statially through config file, or
automatically/dynamically in code based on some thresholds).
Related: OS#5042
Change-Id: I5402e937ff8d800684655e500ef8e5c867141dc3
The old VTY command is marked as deprecated and still overrides the use
in case it's used.
Related: SYS#5358
Depends: libosmocore.git Change-Id I74fb0a3afc1ac4aadbfc609b882d929401f790eb
Depends: osmo-bsc.git Change-Id I8b97ea11bad5fe05f2f634945b5703ee9abde81d
Change-Id: I46f2a955b157a409055fca7fb917dc4f75482426
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
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
Pau Espin
Pau Espin Pedrol
Vadim Yanitskiy
Harald Welte