O-RAN: Analysis of Latency-critical Interfaces and Overview of Time Sensitive Networking Solutions

Andres Garcia-Saavedra; Esteban Municio; Gines Garcia-Aviles; Xavier Costa-P\'erez

REVIEW 2 major objections 5 minor 15 references

O-RAN can keep hard latency bounds on shared Ethernet by adopting TSN frame preemption and time-aware shaping instead of dedicated over-provisioned links.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · grok-4.5

2026-07-31 00:34 UTC pith:IZNNBKQY

load-bearing objection Clean architectural map of TSN onto O-RAN interfaces; useful exposition, no new measurements or algorithms, and the schedule-overhead question is left open. the 2 major comments →

arxiv 2607.27448 v1 pith:IZNNBKQY submitted 2026-07-29 cs.NI

O-RAN: Analysis of Latency-critical Interfaces and Overview of Time Sensitive Networking Solutions

Esteban Municio , Gines Garcia-Aviles , Andres Garcia-Saavedra , Xavier Costa-P\'erez This is my paper

classification cs.NI

keywords O-RANTime-Sensitive NetworkingOpenFronthaul802.1Qbv802.1QbuvRANfronthauldeterministic Ethernet

verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

O-RAN promises open, multi-vendor, cloud-native radio access by disaggregating functions and sharing transport, but the OpenFronthaul and related interfaces still demand microsecond-scale deterministic delay. The paper argues that ordinary Ethernet can meet those bounds if it is equipped with Time-Sensitive Networking, specifically the fronthaul profile in IEEE 802.1CM together with frame preemption (802.1Qbu) and time-aware gate schedules (802.1Qbv). It maps the TSN configuration entities onto O-RAN’s near-RT and non-RT RICs, enumerates the timing and synchronization constraints that any deployment must satisfy, and shows how existing open-source O-RAN components can be extended. The practical payoff is the replacement of expensive point-to-point fibre or WDM with a single shared Ethernet fabric that still guarantees the 100 µs fronthaul budget, cutting total cost of ownership while preserving multi-vendor openness.

Core claim

The central claim is that O-RAN’s time-critical interfaces—chiefly the OpenFronthaul CUS-plane and the F1 midhaul—can obtain bounded end-to-end latency and near-zero packet-delay variation over cost-efficient shared Ethernet by adopting IEEE 802.1CM together with 802.1Qbu preemption and 802.1Qbv time-aware shaping, with the TSN Centralized Network Configuration realized as a near-RT RIC xApp and the Centralized User Configuration as a non-RT RIC rApp.

What carries the argument

IEEE 802.1Qbv time-aware shaping (gate control lists synchronized across bridges) jointly used with 802.1Qbu frame preemption inside the 802.1CM fronthaul profiles; these mechanisms turn a shared Ethernet fabric into a deterministic TDMA-like medium while still allowing lower-priority traffic to fill unused slots.

Load-bearing premise

The extra management complexity and CPU cost of computing and distributing 802.1Qbv gate schedules will stay small enough inside O-RAN’s near-real-time control loops that the cost advantage of shared Ethernet is not erased.

What would settle it

Measure end-to-end fronthaul latency and packet-delay variation on a multi-hop TSN Ethernet fabric carrying several concurrent OpenFronthaul flows plus best-effort traffic; if the 100 µs one-way budget is exceeded once the CNC must recompute schedules under realistic load fluctuations, the claim fails.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

Operators can replace dedicated point-to-point fibre or WDM fronthaul with a single shared Ethernet network and still meet OpenFronthaul timing.
Legacy CPRI and new eCPRI flows can coexist on the same TSN fabric by aligning 802.1Qbv cycles to transmission-time intervals.
The near-RT RIC becomes the natural home for a TSN CNC xApp that continuously audits and reconfigures flow schedules.
Statistical multiplexing gain appears while hard latency bounds are preserved, lowering total cost of ownership by roughly the figures cited for shared fronthaul.
Dynamic functional splits become feasible because network latency budgets can be adapted to O-DU computational load via gate-schedule updates.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

