O-DU ↔ O-RU Interoperability Troubleshooting (O‑RAN WG4 C/U, S & M Planes)

O-DU ↔ O-RU Interoperability Troubleshooting (O-RAN WG4 C/U, S & M Planes) focuses on identifying and resolving functional and timing mismatches between the Distributed Unit (O-DU) and Radio Unit (O-RU) across the Open Fronthaul interface defined by O-RAN Working Group 4. It provides a systematic approach to diagnosing issues in the Control/User Plane (C/U), Synchronization Plane (S), and Management Plane (M)—the three pillars of inter-vendor interoperability. The guide emphasizes packet-level analysis, timing conformance, and configuration validation aligned with O-RAN and ITU-T standards. Engineers use it to isolate root causes such as compression mismatches, synchronization instability, or YANG model deviations. It bridges lab testing and field validation practices for multi-vendor deployments.

1) Planes & where failures surface

• C/U‑Plane (Control/User): eCPRI transports O‑RAN sections carrying DL/UL IQ, beamforming, PRACH, SRS, compression, and scheduling directives. Failures appear as RF mis‑behavior (EVM/ACLR), missed PRACH, section decode errors, or rate/latency overruns.

• S‑Plane (Synchronization): PTP (IEEE‑1588‑2/‑2019 gPTP profile), SyncE, and timing hold‑over. Faults surface as time error excursions (cTE, dTE, max|TE|), phase/frequency slips, and CU/U jitter cascades.

• M‑Plane (Management): NETCONF/YANG over TLS (or SSH), startup/install, software management, configuration, and performance mgmt. Faults appear as capability mismatches, schema errors, session drops, or wrong operational state machines.

Image source: https://www.researchgate.net/figure/O-RAN-fronthaul-interface-and-fronthaul-planes-This-interface-enables-the-72x-split-of_fig9_367369842

Commonly reported defect buckets (how they’re often labeled in plug‑tests & labs): -

1.      C/U‑Plane: eCPRI Payload/metadata consistency problems (eAxC map, section ID/range, section extension use, compression params, PRACH formats) leading to decode failures or RF anomalies.

2.      S‑Plane: In the synchronization plane, the main problems arise when the distributed and radio units drift outside timing tolerance — either due to excessive phase jitter (dynamic time error), steady offset (constant time error), misinterpretation of how to measure those errors, poor clock-source selection in Synchronous Ethernet or Precision Time Protocol, or unstable master clock elections. Each of these causes loss of alignment between O-DU and O-RU, violating O-RAN timing compliance.

Tight timing non‑compliance—cTE/dTE interpretation, peak‑to‑peak/dynamic time error excursions, SyncE/PTP priority selection, and BMCA instability.

Abbreviation	Full term	Meaning
cTE	Constant Time Error	A steady offset between the delivered time and the reference time (like your watch being 50 ns fast).
dTE	Dynamic Time Error	Short-term variation of that offset (like your watch jitters forward/back a few ns every second).

Too much cTE → your cell’s frame starts late/early every time.

Too much dTE → you drift within each radio frame.

Peak-to-Peak / Dynamic Time Error Deviations

Dynamic Time Error (dTE) = the variation (jitter) of time error over a defined observation window.

Peak-to-Peak excursion = the difference between the maximum and minimum time error values in that window.

Metric	Typical limit (per G.827x / O-RAN)	Meaning
Constant Time Error (cTE)	≤ 100 ns typical target	Static phase offset between reference and node
Dynamic Time Error (dTE)	≤ 1 µs over observation window	Short-term time fluctuations (jitter)

SyncE (Synchronous Ethernet): It distributes frequency synchronization by embedding clock information into the Ethernet physical layer.

PTP (IEEE 1588-2019) sends timestamp messages across the Ethernet to sync clocks. It has multiple “clock types” (Grandmaster, Boundary, Transparent).

