The ORAN Delay Management YANG Model defines how delays are managed and configured between the Distributed Unit (DU) and Radio Unit (RU) to ensure precise synchronization of transmission and reception signals over the CPRI link. The process involves configuring parameters such as cpri_tx_delay and cpri_rx_delay to align signals properly. With the help of the ORAN Delay Management YANG Model, there is a feedback loop to ensure that the delay values are updated in real-time on both the DU and the RU, maintaining accurate synchronization and efficient communication.

1. Delay management current state

1.1 DU (Amarisoft):

To configure delays and adjust propagation delays to the TX signal is aligned to PPS and RX is aligned to TX, you need to setup cpri_tx_delay and cpri_rx_delay.

• cpri_rx_delay: Delay between TX and RX position in CPRI frame. This should be set to the value of (T2a + Ta3 - Toffset) provided by the RRH specification.
• cpri_tx_delay: Advance Start of Frame relative to PPS to compensate for delays in transmit line and RRH. This should be set to T12 + T2a.

Example:

• BBU generates signal at 𝑡=0.
• Signal is sent at 𝑡=−(𝑇12+𝑇2𝑎).
• Signal reaches antenna at 𝑡=0.
• RRU generates frame at 𝑡=−𝑇2𝑎+𝑇𝑜𝑓𝑓𝑠𝑒𝑡 and aligns it accordingly.

The BBU generates the signal to t=0 (Ex: start of a frame).
The signal is put in HFR:0.0 (HFN=0, BFN=0) and is sent to RRU at t=-(T12 + T2a)

HFR:0.0 reaches R2 at t=-T2a
HFR:0.0 reaches antenna at t=0 as expected

The RRU generates HFR:0.0 at t=-T2a + Toffset as it aligns on received HFR:0.0 at t=-T2a
The signal put in HFR:0.0 is the one received -Ta3 earlier at antenna side.
Which means that HFR:0.0 sent by RRU is filled with signal received at antenna side at t=-T2a + Toffset - Ta3

Dynamic Configuration Using Amarisoft's Remote API

To configure these 2 parameters dynamically (lteenb keeps running), we can use Amarisoft's remote API: 

cpri_rx_delay

Request fields:

rf_port

Integer. Defines RF port to set and/or get.

cpri_rx_delay

Optional number. Update cpri_rx_delay in microseconds.

Response fields:

cpri_rx_delay

Current cpri_rx_delay in microseconds

cpri_tx_delay

Request fields:

rf_port

Integer. Defines RF port to set and/or get.

cpri_tx_delay

Optional number. Update cpri_tx_delay in microseconds

Response fields:

cpri_tx_delay

Current cpri_tx_delay in microseconds. Note that the delay with PPS won’t be affected. This will only affect the IQ signal inside CPRI frames.

 

1.2 RU(Lopcomm):

• Toffset = serdes RX delay + CPRI module RX delay + serdes TX delay + CPRI module TX delay + Frame header delay from rx to tx
• T2a = serdes RX delay + CPRI module RX delay + RX logic delay + Downlink signal processing delay
• Ta3 = serdes TX delay + CPRI module TX delay + TX logic delay + Uplink signal processing delay

Downlink have four modules, including SERDES_RX, RX_ADAPT, DL_CPRI_PROC and DL_DFE;
Uplink have four modules, including UL_DFE, UL_CPRI_PROC, TX_ADAPT and SERDES_TX;
Defined delay parameters as below, will hardcode in device software, initialize the FPGA registers base on the BBU vendor and CPRI Line Rate option:

1. SERDES_RX_DELAY/SERDES_TX_DELAY, SERDES_RX and SERDES_TX module processing delay, calculate the value as per Xilinx Spec for different CPRI Line Rate;

2. RX_ADAPT_DELAY/TX_ADAPT_DELAY, RX_ADAPT and TX_ADAPT module processing delay, calculate the value with simulation;

3. DL_CPRI_DELAY/UL_CPRI_DELAY, DL_CPRI_PROC and UL_CPRI_PROC module delay, calculate the value with simulation;

