The current name of PCU_IF_SAPI_AGCH_DT is a bit misleading as it
describes a method to send immediate assignment messages (normally AGCH)
via the PCH. The name in the constant should reflect that correctly
Change-Id: I6dfb8035134bc85a025415bd6c2f9c01987d9268
Related: OS#5198
osmo-bsc may send invalid frame numbers through the pcu-sock interface.
Lets make sure that incoming frame numbers do not exceed the valid
range.
Change-Id: Ib0cf1738be07733c95fc6c459a8a7c4cb2eeef26
Related: OS#5198
osmo-pcu will also support GPRS via E1 timeslots in a BSC co-located
setup. To avoid duplicate configuration the BSC has to communicate the
E1 parameters (which TS, SS etc.) to the PCU. Lets add a new primitive
to do that.
Change-Id: Ia7928489130c1205b06bb9b10de0fb1461843301
Related: OS#5198
After some earlier refactoring, those fields are only used internally in
the module, and hence can be marked as static.
Change-Id: Ibf2a6ee5636ae7102ffd13b7497769652bcc3202
This is probably a leftover from an old refactoring where the tv was
moved to MetaInfo (msg->cb[].
Change-Id: I7aceaf2d13a125c75925877c4344c0aeed326c79
The previous function name was misleading since it was checking already
for more stuff than pdu containing user data.
Rename the function and move all checks on PDU in there instead of
having it half in one place and half in the other.
Change-Id: Ia0738caa1ccab5f78c2d49db582bdce96f18600a
In case of an FN jump the expected value is logged. Lets also log the
delta between the expected and the current FN as it may give a better
clue what goes wrong
Change-Id: Ie361df30852570fe8a47347a42e962db869ccf82
The function bts_rfn_to_fn() uses int32_t for its internal variables and
the input parameter rfn while the callers and everything outside uses
uint32_t to store frame numbers. Lets convert this to uint32_t and use
GSM_TDMA_FN_ macros wherever possible.
Change-Id: Iedd493bb30dd1c342dec031883060c545432e740
Related: OS#5198
A valid GSM frame ranges from 0 to 2715647. When using
set_current_frame_number() to set the current frame number (source
usually is the layer 1 and below) we should not allow invalid frame
numbers.
Note: this also fixes FnTest which uses invalid frame numbers for
testsing.
Change-Id: Iaae31b370fababba975d419b0d20ac15618c296e
Related: OS#5198
The DL-TBF assigned to another MS object may have a totally different
set of reserved resources (TS set, TRX, etc.), so one cannot simply move
those to the new MS. To start with, if the 2 MS are on different TRX it
is clear that one of them will not be really in operation. That's most
probably the DL-TBF being in ASSIGN state on CCCH waiting for PCUIF_CNF
and later X2002 to trigger to start sending DL blocks, but without
confirmation whether the MS is really there. Since the other new MS
object probably has a UL-TBF, that's the one probably operative, and
hence a new DL-TBF can be created at that same time and assigned through
UL-TBF's PACCH.
Unit test test_ms_merge_dl_tbf_different_trx showcases the above
scenario.
Related: SYS#6231
Related: OS#5700
Related: 677bebbe5c
Change-Id: Ie8cb49d5492cfc4cbf8340f3f376b0e6105e8c82
Add a test which showcases a scenario where the PCU ends up with 1
GprsMs object holding a DL-TBF in a weird condition half in one TRX and
half in other due to ms_merge().
This test (slightly adapted) used to cause a crash in osmo-pcu.git
586ddda9bc (a few versions behind current
master).
Related: SYS#6231
Change-Id: Ic16b5e96debf91e72684833cd64253687857f3aa
This allows having full TS information, not only ts_no, which will be
needed later on followup patches.
Change-Id: I1efccb32c5afa4fe62233bf114ea95b6fbbe1a06
The DL-TBF in the test gets its TS allocated on TS4 (only that one is
enabled through setup_bts(bts, ts_no=4)), and hence it makes no sense to
ask it to send data on TS7.
Change-Id: Ibe6fc073b7438b8024c4d3ddb0e60c6112752351
This allows having full information on the control TS easily reachable
(like TRX ofthe PDCH), and makes it easy to compare TS by simply
matching the pointer address.
Change-Id: I6a97b6528b2f9d78dfbca8fb97ab7c621f777fc7
First commit towards trying to have alloc algorithm as isolated as
possible from others parts of the code trying to avoid state changes on
data structures.
Change name also because the alloc_algo not only allocated TS, but TFIs
and USFs.
Change-Id: I33a6c178c64a769f05d3880a69c38acb154afa62
struct gprs_rlcmac_bts still hardcodes it to 8, but using ARRAY_SIZE
there should aim at seeing the relation between those, and avoid having
one updated without the other.
Related: OS#5827
Change-Id: I165588ba10d8528a9a496175d8dfe9d902c89e55
* Make it similar to the already existing TBF allocation procedures
* Pass pdch pointer instead of trx and ts numbers
Change-Id: I04b3b65942732cc652adeaa507529b849292ff61
The triggering of the assignment for the new TBF allocation is part of
the "upgrade to multislot" process, hence move that inside the function.
Change-Id: Ic2b959f2476b900cb263ccd8f6698ed843bafd29
* Make clear the code relates to DL-TBF and not UL-TBF.
* Change wording to "upgrade" to match the existing field and API
"tbf_can_upgrade_to_multislot()".
* Free the TBF if we cannot allocate new resources.
Change-Id: I0e4f8d7e46235a471b2124b280c81ff07b6967a4
There's no big benefit in keeping it stored since it can be quickly
found. This makes the tbf data structure simplier and easier to
maintain, and discharges the alloc_algorithm functions from an extra
step.
Change-Id: I5d2f665f648f8637466bfdd3bf7b924cb61ede33
The field contains a common value between the 2 active TBFs of the MS,
so it makes no sense to have them duplicated on each TBF. It can be
sanely stored in the MS object.
Change-Id: I8df01a99ccbfaf7a442ade5000ee282bd638fbba
The array of trx in gsm_pcu_if_info_ind can hold trx 8 items. Lets use a
define constant to specify the size of that array.
Change-Id: I2b12fd562ff867188a37e701bba1ad5de904f9bd
The pdch pointer contains more info than just timeslot number. For
instance, it contains information about the TRX owning the TS.
Change-Id: Ic31a7360a29e61f70bb1338ddab6f5f31aa8b26e
Since the tbf_fsm was split recently into tbf_dl_fsm and tbf_ul_fsm,
each has now its own ctx strucvture, which can hold the proper tbf
subclass.
Change-Id: Id2571e55e1fea2918207175f2030ec026e880bc1
Since the tbf_fsm was split recently into tbf_dl_fsm and tbf_ul_fsm,
each has now its own ctx strucvture, which can hold the proper tbf
subclass.
Change-Id: I7741d524a14437caf4c92b9c09e19762eb272e30
This will allow also validate easily the TRX is the correct one too, not
only the TS number in any random TRX.
Change-Id: Ib1a62b6e7b465253ee7cba63bf5e277f8aa8eaea
This patch refactors rcv_resource_request() in several ways:
* Move the ID_TYPE=DL/UL_TFI handling at the start of the function, so
that the function is split in 2 sections: First section gathers a
GprsMS object from the ID_TYPE in the PktResReq. Second section
handles the packet for the GprsMS based on the expectd ULC slot.
* Initial handling of PktResReq when transmitted by the MS on the UL-TBF
as an answer to USF. This case is basically the one where the MS
wishes to change some parameters of the currently active UL-TBF.
In order to do so, for now simply delete the current TBF and re-create
a new one to triger the PktUlAss which is expected by the MS.
This behavior is not entirely correct since in this case the MS is
expected to keep using actively the old TBF until the PktUlAss is
received, so in this case ideally we should be keeping the TBF object
and simply upgrading it and using itself to trigger a PktUlAss in its
ul_tbf->ul_ass_fsm. Doing this however requires far more work, so it
can be done later as an incremental step fix. The current behavior is
alreday better than the previous one, since the MS has been tested to
be PKT_CTRL_ACKing the PKT_UL_ASS and continuing to use the new TBF.
Related: OS#4947
Change-Id: Ie6b1b438d26cd977f88ddb4eff6b3041e0739d92
The 2 types of TBF share some parts of the implementation, but actually
half of the code is specific to one direction or another.
Since FSM are becoming (and will become even) more complex, split the
FSM implementation into 2 separate FSMs, one for each direction.
The FSM interface is kept compatible (events and states), hence code can
still operate on the tbfs on events and states which are shared.
Test output changes are mainly due to:
* FSM instance now created in subclass constructor, so order of log
lines during constructor of parent class and subclass slightly
changes.
* osmo_fsm doesn't allow having 2 FSM types with same name registered,
hence the "TBF" name has to be changed to "DL_TBF" and "UL_TBF" for
each FSM class.
* FSM classes now use DTBFUL and DTBFDL instead of DTBF for logging. Some
tests don't have those categories enabled, hence some log lines
dissappear (it's actually fine we don't care about those in the test
cases).
Change-Id: I879af3f4b3e330687d498cd59f5f4933d6ca56f0
The state_fsm field will be moved to subclass (DL_TBF/UL_TBF) in a
follow up commit when splitting the tbf_fsm.c implementation per
subclass.
Rearrange a bit the code to access the using the subclass pointer in the
only sublcass where it needs to be used (DL_TBF).
Change-Id: I360485c73be8636565f89ba29796d84ac94fd94e
This way we can easily get the subclass from the parent if the pointer
is const. Similar to what we already have for the opposite direction
{ul,dl}_tbf_as_tbf_const().
Change-Id: I35e650d13ecf3a5020d136e7d8d99837786503e2
This is a preparatory step towards splitting tbf_fsm.c into tbf_ul_fsm.c
and tbf_dl_fsm.c.
In order to accomplish it, the struct tbf_fsm_ctx will also be
duplicated (and each one will contain a explicit ul_tbf/dl_tbf pointer).
Hence, a DL_TBF will have a struct tbf_dl_fsm_ctx and a UL_TBF will have
a struct tbf_ul_fsm_ctx, since those hold implementation specific
state. However, the FSM interface will be partly shared (events,
states), and hence we want to keep the "fi" pointer into the "tbf"
parent class so that it can be used regardless of the tbf direction
type.
Change-Id: I03e691ccf6a94431caa55653349158f5b85db017
Pau Espin
Philipp Maier
arehbein