BMCA (Best Master Clock Algorithm)

BMCA is the decision logic inside PTP that selects which clock is the “Grandmaster.” Each clock advertises its priority, quality, and identity, and others elect the best.

3.      M‑Plane: Startup & capability negotiation—NETCONF session hardening, YANG deviations, RPC sequence ordering (activate‑deactivate), and SW mgmt edges.

2) Lab Topology & Golden Setup

Golden lab checklist –

1.      One known‑good GM with verified TE budget; disciplined SyncE; BC/TC configured and locked.

2. L2 QoS: eCPRI & PTP CoS separated; strict priority for PTP; policing disabled on PTP.

3. Port Mirroring/Hardware Network Taps on O‑DU↔RU links for PCAP capture at line rate; jumbo MTU = 9k where supported.

4. RF bench: calibrated attenuators, OTA/CTIA box (if needed), vector signal analyzer for EVM/ACLR/OBUE.

5. Version lock: record O‑RAN spec versions, YANG model revisions, test suite IDs, and firmware hashes.

3) C/U‑Plane Troubleshooting

Below are C/U‑plane issues you should be prepared to see in multi‑vendor interop. Each includes Symptoms → Likely Cause → Tools → Step‑by‑step fix → Validate → Prevent.

CU‑1) Section ID / PRB range mismatch

In the interface between the distributed unit (DU) and the radio unit (RU), the control-plane (“C-plane”) section messages describe “sections” of resource grid (in time/frequency) that the DU schedules for the RU to process or transmit. Each section has identifiers: a section_id, plus parameters like start_prb (the first physical resource block) and num_prb (how many resource blocks) in that section. If the DU and RU disagree on what those values mean (for example the DU schedules resource blocks outside the RU’s bandwidth, or uses a section_id that the RU treats differently), then the RU may ignore, reject or mistransmit those resources. As a result you may see “no downlink RF”, “missing resource blocks”, or PCAP decode errors.

• Physical Resource Block (PRB): In 5G New Radio, the basic unit of allocation in frequency domain is a “physical resource block” of 12 sub-carriers (by default), over one slot/OFDM symbol set.

• section_id: A unique identifier in the C-plane message that marks that “section” of the spectrum/time that the RU should handle.

• start_prb, num_prb: The offset (in PRBs) within the carrier and the count of PRBs that this section covers.

• carrier bandwidth/NRB: The total number of PRBs in the carrier. If the DU schedules start_prb + num_prb beyond NRB, the RU might ignore.

Symptoms: No DL RF, or RBs missing; Wireshark shows section decode errors.

Likely cause: section_id, start_prb, num_prb out of spec or outside carrier map.

Tools: PCAP (DU+RU sides), Wireshark O‑RAN dissector, DU/RU logs.

Steps: 

1. Capture 5–10 s PCAP on both ends; export section tables.

2. Check section_id monotonicity (consistently increasing) and ranges vs M‑plane carrier bandwidth.

3. Align DU scheduler PRB allocations to RU static-o-ru-config.

4. Re‑push DU profile; restart C/U session.

Validate: Sections decode end‑to‑end; RF grid filled as scheduled.

Prevent: Template PRB ranges from RU capabilities; unit tests for boundary PRBs.

CU‑2) eAxC ↔ Antenna‑port mapping inconsistency

In the Open Fronthaul split architecture defined by the O-RAN Alliance, the DU can assign one or more extended antenna-carriers (eAxC) to a RU. Each eAxC is tied to a physical antenna port (or port group) on the RU. If the mapping the DU uses (eAxC ID → RU port) is not exactly identical to what the RU expects (for example the RU has a port numbering reversed, or the DU maps port 3 to eAxC ID 0 whereas RU expects port 3 = eAxC ID 2), then you’ll observe mismatches such as the wrong antenna radiating (wrong beam or polarization), dropped sectors, or severe degradation in signal quality (e.g., high cross-polar leakage). Essentially the wrong physical antenna gets the IQ data.

