The previous gprs/protocol/gsm_04_60.h header from libosmogsm was
misleading because it was placed in the subdirectory used by libosmogb,
and hence was recently deprecated in favour of gsm/protocol/gsm_04_60.h.
Let's follow the pragma message advising to move to the new header file.
Depends: libosmocore 0158b05337a825352d9fd7f074170b686e9fd1e5
There is a function l1if_connect_pdch, but no complementary function
like we have it with l1if_open_pdch and l1if_close_pdch. The reason for
this is that the PHY implementations that rely on a femtocell DSP do not
need to disconnect the pdch explcitly. However, the planned support for
the E1 based Ercisson RBS CCU will require an explicit disconnect. So
lets add a function call for this.
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
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
Note: this also fixes FnTest which uses invalid frame numbers for
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
Unit test test_ms_merge_dl_tbf_different_trx showcases the above
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
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.
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.
First commit towards trying to have alloc algorithm as isolated as
possible from others parts of the code trying to avoid state changes on
Change name also because the alloc_algo not only allocated TS, but TFIs
* Make clear the code relates to DL-TBF and not UL-TBF.
* Change wording to "upgrade" to match the existing field and API
* Free the TBF if we cannot allocate new resources.
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.
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
* 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
This is a preparatory step towards splitting tbf_fsm.c into tbf_ul_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
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.
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.
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
A counter is removed which was counting contention resolution (MS) on
the wrong place.
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
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.
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.
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
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).
Those power params are applied in the Pkt Ul Ass sent to the
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.
That's the special value checked in the implementation of get_ms() to
skip lookups based on TLLI.
This should save some cicles trying to match TLLI 0.
I believe this may be related to sporadic failures we hit on Jenkins:
test -z "atconfig" || rm -f atconfig
../../../tests/testsuite: line 987: ./atconfig: No such file or directory
make: *** [Makefile:1464: clean-local] Error 1
This dependency is present in all other Osmocom projects.
The timeout is set to a high value to avoid freeing the MS during main
loop iteration. Let's set it back to 0 to have a common free path in