pith. sign in

arxiv: 2604.25857 · v1 · submitted 2026-04-28 · 💻 cs.NI

Slice Agent: Identifying and Isolating Slices in Shared Open Radio Unit

Felipe Arnholda , Flavio Rocha , Lucio Prade , Cristiano Bonato Both This is my paper

Pith reviewed 2026-05-07 14:49 UTC · model grok-4.3

classification 💻 cs.NI
keywords network slicingopen RANO-RUuplink slicingeCPRIFPGA implementationfronthaul5G 6G
0
0 comments X

The pith

An embedded slicing agent in the Open Radio Unit identifies uplink slices from fronthaul data and isolates them into dedicated eCPRI packets.

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

The paper tackles the problem that shared Open Radio Units cannot inherently tell which uplink packets belong to which network slice because scheduling happens at the Open DU. It introduces a slicing agent placed inside the O-RU that examines available fronthaul information to recognize slices and repackage the data into separate eCPRI streams per slice. The design uses a pipeline with distinct paths for urgent and flexible operations so that processing stays within the tight timing limits of multi-point fronthaul links. When built on an FPGA the agent finishes each packet in two clock cycles and can manage up to 3822 slices in one slot. This would let slice-aware behavior extend all the way to the radio unit for services that need guaranteed isolation in 5G and 6G networks.

Core claim

We propose a slicing agent embedded in the O-RU that identifies slices and segregates uplink data into slice-specific enhanced Common Public Radio Interface (eCPRI) packets. Our design employs a pipeline architecture with dedicated paths for time-sensitive, flexible slicing, enabling slice isolation and prioritization. When implemented on an FPGA, the agent processes each packet in 2 clock cycles, supporting up to 3822 slices per slot.

What carries the argument

The slicing agent: a hardware pipeline inside the O-RU that reads fronthaul control information to label uplink packets by slice and emits separate eCPRI flows for each slice.

If this is right

  • Uplink traffic from multiple slices can be isolated and prioritized directly at the radio unit.
  • The approach satisfies the ultra-low-latency timing rules required for multi-point fronthaul.
  • One FPGA realization can handle thousands of concurrent slices per transmission slot.
  • End-to-end network slicing becomes possible without adding extra signaling overhead between DU and RU.

Where Pith is reading between the lines

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

  • The same agent structure might later be used to enforce per-slice power or beamforming rules at the radio unit.
  • Operators could test whether removing slice metadata from the fronthaul link reduces overall control-plane load.
  • The two-cycle pipeline latency bound offers a concrete target for comparing hardware versus software slice handling in future O-RAN testbeds.

Load-bearing premise

Slice identity for each uplink packet can be correctly read from existing fronthaul signals and messages without the O-DU sending explicit per-packet slice labels.

What would settle it

Running the FPGA design under realistic MP2MP fronthaul traffic and checking whether packets are correctly grouped by slice while every packet still finishes in exactly two clock cycles.

Figures

Figures reproduced from arXiv: 2604.25857 by Cristiano Bonato Both, Felipe Arnholda, Flavio Rocha, Lucio Prade.