Symptoms: Wrong antenna emits power; cross‑polar leakage; beam IDs shift across ports.

Likely cause: axc_id/ru_port_id clash with DU’s internal antenna map.

Tools: M‑plane dump, DU port map, PCAP.

Steps: 

1. Read RU ru-capabilities for eAxC/port map.

2. Compare to DU internal map; generate an intersection table.

3. Update DU C‑plane templates; reboot RU if required.

Validate: Per‑port power/phase matches expected.

Prevent: Always render C/U from M‑plane live data.

CU‑3) Compression mode/shift mismatch (BFP/µ‑law)

For the U-plane (user-plane) data – the IQ sample streams – there is often a requirement to compress data to reduce fronthaul bandwidth. The DU and RU must agree on the compression method (for example block-floating-point (BFP), µ-law companding, fixed point) and associated bit-width and scaling (shift) parameters. If the DU sends compressed samples with one format, but the RU expects another, then the RU will fail to decode or will produce distorted IQ with high error vector magnitude (EVM), bursts of CRC failures, or mismatched payload sizes.

Typical “rule of thumb” acceptance threshold: if EVM degrades by >2 dB when enabling compression (vs no compression baseline) and CRC errors appear, suspect mismatch.

• Compression method (compMeth): Indicates how the IQ samples are compressed. E.g., BFP (Block Floating Point), MLW (µ-law), FP (fixed point) etc.

• iqBitWidth: The number of bits used for each IQ sample after compression.

• compShift: The number of binary shifts applied to mantissa for normalization in BFP.

• EVM (Error Vector Magnitude): A measure of modulation accuracy – higher EVM means the transmitted signal deviates more from its ideal constellation point.

• CRC failures: For uplink frames the RU or DU might compute a Cyclic Redundancy Check; compression mismatch may cause invariants to fail.

Symptoms: UL CRC failures; high EVM; U‑plane payload size inconsistent.

Likely cause: compMeth, iqBitWidth, compShift not agreed.

Steps: 

1. From RU capabilities, list supported compression tuples.

2. Force DU to least‑common‑denominator (e.g., 9‑bit BFP, shift=0).

3. Retest UL decode; iterate shift.

Validate: Stable throughput; no UL IQ decode errors.

Prevent: Capability negotiation gate in DU provisioning.

CU‑4) IQ packing / endianness / sign extension error

The user-plane IQ stream is just numbers: in-phase (I) and quadrature (Q) samples. Those numbers are serialized into bytes and sent over Ethernet. If the transmitter and receiver don’t agree on endianness (byte order), bit-width, or how negative values are represented (two’s-complement sign extension), samples get misread. You’ll see constellation rotation or mirroring and a sudden error vector magnitude increase.

Symptoms: Spectral mirror, constellation rotation, sporadic decode.

Cause: Byte order or sign extension differs from spec.

Steps: 

1. Decode a single PRB burst; dump raw IQ bytes.

2. Reconstruct in a script; verify endian and sign.

3. Toggle DU packer options per spec; re‑flash RU if vendor quirk.

Validate: IQ histograms are symmetric; EVM improves.

Prevent: Contract tests on pack/unpack.

CU‑5) PRACH format mismatch (A1/A2/A3/B1/B4/C0/C2)

The distributed unit(DU) schedules a particular PRACH format (for example “A1”, “B4”, “C0”), which defines subcarrier spacing, cyclic prefix, and duration. If the radio unit supports a different set—or the DU schedules the wrong spacing or repetition—the RU fails to detect preambles and random access collapses.

Conformance suites expect near-perfect detect (> 99 % across 100 attempts) on the selected format when the receiver is within nominal power and delay window.

Symptoms: UE fails RACH; RU never flags PRACH detect.

Cause: DU schedules wrong PRACH format/comb/repetition.

Steps: 