If schedule computation remains too heavy for exact algorithms, the same near-RT RIC that hosts the CNC is the natural place to run learned or approximate schedulers, turning an acknowledged bottleneck into an AI/ML workload.
Successful TSN integration would also give O-RAN a clean path to converge fronthaul and backhaul onto one Ethernet underlay, something the paper notes but does not quantify.
The unspecified CUC–CNC interface left open by 802.1Qcc is likely to become a de-facto O-RAN standard once vendors start shipping the rApp/xApp pair.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Desk Editor's Note

Clean architectural map of TSN onto O-RAN interfaces; useful exposition, no new measurements or algorithms, and the schedule-overhead question is left open.

read the letter

This is a competent design-space survey, not a results paper. What it actually delivers is a careful mapping of existing IEEE 802.1CM / Qbu / Qbv mechanisms onto O-RAN’s latency-critical interfaces (OpenFronthaul CUS-plane first, then F1), plus concrete placement suggestions for CNC as a near-RT xApp and CUC as a non-RT rApp, and a short inventory of where the O-RAN SC code base would need hooks.

That mapping is done well. The authors stay close to the specs: eCPRI delay windows, LLS-C1–C4 topologies, Profile A/B, TAE budgets, and the FHI/xRAN library limitations are cited accurately. Table I and the deployment sketches in Fig. 4 are the parts I would actually keep open while thinking about a shared-Ethernet fronthaul. Self-citations to earlier Crosshaul/WizHaul work are background, not load-bearing. Circularity is essentially zero.

The soft spot is exactly the one the authors already flag in §IV-B: 802.1Qbv schedule computation is “heavy CPU-intensive” and near-RT performance is “challenging,” and 802.1Qcc leaves the CUC–CNC interface to vendors. They offer no numbers, no simulation, and no overhead budget, so the claim that shared TSN Ethernet still wins on TCO remains an assertion rather than a demonstrated result. That is a real gap for anyone who would implement this, but it does not break the organizational value of the paper; it simply marks where the next piece of work has to start.

Who it is for: people already inside the O-RAN/transport intersection who need a single coherent picture of which interfaces are TSN-qualified, which LLS topologies fit, and where the open-source seams are. It will not move anyone outside that subfield, and it does not resolve an open scientific question.

I would send it to peer review. A serious referee can judge whether the mapping is complete enough for a magazine-style piece and can push for at least a back-of-the-envelope schedule-cost discussion. I would cite the interface table and the RIC placement options if I were writing on fronthaul convergence; I would not cite it for any performance claim. Worth a quick reading-group pass if the group is already talking O-RAN transport.

Referee Report

2 major / 5 minor

Summary. The paper surveys how IEEE Time-Sensitive Networking (principally 802.1CM, 802.1Qbu frame preemption, and 802.1Qbv time-aware shaping) can supply deterministic latency and bounded PDV for O-RAN’s time-critical interfaces—especially OpenFronthaul CUS-plane and F1-u/c—over shared, cost-efficient Ethernet rather than dedicated over-provisioned links. It maps TSN configuration entities (CNC as a near-RT RIC xApp, CUC as a non-RT RIC rApp) onto the O-RAN architecture, reviews eCPRI delay windows, LLS-C1–C4 synchronization topologies, 802.1CM Profiles A/B, and O-RAN SC software touch-points (FHI/xRAN, O-DU High), and discusses opportunities (Crosshaul multiplexing, joint Qbv/Qbu) together with acknowledged challenges (schedule computation load, vendor-defined CUC–CNC interaction).

Significance. If the architectural mapping is accepted, the paper supplies a concrete, standards-grounded blueprint that operators and the O-RAN Alliance can use when moving from dedicated fronthaul to shared Ethernet. The value is organizational rather than empirical: it correctly collates latency budgets, LLS topologies, Profile A/B rules, and O-RAN SC integration points that are otherwise scattered across IEEE 802.1CM/Q and O-RAN WG4/WG9 documents, and it explicitly flags the open control-plane questions (CNC placement, schedule overhead). For a survey/architecture venue this is useful community infrastructure; the absence of new measurements is expected for the genre and does not erase the mapping’s utility.

major comments (2)