Figure 1
Figure 1. Figure 1: Functional split options by different organizations, compared with a C-RAN. view at source ↗
Figure 2
Figure 2. Figure 2: Placement of proposed Slice Agent. Slice Agent FH U-Plane DL (eCPRI) FH C-Plane (eCPRI) FH M-Plane (NETCONF) LOW-PHY DL LOW-PHY UL FH C-Plane Manage FH MUX RF O-RU O-RU The architecture of the Slice Agent is presented in view at source ↗
Figure 3
Figure 3. Figure 3: O-RU Slice Agent architecture. Scheduling Data Process 1x14 Sched. Process Type "2" PHY LOW Fronthaul C-Plane C-Plane Message Decoding Control Unit Fronthaul M-Plane Scheduling Data Process 1x14 Ethernet Transceiver Ethernet Encapsulation Slice Agent Sched. Process Type "1" Symbol 0 Buffer 2x1 2x1 2x1 ... Symbol 1 Buffer Symbol 13 Buffer ... ... Time Synchro The second step performs scheduling data process… view at source ↗
Figure 4
Figure 4. Figure 4: Simplified pipeline structure. 17 view at source ↗
Figure 5
Figure 5. Figure 5: Detail of scheduling data processing. received via control messages, uplink processing will occur in the next time slot. The key difference in the Type "2" processing unit is how it handles scheduling information from the input FIFO. If the information is not rel￾evant for the current time slot, it is popped from the FIFO and reinserted at the FIFO input rather than blocking processing as in the Type "1" u… view at source ↗
Figure 6
Figure 6. Figure 6: Data fragmentation example. PRB: 0 - 60 Symbol: 0 - 1 S1 PRB: 0 - 10 Symbol: 0 - 3 S2 S1[0-30] S1[31-60] S2[0-10] Symbol 0 S1[0-30] S1[31-60] S2[0-10] Symbol 1 S2[0-10] Symbol 2 S2[0-10] Symbol 3 ... The output signals from each symbol must be combined into a single sig￾nal because there are two processing units. This combination is implemented using a 2x1 multiplexer that selects which active processing u… view at source ↗
Figure 7
Figure 7. Figure 7: Encapsulation diagram. Payload Length Multiplication unit NumPRB Sched Info Start PRB Scheduling info reading Header Header Mount Send Data Symbol Buffer NumBytesPRB Low PHY Eth Data start Byte The first step is to read the packet parameters from the symbol buffer. If an entry is available in the buffer output, the encapsulation unit reads it. Therefore, the payload size is calculated with the loaded infor… view at source ↗
Figure 8
Figure 8. Figure 8: Control Unit block diagram. Dest MAC Address Parameters Configuration Source MAC Address eCPRIIdCheck Slice Management eCpriValid IqSampleWidth symbolId Pipeline Control Control Unit add slice remove slice Source MAC Address IqSampleWidth Dest MAC Address Numerology Frequency Range eCPRIIdWrite frameID subframeID slotID nextSymbolId nextFrameID nextSubframeID nextSlotID swap symbSel Max PRB Packet Max PRB … view at source ↗
Figure 9
Figure 9. Figure 9: Slice Agent prototype. Metrics O-RU Emulation Slice Agent C-plane Interface Ethernet Transceiver UART Parameters Settings C-plane Messages Generator C-plane low-PHY Slot Ids Slice Mgmt Parameters U-Plane Reception ETHERNET Tester FPGA Board (SUT) We can set up all parameters for the O-RU emulation through the software component called Tester, which we wrote in Python. The Tester can generate configuration … view at source ↗
Figure 10
Figure 10. Figure 10: SUT sequence diagram. O-RU Emulation Slice Agent FPGA Board (SUT) Parameters Parameters C-Plane Messages Start command C-Plane Messages slot n PHY data slot n PHY data (ID) C-Plane Messages slot n+1 UART Ethenet Signal Legend Start byte Tester • Processing time: measured in clock cycles, processing time indicates how long it takes for the Slice Agent to handle specific tasks. This metric includes the time… view at source ↗
Figure 11
Figure 11. Figure 11: Processing time of a slice based on number of PRBs and MTU. view at source ↗
Figure 12
Figure 12. Figure 12: Number of packets and processing time for one slice of (a) 30, (b) 90, (c) 210, view at source ↗
Figure 13
Figure 13. Figure 13: Type "2" processing unit input FIFO occupation for 600 and 1200 slices per slot. Finally, it is essential to note that the processing units are isolated from each other, allowing critical slices to be assigned to the Type "1" unit. We evaluated this isolation using the URLLC use case. In the first scenario, where URLLC and mMTC share the Type "2" unit, all URLLC slices were lost because, by the time they … view at source ↗
read the original abstract

