Feature #5128
opendec_RlcmacDlCtrlBlock: Get rid of annoying warning about remaining padding
0%
Description
While running PCU_Tests, (probably) ./library/RLCMAC_EncDec.cc prints lots of warnings at runtime, for each RLCMAC block parsed, due to final padding not being parsed:
BTS(438)@41804d0dad09: Warning: dec_RlcmacDlCtrlBlock(): Data remained at the end of the stream after successful decoding: '2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B'O ("+++++++++++++++++++++") BTS(438)@41804d0dad09: Warning: dec_RlcmacDlCtrlBlock(): Data remained at the end of the stream after successful decoding: '2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B'O ("+++++++++++++++++++++") BTS(438)@41804d0dad09: Warning: dec_RlcmacDlCtrlBlock(): Data remained at the end of the stream after successful decoding: '2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B'O ("+++++++++++++++++++++")
Ideally we should modify ./library/RLCMAC_Types.ttcn and have a "octetstring padding optional" or alike, and the Decoder should put the decoded padding in there.
Or even simpler, read the padding bytes to avoid this kind of warnings.
Updated by laforge about 3 years ago
I think I tried at the time I wrote this, but couldn't find a method that worked. But that was years ago, with very limited TTCN/TITAN knowlege, and with a much older version of TITAN.
Updated by pespin about 3 years ago
I think I initially misunderstood the possible cause due to creating the ticket quickly.
IIUC, the warning is probably logged when from ./library/RLCMAC_EncDec.cc C function dec__RlcmacDlBlock(), we end up calling:
ret_val.ctrl() = dec__RlcmacDlCtrlBlock(stream);
which is defined as titan external function in TTCN3 RLCMAC_Types.ttcn:
/* TS 44.060 10.3.1 Downlink RLC/MAC control block */ type record RlcmacDlCtrlBlock { DlMacHeader mac_hdr, DlCtrlOptOctets opt optional, RlcmacDlCtrlMsg payload } with { /* Automatic padding by RAW encoder seems to causing problems * due to padding sequence 2b inserted shifted from octet * boundary on some messags. See UL CTRL blocks in TC_t3193. * See 3GPP TS 44.060 Figure 11.1 (below) * variant "PADDING(184), PADDING_PATTERN('00101011'B)" */ variant (opt) "PRESENCE(mac_hdr.payload_type = MAC_PT_RLCMAC_OPT)" }; external function enc_RlcmacDlCtrlBlock(in RlcmacDlCtrlBlock si) return octetstring with { extension "prototype(convert) encode(RAW)" }; external function dec_RlcmacDlCtrlBlock(in octetstring stream) return RlcmacDlCtrlBlock with { extension "prototype(convert) decode(RAW)" };
So ideally we should have a "octetstring padding optional" at the end of "record RlcmacDlCtrlBlock", but titan seems to be having some issues? Apparently I wrote those comments in following commit but I don't recall doing so lol:
commit cb00c52b0727ae10086bdc8417060110f317900b Author: Pau Espin Pedrol <pespin@sysmocom.de> Date: Fri Nov 6 19:52:05 2020 +0100 pcu: Specify (M)CS to use when sending UL rlcmac data blocks Apply padding and spare bits in the encoder according to CS/MCS format. Change-Id: I918acac81f550077daeda3374b3de9b426ff3572
So it seems I did some related work but for the "encoder" part, while this issue shows up in the "decoder" one.