The function neigh_cache_lookup_entry() is only used from within
neigh_cache.c. Let's make it static and move it, so that we do not need
the prototype declaration.
Change-Id: I1ea72ad9c79bfeaa06391cf8f62b284fbfea8efc
Scenario: A DL TBF is assigned over PCH (CCCH) and we start transmitting
DL data blocks blindly after X2002, but at the same time the MS start
packet-access-procedure to request an UL TBF.
Right now osmo-pcu correctly detects the MS is available in PDCH and
re-assigns a DL TBF using PACCH, but the LLC frames it transmitted in
the old PCH-assigned DL TBF get lost when that older TBF is freed
(because the DL blocks were removed from the GprsMs llc_queue).
This issue is now more frequent since X2002 timer was added recently to
delay starting requesting USF for a UL TBF, hence the contention
resolution in general takes more time and hence the PACCH assignment of
the DL TBF takes more time too, so more DL data blocks are transmitted
to the DL TBF assigned over PCH during that time.
This patch improves the situation to at least recover the DL blocks
transmitted if the DL TBF is freed (due to MS merge trigger by scenario
mentioned above), where no DL ACK/NACK was ever received by the MS.
Ideal solution would be to have complete tracking of which LLC PDUs from
the llc_queues were completely ACKed at RLC/MAC level, but that really
requires a lot of work and major refactoring, which are left as a future
improvement.
Change-Id: I9be4035fb2cf2b3ee56e91dcc12cc8c24028b4aa
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
In RELEASE state, the UL TBF is considered not available anymore, and we
are simply waiting in order to be able to reuse the allocated resources
(just in case it was still around). Hence, a UL TBF in that state should
not be selectable to initiate a DL TBF assignment over PACCH.
Related: OS#5472
Change-Id: Ia11f7802779cfeea15a71bddad9f7e0c6c1afb11
Otherwise the scheduler selects the UL TBF for USF during that time, and
of course no one has that USF assigned yet, so no answer and that ends
up triggering MAX_N3101 on the UL TBF.
This is specially important when PCU is connected to the BSC, since the
amount of time for the ImmAss to be scheduled on the BTS and reach the
MS can be bigger.
Change-Id: I48babd70ca44f11110240cbcfbab43d0e3a0fb59
A new state TBF_ST_WAIT_REUSE_TFI was added lately in dl_tbf_fsm, which
allows differentiating the time where the MS is listening on PACCH
after having sent last DL ACK/NACK, and time where it should already be
in idle mode.
In the former, the ms_need_dl_tbf() should return false since the MS is
still ongoing in packet-active mode (and new data incoming from SGSN
will trigger new DL TBF assignment over PACCH as needed), while in the
later we want to start a new PCH assignment.
Fixes: 40a297f3b0
Change-Id: I96f311480d036859511c6ba825ccd36bdc71190b
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
In that code path, new_tbf is an UPLINK_TBF. Uplink TBFs (tbf_ul_fsm.c)
don't use state TBF_ST_WAIT_RELEASE, hence that condition cannot ever be
true.
Change-Id: I379d4140326a46e94914152fe9b735de852ceda0
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
Timer T3192 may be used in the future to know wheter a DL TBF assignment
can be sent on PACCH after the last DL TBF has finished (final ACK).
Change-Id: Ie5f6251ee773f56771f9a9507711a20e6282aac6
That timer is configured by value sent over PCUIF, hence better have it
to the same default value in osmo-bsc/osmo-bts.
Change-Id: I498f05ff4d232164690d177430e90eb99b4eea9d
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
When we receive PCU_IF_MSG_DATA_CNF_DT, we check on PCU_IF_SAPI_PCH.
This is formally not correct, we should check on PCU_IF_SAPI_PCH_DT
instead.
(This patch will only affect osmo-bsc but not osmo-bts. The reason for
this is that osmo-bts still uses the older PCUIF v.10)
Depends: osmo-bsc.git Id5c799e625c56e57f7b51cd4fb57f5bea9c973d2
Change-Id: I0883b51fc232ec0267f1511c3a37c0bcd0967a08
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
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: I6b44121bbe185b58f3a77be8c12b4ef1f3180a30
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
It makes no sense to continue trying to assign the UL TBF over PACCH
after T3168 * 4 retrans time out.
This helps in releasing the TBF after we got rid of incorrect use of
N3015 in UL TBFs.
While at it, update tbf_ul_fsm to use T3168 instead of X2001, since it
really needs to match T3168. Ideally it would not even have a timer
itself and receive an event from tbf_ul_ass_fsm, but that's left as a
TODO (it was already before) and simply the timer is updated.
Change-Id: I87dff68dedd06b60501e7586d20faf02bb1f0c93
T3195 is triggered as consequence of N3105 reaching MAX, which only
occurs in DL TBFs. Hence, T3195 also only applies to DL TBFs.
The references to T3195 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: I07a43c13289d50707115187a3f22df21443a7b4a
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
This counter is only used in DL TBFs as per TS 44.060.
section 13.4 "N3105":
"When the network after sending a RRBP field in the _downlink RLC data block_ ..."
(DL data blocks are only sent in DL TBFs).
section 8.1.2.1:
"If N3105 = N3105max, the network shall release the downlink TBF internally
and start timer T3195 for that TBF. When T3195 expires, the network may reuse
the TFI"
Change-Id: I4d4f4d4d3e6e0539ea8ec2395bed00d059b84e04
N3103 counts retransmits of PACKET UPLINK ACK/NACK with FinalACK=1. As a
consequence, this counter only applies to UL TBFs.
Current code is only using it in UL TBF, but add an assert to clarify
and make sure it is not used unproperly in the future.
Change-Id: I026d6145249ef19694f673ec7b4928af9d401dd6
TS 44.060 13.4 "N3101" clearly states this counter relates to UL TBFs,
since it only applies to TBFs for which USFs are set:
"When the network after setting USF for a given TBF, receives a valid data block of this TBF from
the mobile station in a block assigned for this USF, it will reset
counter N3101. If PS Handover is not ongoing, the network will increment counter N3101 for each
USF for which no data is received for this TBF."
Furthermore, N3101 must only be reset for data blocks, so drop all rx
CTRL block patches on UL TBF resetting the counter.
Change-Id: I207f3906d13fc6feea2282e261f468a09db37d86
While at it, fix a typo in the test output.
This function is nowadays only used in ms_current_pacch_slots(), which
is used only to print the PACCH TS (the first common UL & DL TS).
Change-Id: Id1d0b681f6866618f9f3a8c64d6a6c809ca50ea7
The cast for different types it's not really needed, simply use the
unsigned long long version to make sure we don't drop 1s, in any case
__builtin_popcountll() will be quicker than what we used to have.
Change-Id: I80ae72d34d53564fc3da1601ee48c8b2ffe79735
That case should only happen under really rare conditions, like
receiving a RACH.ind before having received any DATA.ind.
Change-Id: I4c71f3481764b501a4441bc735a87725884a3e75
The FN time counter is not really PDCH specific, but to the whole BTS,
and all other calls t the bts_set_current_frame_number() are already
laced in pcu_l1_if.cpp; move it there.
Change-Id: If36f22a1067c904fa7fda87bed5062b6738f0dd1
Those function don't really require the full FN, hence let's pass only
the required information.
This makes the implementation here less dependent on how/if we are able to calculate
full FNs based on RFN: We get an RFN, and we have to encode so that the RFN can be
derived again, so feels less cumbersome having to go through RFN->FN->RFN which may
only cause possible issues if there's some FN timing bug.
3GPP TS 44.018 10.5.2.30 Request Reference:
"The purpose of the Request Reference information element is to provide the random
access information used in the channel request and the frame number, FN modulo 42432"
3GPP TS 44.018 10.5.2.38 Starting Time:
"The purpose of the Starting Time information element is to provide the start TDMA
frame number, FN modulo 42432."
Change-Id: If9b758434c00f2a3868534d5be84946809c989a9
RFN_MODULUS (42432) used to calculate is a multiple of 416:
416 * 102 = 42432
Hence, (X % 42432) % 416 == X % 416.
So, there's no need to derive the full FN.
Change-Id: If7a6a15c373a068bcc757d27937dd6eeac2e0bae
This may happen if a RACH.ind is received before any DATA.ind has been
received.
With usual osmo-bts-trx or osmo-bts-sysmo, this shouldn't happen
nowadays, but it is still a problem with osmo-bts-virtual, where lower
layers don't submit NOPE.ind in the absence of data, and hence it won't
sent DATA.ind to osmo-pcu all the time.
This change helps in showcasing confusing scenarios where the RFN
generated in the Imm Ass was wrong.
Change-Id: I29b7ba828fe890f90e35686bbb04d4abfe56b955
The previous code was really confusing, passing full FNs as RFNs under
certain external conditions, and then assuming the RFN input of
rfn_to_fn() function could actually be a FN.
As a result, we had a lot of code behaving slightly different depending
on whether the incomding FN from pcuif was filled in by a BSC or a BTS.
Avoid this b ehavior differentiation and always assume the most
restricted one, aka RFN.
Change-Id: Ib3b5702168195b595711cd0ff32c211b9aba429d
Philipp Maier
Pau Espin