Network Slice as a Service (NSaaS) is a key enabler of Beyond Fifth Generation (5G) and Sixth Generation (6G) networks, supporting next-generation applications such as extended reality (XR), immersive services, and the tactile Internet. These networks must provide native support for slice-aware services across the entire Radio Access Network (RAN), including the Radio Unit (RU), Distributed Unit (DU), Central Unit (CU), and transport segments (fronthaul, midhaul, and backhaul). However, uplink slicing identification in shared Open-RUs (O-RUs) presents a fundamental challenge because the Open-DU (O-DU) handles scheduling, and the O-RU does not inherently know which uplink data belongs to which slice. In MultiPoint-to-MultiPoint (MP2MP) fronthaul scenarios, this limitation is further exacerbated by synchronization and timing constraints, which necessitate that the O-RU process control messages and the encapsulated data be delivered with ultra-low latency. To address this issue, we propose a slicing agent embedded in the O-RU that identifies slices and segregates uplink data into slice-specific enhanced Common Public Radio Interface (eCPRI) packets. Our design employs a pipeline architecture with dedicated paths for time-sensitive, flexible slicing, enabling slice isolation and prioritization. When implemented on an Field-Programmable Gate Array (FPGA), the agent processes each packet in 2 clock cycles, supporting up to 3822 slices per slot. Experimental results validate the approach, showing its feasibility, scalability, and high-performance capabilities for real-time, slice-aware uplink processing in Beyond 5G and 6G Open RAN deployments.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

1 major / 0 minor

Summary. The manuscript proposes a slicing agent embedded in the shared Open Radio Unit (O-RU) to identify network slices for uplink data and segregate them into slice-specific enhanced Common Public Radio Interface (eCPRI) packets. The design uses a pipeline architecture with dedicated paths for time-sensitive and flexible slicing to enable isolation and prioritization. An FPGA implementation is reported to process each packet in 2 clock cycles while supporting up to 3822 slices per slot, with experimental results demonstrating feasibility for real-time slice-aware processing in Beyond 5G and 6G Open RAN deployments.

Significance. If the results hold, the work would be significant for enabling Network Slice as a Service (NSaaS) across the full RAN including the RU in Open RAN architectures. It addresses the challenge of uplink slice identification in MP2MP fronthaul scenarios where the O-RU lacks inherent slice knowledge due to O-DU scheduling. The low-latency FPGA performance suggests practical applicability for ultra-low latency requirements in 5G/6G networks supporting applications like XR and tactile Internet. The concrete FPGA throughput figures and pipeline design are strengths that provide evidence of deployability.

major comments (1)
  1. The slice-identification logic is not described. The abstract states that the O-RU does not inherently know which uplink data belongs to which slice and that the agent must derive slice identity from available fronthaul information without explicit per-packet metadata from the O-DU, yet no algorithm, mapping from eCPRI headers/UE context, or robustness check under realistic multi-slice uplink traffic is provided. This is load-bearing for both the isolation claim and the reported 2-cycle FPGA performance, which appears to measure processing only after identity is known.

Simulated Author's Rebuttal

1 responses · 0 unresolved

Thank you for the constructive feedback and for recognizing the potential significance of our work in enabling NSaaS in Open RAN. We respond to the major comment as follows and will revise the manuscript to incorporate the necessary clarifications and additions.

read point-by-point responses

  1. Referee: The slice-identification logic is not described. The abstract states that the O-RU does not inherently know which uplink data belongs to which slice and that the agent must derive slice identity from available fronthaul information without explicit per-packet metadata from the O-DU, yet no algorithm, mapping from eCPRI headers/UE context, or robustness check under realistic multi-slice uplink traffic is provided. This is load-bearing for both the isolation claim and the reported 2-cycle FPGA performance, which appears to measure processing only after identity is known.

    Authors: We agree that the slice-identification logic requires more detailed exposition in the manuscript. The design derives slice identity by inspecting specific fields in the eCPRI headers (such as the eCPRI message type and flow identifiers) along with UE context information extracted from control plane messages, using a pre-provisioned mapping table at the O-RU. We will add a new subsection in Section III detailing the identification algorithm, including a flowchart and pseudocode. Additionally, we will include an analysis of robustness under multi-slice traffic by discussing worst-case scenarios and how the pipeline handles concurrent slices. Regarding the FPGA performance, the reported 2-clock-cycle latency encompasses the full pipeline including identification; we will provide a detailed timing breakdown in the revised manuscript to clarify this point. These changes will strengthen the claims and address the load-bearing nature of this component. revision: yes

Circularity Check

0 steps flagged

No circularity in proposed O-RU slicing agent design or FPGA results

full rationale

The paper presents an engineering proposal for a slicing agent embedded in the O-RU, using a pipeline architecture to identify slices from fronthaul information and segregate uplink data into slice-specific eCPRI packets. It reports an FPGA implementation that processes packets in 2 clock cycles and supports up to 3822 slices per slot, validated through experimental results. No mathematical derivations, equations, fitted parameters, predictions, or self-citations are described that reduce any claimed result to its inputs by construction. The performance claims rest on direct hardware measurement rather than any self-referential logic, making the work self-contained against external benchmarks.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 1 invented entities

