Project

General

Profile

Actions

Feature #5128

open

dec_RlcmacDlCtrlBlock: Get rid of annoying warning about remaining padding

Added by pespin almost 3 years ago. Updated over 2 years ago.

Status:
New
Priority:
Low
Assignee:
-
Target version:
-
Start date:
04/23/2021
Due date:
% Done:

0%

Spec Reference:

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.

Actions #1

Updated by laforge almost 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.

Actions #2

Updated by pespin almost 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.

Actions #3

Updated by laforge over 2 years ago

  • Priority changed from Normal to Low
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)