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
It is nowadays only used internally, hence it can be moved to the .c file
to better describe its scope.
Change-Id: I23cfa5b7efbeb6a58855099780749741c9c947e9
FSM IDs are properly updated now, so there's no need for the pointer
address to properly follow them.
Change-Id: Ia48c6d5afcdd95e32c7c9b327774f78f07342a0f
Use same formatting similar to what's now used in TBF, which is far more
easy to grep and follow. This way one can easily follow what happens to
a given IMSI, a give TFI, a given TLLI, etc.
Change-Id: If9b325764c8fd540d60b6419f32223fd7f5a5898
use a format in tbf::name() which is sanitized (osmo_sanitize) and hence
can be used both in regular log as well as for its internal FSM ids.
Until now, the FSMs contained a small amount of information with
different formatting than the regular LOGPTFB(), which made it difficult
to grep or follow a TBF through its lifetime looking at logs. The new
unified format makes that a lot easier.
Extra information is now printed if available, such as IMSI.
Furthermore, the TFI is updated to include BTS and TRX, since the TFI is
unique within the scope of a TRX.
Change-Id: I3ce1f53942a2f881d0adadd6e5643f5cdf6e31da
If data received from SGSN is waiting to be sent to the MS, we may have
created a DL-TBF assignment over PCH if the MS was not in packet-active
mode. If the MS instead reaches back to the PCU asking for an UL-TBF, the
PCU has to wait until Content Resolution of the UL-TBF has succeeded in order
to attempt now to assign the DL-TBF over PACCH.
The delay was already there, but the trigger to attempt the DL-TBF
assignment upon UL-TBF contention reslution success was missing.
Related: OS#5700
Change-Id: Ib8f7ad2390485ce9fd76a9de6cd349a5f4037568
This is a preparation towards fixing MS not recreating a DL-TBF (being
assigned on CCCH) when MS starts an UL-TBF and finishes contention
resolution.
A counter is removed which was counting contention resolution (MS) on
the wrong place.
Change-Id: I8b9555864d3615ce0a024b641c67921f82273a8d
It is desired to free pending DL-TBF under some scenarios, which somehow
are related to those where we call the ms_merge() procedure since it's at
time an MS can be identified when coming from packet-idle state.
Until now, the freeing of those DL-TBFs happen because the ms_merge()
procedure doesn't migrate DL-TBF from "old_ms" to "ms". This was done
manually under the cases where it was deemed necessary before calling
the ms_merge() procedure 8because old_ms and its tbfs are gone after
returning from it).
This logic, though convinient for the specific cases at hand, is quite
confusing for readers and program execution since one would expect the
ms merge to, well, merge everything.
Therefore, this patch changes the ms_merge() logic to always merge the
DL-TBF, and only under the specific cases where it makes sense to free
it, do so explicitly after MS merge, where all the info has been updated
and united.
2 code paths are now explicitly freeing the existing DL-TBF when needed:
- TBF_EV_FIRST_UL_DATA_RECVD: 1st data (containing TLLI) is
received from MS, hence identifyng the MS and potentially having been
merged with some old MS which used to have a DL-TBF, most probably in
process of being assigned through CCCH (PCH). This event is triggered
during MS using 1phase-access, and we should drop the exsitng DL-TBF
because MS just came from packet-idle mode (CCCH).
- rcv_resource_request(): PktResourceRequest is received at an scheduled
SBA, meaning the MS is doing 2phase-access, meaning MS also came from
packet-idle mode (CCCH), so previous DL-TBF can be dropped.
Related: OS#5700
Change-Id: I29f4ffa904d79d58275c6596cc5ef6790b6e68c6
This allows easier tracking of this event. It will also extended later
on with more logic which is better placed in tbf_fsm.
Change-Id: I5c935914e13db3928c32621ec04eb2760367615d
That function was pretty confusing since it used a "enum
gprs_rlcmac_tbf_direction dir" param (whose type is expected to describe
the data direction of a TBF) to describe the direction of the the packet
which triggered its call.
The parameter was actually always called with "GPRS_RLCMAC_UL_TBF" which
in this case meant "uplink direction" which meant "TLLI was updated from
the MS, not the SGSN".
The DL direction was only used in unit tests, which can hence be simply
replaced by ms_confirm_tlli(), which this commit does.
So this update_ms() function was actually used in practice in osmo-pcu
to trigger update of TLLI and find duplicates only when an RLCMAC block
(control or data) was received from the MS. Therefore, this function is
renamed in this patch and moved to the gprs_ms class, since it really
does nothing with the TBF.
Related: OS#5700
Change-Id: I1b7c0fde15b9bb8a973068994dbe972285ad0aff
This will help in the future when splitting tbf_fsm into different FSMs
for UL-TBF and DL-TBF, since only some of the events and states are
shared.
That means we can keep a single state and event enum, but the FSMs can
be implemented separately in different files, easing a lot extending and
understanding the logic.
Change-Id: Id97f0d532d2d7ab2791a35c1f836d7c8da050124
ms_new_dl_tbf_assignment() is split into 2 functions, one to
allocate+assign on PACCH and another one for PCH.
This makes a lot clearer the aim of each caller of the function.
Once this is done, it becomes obvious tbf->establish_dl_tbf_on_pacch()
is basically doing the same as ms_new_dl_tbf_assigned_on_pacch() so drop
it.
Change-Id: I610210e3120c962d91ce8ff94c66161e086761ba
Use the dl_tbf prefix which is usually used to easily distinguish from
"ul_tbf" specific APIs and "tbf" generic (parent class) APIs.
Change-Id: Ibf6ae20da99866af5f2b6e12184f3145d1fc0bbf
Split the function into 2 functions, one for assignment on PACCH and one
for assignment on PCH. This makes code calling this API far more clearer
on what is the exact aim when assigning the TBF.
Change-Id: Ic92867e55337b0bd6b5bfc97f13b7982eedb1cb7
In that state (ul_tbf=TBF_ST_FINISHED), we are unable to reach the MS to
assign a new DL TBF.
* MS Is not available in CCCH because it's attached the PDCH.
* MS won't be able to PKT_CTRL_ACK a PktDlAss on PACCH, because next
thing it will do is to PKT_CTRL_ACK the UL_ACK_NACK(FINACK=1) we
already polled it for, and immediatelly after that it will release the
UL TBF on its side and go back to packet idle mode.
Hence, we must wait for MS to send the PKT_CTRL_ACK to us in order to be
able to assign the DL TBF in PCH (CCCH).
Related: OS#5700
Change-Id: I7a30db9cc7dae70e04054f1a4dba004bd1780d4a
Those power params are applied in the Pkt Ul Ass sent to the
MS.
In practice it doesn't matter much because the Pkt Ul Ass message is
created later asynchronously by the scheduler (event CREATE_RLCMAC_MSG).
Still it's much cleaner applying the information before allocating the
UL-TBF, since that's an extra independent step.
Change-Id: I63133aa42dcf27a86437b1bc8dc83c30d6718028
There's no sense if doing the lookup and allocation if the message is
not expected, it will be unrefed (freed) afterwards anyway.
Moreover, this way we avoid doing stuff for the WIP code paths which act
on different request ID than TLLI.
Change-Id: I4be8858230a2eebdb33260093d082a005cb9fcd4
Pau Espin
Philipp Maier
Max
Harald Welte
Vadim Yanitskiy