Before this patch, the last RLC block (CV=0) would only be filled with
up to 1 LLC frame, even if several LLC frames were enqueued and expected
to be put in that RLC frame (CV calculation).
Fixes the unit test provided in an earlier patch.
Related: OS#6351
Change-Id: Id51f595f967b721a5ebe9d44b4e31b6ef9c1b4ae
This in turn delays reconfiguring the lower layers (L1CTL-CFG_UL_TBF.req
mask=0x0) until the last block has been transmited.
Change-Id: Ic38b4207623ccbda3b77d4b0a47431c25de95034
The poll is part of the FSM mechanism to get events to transit over the
different states. Register it from within the FSM to have more fine
grained control as well as have knowledge about the FN being reserved.
This knowledge will be used ina follow up patch for the UL TBF to wait
for the correct PKT CTRL ACK BLOCk.conf.
Change-Id: Iaa8ad8052b9f3b52b05af2b7fc9cb8172f1b6bb7
Test test_ul_tbf_t3166_timeout needs to be modified in order to avoid
triggering T3180 once it is implemented in a follow-up patch.
Both T3180 and T3166 are armed at the same time, so modify the scenario
to really scenify the case where T3166 matters: the MS keeps receiving USF
indications but the PCU doesn't see them and hence never sends a PKT UL
ACK/NACK.
Related: OS#6209
Change-Id: Ib84ccfd89773913703e0ab3e09d0ce9eb123e994
Test test_ul_tbf_t3182_timeout needs to be modified in order to avoid
triggering T3180 once it is implemented in a follow-up patch.
Both T3180 and T3182 are armed at the same time, so modify the scenario
to really scenify the case where T3182 matters: the MS keeps receiving USF
indications but the PCU doesn't see them and hence never sends a PKT UL
ACK/NACK acking the last block.
Related: OS#6209
Change-Id: I73b648bc04d863b9eb67093e5fa510ba88d712c8
Re-arming upon retransmission of block CV=0 is only described in the
unacknowledged mode of operation.
Change-Id: I532def7f87367b446b5370daf8c81f511e26eb5f
The restriction to only to transmit last data block (CV=0) up to 4 times
only applies in Unacknowledged mode of operation, which we don't
support. Hence, simply comment it out so that it can be enabled if
unacknowledge mode is ever supported.
Related: OS#6208
Change-Id: Ie7cdb286b9c7255e3fbf9f936f103fab04acf96a
The RA value does change during RACH retransmissions, so we cannot
expect a specific value in gprs_rlcmac_handle_ccch_imm_ass_ul_tbf()
anymore. Offload checking it to the lower layers.
* Rename submit_rach_req() to submit_packet_access_req().
* Get rid of gen_chan_req(), indicate only the access cause.
Ideally, we should also rename the OSMO_GPRS_RLCMAC_L1CTL_RACH
to something like OSMO_GPRS_RLCMAC_L1CTL_PKT_CHAN_ACCESS, but
let's better do this separately.
Change-Id: If0de3ed86b1e2897d70183f3b0f4fbfd7d2bda80
Related: osmocom-bb.git Iab6d9147f6e0aeb99239affacf318a3897fd6ffe
Related: OS#5500, OS#6131
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
The Starting time contains a "frame number, FN modulo 42432", aka RFN.
The translation to absolute FN was missing.
Depends: libosmocore.git Change-Id Ib71e8da976f6cc84c3a4ab17b0a8c2101492e243
Change-Id: I00741289333853a8db472950ee2ac38dc2c74fd3
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
Recalculating CV when in Countdown Procedure will be implemented in a
follow-up commit.
Related: OS#6108
Change-Id: I1e7b28c2e5f1d77a962ec3070f3a027b8f66a69e
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
TS 24.007, TS 24.008, TS 44.064 nor TS 44.065 explain how the TLLI
update happening during GMM RAU propagates to the SNDCP layer.
GMM only has interfaces towards LLC and GRR, and uses LLGMM-Assign.Req
and GMMRR-Assign.req to update the TLLI in the respective layers.
This patch adds a new primitive in the LL interface (LLC->SNDCP)
LL-Assign.ind to propagate the LLGM-Assign.req received from
GMM towards SNDCP, so that it can use the new TLLI in order to address
the specific MS.
Change-Id: Icb858f5397414b6d4183c21f13d35c0166ca7635
TS 24.007 and TS 24.008 seem to lack providing an explicit way to pass
information between GMM and SM (GMMSM interface) when a RAU process
happens in GMM (rx RAU Accept).
This lack of primitive can easily be spotted by looking at TS 24.007
Appending C.15, or even better, at the 3rd page of "C.16(cont’d)" around
the "STOP Trams" timer, where the info is magically available in SM when
being received at GMM.
Change-Id: I81e207d44d88f18f0ee13fb413827606a6f830bc
The TLLI was wrong (I tooked the one from the Attach Accept msg instead
of RAU accept message defined above).
Change-Id: I2f7d61c72febad24fde285578e20485a23b8e175
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
This information will be needed once the GRR layer starts listening for
paging requests, which identify MS by either PTMSI or IMSI.
Change-Id: I3a0c4a57c3d624c3ebb40ae2cc0c96626ccc2c99