Problem in reading dynamic compression in O-RAN Fronthaul protocol
Summary
- Activating the dynamic compression flag (udCompHdr) in the preferences, modulation and IQ bitwidth are recognized but not applied.
- Presence of 1 byte (udCompParam) when it should not be read (in case of modulation compression).
What is the current bug behavior?
By activating the udCompHdr field, I expected that the IQ bitwidth (Downlink in this example) and Compression method selected in the “Preferences” window would not affect the readout of the IQ sample data, which should only be influenced by the byte in the udCompHdr, which defines the type of compression and IQ width.
However, there are two behaviors that seem uncorrect:
- DYNAMIC PROFILE RECOGNIZED BUT NOT APPLIED
While the modulation and IQ width are correctly read by Wireshark (as shown in the next picture, with modulation compression and bit width of I and Q equal to 1), instead of representing each PRB with 3 bytes (when IQ width = 1, total bits = 2, for each PRB: 2*12 re = 24 bits = 3bytes), it represents each PRB considering the IQ width specified in the configuration profile (and not the IQ width specified in the byte of udCompHdr as expected) with 42 bytes per PRB (28 bits per scs * 12 = 336 bits = 42 bytes). This behavior leads to a misread packet.
However, when setting the right value of compression and IQ bitwidth in the “Preferences” (as in the next figure)
the result is different, even though I expected nothing to change for a dynamic profile.
In any case, the reading of the packet is still incorrect even with this correction. This introduces the second doubt.
- PRESENCE OF udCompParam ALSO WITH MODULATION COMPRESSION
The second doubt concerns the “exponent” parameter (as shown in the next picture). While “reserved” is correctly reported (as 1 byte when udCompHdr is activated), the presence of the next byte, that should be absent, seems to mislead the reading of the packet.
In fact, according to the table quoted above (Table 8.3.2-1) of O-RAN.WG4.CUS.0-v09.00 specification, this byte has to be the “udCompParam”, which is the only one between “reserved” and the data sample that can carry 1 byte. However, “udCompParam” should be absent in modulation compression, as reported in Table 8.3.3.15-1 of O-RAN.WG4.CUS.0-v09.00 specification.
What is the expected correct behavior?
I expect
- reading of the packet in line with the modulation compression and I/Q bitwidth characteristics;
- absence of udCompParam byte when modulation compression is read in udCompHdr byte.
Build information
Version 4.0.3 (Git v4.0.3 packaged as 4.0.3-1~ubuntu22.04.0~ppa1).
Compiled (64-bit) using GCC 11.3.0, with GLib 2.72.4, with PCRE2, with zlib
1.2.11, with Qt 5.15.3, with libpcap, with POSIX capabilities (Linux), with
libnl 3, with Lua 5.2.4, with GnuTLS 3.7.3 and PKCS #11 support, with Gcrypt
1.9.4, with Kerberos (MIT), with MaxMind, with nghttp2 1.43.0, with brotli, with
LZ4, with Zstandard, with Snappy, with libxml2 2.9.13, with libsmi 0.4.8, with
QtMultimedia, without automatic updates, with SpeexDSP (using system library),
with Minizip, with binary plugins.
Running on Linux 5.15.90.1-microsoft-standard-WSL2, with Intel(R) Core(TM)
i5-10310U CPU @ 1.70GHz (with SSE4.2), with 7825 MB of physical memory, with
GLib 2.72.4, with PCRE2 10.39 2021-10-29, with zlib 1.2.11, with Qt 5.15.3, with
libpcap 1.10.1 (with TPACKET_V3), with c-ares 1.18.1, with GnuTLS 3.7.3, with
Gcrypt 1.9.4, with nghttp2 1.43.0, with brotli 1.0.9, with LZ4 1.9.3, with
Zstandard 1.4.8, with libsmi 0.4.8, with light display mode, without HiDPI, with
LC_TYPE=C.UTF-8, binary plugins supported.