| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Dispatching TBF_EV_CONTENTION_RESOLUTION_MS_SUCCESS means the UL TBF is
able to be used to assign DL TBFs over PACCH.
However, there's an extra implicit restriction: if the PCU already sent
the final UL ACK/NACK to that UL TBF, then whatever message sent
after it cannot be reliably answered, since the MS will go back to idle
state after issues the PKT CTRL ACK for that final UL ACK/NACK.
This condition is already being checked in
contention_resolution_success():
"""
if (ms_need_dl_tbf(ms()) && !tbf_ul_ack_waiting_cnf_final_ack(this))
ms_new_dl_tbf_assigned_on_pacch(ms(), this);
"""
Since we are considering the UL TBF to have done contention resolution
when we transmit the *first* UL ACK/NACK, it mans we are doing both things
on the same code path iif the *first* UL ACK/NACK is at the same time
the *final* UL ACK for that UL TBF. This can happen if the UL TBF is
only sending 1 block, which will have CV=0. This can usually happen
during GMM Attach Request.
In this scenario, with current code goes into a situation where first
the TBF_EV_CONTENTION_RESOLUTION_MS_SUCCESS is triggered and *afterwards*
the UL_ACK/NACK state is updated. As a result, the code snippet check
above (!tbf_ul_ack_waiting_cnf_final_ack()) will be true and the DL TBF
be assigned, but afterwards in the same code path it figures out the
final ack happens.
In order to fix this, first update the ACK/NACK state and only
afterwards trigger the Contention Resolution Success event.
Change-Id: I62ae91b494e4fd0ade3f4a3ba3817bcaedbdebf5
|
|
Change-Id: I51ebe8174006380821eb978bbd78f600c10b02e7
|
|
After some earlier refactoring, those fields are only used internally in
the module, and hence can be marked as static.
Change-Id: Ibf2a6ee5636ae7102ffd13b7497769652bcc3202
|
|
Change-Id: I5ecc57c72e7f60e31e64e76e724d7a5a95968c40
|
|
Change-Id: I1c7140b35b7c93d3df4156841e908d3b44d7336d
|
|
The pdch pointer contains more info than just timeslot number. For
instance, it contains information about the TRX owning the TS.
Change-Id: Ic31a7360a29e61f70bb1338ddab6f5f31aa8b26e
|
|
Let each subsystem handle that internally.
Change-Id: Ifaf7dde651d56942779d84aa9135fc8c974b6f26
|
|
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
|
|
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
|
|
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 UL_ACK_NACK FSM is only used in Uplink TBFs.
Change-Id: Ic9893d274f4b6fafc75a615f7d6dcb9433b94ace
|
|
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
|
|
When setting a POLL, it will always happen on PACCH, so all the CCCH
part makes no sense there. Let's drop it and move the logging of each
case to the caller, where logging file+line is more useful.
Change-Id: I242f97fd6f927131ac64c1a7c9c3812b6389de04
|
|
Related: OS#2709
Change-Id: Icf23bf5a4b85fbcbf1542cebceb76b9ba7185d30
|