The design rests on standard Open RAN fronthaul timing and protocol assumptions plus the new agent component. No numerical parameters are fitted to data in the visible text.

axioms (2)
  • domain assumption Uplink data arriving at the O-RU contains sufficient information for the agent to determine slice membership without additional signaling from the O-DU.
    Invoked implicitly when the agent is described as identifying slices from incoming data.
  • domain assumption MP2MP fronthaul timing constraints remain satisfied when the agent adds two clock cycles of processing per packet.
    Required for the latency claims to hold in the stated deployment scenario.
invented entities (1)
  • Slicing agent no independent evidence
    purpose: Identify uplink slices and segregate data into slice-specific eCPRI packets inside the O-RU
    New hardware/software component introduced to solve the identification problem.

pith-pipeline@v0.9.0 · 5613 in / 1605 out tokens · 106719 ms · 2026-05-07T14:49:42.577357+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

45 extracted references · 45 canonical work pages

  1. [1]

    (2019) The 5G Guide: A Refer- ence for Operators

    GSM Association. (2019) The 5G Guide: A Refer- ence for Operators. Accessed on August 21, 2023. [On- line]. Available: https://www.gsma.com/wp-content/uploads/2019/ 04/The-5G-Guide_GSMA_2019_04_29_compressed.pdf

    work page 2019

  2. [2]

    Zero-touch network and Service Management (ZSM); End-to-end management and orchestration of network slicing,

    ETSI GS ZSM, “Zero-touch network and Service Management (ZSM); End-to-end management and orchestration of network slicing,” European Telecommunications Standards Institute, TS, 2021, version 1.1.1. [Online]. Available: https://www.etsi.org/deliver/etsi_gs/ZSM/ 001_099/003/01.01.01_60/gs_ZSM003v010101p.pdf

    work page 2021

  3. [3]

    WhenSDNmeetsC-RAN:Asurveyexploringmulti- point coordination, interference, and performance,

    F.Z.Moraiset al., “WhenSDNmeetsC-RAN:Asurveyexploringmulti- point coordination, interference, and performance,”Journal of Network and Computer Applications, vol. 162, p. 102655, 2020. 35

    work page 2020

  4. [4]

    NR; NR and NG-RAN Overall description; Stage- 2,

    3GPP, “NR; NR and NG-RAN Overall description; Stage- 2,” 3rd Generation Partnership Project, TS Version 15.0.0,

    work page

  5. [5]

    Available: https://portal.3gpp.org/desktopmodules/ Specifications/SpecificationDetails.aspx?specificationId=3191

    [Online]. Available: https://portal.3gpp.org/desktopmodules/ Specifications/SpecificationDetails.aspx?specificationId=3191

    work page

  6. [6]

    NR; NR and NG-RAN Overall description; Stage-2,

    ——, “NR; NR and NG-RAN Overall description; Stage-2,” 3rd Generation Partnership Project, TS 38.300, 2023, version 16.12.0. [Online]. Available: https://portal.3gpp.org/desktopmodules/ Specifications/SpecificationDetails.aspx?specificationId=3191

    work page 2023

  7. [7]

    NR; NR and NG-RAN Overall description; Stage-2,

    ——, “NR; NR and NG-RAN Overall description; Stage-2,” 3rd Generation Partnership Project, TS 38.300, 2023, version 17.4.0. [Online]. Available: https://portal.3gpp.org/desktopmodules/ Specifications/SpecificationDetails.aspx?specificationId=3191

    work page 2023

  8. [8]

    O-RAN Architecture Description 9.0,

    O-RAN Alliance, “O-RAN Architecture Description 9.0,” Open Radio Access Network Alliance, TS Work Group 1 - Version 9, 2023, Accessed on August 21, 2023. [Online]. Available: https: //orandownloadsweb.azurewebsites.net/specifications

    work page 2023

  9. [9]

    Control, User and Synchronization Plane Specification,

    ——, “Control, User and Synchronization Plane Specification,” Open Radio Access Network Alliance, TS Work Group 4 - Version 12, 2023, Accessed on August 21, 2023. [Online]. Available: https://orandownloadsweb.azurewebsites.net/specifications

    work page 2023

  10. [10]

    Slicing Architecture,

    ——, “Slicing Architecture,” Open Radio Access Network Alliance, TS Work Group 1 - Version 10, 2023, Accessed on August 21, 2023. [Online]. Available: https://orandownloadsweb.azurewebsites.net/specifications

    work page 2023

  11. [11]

    Use Cases Detailed Specification,

    ——, “Use Cases Detailed Specification,” Open Radio Access Network Alliance, TS Work Group 1 - Version 10, 2023, Accessed on August 21, 2023. [Online]. Available: https://orandownloadsweb.azurewebsites. net/specifications

    work page 2023

  12. [12]

    Dahlman, S

    E. Dahlman, S. Parkvall, and J. Skold,5G NR: The next generation wireless access technology. Academic Press, 2020

    work page 2020

  13. [13]

    TS 23.501: System Architecture for the 5G System (5GS),

    3GPP, “TS 23.501: System Architecture for the 5G System (5GS),” 3rd Generation Partnership Project (3GPP), Technical Specification 23.501, Dec. 2025, release 20, Stage 2. 36

    work page 2025

  14. [14]

    TS 23.502: Procedures for the 5G System (5GS),

    ——, “TS 23.502: Procedures for the 5G System (5GS),” 3rd Generation Partnership Project (3GPP), Technical Specification 23.502, Dec. 2025, release 20, Stage 2

    work page 2025

  15. [15]

    A vision of 6G wireless systems: Applications, trends, technologies, and open research problems,

    W. Saad, M. Bennis, and M. Chen, “A vision of 6G wireless systems: Applications, trends, technologies, and open research problems,”IEEE network, vol. 34, no. 3, pp. 134–142, 2019

    work page 2019

  16. [16]

    Thebridgetoward6G:5G-Advancedevolutionin3GPPRelease I9,

    X.Lin, “Thebridgetoward6G:5G-Advancedevolutionin3GPPRelease I9,”IEEE Communications Standards Magazine, vol. 9, no. 1, pp. 28–35, 2025

    work page 2025

  17. [17]

    Cloud RAN for mobile networks—A tech- nology overview,

    A. Checko, H. L. Christiansen, Y. Yan, L. Scolari, G. Kardaras, M. S. Berger, and L. Dittmann, “Cloud RAN for mobile networks—A tech- nology overview,”IEEE Communications surveys & tutorials, vol. 17, no. 1, pp. 405–426, 2014

    work page 2014

  18. [18]

    A Survey of the Functional Splits Proposed for 5G Mobile Crosshaul Networks,

    L. Larsen, A. Checko, and H. Christiansen, “A Survey of the Functional Splits Proposed for 5G Mobile Crosshaul Networks,”IEEE Communi- cations Surveys & Tutorials, vol. 21, no. 1, pp. 146–172, 2019

    work page 2019

  19. [19]

    TS 38.401: NG-RAN; Architecture description,

    3GPP, “TS 38.401: NG-RAN; Architecture description,” 3rd Generation Partnership Project (3GPP), Technical Specification 38.401, Dec. 2025, release 19

    work page 2025

  20. [20]

    PlaceRAN: Optimal Placement of Virtualized Net- work Functions in Beyond 5G Radio Access Networks,

    F. Z. Moraiset al., “PlaceRAN: Optimal Placement of Virtualized Net- work Functions in Beyond 5G Radio Access Networks,”IEEE Transac- tions on Mobile Computing, vol. 22, no. 9, pp. 5434–5448, 2023

    work page 2023

  21. [21]

    Network Slicing Support by Fronthaul Interface in Disaggregated Radio Access Networks: A Survey,

    F. Arnholdet al., “Network Slicing Support by Fronthaul Interface in Disaggregated Radio Access Networks: A Survey,”IEEE Transactions on Network and Service Management, vol. 21, no. 4, pp. 4510–4530, 2024

    work page 2024

  22. [22]

    Sliced-RAN: Joint slicing and functional split in fu- ture 5G radio access networks,

    B. Ojaghiet al., “Sliced-RAN: Joint slicing and functional split in fu- ture 5G radio access networks,” inIEEE International Conference on Communications (ICC). IEEE, 2019, pp. 1–6

    work page 2019

  23. [23]

    Impact of Network Densification on Joint Slicing and Functional Splitting in 5G,

    ——, “Impact of Network Densification on Joint Slicing and Functional Splitting in 5G,”IEEE Communications Magazine, 2022. 37

    work page 2022

  24. [24]

    Technical Specification Group Services and System Aspects; Management and orchestration; Concepts, use cases and requirements ,

    3GPP, “Technical Specification Group Services and System Aspects; Management and orchestration; Concepts, use cases and requirements ,” 3GPP, Tech. Rep. 38.801, 09 2022, version 17.3.0

    work page 2022

  25. [25]

    3GPP ts 23.501 technical specification group services and system aspects; system architecture for the 5G system; stage 2 (release 15),

    ——, “3GPP ts 23.501 technical specification group services and system aspects; system architecture for the 5G system; stage 2 (release 15),” 2017

    work page 2017

  26. [26]

    A framework for network slices in networks built from ietf technologies,

    A.Farrel, J.Drake, R.Rokui, S.Homma, K.Makhijani, L.M.Contreras, and J. Tantsura, “A framework for network slices in networks built from ietf technologies,” RFC 9543, IETF, Tech. Rep. 9543, Tech. Rep., 2024

    work page 2024

  27. [27]

    Management Plane Specification,

    O-RAN Work Group 4, “Management Plane Specification,” Open Radio Access Network Alliance, TS, 06 2023, version 12. [Online]. Available: https://orandownloadsweb.azurewebsites.net/specifications

    work page 2023

  28. [28]

    Orion: RAN slicing for a flexible and cost-effective multi-service mobile network architecture,

    X. Foukas, M. K. Marina, and K. Kontovasilis, “Orion: RAN slicing for a flexible and cost-effective multi-service mobile network architecture,” inProceedings of the 23rd annual international conference on mobile computing and networking, 2017, pp. 127–140

    work page 2017

  29. [29]

    On the Rollout of Network Slicing in Carrier Networks: A Technology Radar,

    J. Ordonez-Lucenaet al., “On the Rollout of Network Slicing in Carrier Networks: A Technology Radar,”Sensors, vol. 21, no. 23, 2021

    work page 2021

  30. [30]

    5G-Crosshaul: An SDN/NFV control and data plane architecture for the 5G integrated Fronthaul/Backhaul,

    S. Gonzálezet al., “5G-Crosshaul: An SDN/NFV control and data plane architecture for the 5G integrated Fronthaul/Backhaul,”Transactions on Emerging Telecommunications Technologies, vol. 27, no. 9, pp. 1196– 1205, 2016

    work page 2016

  31. [31]

    5G-Crosshaul Network Slicing: Enabling Multi-Tenancy in Mobile Transport Networks,

    X. Liet al., “5G-Crosshaul Network Slicing: Enabling Multi-Tenancy in Mobile Transport Networks,”IEEE Communications Magazine, vol. 55, no. 8, pp. 128–137, 2017

    work page 2017

  32. [32]

    Packet forwarding for heterogeneous technologies for integrated fronthaul/backhaul,

    T. Deißet al., “Packet forwarding for heterogeneous technologies for integrated fronthaul/backhaul,” inEuropean Conference on Networks and Communications (EuCNC), 2016, pp. 133–137

    work page 2016

  33. [33]

    SlicedRAN: Service-Aware Network Slicing Framework for 5G Radio Access Networks,

    B. Ojaghiet al., “SlicedRAN: Service-Aware Network Slicing Framework for 5G Radio Access Networks,”IEEE Systems Journal, vol. 16, no. 2, pp. 2556–2567, 2022. 38

    work page 2022

  34. [34]

    Sliced-RAN: Joint Slicing and Functional Split in Future 5G Ra- dio Access Networks,

    ——, “Sliced-RAN: Joint Slicing and Functional Split in Future 5G Ra- dio Access Networks,” inIEEE International Conference on Communi- cations (ICC), 2019, pp. 1–6

    work page 2019

  35. [35]

    Supplement 71 to ITU-T G-series Recommendations: Optical line termination capabilities for supporting cooperative dynamic bandwidth assignment,

    ITU-T, “Supplement 71 to ITU-T G-series Recommendations: Optical line termination capabilities for supporting cooperative dynamic bandwidth assignment,” Geneva, Switzerland, TR Supplement G Suppl. 71, 2023. [Online]. Available: https://handle.itu.int/11.1002/ 1000/15854

    work page 2023

  36. [36]

    Dynamic bandwidth allocation scheme for network- slicing-based TDM-PON toward the beyond-5G era,

    H. Uzawaet al., “Dynamic bandwidth allocation scheme for network- slicing-based TDM-PON toward the beyond-5G era,”Journal of Optical Communications and Networking, vol. 12, no. 2, pp. A135–A143, 2020

    work page 2020

  37. [37]

    Optimal Slicing of Virtualized Pas- sive Optical Networks to Support Dense Deployment of Cloud-RAN and Multi-Access Edge Computing,

    S. Das, F. Slyne, and M. Ruffini, “Optimal Slicing of Virtualized Pas- sive Optical Networks to Support Dense Deployment of Cloud-RAN and Multi-Access Edge Computing,”IEEE Network, vol. 36, no. 2, pp. 131– 138, 2022

    work page 2022

  38. [38]

    Optimal virtual PON slicing to support ultra- low latency mesh traffic pattern in MEC-based Cloud-RAN,

    S. Das and M. Ruffini, “Optimal virtual PON slicing to support ultra- low latency mesh traffic pattern in MEC-based Cloud-RAN,” inInter- national Conference on Optical Network Design and Modeling (ONDM), 2021, pp. 1–5

    work page 2021

  39. [39]

    PONVirtualisationwithEAST-WESTCommunicationsforLow- Latency Converged Multi-Access Edge Computing (MEC),

    ——, “PONVirtualisationwithEAST-WESTCommunicationsforLow- Latency Converged Multi-Access Edge Computing (MEC),” inOptical Fiber Communications Conference and Exhibition (OFC), 2020, pp. 1–3

    work page 2020

  40. [40]

    Virtualized EAST–WEST PON architecture supporting low-latency communication for mobile functional split based on multi- access edge computing,

    S. Daset al., “Virtualized EAST–WEST PON architecture supporting low-latency communication for mobile functional split based on multi- access edge computing,”Journal of Optical Communications and Net- working, vol. 12, no. 10, pp. D109–D119, 2020

    work page 2020

  41. [41]

    Optical Front/Mid-haul with Open Access-Edge Server Deployment Framework for Sliced O-RAN,

    S. Mondal and M. Ruffini, “Optical Front/Mid-haul with Open Access-Edge Server Deployment Framework for Sliced O-RAN,” CoRR, vol. abs/2110.09365, 2021. [Online]. Available: https: //arxiv.org/abs/2110.09365

    work page arXiv 2021

  42. [42]

    FSA: Fronthaul Slicing Architecture for 5G Using Dataplane Programmable Switches,

    N. Budhdevet al., “FSA: Fronthaul Slicing Architecture for 5G Using Dataplane Programmable Switches,” inProceedings of the 27th Annual 39 International Conference on Mobile Computing and Networking, 2021, p. 723–735

    work page 2021

  43. [43]

    O-RAN Control, User and Synchronization Plane Specification,

    “O-RAN Control, User and Synchronization Plane Specification,” O- RAN Alliance WG4, Tech. Rep. O-RAN.WG4.TS.CUS.0-R005-v20.00, 2026, open Fronthaul interface specification. Accessed: 2026-04-23. [Online]. Available: https://specifications.o-ran.org/download?id=738

    work page 2026

  44. [44]

    O-RAN Slicing Architecture,

    O-RAN Alliance WG1, “O-RAN Slicing Architecture,” O-RAN Alliance, Technical Specification O-RAN.WG1.TS.Slicing-Architecture- R004-v14.01, 2025, version 14.01. [Online]. Available: https: //specifications.o-ran.org

    work page 2025

  45. [45]

    Optimal resource allocation with delay guarantees for net- work slicing in disaggregated ran,

    F. G. Rocha, G. M. Almeida, K. V. Cardoso, C. B. Both, and J. F. De Rezende, “Optimal resource allocation with delay guarantees for net- work slicing in disaggregated ran,”IEEE Transactions on Networking, 2026. 40

    work page 2026