1. Compare DU PRACH template vs RU supported list.

2. Schedule a single known occasion; capture PCAP & RF.

3. Correct format/occasion; align μ numerology.

Validate: PRACH detect on RU; RACH success.

Prevent: Static PRACH library per band/numerology.

CU‑6) PRACH timing window / numerology slip

Even with the correct format, the time alignment must place preambles inside the radio’s PRACH detect window. If the subcarrier spacing and slot/occurrence index imply a different timing or if network time is off, preambles land outside the window and detection becomes intermittent.

Symptoms: Intermittent RACH; PRACH present but outside window.

Cause: Wrong CP/FFT sizes vs µ; time alignment error.

Steps: 

1. Check DU µ and SCS; compute expected PRACH offset.

2. Align window and guard; verify timing on scope/PTP.

Validate: Stable detect across 100+ attempts.

Prevent: Auto‑derive window from µ & RU config.

CU‑7) Beamforming weight/scaler mismatch

Downlink beam-forming sends complex weights per antenna and an overall scaler (gain). If the RU expects a different bit-width or packing of those weights—or interprets scaler differently—you get wrong beam directions or clipping.

Symptoms: Wrong beam points; gain compresses/clips.

Cause: Weight/scaler bit‑width disagreement; complex packing mismatch.

Steps: 1. Inspect C‑plane weight sections; verify scaler width.

2. Switch to vendor “safe” profile; reduce dynamic range.

3. Validate per‑beam EIRP on RF bench.

Validate: Beams match design codebook.

Prevent: Normalize to RU scaler capability during generate.

CU‑8) Section Extension misuse (#4/#25 or vendor‑specific)

The C-plane allows extensions (for example proprietary beam metadata). If order, presence, or interpretation differs between DU and RU, RUs may reject sections or apply wrong metadata.

Symptoms: RU rejects sections or misapplies metadata.

Cause: Different interpretation/ordering of extensions.

Steps: 

1. List extensions seen in PCAP; compare to RU claims.

2. Disable optional extensions; retest baseline.3. Re‑enable one‑by‑one to isolate offender.

Validate: No section reject counters increment.

Prevent: Feature flags & version guardrails.

CU‑9) Transport rate/MTU/offload pitfalls

Even if messages are perfect, the Ethernet path can break you: jumbo frame mismatches, Large Segment Offload / Generic Receive Offload hiding real packetization, or class of service starvation for C/U cause resets, latency spikes, and partial frames.

Symptoms: Periodic XRAN resets; truncated frames; jittery latency.

Cause: GRO/LSO/NIC Coalesce corrupt captures, MTU mismatch, oversubscription.

Steps: 

1. Disable GRO/LSO for test; set uniform MTU (e.g., 9200).

2. Ensure ≥15% headroom; pin eCPRI queues.

3. Retest with clean PCAPs (no truncation).

Validate: No resets; clean counters.

Prevent: Golden NIC/driver baselines.

CU‑10) Frame/subframe/slot counters wrap/offset

The control plane references frame, subframe, and slot indices (time positions). If DU and RU disagree on the epoch or how counters roll over, sections arrive “early” or “late” and are dropped.

Symptoms: Random decode gaps; “late section” logs.

Cause: Off‑by‑one in frame counters or timestamping.

Steps: 

1. Check frame_id/subframe/slot continuity across PCAPs.

2. Align DU clock to S‑plane; verify TSN/SyncE.

3. Patch DU/RU to same epoch/frame mapping.

Validate: No late/early section alarms for >1 h.

Prevent: Counter wrap tests in CI.

3.2 Step‑by‑step

1)      Freeze & capture

• Take back‑to‑back PCAPs on O‑DU and O‑RU sides for 5–10 s around the event. Ensure full frames (no truncation) and nanosecond timestamps.

• Record RF metrics in the same window (EVM/ACLR/OBUE, DL power, UL noise rise).