4. DL_DFE_DELAY, DL_DFE module delay, measure the delay with DDR source and VSA;

5. UL_DFE_DELAY, UL_DFE module delay, measure the delay with VSG and DDR capture;

6.Toffset_Fixed, delay between downlink received frame header and uplink transmitted frame header, different calculation algorithm as per BBU requirements.

In FPGA design, we use the below calculation method:

• T2a_Fixed = DL_CPRI_DELAY + DL_DFE_DELAY
• Ta3_Fixed = UL_DFE_DELAY + UL_CPRI_DELAY
• T2a = T2a_Fixed + SERDES_RX_DELAY + RX_ADAPT_DELAY
• Ta3 = Ta3_Fixed + TX_ADAPT_DELAY + SERDES_TX_DELAY
• Toffset = Toffset_Fixed + SERDES_RX_DELAY + RX_ADAPT_DELAY + TX_ADAPT_DELAY + SERDES_TX_DELAY

2. Implementation Steps Based on YANG Model

rapidspace-o-ran-delay-management-ru-cpri.yang :
How to:
        Step1: DU get delay profile(ru-delay-profile) by means of rpc get-config
        Step2: DU get t14 from CPRI master(HUB or itself)
        Step3: DU cal the delay config
        Step4: DU config cpri link related params(ru-delay-config-cpri-link-related) to RU, 
               by means of rpc edit-config.
        Step5: DU config data flow delay config(ru-delay-config-data-flow-related) to RU,
               by means of rpc edit-config.

You can find the steps in the flowchat:

Step 1: DU Gets Delay Profile (ru-delay-profile) via RPC get-config

BBU queries RU latency data through the following Netconf RPC
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="64">
  <get xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <filter type="xpath" xmlns:o-ran-delay-ru-cpri="urn:o-ran:delay-ru-cpri:1.0" select="/o-ran-delay-ru-cpri:ru-delay-profile" />
  </get>
</rpc>

RU returns two sets of delay data. The BBU selects according to the bandwidth. 3M selects data with a bandwidth of 3000, and other bandwidths select data with a bandwidth of 5000:

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="64">
  <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <ru-delay-profile xmlns="urn:o-ran:delay-ru-cpri:1.0">
        <ru-delay-profile-list-radio-related>
            <radio-technology>LTE</radio-technology>
            <bandwidth>3000</bandwidth>
            <subcarrier-spacing>15000</subcarrier-spacing>
            <t2a>23074</t2a>
            <ta3>20853</ta3>
        </ru-delay-profile-list-radio-related>
        <ru-delay-profile-list-radio-related>
            <radio-technology>LTE</radio-technology>
            <bandwidth>5000</bandwidth>
            <subcarrier-spacing>15000</subcarrier-spacing>
            <t2a>14745</t2a>
            <ta3>11384</ta3>
        </ru-delay-profile-list-radio-related>
        <t-offset>626</t-offset>
      </ru-delay-profile>
  </data>
</rpc-reply>

Step 2: DU Gets t14 from CPRI Master (HUB or Itself)

t14 is obtained via Amari Remote API rf_info:

