Miscellaneous Projects » Core testing infrastructure

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.

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.