2)      Sanity parse (Wireshark + dissector)

• Validate Section Header fields: section_id, frame_id, subframe, slot, start_prb, num_prb.

• Verify eAxC → AntennaPort mapping; confirm consistency with axc_id/ru_port_id in M‑plane config.

• Compression: check compMeth, iqBitWidth, compShift across C/U. All paths must match negotiated capabilities.

3)      PRACH deep‑dive

• Check format (A1/A2/A3/B1/B4/C0/C2), preamble repetition, and comb parameters.

• Confirm section timing aligns with numerology μ and PRACH occasion index.

4)      Beamforming weights

• Validate weight format and scaler bit‑width versus RU capability; confirm Endianness and complex packing.

• If vendor uses Section Extension #4/#25 for additional metadata, ensure both sides interpret the same structure.

5)      Transport & rate

• Check MTU/Jumbo alignment; disable NIC GRO/LSO for capture precision; ensure line rate headroom ≥ 15%.

• Confirm QoS: eCPRI DSCP/COS lanes do not starve PTP.

6)      Iterative fixes

• Harmonize compression to the least common denominator.

• Re‑derive eAxC map from M‑plane and ensure C‑plane reflects it.

• Apply PRACH template from the conformance suite; re‑test.

Artifacts to keep: PCAPs, decoded section tables, RF screenshots, and the exact config deltas.

4) S‑Plane Troubleshooting

S‑1) Flapping GM/instability

Multiple apparent grandmasters or wrong priority vectors cause frequent master changes, producing time steps or phase jumps at the radio.

Use a single grandmaster per Precision Time Protocol domain during test; ensure priority1/priority2 force deterministic win. Continuous “slave” state with no announce storms is your acceptance.

If configurations are wrong — for example two devices both believe they are “best” — you get flapping (rapid master changes).

Spec thresholds:

• BMCA flaps should be zero in steady state.

• Grandmaster Announce interval typically ≤ 1 s.

• Time to settle after a change ≤ 5 min per ITU-T G.8275.1 guidance.

Symptoms: RU PTP state toggles; TE spikes; RU loses lock.

Cause: Multiple visible GMs or wrong priority vectors.

Steps: 

1. Ensure one GM per domain; set priority1/2 to win.

2. Block foreign Announce on test VLAN.

3. Verify BC/TC roles; limit BC chain depth.

Validate: Stable SLAVE; no Announce storms.

Prevent: Domain isolation & priority policy.

S‑2) SyncE not selected / bad QL

Without Synchronous Ethernet, frequency must be held only by Precision Time Protocol corrections; load or wander can push frequency out of tolerance, making dynamic time error ramp.

Symptoms: Frequency slips; dTE ramps; RU holdover toggles.

Cause: ESMC SSM not preferred; EEC not locked.

Steps: 

1. Verify ESMC presence and QL=PRC/PRS.

2. Force SyncE as freq source; replace optics if LOS/LOP.

Validate: EEC Locked; frequency offset < spec.

Prevent: ESMC guard + LOS alarms.

S‑3) PTP QoS starvation / policing

If timing packets share queues with heavy user traffic—or encounter policers—dynamic time error increases under load.

Give highest class/queue to Precision Time Protocol; disable policing for event messages; keep transparent clock residence time within your budget per hop (operator-defined from ITU-T budget examples).

Symptoms: cTE/dTE exceed spec under load.

Cause: PTP shares queue with eCPRI; policer drops Sync.

Steps: 

1. Give PTP highest CoS/queue; disable policing.

2. Verify TC residence time < budget; ECMP off for PTP.

Validate: dTE within window during traffic stress.

Prevent: QoS profiles locked in fabric.

S‑4) Link asymmetry (fiber/optic)

Different delays on transmit vs. receive paths create a constant phase offset that Precision Time Protocol cannot remove without compensation.

