If in those states, we already left the FINISHED step which means we
already received a FinalACk previously, hence it means we are missing
requested retransmissions of the last DL ACK/NACK due to fn-advance
(several DL blocks in transit before receiving UL response).
Change-Id: Ib0f23a9cc3c614fe428b682e01502930cd2e478f
Due to the fn-advance feature, we schedule DL blocks in advance, which
may make several retransmitted DL ACK/NACK [RRBP] be in flight, and
hence several of them may be answered by the MS.
When the first one is received, we attempt to initiate a PktDlAss over
PACCH if new DL data was received meanwhile from SGSN.
However, if we receive duplicates of that final PKT CTRL ACK, we don't
want to re-initiate it again, since it is already ongoing.
Related: OS#5471
Change-Id: Idc204aba61ad98f75853dcd46200f5dcc4139203
T3192 on the MS side (boadcasted by the network on SI13) is used for the
MS to stay monitoring the PDCH of a DL TBF after sending PKT DL ACK/NACK
for the last DL data block (FinalAck=1).
T3193 is the counterpart in the network, defined as >T3192, which is
used to make sure the TFI is no longer used by the MS and hence can be
reused/re-assigned again.
Hence, we want to differentiate between those 2 timers, since the first
one gives us information on how late can we still tx PktDlAss on PACCH
on that DL TBF, while the later only provides info on when to free the
DL TBF in order to reuse the TFI.
Change-Id: I7421342461bf159d945651037e6fe690f88c6fae
When sending the last DL block, the FSM moves FLOW->FINISHED. Hence, it
is impossible to receive the FINAL_ACK in state flow, when we didn't yet
sent the last DL block (it's only possible if there's a bug in the MS).
TbfTest need to be adapted since they where acting wrong.
Change-Id: I3288743ff01ff84c3d345b6efb7c3fb6ca934791
It makes more sense to have it there, where it is transmitted with more
control depending on current state. Furthermore, it's
counterpart/continuation TBF_EV_ASSIGN_PCUIF_CNF logic is already there,
so it makes sense to have the whole logic together.
Change-Id: I8af39d3087ccf197321f0c71cb29b67adbe1f36e
That flag was still in state_fsm for historical reasons (refactoring
steps), but it's not really the best place for it, since it's really
specific to dl_tbf and to transmit of data and DL ACK/NACK not the
overall state of the TBF.
Change-Id: I12c28c1a52f363f2d17a8bc24bbdf379543fc7a6
First print what is going to be attempted, later alarm about the
possible error, finally early return.
Change-Id: I417e9689f60e7f5d3c8ef67543e56fea87c8eebd
That path should not really happen. It happening would mean a totally wrong
code being used. Hence, just abort() to simplify the code.
Change-Id: Iaf65e909e45cc279e5be4b045c15174f910ffc12
We are no longer making use of the 4 high bits in state_flags, so we can
safely drop masking them.
Change-Id: I1402310919578a09669530786296f34bf3b23ef2
T3169 is triggered as consequence of N3101 and N3103 reaching MAX. Those
counters are related to UL TBF only, and hence T3169 also only applies
to UL TBFs. The references to T3169 were there as a remains from time
where we had a single tbf_fsm for both UL and DL TBFs. It can now be
further simplified.
Change-Id: I02f7654518da617ce6704d807d34761dbadecf07
After some earlier refactoring, those fields are only used internally in
the module, and hence can be marked as static.
Change-Id: Ibf2a6ee5636ae7102ffd13b7497769652bcc3202
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
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
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
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
Pau Espin