After some earlier refactoring, those fields are only used internally in
the module, and hence can be marked as static.
Change-Id: Ibf2a6ee5636ae7102ffd13b7497769652bcc3202
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
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
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
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
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
Remove the paragraph about writing to the Free Software Foundation's
mailing address. The FSF has changed addresses in the past, and may do
so again. In 2021 this is not useful, let's rather have a bit less
boilerplate at the start of source files.
Change-Id: I4a49dbeeec89b22624c968152118aecf8886dac6
The whole paging path and data structre is cleaned up.
New MS helpers ms_imsi_is_valid() and ms_paging_group() are introduced
to help in the process and keep implementation details inside GprsMs
class.
Related: OS#5303
Change-Id: I4c0838b26ede58e4b711410eee2a8e4f71e9414b
Code above setting the timer in same tbf_fsm already has this kind of
assert, but it helps understanding the code having this assert here.
Change-Id: I7588deef5073694eb5fecdb516c241a04594e2b0
Seen on a runnig osmo-pcu against real MS:
"""
pdch_ul_controller.c:329 PDCH(bts=0,trx=1,ts=7) Timeout for registered POLL (FN=751140): TBF(TFI=0 TLLI=0xe8c12143 DIR=UL STATE=ASSIGN EGPRS)
tbf.cpp:542 TBF(TFI=0 TLLI=0xe8c12143 DIR=UL STATE=ASSIGN EGPRS) poll timeout for FN=751140, TS=7 (curr FN 751140)
tbf.cpp:384 TBF(TFI=0 TLLI=0xe8c12143 DIR=UL STATE=ASSIGN EGPRS) N3105 exceeded MAX (8)
tbf.cpp:594 TBF(UL-TFI_0)[9bc050]{ASSIGN}: Received Event MAX_N3105
tbf.cpp:594 TBF(UL-TFI_0)[9bc050]{ASSIGN}: Event MAX_N3105 not permitted
"""
It was first though when FSMs where introduced that an FSM in ASSIGN
state could not receive this kind of event because it was believed to be
sending no CTRL blocks at all until flow state. That's because the
believe was that Assignment over PACCH was done by another existing TBF.
It turns out this is usually the case, but not in all cases. In at least
one case, the tbf object (and tbf_fsm/tbf_{ul,dl}_ass_fsm) itself is
handling its own assignment (hence eg. sending the UL assignment and waiting
response through tbf_ul_ass_fsm. This happens if a UL TBF sends a Pkt
Resource Req as a response to RRBP of final UL ACK/NACK in order to
request a new TBF, where it temporarily uses the control_ts of the
previous TBF to get a new Pkt UL Assignment over PACCH.
If Pkt Ul Assignment doesn't receive a CTRL ACK, tbf_ul_ass_fsm will
retrnamist it, until MAX_N3015 is reached (the event we failed to
handle until now). At this point, we really want to transition to
RELEASING in order to avoid keeping the TBF allocating resources (until
X2001 times out).
Related: SYS#5647
Change-Id: I86d5c1bbccd06673d08451b812d149e727404733
This helps distinguishing the case where a TBF is in the initial state
and the unexpected case where osmo_fsm_inst_state_name reports "NULL"
due to fi pointer being NULL.
Change-Id: Ieaabfc9fa0dedb299bcf4541783cf80e366a88c3
Fixes following error log line:
"{RELEASING}: Event DL_ACKNACK_MISS not permitted"
Rationale: We may move to RELEASING state at some point, for instance
due to MAX_N3101/MAX_N3105 while still having some active poll
registered in some PDCH ulc. Upon that poll (most probably) timing out,
it will send a DL_ACKNACK_MISS event to us. Since we are already
determined to release the TBF (waiting for T3195 or T3169 to trigger),
simply ignore the event and avoid logging an error.
Fixes: OS#5240
Change-Id: Ibfb49356d2b3b5fccb6d59db8593b2256e5c51fb
The side effect is that the timer is enabled for other scenarios where a
PACCH assignment happens, like an Assignment Reject or Ul Assignment
(that's why there's more lines showing up now in TbfTest.err).
Change-Id: Ib8ab2f7397ad05c6fcd5dd74af55a1e2c56e1463
PdchUlcTest output changes because the original state NULL is not
expected when transactioning to RELEASING upon MAX N310* being hit. In
any case, none of those events should happen in NULL state, but we
don't really care about TBF states there so we are fine with whatever
the state is.
Related: OS#2709
Change-Id: I516b8d989a0d705e5664f8aeaf7d108e0105aa16
While at it, method maybe_start_new_window is renamed to
rcvd_dl_final_ack to make more sense out of the code.
Related: OS#2709
Change-Id: Iebd650c1036ef2d5132789778be7117ce3391c01
At some point later in time the state_flags will most probably be split
into different variables, one ending up in a different FSM. It is moved
so far to the exsiting FSM from the C++ class since it's easier to
access it from C and C++ code, and anyway that kind of information
belongs to the FSM.
Related: OS#2709
Change-Id: I3c62e9e83965cb28065338733f182863e54d7474
This is only an initial implementation, where all state changes are
still done outside the FSM itself.
The idea is to do the move in several commits so that they can be
digested better in logical steps and avoid major break up.
Related: OS#2709
Change-Id: I6bb4baea2dee191ba5bbcbec2ea9dcf681aa1237
Pau Espin
Oliver Smith