Constant time error must remain inside your max |time error| budget (derived per design from G.8271.x examples). If not, compensate or replace optics/fiber.

Symptoms: Constant phase offset; passes frequency, fails phase.

Cause: Unequal TX/RX delay.

Steps: 

1. Swap optics/fibers; measure asymmetry.

2. Apply asymmetry compensation if supported.

Validate: Phase error within spec.

Prevent: Calibrated patch cords; vendor delay tables.

S‑5) Measurement window misinterpretation (cTE/dTE)

Different tools sometimes compute peak-to-peak vs. root-mean-square or use different window lengths and filters. Labs then “disagree” on pass/fail.

Symptoms: “Fail” though RF is fine; lab‑to‑lab disagreement.

Cause: p‑p vs RMS windowing mismatch; filter bandwidth differences.

Steps: 

1. Align to the spec’s window definition and filter.

2. Retake 10‑min baseline; repeat disturbance tests.

Validate: Convergent TE metrics across tools.

Prevent: Single approved timing toolchain.

5) M‑Plane Troubleshooting

M‑1) TLS/ciphersuite mismatch

Netconf Client and server disagree on protocol version or cipher suite → handshake fails.

Symptoms: NETCONF can’t connect; handshake fails.

Cause: Unsupported TLS version/cipher.

Steps: 

1. List RU accepted suites; align DU client.

2. Enable NETCONF chunked framing.

Validate: Stable handshake; <hello> exchanged.

Prevent: Security baseline matrix.

M‑2) Missing YANG modules / yang‑library mismatch

The distributed unit pushes configuration that references modules or revisions the radio unit doesn’t serve—leading to unknown-element errors.

Exact revision alignment is required. Query the radio unit’s yang-library first, then generate templates against those revisions

Symptoms: <rpc-error> unknown‑element.

Cause: DU template references absent module/rev.

Steps: 

1. Query yang-library on RU.

2. Regenerate DU profile against exact revisions.

Validate: get-schema succeeds; no unknowns.

Prevent: Version pinning.

M‑3) Deviations not applied

Vendors legally alter constraints via YANG deviation statements. If your validator or generator ignores those, otherwise “valid” edits are rejected.

Symptoms: Valid model still rejects edits.

Cause: Vendor deviations alter must/when or leaf types.

Steps: 

1. Load deviation files into validator.

2. Reorder edits to meet constraints.

Validate: edit-config returns ok.

Prevent: CI lint with deviations.

M‑4) Edit‑config ordering errors

Pushing leaves out of order can violate must/when constraints or enable the radio before timing is configured.

Enable only after clocking is configured and locked (see S-plane acceptance). ETSI TS 104 023 and WG4 management specs define the overall startup expectations.

Symptoms: RU stuck DISABLED; partial config applied.

Cause: Clock/axc configured after dependent leaves.

Steps: 

1. Apply: capabilities → static → dynamic (axc/port) → clocks → enable.

2. Use confirmed commit.

Validate: State ENABLED; alarms clear.

Prevent: Transactional playbooks.

M‑5) Leafref/path errors (XPath)

YANG leaf-ref paths or namespaces change across revisions; stale templates point to nowhere.

schema correctness is the threshold. Validate with a YANG linter before applying.

Symptoms: bad-attribute / data-missing.

Cause: Wrong path targets after model changes.

Steps: 

1. Re‑resolve leafrefs; fix namespaces.

2. Validate with pyang --lint.

Validate: No path errors.

Prevent: Schema‑driven codegen.

M‑6) Software package activation failure

Wrong bundle type or signature → activation rejected; the radio unit reboots into the old image.

Symptoms: RU boots old image; activation rejected.

Cause: Wrong bundle type/signature or missing hooks.

Steps: 

1. Verify package type & signature; upload via M‑plane RPC.

2. Sw download -> sw install -> sw activate → commit → reboot in order.

Validate: New hash in inventory; running version updated.