[§IV-B] §IV-B states that CNC schedule computation is “heavy CPU-intensive” and that “near-real-time performance may be challenging for exact algorithms,” yet offers neither a complexity bound, a citation to existing TSN traffic-planning results (e.g., Steiner et al. already cited as [15]), nor a qualitative argument that the near-RT RIC control-loop (10 ms–1 s) can absorb re-computation and O1/E2 distribution. Because the paper’s central feasibility claim rests on CNC-as-xApp being viable inside those loops, a short quantitative or literature-backed feasibility sketch (even order-of-magnitude gate-list sizes or re-computation intervals) is needed to keep the claim load-bearing rather than aspirational.
[§II-C, §III-C] §II-C and §III-C propose CNC as a near-RT xApp and CUC as a non-RT rApp, and an additional south-bound interface (O1 or extended E2) for schedule delivery to the O-DU. 802.1Qcc leaves the CUC–CNC protocol to vendors; the manuscript does not indicate which information elements (gate-control lists, stream IDs, TX/RX window offsets) would travel over O1/E2 nor how they would be reconciled with existing F1 and OpenFronthaul timing. Without at least a sketch of the required IEs or a statement that this is left as future O-RAN Alliance work, the integration path remains too underspecified to support the “natively support a CNC” claim.

minor comments (5)

[Table I] Table I lists max-delay ranges (e.g., OF U 25 µs–1 ms, F1 1.5–10 ms) without explicit pointers to the O-RAN CUS or 3GPP clauses that define each bound; adding a column or footnote with document/version references would improve traceability.
[Fig. 1] Fig. 1 places CNC/CUC and boundary clocks but does not show the control-plane arrows (O1/E2/A1) that would carry schedule or stream-requirement messages; a dashed overlay would clarify the proposed control loops.
[§III-B] §III-B: the statement that Profile B’s worst-case preemption latency is “1080 ns in a 1 Gb/s link” is correct for a 124-byte fragment, but the text should note that the figure scales inversely with link rate (important for 10/25 GbE fronthaul).
Minor typographical inconsistencies: “802.Qbv” vs “802.1Qbv” (§IV-B), “fan-in” delay introduced without definition in the Introduction, and “adApp”/“dApp” used once without expansion beyond the citation.
[§IV] The economic claim of “30 % TCO reduction” (§IV) is supported only by an external project deliverable URL; a one-sentence summary of the scenario assumptions (number of sectors, optics prices, traffic mix) would make the figure self-contained.

Circularity Check

0 steps flagged

No circularity: architectural survey mapping existing IEEE/O-RAN specs, not a derivation or prediction chain

full rationale

The paper is an architectural review that maps established TSN standards (IEEE 802.1CM, 802.1Qbu, 802.1Qbv, 802.1Qcc) and O-RAN specifications (OpenFronthaul CUS/M-plane, LLS-C1–C4, eCPRI delay windows, O-RAN SC components) onto deployment options (CNC as near-RT xApp, CUC as non-RT rApp). It does not claim first-principles derivations, quantitative predictions, fitted parameters, or uniqueness theorems. Self-citations ([2], [7], [10]) supply background on O-RAN and Crosshaul/WizHaul context and are not used to close any load-bearing argument by construction. Latency bounds and profiles are taken from external standards (O-RAN WG4/WG9, IEEE 802.1CM Profiles A/B), not redefined from the paper’s own outputs. Discussion §IV openly flags schedule-computation cost and unspecified CUC–CNC interaction as open challenges rather than asserting them as proven results. No step reduces a claimed prediction to its inputs. Circularity score is therefore 0.

Axiom & Free-Parameter Ledger

0 free parameters · 3 axioms · 0 invented entities

As a standards-mapping survey the paper inherits latency numbers, topology classes and TSN mechanisms from O-RAN and IEEE documents; it introduces no fitted constants and only lightly postulates controller placement. The ledger is therefore thin: domain assumptions drawn from the cited specs, plus one architectural placement choice that is presented as optional.

axioms (3)

domain assumption OpenFronthaul U-plane one-way latency budget is typically 100 µs (ultra-low-latency cases 25 µs) and must be met end-to-end including switching and processing.
Taken directly from O-RAN.WG4.CUS and eCPRI delay models (Sections III-B, Table I); load-bearing for any claim that TSN is necessary or sufficient.
domain assumption IEEE 802.1Qbv time-aware shaping plus 802.1Qbu preemption can bound PDV to essentially zero for multiple high-priority flows on shared Ethernet when schedules are correctly computed and synchronized.
Assumed from the TSN literature and 802.1CM (Section II-A); the paper does not re-derive or re-measure this property.
ad hoc to paper CNC can be realized as a near-RT RIC xApp and CUC as a non-RT RIC rApp without violating O-RAN control-loop timing.
Architectural proposal in Section II-C and Figure 1; not mandated by either O-RAN or 802.1Qcc and left as a design option.

