Bug #4849

osmo-pcu: Sending LLC UI Dummy commands inside DL RLCMAC GPRS data blocks for no good reason

Added by pespin 20 days ago. Updated 11 days ago.

Target version:
Start date:
Due date:
% Done:


Spec Reference:


I noticed, now that LLC block parsing has been improved in wireshark [1], that osmo-pcu tends to send lots of RLCMAC blocks with 2 LLC fragments, specially in CS2 & upwards.

This 2nd LLC data fragment can be identified because it contains:

Frame 33759: 94 bytes on wire (752 bits), 94 bytes captured (752 bits)
Linux cooked capture v1
Internet Protocol Version 4, Src:, Dst:
User Datagram Protocol, Src Port: 59082, Dst Port: 4729
GSM TAP Header, ARFCN: 866 (Downlink), TS: 5, Channel: PDTCH (0)
        00.. .... = Payload Type (DL): RLC/MAC block contains an RLC data block (0)
        ..00 .... = RRBP: Reserved Block: (N+13) mod 2715648 (0)
        .... 0... = S/P: RRBP field is not valid
        .... .111 = USF: 7
    00.. .... = PR: 0 dB (included) to 3 dB (excluded) less than BCCH level - P0 (0)
    ..00 000. = DL TFI: 0
    .... ...0 = FBI: Current Block is not last RLC data block in TBF
    0000 001. = BSN: 1
    .... ...0 = Extension: Extension octet follows immediately
    0111 01.. = Length Indicator: 29
    .... ..01 = ME: no more LLC segments in this RLC block after the current segment, no more extension octets (1)
    .... ...1 = Extension: No extension octet follows
    data segment: LI[0]=29 indicates: (Last segment of) LLC frame (29 octets)
        Data (29 bytes)
            Data: 43c0012b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b       <!--------- HERE!!!: 43c001 + 2b padding filling what's left of the remaining space
            [Length: 29]
    0000 0000 = DL SPARE: 0

Apparently it sends it when the end of the current LLC PDU is finished in current rclmac DL data block and there's still some space left.

This kind of frame is actually documented, but AFAIU it's being used in a wrong way. It should not be used in this kind of scenarios, but in others explained by the spec.
In this kind of scenarios AFAIU we should be simply sending 1 data block, followed by filling padding until the end.

The use of LLC UI Dummy commands is documented in:

In my understanding, current behavior is not strongly bad, but it doesn't server any purpose sending those since they are simply ignored by the MS at the LLC layer. It only makes sense to send them if there's really no information to send to the MS but we still want to keep the DL TBF open for a while while we wait for more DL data to come.



#1 Updated by pespin 11 days ago

The situation is even worse because counter CTR_RLC_DL_PAYLOAD_BYTES which is supposed to count RLC DL Payload bytes is counting all those forged LLC dummy frames, which means the counter values makes not much sense from someone expecting it to roughly match amount of data received at the Gb side of osmo-pcu.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)