{
  "rf_info": "TRX SDR driver 2024-03-05, API v15\n" +
             "PCIe CPRI /dev/sdr0@0:\n" +
             " Hardware ID: 0x4b12\n" +
             " DNA: [0x0054682442f1b05c]\n" +
             " Serial: ''\n" +
             " FPGA revision: 2023-11-06 19:14:51\n" +
             " FPGA vccint: 0.99 V\n" +
             " FPGA vccaux: 1.78 V\n" +
             " FPGA vccbram: 0.99 V\n" +
             " FPGA temperature: 56.4 °C\n" +
             " Clock tune: -0.4 ppm\n" +
             " NUMA: 0\n" +
             " CPRI_option: '5' (x8) signal=yes lock=HW+SW rx/tx=1.652us\n" +
             " Port #0: T14=1.652us\n" +
             " DMA0: TX fifo: 66.67us Usage=16/32768 (0%)\n" +
             " DMA0: RX fifo: 66.67us Usage=16/32768 (0%)\n" +
             " DMA0 Underflows: 0\n" +
             " DMA0: Overflows: 0\n" +
             " BUFS: TX idx=52644.70 RX idx=52644.71\n" +
             "PCIe CPRI /dev/sdr0@1:\n" +
             " Hardware ID: 0x4b12\n" +
             " DNA: [0x0054682442f1b05c]\n" +
             " Serial: ''\n" +
             " FPGA revision: 2023-11-06 19:14:51\n" +
             " FPGA vccint: 0.99 V\n" +
             " FPGA vccaux: 1.78 V\n" +
             " FPGA vccbram: 0.99 V\n" +
             " FPGA temperature: 56.2 °C\n" +
             " Clock tune: -0.4 ppm\n" +
             " NUMA: 0\n" +
             " CPRI_option: '5' (x8) signal=yes lock=HW+SW rx/tx=1.628us\n" +
             " Port #0: T14=1.628us\n" +
             " DMA0: TX fifo: 66.67us Usage=16/32768 (0%)\n" +
             " DMA0: RX fifo: 66.67us Usage=16/32768 (0%)\n" +
             " DMA0 Underflows: 0\n" +
             " DMA0: Overflows: 0\n" +
             " BUFS: TX idx=52644.77 RX idx=52644.78\n"
}

Step 3: DU Calculates the Delay Configuration

Using provided t2a, ta3, toffset values, the DU calculates:

• cpri_tx_delay = T12 + T2a
• cpri_rx_delay = T2a + Ta3 - Toffset

Step 4: DU Configures CPRI Link Related Parameters (ru-delay-config-cpri-link-related) to RU via RPC edit-config

Parameters in ru-delay-config-cpri-link-related:

• port-name: The delay configuration is performed on the primary fiber and the secondary/standby fiber
• t12: t12, from original CPRI master R1 to RU's R2
• t34: t34, from RU's R3 original CPRI master R4
• TR1-offset: Offset of CPRI frame header to GPS time,unit is CPRI chip, 1/3.84MHz (mandatory false)

T12 = T34 = ( T14 - Toffse t) / 2

Guessed example RPC:

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="65">
  <edit-config>
    <target>
      <running/>
    </target>
    <config>
      <ru-delay-config-cpri-link-related xmlns="urn:o-ran:delay-ru-cpri:1.0">
        <CPRI-link-related-config>
          <port-name>1</port-name>
          <t12>5000</t12>
          <t34>5000</t34>
          <TR1-offset>100</TR1-offset>
        </CPRI-link-related-config>
      </ru-delay-config-cpri-link-related>
    </config>
  </edit-config>
</rpc>

Step 5: DU Configures Data Flow Delay Configuration (ru-delay-config-data-flow-related) to RU via RPC edit-config

Parameters in ru-delay-config-data-flow-related:

• eaxc-id: eaxc-id, which represents data flow of 1 specific carrier antenna
• t_cal_dl: dl cal delay cfg, for data flow of 1 specific carrier antenna
• DL-offset: Offset of IQ frame header to CPRI frame header,unit is CPRI chip, 1/3.84MHz
• t_cal_ul: ul cal delay cfg, for data flow of 1 specific carrier antenna

Guessed example RPC:

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="66">
  <edit-config>
    <target>
      <running/>
    </target>
    <config>
      <ru-delay-config-data-flow-related xmlns="urn:o-ran:delay-ru-cpri:1.0">
        <dl_cal_ru_list>
          <eaxc-id>1</eaxc-id>
          <t_cal_dl>15000</t_cal_dl>
          <DL-offset>300</DL-offset>
        </dl_cal_ru_list>
        <ul_cal_ru_list>
          <eaxc-id>1</eaxc-id>
          <t_cal_ul>13000</t_cal_ul>
        </ul_cal_ru_list>
      </ru-delay-config-data-flow-related>
    </config>
  </edit-config>
