This also fixes a memcpy writing out of bounds reported by Coverity
CID#323120 in gprs_rlcmac_tbf_ul_ass_start_from_dl_tbf_ack_nack(), due
to the difference of size between struct gprs_rlcmac_ul_tbf_allocation
and struct gprs_rlcmac_dl_tbf_allocation.
While fixing it, actually properly implement passing of the 1 only
interesting TS to the tbf_ul_ass_fsm at that point in time.
Change-Id: I89b15982b73f00599183981142495d7b9befbb78
Some solutions are not meant to be final ones, but some small
workarounds to have the whole thing running until the lower layers are
fixed/improved.
Related: OS#5500
Change-Id: I94bd0de6917b004cba73d2fffc7cf69b3b5c305d
This is unfortunately not yet working since lower layers are always
sending hardcoded fn=0 and hence ctx->tbf_starting_time calculated in
handle_imm_ass()->TBF_StartingTime_to_fn() is wrong.
Related: OS#6130
Change-Id: If6b7766ee1ba6667db4e54e897f376f5b27ad73d
This code part will also be used by tbf_ul_ass_fsm.c to temporarily
configure lower layers with ctx->phase1_alloc in order to receive RTS
indications which the RLC/MAC uses to tick the FSM in state
GPRS_RLCMAC_TBF_UL_ASS_ST_WAIT_TBF_STARTING_TIME1.
Change-Id: I174327b25b726662a6b5902008e205ddb3de2fe0
This simplifies the array handling in the LLC queue, and moves param
checking to the rx rlcmac_prim path instead of deep in the llc_queue
enqueuing code.
This commit also fixes the RADIO_PRIORITY field in the Channel Request
Description section of PKT DL ACK/NCK, since
gprs_rlcmac_llc_queue_highest_radio_prio_pending() now returns the enum
normalized 0..3 as expected by the field format (before it was returning
1..4).
Change-Id: If2d1946522bc4a1c19d65acb23605f1a3f05ab45
This allows gathering more information on the state of the queue and
helps in understanding possible bugs on the CV calculation algo.
Related: OS#6108
Change-Id: I97f4977944a6f82abc7b39c4e578de9d8e152740
Problem this patch is fixing:
The current RLCMAC window code ported from osmo-pcu is never
invalidating the BSNs which have been received after they are not
needed.
As a result, when the DL TBF keeps sending data for a long time, and
finally BSN wraps around 127->0, when this implementation receives the
BSN=0, it will find it is already received and hence will discard it,
and then keep asking for BSN=0 nevertheless in PKT DL ACK, causing an
endless loop where PCU stays submitting the same block forever.
Explanation of the solution:
The V(N) array contains the status of the previous WS (64 in GPRS) data
blocks. This array is used to construct the RRB signaled to the peer
during PKT DL ACK/NACK messages together with the SSN (start sequence
number), which in our case is mainly V(R), aka one block higher than the
highest received block in the rx window.
Hence, whenever PKT DL ACK/NACK is transmitted, it contains an RRB
ranging [V(R)-1,...V(R)-WS)] mod SNS (SNS=128 in GPRS).
The receive window is basically [V(Q) <= BSN < V(R)] mod SNS, as is of
size 64.
The V(R) is increased whenever a highest new block arrives which is in the
receive window (guaranteeing it will be increased to at most V(Q)+64.
Since we are only announcing state of blocks from V(R)..V(R)-WS, and
blocks received which are before that BSN are dropped since don't fall
inside the rx window, we can securely mark as invalid those blocks
falling behind V(R)-WS whenever we increase V(R).
Related: OS#6102
Change-Id: I962111995e741a7e9c230b2dd4904c2fa9a828e9
This is used by lower layer L1CTL to notify the upper layer RLCMAC when
it's prepared to use CCCH.
Change-Id: I4cfb1e2db217a97b7a1dc8849cd13d58e4034c56
TS 44.018 3.5.2.1.4:
"The one phase packet access procedure is completed at a successful
contention resolution. The mobile station has entered the packet transfer
mode. Timer T3141 is stopped on the network side. Timer T3164 is stopped
on the mobile station side."
Change-Id: Ic7420a42e2e81effdde587d7e49acd66b404354c
* Send the PDCH_ESTABLISH.req on receipt of RR IMM ASS,
* Sending of PDCH_RELEASE.req is to be implemented.
Change-Id: I2568c58646ce7511367275ac96cd55e7fdd7ec18
Related: OS#5500
In the test more PDUs are submited in LLC in order to avoid trigger
max_retrans=4 for last block, which would trigger beforehand in that
case.
Change-Id: Ia83173afdbb25df18c7cead7857fe1b39a1ce82f
The Countdown procedure (decreasing CV field in UL RLCMAC data blocks)
is defined in TS 44.060 9.3.1.
It is implemented by means of counting/calculating the amount of RLC/MAC
blocks to be transmitted based on the LLC frames in the several LLC
queues, without actually generating the RLC/MAC blocks. The blocks
cannot be generated ahead of time because that wouldn't allow recreating
them in case Tx UL CS changes, or if a higher priority LLC frames
arrives.
The functions calculating the required amount of RLC/MAC blocks are
coded so that they early return to avoid spending more time than
necessary counting blocks (< BS_CV_MAX).
An extra heuristic optimization to be used when LLC queues are long is left
documented as a TODO, in order to test further the general non-optimized
path for now. Once the counting is proved to work reliably, that and
other heuristic optimizations ca be implemented, like keeping and
decreasing CV cached counter while no Tx CS change occurs or no new LLC
frames are enqueued.
Change-Id: If043c86a0c2b89d0ac0b8174de39fbcb22bed8cb
According to 3GPP TS 45.002, section 6.3.2.2.1, in the case of multi-
slot Uplink TBF allocation, a USF (Uplink State Flag) is given for
each PDCH allocated to the MS. Thus we need to indicate a USF value
for each PDCH to the lower layers: add ul_usf[8] to cfg_ul_tbf_req.
According to 3GPP TS 44.060, section 5.2.2, in the case of multi-slot
Downlink TBF allocation, a DL TFI (Temporary Flow Identity) given to
the MS is not limited to the scope of a single PDCH and applies to
all timeslots allocated. We're already doing this fine.
Change-Id: I1dda0b4eedcaca7e93f832fc875507028c3ff3eb
Related: OS#5500
The comment above the invocation of configure_ul_tbf() suggests that
the lower layers need to be notified about the *release* of a tbf_nr.
Change-Id: Iabfe9c7ee23335d6eae8017071651b78a36079bf
Related: OS#5500
The DL_TBF for the assignment is not created until later on when the
DL_TBF is first used, only the DL_ASS request is stored as part of the
gpre->tbf_dl_ass_fsm.
Since no DL_TBF existed, the POLL was being stored if the DL_ASS
referred the UL_TBF by means of GlobalTFI->ULTBF.
Instead, let's not require an UL_TBF to be present and simply pass the
GRE along which can be used to send the PKT_CTRL_ACK later on when the
scheduling the poll triggers.
Change-Id: Icdaa30e9ff942fb53cc4bbd801e4542b8885b32a
While reworking tbf_ul_ass_fsm, avoid being in "ASSIGN" state while
waiting to send Pkt Ctrl Ack. The PCU is free to ask the TBF to transmit
data before receiving Pkt Ctrl Ack; the time where it can start
transmitting data is actually controlled by TBF Starting Time.
Change-Id: Id81f16743f2c464e01caf27ba2eb8c0fc715fe8a
The TI bit was correctly set (together with the TLLI) in
create_new_bsn(), but was not properly propagated later on in
create_ul_acked_block() to the intermediate struct before the final
encoding to the packed structure containing the final message
(gprs_rlcmac_rlc_write_ul_data_header).
Change-Id: I6ba361bc9bc47230954cca19c7f2f8cf74d8278e
We'll need to get one event for each Pkt UL ACK/NACK the UL TBF receives
in order to implement T3182 properly in a follow-up patch, hence rework
the events sent to the FSM (merge events about Final ACK and Contention
Resolution in one generic UL ACK/NACK event with some data parameters).
Change-Id: I4420abd69a318bd93fde73a67239456466071497
If there's only 1 block to be sent, the LAST_UL_DATA_SENT was being sent
before the FIRST_UL_DATA_SENT one, which created problems in the FSM
(when adding more logic later).
Furthermroe, this change also makes it send retransmission events, which
makes it similar for both FIRST and LAST events. This will also be
needed for T3182.
Change-Id: I701dbe00ff2af62c45d862a9211b5b1120f3efa3
Measurement related functionality is not yet implemented and hence the
related fields cannot be filled in yet.
Related: OS#5500
Change-Id: I6ae2df07929fb6c4733e87b18cebe75a6f24f520
This commit imports pdch_ul_controller.{c,h} from osmo-pcu.git
d8cea3c618dbd2a343e6c012e5545006d44fc244 and adapts it to be of use on
the MS side.
Related: OS#5500
Change-Id: I9d38a8de4240e65585cc8bbe3c044473af5a83e5
This code imports code from osmo-pcu.git
d8cea3c618dbd2a343e6c012e5545006d44fc244 (heavy modified to adapt to
current code base).
With this patch the RLCMAC layer is already capable of decoding RLC/MAC
GPRS data blocks and submit them as LLC frames to the upper layer.
Related: OS#5500
Change-Id: Ie7535606916c0800c0e1bd9555be022c81ea257d
This patch only introduces the gprs_rlcmac_dl_tbf subclass and
allocates/frees it based on PCH ImmAss, and adds initial paths for
received blocks. It also provides a unit test to showcase the scenario.
Change-Id: I7f98e3456ef35d80becdad3481afeb771457b0ef
This is basically an import of relevant code from osmo-pcu.git
08523c2286dfe27402f8e2eb4b98da5a529c7915 which allows encoding LLC
frames into RLC/MAC uplink data blocks.
A 1-to-1 import was not possible for several reasons:
* osmo-pcu uses C++ in some places
* osmo-pcu implements encoding of DL data blocks, not UL data blocks
* Some osmo-pcu code is still not really polished and stuff is still
mixed (for instance rlc_window(_ul).c/h were split into their own
files here).
Hence this was not a "copy all files and leave as they are" import, but
rather looking at the encode path starting on osmo-pcu.git scheduler and
see which code had to be pulled in to encode the RLC/MAC blocks.
Due to the slightly different requerirements for UL and DL blocks, it is
well possible that further work in needed in order to have the code
produce correct blocks. This is only a first step to pull in all code so
that stuff can be fixed in smallish incremental steps.
Related: OS#5500
Change-Id: I0a01d79d16bbfc63aa88e6bb0f432f3772645730
Pau Espin
Vadim Yanitskiy