pith-pipeline@v1.2.0-daily-grok45 · 18225 in / 2437 out tokens · 41651 ms · 2026-07-31T00:34:38.382406+00:00 · methodology

0 comments

read the original abstract

5G and B5G/6G foundations heavily rely on virtualization technologies, and virtualized Radio Access Networks (vRANs) are one of their major keystones. However, while vRANs have been traditionally suffering from significant hardware/software coupling, next generation vRANs aim for open, standardized interfaces and multi-vendor, interoperable components to enable truly flexible deployments following the cloud-native principles. In this line, the O-RAN Alliance is promoting a novel Open RAN architecture to further boost flexibility and cost efficiency. In order to reduce costs and effectively achieve the promised disaggregation levels, O-RAN must ensure shared, integrated transport networks in opposition to dedicated, over-provisioned links from traditional approaches. However, keeping deterministic performance requirements in such cost-effective networks (i.e., general-purpose Ethernet networks), especially in those interfaces that are time-critical, is a challenge. In this article, we review the most relevant Time Sensitive Networking (TSN) standards that may bring compelling benefits to O-RAN (i.e., IEEE 802.1CM, IEEE 802.1Qbu and IEEE 802.1Qbv) for providing determinism over cost-efficient networks. We explore the design space for a TSN-enabled O-RAN architecture, reporting on the requirements and deployment options and finally, we discuss on the opportunities and challenges that O-RAN will face when adopting TSN technologies to fully open the vRAN ecosystem.

Figures

Figures reproduced from arXiv: 2607.27448 by Andres Garcia-Saavedra, Esteban Municio, Gines Garcia-Aviles, Xavier Costa-P\'erez.