</rpc>

Step extra: Post-Configuration Validation and Feedback Loop

After the RU receives these containers with the updated delay values (ru-delay-config-cpri-link-related and ru-delay-config-data-flow-related), it needs to perform a validation step to ensure synchronization accuracy. Here is the detailed process for this step:

1. Comparison with Previous Values:

   • The RU compares the newly received delay values with the previously configured values.
   • This ensures that the new values are correctly applied and whether there is any significant deviation that might impact synchronization.

2. Updating ru-delay-profile:

   • If there are changes or adjustments needed, the RU updates the ru-delay-profile accordingly.
   • This update is essential for maintaining accurate records of the current delay configurations.

3. Restart Delay Management Steps:

   • Once the ru-delay-profile is updated, the RU triggers the feedback loop to restart the delay management steps.
   • This continuous loop ensures that any changes in the system, such as temperature variations or hardware updates, are accounted for in real-time, maintaining precise synchronization.

3. Implementation Suggestion (What is missing)

To successfully complete steps 4, 5, and the additional validation step, certain parameters are required. These parameters are critical for configuring and managing delays accurately in the CPRI link between the DU and RU. Here’s what is missing and how these values are expected to be obtained and used:

• t_cal_dl: dl cal delay cfg, for data flow of 1 specific carrier antenna
• DL-offset: Offset of IQ frame header to CPRI frame header,unit is CPRI chip, 1/3.84MHz
• t_cal_ul: ul cal delay cfg, for data flow of 1 specific carrier antenna

These values are expected to be read from the DU using the Amarisoft stack. 

These values are expected to be used for calculating the RU delay values. How will RU use these values? (including T12, T34)

Assumptions for Implementation (Could Be Incorrect):

Parameters in the YANG Model

1. t_cal_dl: Downlink calibration delay for data flow.
2. DL-offset: Offset of IQ frame header to CPRI frame header.
3. t_cal_ul: Uplink calibration delay for data flow.
4. t12: Delay from the original CPRI master (R1) to RU's R2.
5. t34: Delay from RU's R3 to the original CPRI master (R4).
6. TR1-offset: Offset of CPRI frame header to GPS time.

Parameters in the RU

1. DL_CPRI_DELAY: Delay in downlink CPRI processing.
2. DL_DFE_DELAY: Delay in downlink digital front-end processing.
3. UL_DFE_DELAY: Delay in uplink digital front-end processing.
4. UL_CPRI_DELAY: Delay in uplink CPRI processing.
5. SERDES_RX_DELAY: Delay in the SERDES receiver.
6. RX_ADAPT_DELAY: Delay in the receive adaptation logic.
7. TX_ADAPT_DELAY: Delay in the transmit adaptation logic.
8. SERDES_TX_DELAY: Delay in the SERDES transmitter.
9. Toffset_Fixed: Fixed offset delay between received frame header and transmitted frame header.

Possible Relationships

Let's identify which parameters might be related and how they can be calculated from one another.

Mapping t_cal_dl and t_cal_ul

• t_cal_dl (downlink calibration delay) likely includes:

  • DL_CPRI_DELAY: Downlink CPRI processing delay.
  • DL_DFE_DELAY: Downlink digital front-end processing delay.
  • SERDES_RX_DELAY: SERDES receiver delay.
  • RX_ADAPT_DELAY: Receive adaptation delay.

  So, we can express t_cal_dl as:

  𝑡_𝑐𝑎𝑙_𝑑𝑙≈𝐷𝐿_𝐶𝑃𝑅𝐼_𝐷𝐸𝐿𝐴𝑌+𝐷𝐿_𝐷𝐹𝐸_𝐷𝐸𝐿𝐴𝑌+𝑆𝐸𝑅𝐷𝐸𝑆_𝑅𝑋_𝐷𝐸𝐿𝐴𝑌+𝑅𝑋_𝐴𝐷𝐴𝑃𝑇_𝐷𝐸𝐿𝐴𝑌

