Function f_rx_rlcmac_dl_block_exp_data() still misses proper
verification of data. Apparently the received message has 2 blocks,
first with expected 10 bytes, but next one contains 18 bytes with 4
actual bytes and other bits are padding.
Last DL ACK/NACK sent is not yet working correctly. osmo-pcu seems to be
unable to match it against sent DL block (I think due to non-matching
FN), and instead drops it and schedules after timeout an IMM ASS to try
to send DL block again.
Change-Id: Icf66dd5c07690368722c586632c38fb7e770053c
There's also DL_ACK_NACK message for which a template will be introduced
soon, so let's rename and fix typos/wrong descriptions to avoid
confusion later.
Change-Id: I4a2025ad282006953fcfadf429c980b77cb94371
This change introduces a new test case TC_cs_lqual_ul_tbf, which
is aimed to test the feedback of OsmoPCU on changing link quality
measurements in Uplink Data blocks during an active TBF.
Change-Id: Ia78d93e43a3c41b0b30e70df20a2da31077fd05f
Related: SYS#4607
Some of our files didn't have a copyright notice at all, let's add
it. Also, update the notices in other files and ensure a SPDX
identifier is present in all but the most trivial files.
Change-Id: If7fa19ce484b415bc645e39b3d0d666b44b5f0fd
Their format is simply too complex to be used with the automatic RAW
encoder/decoder. Let's implement it by hand, using the automatic
coder whenever possible.
For Downlink and Uplink RLC/MAC Control blocks this is already working
quite nicely. Data blocks is not working, as their encoding cannot be
expressed in TTCN-3 RAW syntax, and a mixture of C++/native and
RAW-generated coder will be required.