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
Otherwise it may give the wrong impression that the FSM can be used by
both DL TBFs and UL TBFs, which is not the case (only used by UL TBFs).
Change-Id: I788eae58248fa21732efe802344aa3c0c5031b5a
It is quite common in all osmo-pcu code to have to convert between
parent class "tbf" and children "dl_tbf"/"ul_tbf", or other way around.
This commit adds new helper static inline functions to cast between
those while doing type checks.
This is used by new LOGPTBFDL and LOGPTBFUL macros to now expect the
proper subclass and cast securely inside the macro itself, hence sparing
all code calling those macros to have to cast explicitly the pointer to
the parent "tbf" class.
Change-Id: I7e4489ad4b93c9c8442213947e53c10b61fdc5e9
The struct gsm_pcu_if_info_ts is named "gsm_pcu_if_info_trx_ts" in
osmo-bts. Lets rename it since the definition in osmo-bts is newer.
Change-Id: If8b50181d3b609612aa8433b635052aadddd3484
struct gsm_pcu_if_info_ts has a struct member "h", which controls
frequency hopping. This struct member is named "hopping" in osmo-bts, so
lets rename it here as well to be consistent.
Change-Id: I3156b39cc91da07ee3f97e8c8be60fc989cf112b
The LLC queue is already in the MS object. The LLC timer and most
of the logic to enqueue its data is independent from the TBF.
Change-Id: I56b89fcac838d8eb732b629734d5e458e9c806d1
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.
Change-Id: I364d238ff8a82abb14281140fe18b273c0e8f541
Based on information from original commit introducing the functions
(9399046729) and looking at the current
code.
Change-Id: Ia440c672a8d2e11169b41f787239bfbba0989231
This makes no sense and confuses Wireshark, so it shows malformed
packets. We are not sending empty PDTCH blocks to GSMTAP either.
Change-Id: Ic7b6aca4f3af43a6fd47d033c950c711164685a4
Related: SYS#6045
By default systemd will execute service with root directory
(or home directory for user instance) which might result in
attempts to create files in unexpected place. Let's set it
to 'osmocom' subdir of state directory
(/var/lib for system instance) instead.
Related: OS#4821
Change-Id: Ib6acc84c3018e468f4c320bc2a3003ba906e4aeb
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[2]: *** [Makefile:1464: clean-local] Error 1
This dependency is present in all other Osmocom projects.
Change-Id: Id9bf06392ad31e1ecc66a5bd13069a915183a76b