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.
![](https://handbook.rapid.space/user/faq/rapidspace-Lopcomm.RRH.Delay.Management.CPRI.Delay.image.1?format=)
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
![](https://handbook.rapid.space/user/faq/rapidspace-Explanation.on.ORAN.Delay.Management.YANG.Model.image.1?format=)
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
Parameter |
FPGA Register Map |
Note |
T2a_Fixed |
0x06c5 |
Fixed, Hardcode |
Ta3_Fixed |
0x06c6 |
Fixed, Hardcode |
Toffset_Fixed |
NA |
Auto Calculated in FPGA logic
Related to BBU vendor |
SERDES_RX_DELAY |
0x06c1 |
Hardcode
Related to CPRI Line Rate |
SERDES_RX_DELAY |
0x06c2 |
Hardcode
Related to CPRI Line Rate |
RX_ADAPT_DELAY |
0x06c3 |
Hardcode
Related to CPRI Line Rate |
TX_ADAPT_DELAY |
0x06c4 |
Hardcode
Related to CPRI Line Rate |
T2a |
0x06d2 |
Read Only
Report to BBU via Mplane |
Ta3 |
0x06d3 |
Read Only
Report to BBU via Mplane |
Toffset |
0x06d0 |
Read Only
Report to BBU via Mplane |
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:
![](https://handbook.rapid.space/user/faq/rapidspace-Explanation.on.ORAN.Delay.Management.YANG.Model.image.3?format=)
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
![](https://handbook.rapid.space/user/faq/rapidspace-Lopcomm.RRH.Delay.Management.CPRI.Delay.image.2?format=)
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
![](https://handbook.rapid.space/user/faq/rapidspace-Explanation.on.ORAN.Delay.Management.YANG.Model.image.4?format=)
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:
-
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.
-
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.
-
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
- t_cal_dl: Downlink calibration delay for data flow.
- DL-offset: Offset of IQ frame header to CPRI frame header.
- t_cal_ul: Uplink calibration delay for data flow.
- t12: Delay from the original CPRI master (R1) to RU's R2.
- t34: Delay from RU's R3 to the original CPRI master (R4).
- TR1-offset: Offset of CPRI frame header to GPS time.
Parameters in the RU
- DL_CPRI_DELAY: Delay in downlink CPRI processing.
- DL_DFE_DELAY: Delay in downlink digital front-end processing.
- UL_DFE_DELAY: Delay in uplink digital front-end processing.
- UL_CPRI_DELAY: Delay in uplink CPRI processing.
- SERDES_RX_DELAY: Delay in the SERDES receiver.
- RX_ADAPT_DELAY: Delay in the receive adaptation logic.
- TX_ADAPT_DELAY: Delay in the transmit adaptation logic.
- SERDES_TX_DELAY: Delay in the SERDES transmitter.
- 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:
-
t_cal_dl Calculation Example:
π‘_πππ_ππ=π·πΏ_πΆππ
πΌ_π·πΈπΏπ΄π+π·πΏ_π·πΉπΈ_π·πΈπΏπ΄π+ππΈπ
π·πΈπ_π
π_π·πΈπΏπ΄π+π
π_π΄π·π΄ππ_π·πΈπΏπ΄π
-
t_cal_ul Calculation Example:
π‘_πππ_π’π=ππΏ_π·πΉπΈ_π·πΈπΏπ΄π+ππΏ_πΆππ
πΌ_π·πΈπΏπ΄π+ππ_π΄π·π΄ππ_π·πΈπΏπ΄π+ππΈπ
π·πΈπ_ππ_π·πΈπΏπ΄π
-
Toffset Calculation Example:
πππππ ππ‘=πππππ ππ‘_πΉππ₯ππ+ππΈπ
π·πΈπ_π
π_π·πΈπΏπ΄π+π
π_π΄π·π΄ππ_π·πΈπΏπ΄π+ππ_π΄π·π΄ππ_π·πΈπΏπ΄π+ππΈπ
π·πΈπ_ππ_π·πΈπΏπ΄π
Reference: