User data IQ width and compression method mismatch

[wei-lou]

I have configured the IQ width as 9 and compression method bfp. However from captured pcap, it shows IQ width as 16 bits and no compression.

compr_method_ul: bfp
compr_bitwidth_ul: 9
compr_method_dl: bfp
compr_bitwidth_dl: 9
compr_method_prach: bfp
compr_bitwidth_prach: 9
enable_ul_static_compr_hdr: true
enable_dl_static_compr_hdr: true
iq_scaling: 5.5

C-Plane Section Type 1, Downlink, Frame: 85, Subframe: 7, Slot: 0, StartSymbol: 0
    1... .... = Data Direction: Downlink (1)
    .001 .... = Payload Version: 1
    .... 0000 = Filter Index: standard channel filter (0)
    Frame ID: 85
    0111 .... = Subframe ID: 7
    .... 0000 00.. .... = Slot ID: 0
    ..00 0000 = Start Symbol ID: 0
    [RefA: 85-7-0]
    Number of Sections: 1
    Section Type: Most DL/UL radio channels (1)
    0000 .... = User Data IQ width: I and Q are each 16 bits wide (0) (16 bits)
    .... 0000 = User Data Compression Method: No compression (0)

gnb_ru_fuji_tdd_n48_40mhz_2x2_23101BM.txt

IQ_width_Compress.zip

What haveI missed?

[andrepuschmann]

Are you sure this PCAP is from a run with this config? Can you please share the console messages when you start the gNB. It prints the OFH config.

[wei-lou]

Hi @andrepuschmann. yes, that's the match pcap with the configure file. Here are the console screen display. I also recapture the pcap and gnb.log. The pcap indicated no compression and 16bit IQ width.

user@srsran:~$ sudo gnb -c srsRAN_Project/configs/gnb_ru_fuji_tdd_n48_40mhz_4x4_23101BM.yml

The PRACH detector will not meet the performance requirements with the configuration {Format 0, ZCZ 0, SCS 1.25kHz, Rx ports 1}.

--== srsRAN gNB (commit 55c984b55) ==--

Connecting to AMF on 192.168.70.210:38412
Initializing Open Fronthaul Interface sector=0: ul_comp=[BFP,9], dl_comp=[BFP,9], prach_comp=[BFP,9] prach_cp_enabled=true, downlink_broadcast=false.
Warning: Configured PRACH occasion collides with PUCCH RBs ([0..1) intersects [0..3)). Some interference between PUCCH and PRACH is expected.
Warning: Configured PRACH occasion collides with PUCCH RBs ([0..1) intersects [0..3)). Some interference between PUCCH and PRACH is expected.
Cell pci=48, bw=40 MHz, dl_arfcn=643464 (n48), dl_freq=3651.96 MHz, dl_ssb_arfcn=642432, ul_freq=3651.96 MHz

==== gNodeB started ===
Type <t> to view trace
q
Stopping ..

gnb_run04.log

srsran_BM_n48_40MHz_DU_run04.pcap.gz

gnb_ru_fuji_tdd_n48_40mhz_4x4_23101BM.txt

[mmailand]

As far as I understand that behavior is correct, the udCompHdr value is not used in the C-Plane in the downlink direction and therefore it is set to all zeros. See the O-RAN.WG4.CUS.0-R003-v13.00 specification section 7.5.2.10 for more details:

This means the udCompHdr in a C-Plane message only has meaning for UL U-Plane data (dataDirection = 0b) and should be set to 0x00 when dataDirection = 1b (DL data), and the receiving O- RU shall ignore the received udCompHdr value

The second point is that static data format and compression is used and therefore no udCompHdr is needed, section 7.5.2.10:

When static data format and compression is used (see clause 8.1.2) then udCompHdr is not needed in any C-Plane message and should be set to 0x00, and the receiving O-RU shall ignore the received udCompHdr value.

There also won't be any udCompHdr values in the U-Plane because of the static format and compression, section 8.3.3.13:

This field shall be absent from U-Plane messages when the static IQ format and compression method is configured via the M-Plane

[mmailand]

If you want to have the udCompHdr in the U-Plane you can do that via the config option:
enable_ul_static_compr_hdr: false
enable_dl_static_compr_hdr: false
and than adjust the different compr_bitwidth and compr_method settings as you mentioned in the your first post, e.g. for DL:
compr_bitwidth_dl: 9
compr_method_dl: bfp

Because there is no flag in the specification to indicate the presents of the udCompHdr we need to configure that in the wireshark preferences. Tick those two boxes and save the preferences.

After that you can see the expected udCompHdr in the U-Plane.

[wei-lou]

great! let me try that. Thank you so much for your help

[andrepuschmann]

Thanks @mmailand for helping out. As @mmailand pointed out the trouble with the OFH spec is that some config options are not type-length-value (TLV) in the messages but are always present, regardless of whether they are used or not. It is a bit counter intuitive. So when viewing the messages with Wireshark you need to make sure the dissector is configured accordingly.

[pgawlowicz]

@wei-lou Did the hint from @mmailand solve your issue? Could you provide your feedback?

[wei-lou]

Yes, the explanation makes sense. There was no issue here. Thanks,

[andrepuschmann]

Thanks for the feedback. Closing.