Currently the DL Ack/Nack is not requested, if the last chunk of the
final LLC frame in the TBF fits exactly into the remaining space of
the RLC block. It is also not requested, if the RRBP flag cannot be
set due to scheduling issues (single block allocation, polling
already pending for this TBF, ...). So up to POLL_ACK_AFTER_FRAMES
(20) RLC data blocks will have to be resent, before requesting the
Ack/Nack will be retried.
This commit removes the first_fin_ack parameter of
create_dl_acked_block entirely and adds a request_dl_ack() method
that should be called, when the TBF's state changes to FINISHED. This
request will be reset, when the block has been scheduled
successfully. Since the first_fin_ack hasn't been set if chunk ==
space, calling request_dl_ack() on both places in create_new_bsn()
when the state is changed to FINISHED will also fix the first issue
described above.
Note that DL scheduling might not be fair concerning access to
first_ts when multiple TS are used for a TBF. In theory, a TBF might
never get access to first_ts in the worst case.
Sponsored-by: On-Waves ehf
Currently two DL TBF objects with the same TLLI exist after reuse_tbf
which make the result of tbf_by_tlli undefined. This leads to several
DL TBFs belonging to the same TLLI.
This commit extends tbf_by_tlli to check the m_tlli_valid flag for
DL, too. That flag is set to 0 in reuse_tbf to mark the 'old' DL TBF
as invalid after its LLC data has been copied to the new one.
Sponsored-by: On-Waves ehf
If the PCU didn't receive the downlink ack/nack when it was polled there
is no reason to assume it will arrive at a later time. In that case
N3105 is already increased, but the next block sent should have a valid
RRBP set as well to poll again.
This can happen if either the BSN with the valid RRBP gets lost on the
downlink or the DL ACK/NACK gets lost on the uplink path.
Ticket: SYS#382
Sponsored-by: On-Waves ehf
There are a couple of possibilities where one TBF is used to assign a
new one:
1. Assign a DL TBF from a UL TBF
2. Assign a UL TBF from a DL TBF
3. Assign a DL TBF from a DL TBF which is in wait-release state (T3193 is
running)
In these cases the assignment is sent on the existing TBF and triggers
the assignement of the new TBF (with different TFI/direction).
The current code detects these situations by looking at dl/ul_ass_state
and then chosing the TBF with the opposite direction (DL/UL) that has
the same TLLI. This does not work in the case 3 above where a new DL TBF
is triggered for a DL TBF. The current code reuses the old TBF (and
TFI), but this violates the spec.
This patch introduces a m_new_tbf member which is set to the new TBF to
be assigned. When receiving a control ack the code looks up the
n_new_tbf member of the tbf that requested the control ack and completes
the ul/dl assignment. If the old TBF was in the wait release state
(T3193 is running) it is released.
From 3GPP TS 04.60 9.3.2.6:
"""
If the network has received the PACKET DOWNLINK ACK/NACK message with
the Final Ack Indicator bit set to '1' and has new data to transmit for
the mobile station, the network may establish a new downlink TBF for the
mobile station by sending the PACKET DOWNLINK ASSIGNMENT or PACKET
TIMESLOT RECONFIGURE message with the Control Ack bit set to '1' on
PACCH. In case the network establishes a new downlink TBF for the mobile
station, the network shall stop timer T3193.
"""
reuse_tbf() is modified to allocate a new TBF with a new TFI and trigger
a dl assignment for that TBF on the old TBF. All pending data is moved
to the new TBF.
Ticket: SYS#382
Sponsored-by: On-Waves ehf
Jacob Erlbeck
Daniel Willmann