3. O-RAN IP Functional Description
The O-RAN IP comprises compression and decompression, mapper and demapper.
Figure 6. O-RAN IP Block Diagram
Mapper
The mapper includes section and common header mapping blocks. The common header consists of a time reference for each packet. The common header format is the same for C-plane and U-plane messages.
Figure 7. Scheduling control and user data transfer procedure The IP transmits C-plane and U-plane messages at different times.
C-plane and U-plane messages have the same header format and different transmission time. The IP multiplexes one common header mapper instantiation for mapping both C-plane and U-plane messages. The IP stores information elements (IEs) related to common header and Rtcid ID in a FIFO buffer to bypass section mapper.
Section Mapper
The section format is different for each section type in C-plane and U-plane messages. The IP instantiates a separate control and user mapper to interface with the client. A simple arbiter multiplexes the control and user mapper output for transmission window monitoring and common header mapping.
Transmission Window
The O-RAN IP transmission window supports the processing of Long PRACH, Short PRACH, SRS, and PUSCH U-plane data packets using the ext_scs_sel application interface input signal.
You should send long PRACH data packets using the SCS channel for 1.25 kHz or 5 kHz frequencies. You should send short PRACH and PUSCH data packets using the standard SCS channel. To bypass the SRS packets from transmission window monitoring, drive the ext_scs_sel signal with the value 4'b1011.
| ext_scs_sel[3:0] | SCS Channel | Window Monitor Registers |
|---|---|---|
| 4'b1100 | Long PRACH (1.25 kHz) | csr_ta3_min_up_1p25khz_ta3_min_up_1p25khz, csr_ta3_max_up_1p25khz_ta3_max_up_1p25khz |
| 4'b1110 | Long PRACH (5 kHz) | csr_ta3_min_up_5khz_ta3_min_up_5khz, csr_ta3_max_up_5khz_ta3_max_up_5khz |
| Other | Short PRACH or PUSCH | csr_ta3_min_up_ta3_min_up, csr_ta3_max_up_ta3_max_up |
| 4'b1011 | SRS | The O-RAN IP bypasses SRS packets from transmission window monitor. |
You must perform C-plane and U-plane coupling at the system level outside of O-RAN IP and provide the desired value of ext_scs_sel to apply the SCS frequency accordingly. The IP uses corresponding window monitor registers for each SCS channel transmission window processing.
When sending long PRACH data packets, you must ensure tx_u_symbolid value is 0 for correct air time calculation.
Figure 8. Transmission Window Monitoring ensures the incoming packets fall under current time of day (TOD), if not the IP drops the current packet. Transmission and reception window checking starts when you assert packet's SOP and VALID. The O-RAN Design Example does not support window monitoring.
Common Header Mapper
The common header mapper appends the following fields to the start of every packet from the section mapper:
- dataDirection
- payloadVersion
- filterIndex
- frameId
- subframeId
- slotId
- symbolId
This block includes a dispatcher FSM to apply backpressure during insertion of header fields. The block also includes an output FIFO buffer to stream output data with zero or three cycle readyLatency.
Common Header Demapper
The common header demapper demaps the radio application headers from the incoming eCPRI packet and forwards the O-RAN payloads to reception window monitor. This demapper is common for both U-plane and C-plane packets. For every SOP, the IP takes out the MSB nibble and decodes it as a common header. The IP appends the remaining LSB nibble with next clock cycle data and passes it to the next module.
Reception Window Monitoring
The window monitor monitors that the incoming packets fall under current time of day (TOD), if not it drops the current packet. The reception window monitoring shares the same module with the transmission window monitoring. They use different window thresholds, which you program through t2a registers.
Figure 9. Reception Window The O-RAN Design Example does not support window monitoring.
Compression and Decompression
A preprocessing block-based bit shift block generates the optimum bit-shifts for a resource block of 12 resource elements (REs). The block reduces the quantization noise, especially for low-amplitude samples. Hence, it reduces the error vector magnitude (EVM) that compression introduces. The compression algorithm is almost independent of the power value. Assuming the complex input samples is x = x1 + jxQ, the maximum absolute value of the real and imaginary components for the resource block is:
The maximum value of the resource block n is:
Having the maximum absolute value for the resource block, the following equation determines the left shift value assigned to that resource block:
Where bitWidth is the input bit width.
The IP supports compression ratios of 8, 9, 10, 11, 12, 13, 14, 15, 16.
For a compression ratio of 16 (udCompParam field = 0, according to the O-RAN WG specification), the IP does not perform compression or decompression.
Mu-Law Compression and Decompression
The algorithm uses Mu-law companding technique, which speech compression widely uses. This technique passes the input uncompressed signal, x, through a compressor with function, f(x), before rounding and bit-truncation. The technique sends compressed data, y, over the interface. The received data passes through an expanding function (which is the inverse of the compressor, F-1(y). The technique reproduces the uncompressed data with minimal quantization error.
Equation 1. Compressor and decompressor functions
The Mu-law IQ compression algorithm follows the O-RAN specification.