Prevent: Signed artifacts; rollback plan.

M‑7) Certificate trust/expiry

Sessions work for months, then fail. Cause: expired device or intermediate certificate, or missing certificate authority chain.

TLS validation must succeed end-to-end; time must be correct

Symptoms: Handshake drops after months; random failures.

Cause: Expired RU/DU certs; missing CA chain.

Steps: 

1. Check validity; install full chain; sync time.

2. Rotate before expiry via maintenance window.

Validate: Clean TLS logs; stable sessions.

Prevent: Cert lifecycle policy.

M‑8) Keepalive/window sizing issues

Big responses (for example inventory or logs) on small windows or inactive keepalives cause NETCONF disconnects.

Set keepalive to a sane interval (for example 30–60 s) and enable chunked framing when fetching large datasets as recommended by many vendor profiles.

Symptoms: NETCONF sessions drop under load.

Cause: Tiny keepalive/window; large replies unchunked.

Steps: 

1. Increase keepalive; enable chunking.

2. Split large edits; back‑off timers.

Validate: No mid‑RPC drops.

Prevent: Stress tests with max payloads.

M‑9) Inventory/capability skew → C/U mismatch

You push a C/U profile that assumes a compression or PRACH mode the radio unit never advertised. M-plane “passed”, but user/control planes fail.

Symptoms: C/U errors after seemingly “good” M‑plane.

Cause: DU assumes unsupported compression/PRACH/BF.

Steps: 

1. Re‑read capabilities; diff against DU profile.

2. Constrain DU to intersection; re‑generate C/U.

Validate: Clean C/U decode; RF KPIs pass.

Prevent: Auto‑render from live capabilities.

M‑10) State machine deadlock (enable before clock)

Issuing “enable” while Precision Time Protocol/Synchronous Ethernet are not configured or locked leaves the radio unit “enabled” in name only—no fronthaul starts.

Symptoms: Enable RPC accepted but RU never transmits.

Cause: Enable issued before clock/SyncE/PTP config.

Steps: 

1. Disable; configure clocks; wait for lock.

2. Re‑enable; verify operational state.

Validate: RU ENABLED; C/U flows start.

Prevent: Pre‑enable timing checks.

Golden tip: Always derive C/U templates from M‑plane reported capabilities (and not from static profiles).

6) Minimal, Repeatable Test Recipes

6.1 PRACH sanity (C/U)

• Configure one carrier, single RU port, no compression.

• Generate a fixed PRACH occasion; capture PCAP; verify PRACH section & RF detection.

6.2 Timing Tests (S)

• Establish SyncE + PTP with one BC; measure cTE/dTE for 10 min baseline.

• Inject ±TE per spec; correlate RF KPI deltas.

6.3 M‑plane startup

• Clean boot; record complete NETCONF transcript; validate against YANG with pyang --max-line-length=120.

7) Tools & On‑box Commands

• PCAP & parsing - tcpdump -i <intf> -s 0 -w du_side.pcap vlan <id> and (udp port 319 or 320 or 2152 or 7 or 5000) - Wireshark with O‑RAN/eCPRI dissector for section tables export.

• Timing - pmc -u -b 0 'GET TIME_STATUS_NP' (gPTP) or vendor PTP CLI to read cTE/dTE. - Check ESMC SSM and SyncE lock.

• NETCONF/YANG - netconf-console --hello / get --filter='<modules-state/yang-library>' to list models. - pyang to lint models and deviations.

8) References & Pointers

1. O‑RAN WG4 CUS‑Plane and M‑Plane specifications (latest revs).

2. Clarifications in S‑Plane test cases (definitions of cTE/dTE/max|TE|, LLS‑C2 sine amplitudes, PRACH clarifications, modulation compression options).

3. Open Fronthaul Conformance & Interop Test Specifications for test topology, mandatory/conditional test lists, and PRACH/beamforming updates.