osmo-pcu: Sending LLC UI Dummy commands inside DL RLCMAC GPRS data blocks for no good reason
I noticed, now that LLC block parsing has been improved in wireshark , 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: 127.0.0.1, Dst: 127.0.0.1 User Datagram Protocol, Src Port: 59082, Dst Port: 4729 GSM TAP Header, ARFCN: 866 (Downlink), TS: 5, Channel: PDTCH (0) GPRS DL DATA (CS2) DL_Data_Mac_Header 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=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.
- 3GPP TS 44.060 version 16.0.0 "9.3.1a Delayed release of downlink Temporary Block Flow"
- 3GPP TS 44.064 version 16.0.0 "184.108.40.206 Unconfirmed Information (UI) Dummy command"
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.