**Figure 3.** Figure 3: Timing relations per U/C message in DL direction. [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗

**Figure 4.** Figure 4: Different deployment options and their effect on the TAE according to the O-RU and O-DU locations. [PITH_FULL_IMAGE:figures/full_fig_p006_4.png] view at source ↗

discussion (0)

Reference graph

Works this paper leans on

15 extracted references

[1]

Intelli- gence and learning in O-RAN for data-driven NextG cellular networks,

L. Bonati, S. D’Oro, M. Polese, S. Basagni, and T. Melodia, “Intelli- gence and learning in O-RAN for data-driven NextG cellular networks,” IEEE Communications Magazine, vol. 59, no. 10, pp. 21–27, 2021

2021
[2]

O-RAN: Disrupting the vir- tualized RAN ecosystem,

A. Garcia-Saavedra and X. Costa-Perez, “O-RAN: Disrupting the vir- tualized RAN ecosystem,”IEEE Communications Standards Magazine, 2021

2021
[3]

Introduction to time-sensitive networking,

N. Finn, “Introduction to time-sensitive networking,”IEEE Communi- cations Standards Magazine, vol. 2, no. 2, pp. 22–28, 2018

2018
[4]

IEEE Std 802.1Q-2018 Local and Metropolitan Area Networks: Bridges and Bridged Networks,

IEEE, “IEEE Std 802.1Q-2018 Local and Metropolitan Area Networks: Bridges and Bridged Networks,” IEEE Computer Society, 2018

2018
[5]

O-RAN Fronthaul Control, User and Synchronization Plane Specification 7 (O-RAN.WG4.CUS.0-v07.00),

O-RAN Alliance, “O-RAN Fronthaul Control, User and Synchronization Plane Specification 7 (O-RAN.WG4.CUS.0-v07.00),” Tech. Rep., 2021

2021
[6]

IEEE Standard for Local and metropolitan area networks: Time- Sensitive Networking for Fronthaul,

IEEE, “IEEE Standard for Local and metropolitan area networks: Time- Sensitive Networking for Fronthaul,” IEEE Computer Society, 2018

2018
[7]

Integrating fronthaul and backhaul networks: Trans- port challenges and feasibility results,

S. Gonzalez-Diaz, A. Garcia-Saavedra, A. de la Oliva, X. Costa-Perez, R. Gazda, A. Mourad, T. Deiss, J. Mangues-Bafalluy, P. Iovanna, S. Straccaet al., “Integrating fronthaul and backhaul networks: Trans- port challenges and feasibility results,”IEEE Transactions on Mobile Computing, vol. 20, no. 2, pp. 533–549, 2019

2019
[8]

Design aspects of low-latency ser- vices with time-sensitive networking,

C. Simon, M. Maliosz, and M. Mate, “Design aspects of low-latency ser- vices with time-sensitive networking,”IEEE Communications Standards Magazine, vol. 2, no. 2, pp. 48–54, 2018

2018
[9]

Boosting 5G through Ethernet: How evolved fronthaul can take next-generation mobile to the next level,

N. J. Gomes, P. Sehier, H. Thomas, P. Chanclou, B. Li, D. Munch, P. Assimakopoulos, S. Dixit, and V . Jungnickel, “Boosting 5G through Ethernet: How evolved fronthaul can take next-generation mobile to the next level,”IEEE vehicular technology magazine, 2018

2018
[10]

WizHaul: On the centralization degree of cloud RAN next generation fronthaul,

A. Garcia-Saavedra, J. X. Salvat, X. Li, and X. Costa-Perez, “WizHaul: On the centralization degree of cloud RAN next generation fronthaul,” IEEE Transactions on Mobile Computing, vol. 17, 2018

2018
[11]

IEEE Standard for Local and Metropolitan Area Networks: Amendment 31: Stream Reservation Protocol (SRP) Enhancements and Performance Improvements,

IEEE, “IEEE Standard for Local and Metropolitan Area Networks: Amendment 31: Stream Reservation Protocol (SRP) Enhancements and Performance Improvements,” IEEE Computer Society, 2018

2018
[12]

Common Public Radio Interface: Requirements for the eCPRI Transport Network V1.2,

Ericsson AB, Huawei Technologies Co. Ltd., NEC Corporation, and Nokia, “Common Public Radio Interface: Requirements for the eCPRI Transport Network V1.2,” Tech. Rep., Jun 2018

2018
[13]

dApps: Distributed Applications for Real-Time Inference and Control in O- RAN,

S. D’Oro, M. Polese, L. Bonati, H. Cheng, and T. Melodia, “dApps: Distributed Applications for Real-Time Inference and Control in O- RAN,”IEEE Communications Magazine, vol. 60, no. 11, pp. 52–58, 2022

2022
[14]

Synchronization Architecture and Solution Specifica- tion 1.00 (O-RAN.WG9.XTRP-SYN.0-v01.00),

O-RAN Alliance, “Synchronization Architecture and Solution Specifica- tion 1.00 (O-RAN.WG9.XTRP-SYN.0-v01.00),” Tech. Rep., Jul 2021

2021
[15]

Traffic planning for time- sensitive communication,

W. Steiner, S. S. Craciunas, and R. S. Oliver, “Traffic planning for time- sensitive communication,”IEEE Communications Standards Magazine, vol. 2, no. 2, pp. 42–47, 2018. Esteban Municioreceived his Ph.D. degree from the University of Antwerp at imec (Belgium) in 2020. He then joined imec as postdoctoral researcher for two years. Since January 2022, he h...

2018

[1] [1]

Intelli- gence and learning in O-RAN for data-driven NextG cellular networks,

L. Bonati, S. D’Oro, M. Polese, S. Basagni, and T. Melodia, “Intelli- gence and learning in O-RAN for data-driven NextG cellular networks,” IEEE Communications Magazine, vol. 59, no. 10, pp. 21–27, 2021

2021

[2] [2]

O-RAN: Disrupting the vir- tualized RAN ecosystem,

A. Garcia-Saavedra and X. Costa-Perez, “O-RAN: Disrupting the vir- tualized RAN ecosystem,”IEEE Communications Standards Magazine, 2021

2021

[3] [3]

Introduction to time-sensitive networking,

N. Finn, “Introduction to time-sensitive networking,”IEEE Communi- cations Standards Magazine, vol. 2, no. 2, pp. 22–28, 2018

2018

[4] [4]

IEEE Std 802.1Q-2018 Local and Metropolitan Area Networks: Bridges and Bridged Networks,

IEEE, “IEEE Std 802.1Q-2018 Local and Metropolitan Area Networks: Bridges and Bridged Networks,” IEEE Computer Society, 2018

2018

[5] [5]

O-RAN Fronthaul Control, User and Synchronization Plane Specification 7 (O-RAN.WG4.CUS.0-v07.00),

O-RAN Alliance, “O-RAN Fronthaul Control, User and Synchronization Plane Specification 7 (O-RAN.WG4.CUS.0-v07.00),” Tech. Rep., 2021

2021

[6] [6]

IEEE Standard for Local and metropolitan area networks: Time- Sensitive Networking for Fronthaul,

IEEE, “IEEE Standard for Local and metropolitan area networks: Time- Sensitive Networking for Fronthaul,” IEEE Computer Society, 2018

2018

[7] [7]

Integrating fronthaul and backhaul networks: Trans- port challenges and feasibility results,

S. Gonzalez-Diaz, A. Garcia-Saavedra, A. de la Oliva, X. Costa-Perez, R. Gazda, A. Mourad, T. Deiss, J. Mangues-Bafalluy, P. Iovanna, S. Straccaet al., “Integrating fronthaul and backhaul networks: Trans- port challenges and feasibility results,”IEEE Transactions on Mobile Computing, vol. 20, no. 2, pp. 533–549, 2019

2019

[8] [8]

Design aspects of low-latency ser- vices with time-sensitive networking,

C. Simon, M. Maliosz, and M. Mate, “Design aspects of low-latency ser- vices with time-sensitive networking,”IEEE Communications Standards Magazine, vol. 2, no. 2, pp. 48–54, 2018

2018

[9] [9]

Boosting 5G through Ethernet: How evolved fronthaul can take next-generation mobile to the next level,

N. J. Gomes, P. Sehier, H. Thomas, P. Chanclou, B. Li, D. Munch, P. Assimakopoulos, S. Dixit, and V . Jungnickel, “Boosting 5G through Ethernet: How evolved fronthaul can take next-generation mobile to the next level,”IEEE vehicular technology magazine, 2018

2018

[10] [10]

WizHaul: On the centralization degree of cloud RAN next generation fronthaul,

A. Garcia-Saavedra, J. X. Salvat, X. Li, and X. Costa-Perez, “WizHaul: On the centralization degree of cloud RAN next generation fronthaul,” IEEE Transactions on Mobile Computing, vol. 17, 2018

2018

[11] [11]

IEEE Standard for Local and Metropolitan Area Networks: Amendment 31: Stream Reservation Protocol (SRP) Enhancements and Performance Improvements,

IEEE, “IEEE Standard for Local and Metropolitan Area Networks: Amendment 31: Stream Reservation Protocol (SRP) Enhancements and Performance Improvements,” IEEE Computer Society, 2018

2018

[12] [12]

Common Public Radio Interface: Requirements for the eCPRI Transport Network V1.2,

Ericsson AB, Huawei Technologies Co. Ltd., NEC Corporation, and Nokia, “Common Public Radio Interface: Requirements for the eCPRI Transport Network V1.2,” Tech. Rep., Jun 2018

2018

[13] [13]

dApps: Distributed Applications for Real-Time Inference and Control in O- RAN,

S. D’Oro, M. Polese, L. Bonati, H. Cheng, and T. Melodia, “dApps: Distributed Applications for Real-Time Inference and Control in O- RAN,”IEEE Communications Magazine, vol. 60, no. 11, pp. 52–58, 2022

2022

[14] [14]

Synchronization Architecture and Solution Specifica- tion 1.00 (O-RAN.WG9.XTRP-SYN.0-v01.00),

O-RAN Alliance, “Synchronization Architecture and Solution Specifica- tion 1.00 (O-RAN.WG9.XTRP-SYN.0-v01.00),” Tech. Rep., Jul 2021

2021

[15] [15]

Traffic planning for time- sensitive communication,

W. Steiner, S. S. Craciunas, and R. S. Oliver, “Traffic planning for time- sensitive communication,”IEEE Communications Standards Magazine, vol. 2, no. 2, pp. 42–47, 2018. Esteban Municioreceived his Ph.D. degree from the University of Antwerp at imec (Belgium) in 2020. He then joined imec as postdoctoral researcher for two years. Since January 2022, he h...

2018