• t_cal_ul (uplink calibration delay) likely includes:

  • UL_DFE_DELAY: Uplink digital front-end processing delay.
  • UL_CPRI_DELAY: Uplink CPRI processing delay.
  • TX_ADAPT_DELAY: Transmit adaptation delay.
  • SERDES_TX_DELAY: SERDES transmitter delay.

  So, we can express t_cal_ul as:

  𝑡_𝑐𝑎𝑙_𝑢𝑙≈𝑈𝐿_𝐷𝐹𝐸_𝐷𝐸𝐿𝐴𝑌+𝑈𝐿_𝐶𝑃𝑅𝐼_𝐷𝐸𝐿𝐴𝑌+𝑇𝑋_𝐴𝐷𝐴𝑃𝑇_𝐷𝐸𝐿𝐴𝑌+𝑆𝐸𝑅𝐷𝐸𝑆_𝑇𝑋_𝐷𝐸𝐿𝐴𝑌

Mapping DL-offset and TR1-offset

• DL-offset: This parameter represents the offset of the IQ frame header to the CPRI frame header. It’s related to the timing alignment within the downlink data path.

• TR1-offset: This parameter represents the offset of the CPRI frame header to GPS time. It’s used for synchronization with an external time source.

While these offsets are used for different purposes (internal alignment vs. external synchronization), they contribute to the overall timing configuration and can influence how other delays are managed.

Mapping t12 and t34

• t12 and t34: These represent delays from specific points in the CPRI link (R1 to R2 and R3 to R4). They are directly measured or configured delays representing specific segments of the link.

Toffset_Fixed

• Toffset_Fixed: This is a fixed offset delay between the received frame header and the transmitted frame header. It’s a cumulative delay that includes several of the aforementioned delays.

Deriving Relationships

From the relationships above, we can derive and verify parameters as follows:

1. t_cal_dl Calculation Example:

   𝑡_𝑐𝑎𝑙_𝑑𝑙=𝐷𝐿_𝐶𝑃𝑅𝐼_𝐷𝐸𝐿𝐴𝑌+𝐷𝐿_𝐷𝐹𝐸_𝐷𝐸𝐿𝐴𝑌+𝑆𝐸𝑅𝐷𝐸𝑆_𝑅𝑋_𝐷𝐸𝐿𝐴𝑌+𝑅𝑋_𝐴𝐷𝐴𝑃𝑇_𝐷𝐸𝐿𝐴𝑌

2. t_cal_ul Calculation Example:

   𝑡_𝑐𝑎𝑙_𝑢𝑙=𝑈𝐿_𝐷𝐹𝐸_𝐷𝐸𝐿𝐴𝑌+𝑈𝐿_𝐶𝑃𝑅𝐼_𝐷𝐸𝐿𝐴𝑌+𝑇𝑋_𝐴𝐷𝐴𝑃𝑇_𝐷𝐸𝐿𝐴𝑌+𝑆𝐸𝑅𝐷𝐸𝑆_𝑇𝑋_𝐷𝐸𝐿𝐴𝑌

3. Toffset Calculation Example:

   𝑇𝑜𝑓𝑓𝑠𝑒𝑡=𝑇𝑜𝑓𝑓𝑠𝑒𝑡_𝐹𝑖𝑥𝑒𝑑+𝑆𝐸𝑅𝐷𝐸𝑆_𝑅𝑋_𝐷𝐸𝐿𝐴𝑌+𝑅𝑋_𝐴𝐷𝐴𝑃𝑇_𝐷𝐸𝐿𝐴𝑌+𝑇𝑋_𝐴𝐷𝐴𝑃𝑇_𝐷𝐸𝐿𝐴𝑌+𝑆𝐸𝑅𝐷𝐸𝑆_𝑇𝑋_𝐷𝐸𝐿𝐴𝑌

Reference:

• O-RAN.WG7.IPC-HRD-Opt8.0-v03.00.pdf
• rapidspace-o-ran-delay-management-ru-cpri.yang