HexRAN: A Programmable Multi-RAT Platform for

Network Slicing in the Open RAN Ecosystem

Ahan Kak Van-Quan Pham
Nokia Bell Labs Nokia Bell Labs
ahan.kak@nokia-bell-labs.com quan.pham_van@nokia-bell-labs.com

Huu-Trung Thieu Nakjung Choi

Nokia Bell Labs Nokia Bell Labs
huu_trung.thieu@nokia-bell-labs.com nakjung.choi@nokia-bell-labs.com
ABSTRACT 6HUYLFH0DQDJHPHQWDQG2UFKHVWUDWLRQ
2 1RQ5HDO7LPH5,&
)&$366XSSRUW
In recent years, the Open Radio Access Network (O-RAN)
!V $
architecture has emerged as a major driving force for pro- 1HDU5HDO7LPH5,&
grammability in cellular networks and is recognized as a key (&3 &RUH 'LVDJJUHJDWHG
enabler for network slicing within 5G and beyond. While 2&8&3 ( (83 J1RGH%
!PV 2&883 &RUH
O-RAN harbors the potential to revolutionize cellular ac- )&
)8
('8
cess networks, the absence of an open platform for use case 2'8
prototyping has served as an impediment to its widespread 5HDO7LPH 25$1)URQWKDXO
adoption. The situation is further compounded by the fact 258
that O-RAN’s flagship use case, network slicing, presents a ,QIUDVWUXFWXUH
2
rigid dichotomy. On the one hand, systems research in the
slicing domain is largely centered around LTE, while, on Figure 1: The O-RAN reference architecture.
the other hand, 3GPP slicing specifications exclusively cater
to 5G Standalone (SA). From a practical standpoint, most
commercial networks today use a mix of 4G, 5G NSA (Non- in the design, management, and operation of radio access
standalone), and 5G SA, necessitating the need for solutions (RAN) and core networks [5]. At the same time, cellular net-
across all radio access technologies (RATs). With a view to works are expected to serve a burgeoning set of application
addressing these challenges, this paper introduces HexRAN, scenarios ranging from the more well-known enhanced mo-
a first of its kind purpose-built multi-RAT O-RAN compliant bile broadband (eMBB) to the upcoming immersive extended
access network. Key highlights of HexRAN include support reality (XR), along with several automation-related use cases,
for LTE, 5G NSA, and 5G SA with full disaggregation, a novel each presenting a diverse set of service level agreement (SLA)
Programmable Protocol-level API repository, a multi-RAT requirements, necessitating the need for robust network pro-
RAN slicing framework, a modular and extensible E2 Agent, grammability, closed-loop automation and control, and the
and a new O-RAN service model in support of slicing. Fur- provisioning of multiple logical networks over the same in-
thermore, the paper also includes a comprehensive system frastructure in what is known as network slicing [15].
evaluation addressing the key themes of scalability and dis- Recognizing the increasing complexity of cellular net-
aggregation, the slicing framework’s impact, and system works, both academia [16, 20, 28] as well as the industry [14]
performance. The results thus obtained showcase that not have been engaged in efforts to redesign access networks
only is HexRAN the most feature-complete RAN platform to based on the O-RAN concept [7]. Building upon 3GPP’s NG-
date, it also offers a significant performance advantage over RAN architecture which provides the Central Unit- Control
the prior art. Plane (CU-CP), Central Unit-User Plane (CU-UP), and Dis-
tributed Unit (DU) base station components, as shown in
Fig.1, O-RAN further disaggregates the DU into an O-RAN
1 INTRODUCTION DU (O-DU) and an O-RAN RU (O-RU). Furthermore, through
The fifth generation of cellular networks has been largely the introduction of a Near-real Time RAN Intelligent Con-
characterized by the ever-increasing presence of general- troller (Near-RT RIC) with supporting control applications
purpose computing hardware and softwarization of network called xApps and a Non-real Time RAN Intelligent Controller
functions. As networks evolve from 5G to 5G-Advanced and (Non-RT RIC) with rApps, O-RAN also gives rise to the pos-
then 6G, these trends will continue to play a critical role sibility of introducing novel network control functionalities
 Ahan Kak, Van-Quan Pham, Huu-Trung Thieu, and Nakjung Choi

and assurance frameworks that are geared specifically to- relating to disaggregated multi-RAT operations, RAN proto-
wards programmable RANs. col programmability, interactions between the RAN and the
In the O-RAN architecture (see Appendix A for details), RIC, and network slicing as detailed next.
the Near-RT RIC interfaces with the RAN over the E2 in- Disaggregated Multi-RAT RAN Platform. HexRAN incor-
terface, with the network elements within the RAN being porates a fully disaggregated O-RAN-compliant RAN with
referred to as E2 nodes. Communication over the E2 inter- support for LTE, 5G NSA, and 5G SA. Key components in-
face is governed by the extensible E2 Application Protocol clude an eNB and a gNB, along with their respective dis-
(E2AP), which includes a set of procedures to configure the aggregated components. HexRAN also supports chaining
functioning of the target E2 node, in addition to aiding data multiple DUs and CU-UPs to a common CU-CP in the inter-
collection. The specific configuration and statistics collection est of enhanced scalability (Section 2.1).
features depend on the functionality exposed by the E2 node Streamlined Network Control through a Programmable
to the xApps through what is known as a RAN function, Protocol-level API Repository. Recognizing the rigid na-
which in turn is defined by an E2 Service Model (E2SM). The ture of the 3GPP protocol stack, HexRAN introduces a set of
key takeaway being that many of the purported advantages reusable programmable APIs that interact with this proto-
of softwarized programmable networks can now be applied col stack to assist with system configuration and statistics
to the RAN. collection operations. HexRAN also introduces a novel RAN
Challenges. However, in spite of these efforts, outside slicing framework as a flagship showcase implementation of
of a handful of greenfield deployments, O-RAN has yet to the Programmable Protocol-level API (Sections 2.2 and 2.3).
achieve significant mainstream status [17], on account of the Robust Extensibility through a Modular E2 Agent. The
following challenges. E2 Agent serves as the nerve center for communicating and
Absence of an O-RAN Platform for Use Case Proto- coordinating with the Near-RT RIC. Despite its critical role,
typing. While there have been efforts to develop O-RAN it is a proverbial black box with no reference specification.
compliant platforms in the recent past, these endeavors are HexRAN introduces a highly extensible E2 Agent charac-
largely limited to monolithic or LTE-only RAN architectures, terized by a modular high-performance architecture and
devoid of a focus on disaggregation, thus precluding the real- plugin-based approach to service integration (Section 2.4).
ization of key O-RAN use cases such as network slicing [12]. Multi-RAT RAN Slicing with the RSH RAN Function.
Rigid Nature of the Cellular Protocol Stack. The cellular To address drawbacks relating to the RAT-specific nature of
protocol stack presents a well-defined control plane in the RAN slicing, HexRAN introduces a novel RAN function– the
form of the Radio Resource Control (RRC) protocol, governed Radio Slicing Helper (RSH) along with an accompanying ser-
by the 3GPP. On the other hand, O-RAN espouses the use vice model, E2SM-RSH, for slice configuration and statistics.
of external controllers for driving RAN operations, thereby RSH has been designed to support RAN slicing across LTE,
presenting a rigid dichotomy between O-RAN’s goals and a 5G NSA, and 5G SA. (Section 2.5).
RAN protocol stack that is not built for external control. Comprehensive Performance Benchmarking using an
Perceived Complexity of the O-RAN Specification. O- Experimental Testbed. In the interest of demonstrating its
RAN introduces several new interfaces, each characterized efficacy and practical applicability, HexRAN is deployed on
by a unique set of specifications, messages, and actions, ul- a large-scale experimental testbed for an extensive system
timately leading to the perception that O-RAN adds unnec- evaluation. Key aspects of this evaluation include scalability
essary complexity to an already complex RAN. Therefore and disaggregation, the impact of the RAN slicing frame-
there is a need for solutions that simplify the integration of work, and performance comparisons of HexRAN’s E2 Agent
new features and enhancements to the O-RAN framework. with the state-of-the-art (Section 3).
Access-specific Nature of Network Slicing. While net-
work slicing is an exclusive feature of the 5G SA specifica- 2 HEXRAN ARCHITECTURE DESIGN
tion, only 5% of the world’s cellular networks are 5G SA AND IMPLEMENTATION
capable [19], with 4G LTE and 5G NSA accounting for a
major chunk of network deployments and coverage, thus ne- Fig. 2 presents a complete overview of HexRAN, including
cessitating the need for a network slicing framework across the multi-RAT disaggregated RAN platform and the Near-
RT RIC. Herein we focus exclusively on the RAN, with the
LTE, 5G NSA, and 5G SA.
Near-RT RIC lying outside the scope of this paper.
Contributions. To that end, with a view to addressing the
aforementioned limitations, through this work, we introduce
HexRAN, a first of its kind purpose-built O-RAN compliant 2.1 Multi-RAT RAN Platform
RAN platform with several novel features and contributions Since O-RAN builds upon the 3GPP RAN specification, be-
fore attempting to design an O-RAN-compliant RAN, we
HexRAN: A Programmable Multi-RAT Platform for Network Slicing in the Open RAN Ecosystem

1HDUUHDO7LPH5$1,QWHOOLJHQW&RQWUROOHU 1HDU575,& &RUH1HWZRUN

2WKHU1)V 2WKHU H1%J1%&8&8&3&883'8
56+ 56+
( [$SS0DQDJHU 0HVVDJLQJ 1)V
6WDWLVWLFV &RQILJXUDWLRQ ($JHQW
7HUPLQDWLRQ (0DQDJHU6XE ,QIUDVWUXFWXUH
0DQDJHUHWF 
[$SS [$SS $0) 60) 83) 5$1 5$1
)XQFWLRQ1 )XQFWLRQn
(,QWHUIDFH %DFNKDXO,QWHUIDFH 1*6
3URWRFRO 3URWRFRO 3URWRFRO
&8&3 &883 &8&3 &883 OHYHO$3,1 OHYHO$3, OHYHO$3,n
($JHQW ($JHQW ($JHQW ($JHQW 6WDWLVWLFVDQG
5$1)XQFWLRQV 5$1)XQFWLRQV 5$1)XQFWLRQV 5$1)XQFWLRQV &RQILJXUDWLRQ
( ( *33/7(16$6$3URWRFRO6WDFN
H1RGH% 3URWRFROOHYHO 3URWRFROOHYHO J1RGH% 3URWRFROOHYHO 3URWRFROOHYHO
($JHQW $3,V $3,V ($JHQW $3,V $3,V 3URWRFROOHYHO$3,,PSOHPHQWDWLRQ
5$1)XQFWLRQV 55& 5$1)XQFWLRQV 55& 6'$3
3URWRFROOHYHO
$3,V
3'&3& 3'&38 3URWRFROOHYHO 3'&3& 3'&38 E $3,LPSOHPHQWDWLRQZLWKLQ+H[5$1
)& )8 $3,V )& )8
55& 55& 6'$3 3URWRFROOHYHO$3,
'8 '8 '8 '8 7KUHDG
3'&3 3'&3 ($JHQW ($JHQW 3URWRFRO
($JHQW ($JHQW 0HVVDJH
5/& 5/& &RQILJXUDWLRQ 6\QFKURQL]DWLRQ
5$1)XQFWLRQV 5$1)XQFWLRQV 5$1)XQFWLRQV 5$1)XQFWLRQV 3URFHVVRU
0$& 0$& 8SGDWH0HVVDJH 5HTXLUHPHQW 1R
3URWRFROOHYHO 3URWRFROOHYHO 3URWRFROOHYHO 3URWRFROOHYHO
3+< 3+<
$3,V $3,V $3,V $3,V
5/& 5/& 5/& 5/& <HV
0$& 0$& 0$& 0$&
3+< 3+< 3+< 3+< <HV ,PSDFWWR
*333URWRFRO /RFNIUHH
(,QWHUIDFH 5HDO7LPH
6WDFN ([HFXWLRQ
2SHUDWLRQV 1R
)XOO\'LVDJJUHJDWHGH1% )XOO\'LVDJJUHJDWHGJ1% &RQILJXUDWLRQ
0RQROLWKLFH1% 0RQROLWKLFJ1%
ZLWK0XOWL&883DQG0XOWL'86XSSRUW ZLWK0XOWL&883DQG0XOWL'86XSSRUW 8SGDWH
5DGLR$FFHVV1HWZRUN

D +H[5$1V\VWHPDUFKLWHFWXUH F /RFNIUHH$3,H[HFXWLRQIUDPHZRUN

Figure 2: The HexRAN platform architecture.

first need a 3GPP-compliant RAN platform that serves as the Leveraging the aforementioned features, HexRAN intro-
foundation for HexRAN. To that end, we leverage OpenAir- duces the concept of logical traffic-centric cells for load bal-
Interface (OAI) [24] as the base RAN stack for HexRAN. ancing. Since HexRAN espouses a loose coupling between
Challenges. While OAI provides base station software for CU-UPs and DUs, a given cell is anchored by a DU, a CU-CP,
LTE, 5G NSA, and 5G SA, it only offers limited support for and a set of CU-UPs. This set of CU-UPs can also be shared
disaggregation. More specifically, OAI includes a monolithic with other cells in the network, with traffic across CU-UPs
CU but lacks full disaggregation in terms of the CU-CP and being distributed on a per-user, per-bearer, or per-slice basis.
CU-UP components. Furthermore, a CU can be associated An approach of this kind allows communications service
with a single DU only, limiting the system’s scalability. These providers (CSPs) the flexibility to optimize the flow of traffic
limitations preclude OAI from serving as a “drop-in” RAN in their network. For e.g., if a given cell includes only a CU-
solution for HexRAN, requiring the following enhancements. UP 1 initially, then, on account of an increase in traffic, an
The HexRAN Approach. First, as part of HexRAN, we external network controller (RIC or otherwise) can offload
split the monolithic CU into its respective control (CU-CP) some of that traffic to another CU-UP 2, with the cell now
and user (CU-UP) plane components as shown in Fig. 2a. including both CU-UPs 1 and 2 on-the-fly.
Then, in order to enable the CU-CP to communicate with
the CU-UP, we implement the E1 interface between the two
components using the E1 Application Protocol (E1AP) over 2.2 Programmable Protocol-level API
SCTP. In the interest of improved scalability and resiliency, a
single CU-CP within HexRAN can be associated with multi-
Repository
ple distributed CU-UPs. Furthermore, we redesign the GPRS Overview and Challenges. As mentioned in Section 1,
Tunneling Protocol (GTP) stack within OAI to provide for since the RAN is designed to operate as a self-contained
single socket, multi-interface (i.e., F1, NG/S1, and Xn/X2) entity, the 3GPP protocol stack is not amenable to external
operations while simultaneously incorporating dedicated control and performance monitoring. On the other hand, the
per-interface GTP processing. Consequently, in a feature RAN functions and xApps within O-RAN need to interact ex-
unique to HexRAN, not only are multiple DUs able to inter- tensively with the stack to extract statistics, execute policies,
face with a single CU-CP, but also each DU can be associated and enforce configuration parameters. Thus, this inherent
with multiple CU-UPs. Additionally, each DU can have a rigidity within the RAN serves as a major impediment to
unique cell configuration in terms of supported frequency O-RAN’s goal of programmable network control.
bands and carrier bandwidths, greatly enhancing deploy- API Design. To address this issue, HexRAN, introduces
ment flexibility. the concept of a Programmable Protocol-level API Reposi-
tory, as shown in Fig. 2b, which consists of a set of reusable
programmable APIs that can interact with the MAC (Medium
 Ahan Kak, Van-Quan Pham, Huu-Trung Thieu, and Nakjung Choi

5$16OLFH,QLWLDOL]DWLRQ

(OVH 6OLFHVSHFLILF6FKHGXOLQJIRU3ULRULWL]HG'HGLFDWHG6OLFHV
Idle
'HIDXOW$FWLYH6WDWH 6KDUHG )LUVW6OLFH
1XP8(V  6FKHGXOLQJ,WHUDWLRQ /LVWRI3ULRULWL]HGDQG 6FKHGXOH8VHUVLQ6OLFH
(OVH ,QGH[LQ/LVW $VVLJQ9LUWXDO5HVRXUFH
8(5HJLVWUDWLRQ 6WDUW 'HGLFDWHG6OLFHVZLWK %DVHGRQ6OLFHVSHFLILF
6WDWH7UDQVLWLRQ 'HIDXOW$FWLYH6WDWH 6KDUHG %ORFNVWR6OLFH
3HU77,,QLWLDOL]DWLRQ 5HVRXUFH$VVLJQPHQWV 6FKHGXOLQJ$OJRULWKP
5HTXHVW
8(
'HIDXOW 'HUHJLVWUDWLRQ ,QFUHPHQW6OLFH,QGH[E\
Dedicated Shared 6OLFH6WDWH
$FWLYH
1XP8(Vߤ 6WDWH 1XP8(V! 6KDUHG6OLFH6FKHGXOLQJ <HV
1XP8(V! 3ULRULWL]HG
/LVWRI6KDUHG6OLFHV 1R 0RYHG8QXVHG
3HQGLQJ3ULRULWL]HG
6WDWH7UDQVLWLRQ ZLWK2YHUDOO6KDUHG 5HVRXUFHVWR
6WDWH7UDQVLWLRQ 'HGLFDWHG6OLFHV
Prioritized 5HTXHVW 5HVRXUFH3RRO 6KDUHG3RRO
5HTXHVW
1XP8(V! 'HGLFDWHG
8('HUHJLVWUDWLRQ 6FKHGXOHDOO6KDUHG6OLFH
6FKHGXOLQJ
8VHUV%DVHGRQ6\VWHP
,WHUDWLRQ(QG
OHYHO6FKHGXOLQJ$OJRULWKP
1XP8(V!

D 5$1VOLFHVWDWHPDFKLQH E 'XDOVWDJHVOLFHFHQWULFVFKHGXOHU

Figure 3: The HexRAN slicing framework.

Access Control) through RRC layers of the 3GPP stack to con- operations. As shown in the figure, upon receiving a config-
figure RAN operations and collect system statistics. These uration update request from a RAN function or any other
Protocol-level APIs can be considered as an adaptation layer entity, if the system detects a need for thread synchroniza-
that bridges the 3GPP and O-RAN domains by providing a tion that could potentially impact operations, it executes
functional abstraction of the RAN protocol stack. The API the update in a lock-free manner. From an implementation
repository within HexRAN incorporates the following key perspective, lock-free operations within HexRAN are pro-
design principles. vided by Concurrency Kit [13] and liblfds [22]. Through
RAT Agnosticism. All Protocol-level APIs within HexRAN the Protocol-level API Repository, HexRAN effectively elimi-
are designed to be as RAT-agnostic as possible, with a uni- nates the need for RAN functions to directly interact with the
form API definition across LTE, 5G NSA, and 5G SA. protocol stack. This approach offers several advantages, in-
Programmability and Reusability. While the primary cluding: (i) simplified design and seamless integration of new
motivation behind the API repository is to simplify O-RAN- RAN functions, (ii) native support for multi-vendor RAN-RIC
related operations, HexRAN lays a strong emphasis on API solutions, and (iii) conflict-free operations.
programmability and reusability, with several RAN functions
using the same set of APIs for different purposes. In addition 2.3 Multi-RAT RAN Slicing Framework
to RAN functions, HexRAN’s Protocol-level APIs can also Overview. As noted in Section 1, addressing the access-
be used by other control entities such as self-organizing net- specific nature of slicing, HexRAN incorporates support
work (SON) systems, and even other RAN protocols. for multi-RAT RAN slicing through the RSH RAN function.
Conflict Mitigation. HexRAN does not allow external en- However, before desiging this RAN function, we first need a
tities to interact with the RAN protocol stack directly by Protocol-level API that enables slicing across the entire RAN
design. Any and all interactions with the protocol stack must stack. The multi-RAT RAN slicing framework addresses this
go through Protocol-level APIs, which include a built-in con- requirement while also serving as a flagship implementation
flict mitigation mechanism. In the current implementation of of our Protocol-level API concept.
HexRAN, each Protocol-level API uses a FIFO scheduler that RAN Slice Model and State Machine. Within this slic-
queues API calls for execution in order of their respective ing framework, a RAN slice is uniquely identified by its slice
arrivals. ID and RAT type. Furthermore, in the interest of resource
Minimal Overhead. Since the Protocol-level APIs interact efficiency, a slice within HexRAN is also characterized in
with the entire RAN stack, it is critical that API calls do not terms of its state. Inspired by the 3GPP Network Resource
disrupt real-time RAN operations such as scheduling. How- Model [1], a RAN slice can exist in one of four states de-
ever, the multi-threaded nature of HexRAN necessitates the scribed below.
need for thread synchronization to execute configuration Idle. RAN slices that neither contain active users nor have a
changes. To that end, as shown in Fig. 2c, the Protocol-level specific resource assignment are categorized as idle.
APIs within HexRAN incorporate a lock-free synchroniza- Shared. RAN slices that contain active users but have no spe-
tion mechanism to ensure minimal disruption to real-time cific resource assignment are classified as shared. All shared
slices in the network utilize a common shared resource pool.
Prioritized. Prioritized slices are those that have priority
HexRAN: A Programmable Multi-RAT Platform for Network Slicing in the Open RAN Ecosystem

access to their assigned resources with all unused resources slice. After all prioritized and dedicated slices have been
reverting to the shared pool for a given scheduling interval. scheduled, the scheduler moves to the shared scheduling
Dedicated. Dedicated slices have exclusive access to the re- stage wherein users from all shared slices are scheduled
sources assigned to them. For such slices, unused resources in line with the system-level scheduling algorithm which
remain with that slice and do not revert to the shared pool. utilizes the VRBs available in the shared pool. The shared
As shown in Fig. 3a, state transitions are governed by the pool consists of resources that have not been assigned to
RAN slice state machine. In addition to its current state, each prioritized/dedicated slices as well as resources that are not
RAN slice also has a default active state, and upon user reg- used by prioritized slices.
istration and session establishment, a previously idle slice Configuration and Statistics Routines. The multi-RAT
transitions to its default active state. A given slice with active slicing framework also includes a set of configuration and
users remains in its default active state, unless a state transi- statistics routines. On account of reusability, these routines
tion is triggered through either an explicit state transition can be invoked by different entities within the network.
request, or on account of the slice no longer containing ac- Within the HexRAN implementation, such entities include
tive users. If a shared or prioritized slice no longer contains the SMO/Non-RT RIC, the Near-RT RIC, and RAN protocols.
active users, it automatically transitions to the idle state, While RAN protocols can invoke the slicing routines directly,
with the default active state being set to shared. However, the Near-RT RIC must use appropriate RAN functions for the
dedicated slices with no active users continue to remain in same. For example, the Add/Remove Slice routine allows for
the dedicated state with a dedicated resource assignment. addition and removal of RAN slices , while the Update Slice
The four slice states along with the RAN slice state machine State and Update CU-UP Association routines provide for
ensure that the system is able to adapt to a variety of differ- updating slice-related parameters. Additionally, for a given
ent use cases, while also guaranteeing efficient utilization of slice, the Update CU-UP Selection routine can be used to
resources. We will further quantify the performance impact indicate the CU-UP that will be used by the next data bearer
of the state machine in Section 3. that is established within that slice, while the Add/Remove
Accompanying the slice ID, RAT type, and state, the other Users routine is used to update slice-user associations.
parameters include the assigned set of radio resources and a Finally, the Update User Priority routine provides for
slice-specific scheduling algorithm for slices operating in the setting an explicit RAN priority metric for the specified user.
prioritized or dedicated modes, a system-level scheduling An explicit RAN-level user priority is beneficial in situations
algorithm for shared slices, a list of associated CU-UPs, and where there is a need to differentiate users within the same
a list of associated users. HexRAN allows the use of cus- slice having the same QoS identifier (5QI), for e.g., in scenar-
tom slice-specific scheduling algorithms for prioritized and ios where a Communications Service Provider (CSP) provides
dedicated slices, while defaulting to a common system-level a Mobile Virtual Network Operator (MVNO) with a single
scheduling algorithm for shared slices. Both the slice-specific slice for all their users. In such cases, having a RAN priority
as well as system-level algorithms are configurable through metric can help the MVNO to prioritize one user over the
the slicing framework, leading us to the next key component– other, allowing for fine-grained QoS enforcement. The imple-
the slice-centric scheduler. mentation of the RAN priority metric is scheduler-dependent,
Slice-centric Scheduler. HexRAN introduces a new slice- for e.g., with HexRAN’s default weighted proportional fair
centric scheduler across LTE, 5G NSA, and 5G SA, as shown scheduler, the RAN priority metric is used in calculating
in Fig. 3b. During each scheduling iteration, i.e., transmission per-user scheduling weights. We will further explore the
time interval (TTI), the scheduler operates in two stages– the performance impact of the RAN priority metric in Section 3.
slice-specific scheduling stage for prioritized and dedicated In a similar vein, the statistics routines provide the Near-
slices, followed by a shared slice scheduling stage for shared RT RIC and SMO with both slice and user statistics. Typical
slices. The slice-specific scheduling stage involves two steps. slice statistics include the RAT, state, active scheduling policy,
First, for each dedicated or prioritized slice, the scheduler current resource configuration, associated CU-UPs, and list
assigns virtual resource blocks (VRBs) to the slice based on of users, along with the aggregate slice throughput and over-
its resource assignment parameter. Then, the users within all slice latency. Similarly, user statistics include the RAT,
that slice are scheduled based on the slice-specific scheduling priority, throughput, latency, transport block size, buffer
algorithm, i.e., proportional fair, weighted round robin, etc., occupancy, channel quality indicator, and modulation and
by utilizing the VRBs assigned during the first step. Once coding scheme in use. The statistics routine supports both av-
all users within that slice have been scheduled, any unused erage as well as instantaneous values of the aforementioned
resources are either moved to the shared pool (if the slice metrics, where applicable.
is prioritized) or left as is (if the slice is dedicated). The
scheduler then moves on to the next prioritized or dedicated
 Ahan Kak, Van-Quan Pham, Huu-Trung Thieu, and Nakjung Choi

1HDU575,&1 1HDU575,&2 1HDU575,&n

1HDU575,&V
(,QWHUIDFH
($JHQW 6&73 ($30VJ (QFRGHG &RQWURO
1HDU575,&
($3 3DFNHW ,QIUDVWUXFWXUH &RQWURO0HVVDJH 0DQDJHU
($30HVVDJLQJ,QIUDVWUXFWXUH
0HVVDJLQJ
&RQILJXUDWLRQ ,QWHUIDFH 6XEVFULSWLRQ ,QGLFDWLRQ &RQWURO 5HSRVLWRU\ ([WUDFW6&733D\ORDG 3DUVH&RQWURO0HVVDJH
0DQDJHUVDQG 0DQDJHU 0DQDJHU 0DQDJHU 0DQDJHU 0DQDJHU $FWLYH5,&V ([DPLQH($30HVVDJH7\SH 'HWHFW5$1)XQFWLRQ

(601
(60n

(60n

(60n
(601

(601
3OXJLQV

3OXJLQ
5$1)XQFWLRQV

3OXJLQ

3OXJLQ

3OXJLQ

3OXJLQ

3OXJLQ
6XEVFULSWLRQV (QFRGHG5$1 ,QLWLDO9DOLGDWLRQ
)XQFWLRQVSHFLILF3D\ORDG
5$1)XQFWLRQ 5$1)XQFWLRQ1 5$1)XQFWLRQ2 5$1)XQFWLRQ3 5$1)XQFWLRQn )XOO\'HFRGHG5,& 5$1)XQFWLRQ 3URWRFRO&RQILJXUDWLRQ 3URWRFROOHYHO
$3,V $3,V $3,V $3,V $3,V (603OXJLQ
&RQWURO0HVVDJH $3, 8SGDWH0HVVDJH $3,
3URWRFROOHYHO 3URWRFROOHYHO 3URWRFROOHYHO 3URWRFROOHYHO 3URWRFROOHYHO 3URWRFROOHYHO 3URWRFROOHYHO 'HFRGH)XQFWLRQ 7UDQVODWH&RQWURO0HVVDJHWR 3URWRFROOHYHO
$3,V $3,1 $3,2 $3,3 $3,4 $3,5 $3,n VSHFLILF3D\ORDG 3URWRFROOHYHO$3,0HVVDJH &RQILJXUDWLRQ&KDQJH
5$13URWRFRO
&HOOXODU3URWRFRO6WDFN 55&6'$33'&35/&0$&3+< $GGLWLRQDO9DOLGDWLRQ
6WDFN

D ($JHQWLPSOHPHQWDWLRQZLWKLQ+H[5$1 E 5,&FRQWUROPHVVDJHSURFHVVLQJZLWKLQ($JHQW

Figure 4: The HexRAN E2 Agent architecture and message flow.

2.4 E2 Agent Architecture and Design the E2 Agent are divided into a set of Managers including
Overview and Requirements. The E2 Agent is the nerve the Configuration Manager, Interface Manager, Subscription
center for Near-RT RIC-related operations within the RAN. Manager, Indication Manager, and Control Manager. The
Key responsibilities of the E2 Agent include setup and mainte- Configuration Manager is responsible for parsing E2-related
nance of the E2 interface, parsing Subscription and Control aspects of the RAN configuration, for e.g., information about
requests from the RIC, and delivering Indication messages the RAN functions supported by that E2 node as well as
back to the RIC. In the absence of a reference E2 Agent archi- reachability information concerning the Near-RT RICs. Since
tecture to build upon, we take a clean-slate approach to its HexRAN requires that RAN functions interact with the RAN
design by first identifying the following key requirements. protocol stack through Protocol-level APIs only, there exists
Fully Modular Design. Since O-RAN is a fast evolving field, a dependency between RAN functions and Protocol-level
the E2 Agent should incorporate a modular design with re- APIs. To that end, the Configuration Manager also performs
placeable sub-components. dependency verification and considers only those RAN func-
Native Extensibility. A large part of the E2 Agent’s oper- tions for which the required Protocol-level APIs are present
ations are centered around RAN functions within O-RAN. in the RAN. The Configuration Manager then updates the
Therefore, the E2 Agent must be extensible by design to al- E2 Agent Repository with the parsed RAN function data and
low for seamless integration of new RAN functions and their RIC-related information.
accompanying service models. The Interface Manager handles all global procedures in-
RAT-agnostic Operations. HexRAN lays a strong empha- cluding E2 Setup, E2 Reset, and RIC Service Update.
sis on multi-RAT support, and, therefore the same E2 Agent In particular, the Interface Manager uses data from the E2
stack should support LTE, 5G NSA, and 5G SA. Agent Repository to initiate the E2 Setup procedure with
High-performance Message Processing. In dealing with one or more Near-RT RICs. The repository maintains a sepa-
near-real time operations, both message processing latency rate context for each RIC, and based on the RIC’s response,
and reliability are paramount, therefore, the E2 Agent should the Interface Manager activates the requested RAN func-
minimize processing latency while maximizing reliability. tions for that RIC. As their names suggest, the Subscription,
Multi-Near-RT RIC Support. The E2 Agent should be able Indication, and Control (SIC) Managers are responsible for
to interface with multiple Near-RT RICs. Support for multiple their namesake functional procedures. Since functional pro-
RICs not only enhances operational resiliency but also en- cedures involve RAN functions, the SIC Managers should
ables advanced use cases such as RAN sharing, which allow be able to parse RAN function-specific message content and
for differentiated control of a common RAN infrastructure. invoke the corresponding RAN function APIs. To that end,
Design Principles and Operation. The E2 Agent archi- HexRAN introduces the concept of E2SM plugins as shown
tecture along with its implementation within HexRAN is in Fig. 4a. Each RAN function within HexRAN includes a set
shown in Fig. 4a. The E2 Agent is implemented at all E2 of E2SM plugins for the SIC Managers, which are used to
nodes, i.e., eNBs, gNBs, CU-CPs, CU-UPs, and DUs, and in- decode function-specific payloads. A plugin-based approach
cludes several sub-components in the interest of modularity. imparts substantial extensibility to the E2 Agent, while also
First, we have the E2AP Messaging Infrastructure which pro- simplifying RAN function design. With HexRAN, a RAN
vides the SCTP stack. Then, the different functionalities of
HexRAN: A Programmable Multi-RAT Platform for Network Slicing in the Open RAN Ecosystem

function designer need only provide the supporting plug- On-Premises Infrastructure Cloud
RAN Terminal Infrastructure
ins and RAN function APIs without having to deal with the COTS
RAN Terminal

complexity associated with messaging over the E2 interface. UEs

Upon receiving an SCTP message from the Near-RT RIC, SDR 1 NUC 1 SDR 2

the E2AP Messaging Infrastructure extracts the SCTP pay- NUC 2

COTS
UEs Edge Cloud Servers
load, i.e., the E2AP message, examines the message type, and
offloads it to one of the managers. The offload mechanism
Figure 5: Experimental testbed for the HexRAN plat-
is implemented through a set of function callbacks which
form.
invoke the appropriate manager for further processing. For
e.g., as shown in Fig. 4b, if the incoming request belongs to
the Control procedure, the messaging infrastructure will
offload it to the Control Manager. The Control Manager then defined in Section 2.3, and a user-slice context change re-
parses the E2AP payload and performs an initial validation port that is intended to keep the Near-RT RIC in sync with
step. Upon successful validation, the RAN function-specific slice-related changes that occur within the RAN. In order to
payload within the E2AP message is further offloaded to the obtain these reports, an xApp must configure an appropriate
appropriate E2SM plugin. The E2SM plugin decodes the RAN event trigger within the RAN, in response to which HexRAN
function-specific payload, i.e., the RIC Control Header and sends the corresponding report to the RIC. To that end, RSH
RIC Control Message, and may perform additional valida- provides three event triggers– periodic, on-demand, and user-
tion steps. Finally, this decoded payload is used to invoke the slice context change. While the periodic trigger can be con-
corresponding RAN function’s API which translates the de- figured to generate reports every 50, 100, 500, and 1000 ms,
coded message to an appropriate Protocol-level API message. the on-demand trigger generates onetime on-demand re-
The RAN function API then invokes the Protocol-level API ports only. On the other hand, the user-slice context change
which finally executes the requested control action. For e.g., a trigger monitors events that impact slice context within the
request to update a slice’s state would invoke the multi-RAT RAN. While the slice and user statistics reports support both
RAN slicing framework’s Update Slice State routine. periodic and on-demand triggers, the context change report
Each stage of the message processing pipeline is decoupled supports the user-slice context change trigger only.
from the one before it through a system of message queues. Configuration Features. The slice and user configura-
This design ensures that the message processing within the tion capabilities of HexRAN follow from the configuration
E2 Agent experiences minimal delays. Furthermore, the E2 routines of the RAN slicing framework outlined previously.
Agent is designed to host multiple instances of SIC Managers To that end, RSH is responsible for providing configuration
as well as their respective E2SM-specific plugins, allowing features relating to the addition, removal, and update of both
for load balancing. slices as well as users. Key slice configuration parameters
supported by RSH include state, scheduler, resources, CU-UP
selection, and user priorities.
2.5 RSH RAN Function and Service Model Implementation. The RSH RAN function is implemented
Overview and Requirements. Thus far we have presented through an E2SM specification written in the ASN.1 nota-
several features in support of RAN slicing. However, a RAN tion that includes the various statistics and configuration
function that exposes the network slicing features within parameters described above. The RSH implementation also
HexRAN to the Near-RT RIC (and xApps) is still missing. includes a RAN function API to facilitate report generation
Within the O-RAN specifications too, a RAN function target- and configuration execution. This RAN function API invokes
ing network slicing is notably absent. To that end, as part of a Protocol-level API, which in this case is our multi-RAT
HexRAN, we introduce the Radio Slicing Helper (RSH) RAN RAN slicing framework. More specifically, the RAN func-
function accompanied by the E2SM-RSH service model. In tion API generates reports by collecting statistics through
designing this RAN function, we note that our key objectives the statistics routines of the slicing framework, and effects
include slice monitoring, configuration, and management configuration changes through the configuration routines.
across LTE, 5G NSA, and 5G SA, along with support for Furthermore, RSH provides a set of plugins, written in C, for
HexRAN’s RAN slicing framework. the SIC Managers of the E2 Agent, to allow it to communicate
Statistics Features. RSH provides for three kinds of sta- with xApps that leverage RSH. While outside of the scope
tistics reports incorporating both slice and user-related sta- of this paper, in support of RSH, we also develop a set of
tistics. A slice statistics report based on the slice-related sta- xApps– the RSH Configuration xApp for slice configuration
tistics provided by the RAN slicing framework in Section 2.3, and the RSH Statistics xApp for slice performance monitor-
a user statistics report incorporating user-related statistics ing for the Near-RT RIC. Additionally, we also incorporate
 Ahan Kak, Van-Quan Pham, Huu-Trung Thieu, and Nakjung Choi

Cloud by a mix of cloud and on-premises (on-prem) infrastruc-

Near-RT
RIC ture as shown in Fig. 5. The cloud infrastructure consists of
On-Premises
a cluster of eight servers that host OpenStack virtual ma-
1 4
chines, while the on-prem infrastructure consists of two Intel
2 5 DU 1
On-Premises On-Premises Cloud Cloud NUCs. A USRP B210 is attached to each NUC and serves as
3 6 SDR 1 CU-UP CU-CP the software-defined radio (SDR) within our testbed. This
7 Cloud
DU 2 infrastructure is used to create two test environments– a
COTS On-Premises Core
On-Premises hardware radio environment and an emulated radio environ-
UEs SDR 2
ment. Furthermore, both the core network (Open5GS [21])
Figure 6: Hardware radio environment with full disag- and Near-RT RIC are deployed on the cloud infrastructure.
gregation. Hardware Radio Environment. As shown in Fig. 6, the
hardware radio environment is anchored by the two B210
SDRs in the testbed along with a set of seven Google Pixel 6
user devices (UEs). Depending upon on the mode of deploy-
ment, the two NUCs host that E2 node which is typically
associated with the radio. For e.g., for monolithic deploy-
ments, the NUCs host one gNB each, on the other hand, for
disaggregated deployments, each NUC hosts one DU each.
Furthermore, for disaggregated deployments, HexRAN’s CU
(or CU-CP and CU-UP) is deployed in the cloud. In particular,
Fig. 6 showcases a fully disaggregated deployment with two
(a) CPU utilization. (b) Memory utilization. on-prem DUs, and a cloud-based CU-CP and CU-UP.
Emulated Radio Environment. While the hardware
Figure 7: Compute utilization comparison for the state- radio environment is indispensable for conducting field-
of-the-art deployment options. realistic experiments, some of our system evaluation sce-
narios require several cells, rendering the hardware envi-
ronment impractical. In such cases, we turn to an emulated
environment. At the outset, this large-scale test environ-
ment is emulated and not simulated, i.e., the entire HexRAN
software stack is identical across both the hardware radio
and emulated radio environments, with the only difference
being that the emulated environment uses emulated radios
(EMRs) and UEs provided by the OAI project. Our emulated
environment consists of a fully disaggregated deployment
(a) CPU utilization. (b) Memory utilization.
in the cloud. The setup consists of a single CU-CP and two
CU-UPs along with set of 50 DUs having one EMR each. Each
Figure 8: Compute utilization comparison across the
DU represents a single cell having five emulated UEs, for
state-of-the-art and HexRAN.
a total of 250 UEs across 50 cells. While not shown in the
figure, similar emulated setups can also be instantiated for
monolithic gNBs/CUs.
a number of performance-related enhancements within the
RIC’s messaging infrastructure in the interest of scalability.
3.2 Scalability and Disaggregation
3 SYSTEM EVALUATION
As mentioned in Section 2.1, OAI provides monolithic eNBs
In this section, we present a comprehensive evaluation along and gNBs along with a CU that can be associated to a single
three major themes– scalability and disaggregation, the RAN DU only. These deployment options serve as the state-of-the-
slice state machine’s impact, and performance comparisons art. In addition to the state-of-the-art deployment options,
of HexRAN’s E2 Agent with the state-of-the-art. HexRAN incorporates support for CU-CPs that can be associ-
ated with multiple CU-UPs and DUs, while also introducing
3.1 Experimental Testbed Setup the concept of logical traffic-centric cells. To that end, the
In the interest of obtaining realistic and at scale results we im- evaluation herein aims to quantify the benefits brought forth
plement HexRAN on an experimental testbed characterized by the additional deployment flexibility within HexRAN.
HexRAN: A Programmable Multi-RAT Platform for Network Slicing in the Open RAN Ecosystem

Enhancing Resource Efficiency. We begin by bench-

marking the compute, i.e., CPU and memory, utilization asso-
ciated with the state-of-the-art deployment options against
an increasing number of cells. For the monolithic setup, we
instantiate one gNB for each cell, while, for the disaggregated
option, we set up one CU-DU per cell. Each cell operates on
a 40 MHz n78, i.e., 3.5 GHz, carrier with 106 resource blocks
(RBs). Once a given cell has been set up, we initiate a down-
link iPerf UDP session sending 30 Mbps of downlink traffic (a) Per-cell throughput. (b) Per-cell packet loss.
from the core to that cell. Within this context, we increase the
number of cells from 1 and 15 and measure the overall aggre- Figure 9: Performance impact of multiple CU-UPs in
gate CPU and memory usage across cells as shown in Fig. 7. HexRAN.
For e.g., for the 15-cell scenario, the utilization values rep-
resent the aggregate usage of 15 gNBs and 15 CU-DU pairs.
Considering the scale of this experiment, we leverage the CU-UP 2 to this cell in line with HexRAN’s concept of log-
emulated radio environment along with a significant degree ical traffic-centric cells. In either case, using our emulated
of automation through Ansible [27]. Interested readers may test environment, a downlink iPerf session is used to send
refer to Appendix B for more details about our experiment 100 Mbps of traffic from the core to each cell (20 Mbps per
automation workflow. UE). Within this context, we measure the per-cell throughput
From the figure we note that, while generally the compute and packet loss, as shown in Fig. 9. From Fig. 9, we note that
usage increases with an increase in the number of cells for both networks offer identical throughput performance up to
both deployment options, the rate of increase is significantly four cells. However, when the fifth cell is added to Network
higher for the single CU-DU pair case. This result follows 1, the CU in our test environment reaches saturation and is
from the fact that the presence of a midhaul between the CU able to process only 450 Mbps out of the 500 Mbps that it
and the DU causes an increase in the compute utilization receives, and consequently the per-cell throughput perfor-
due to the additional GTP-related traffic processing. With mance for Network 1 falls, accompanied by an increase in
a single CU-DU pair per cell, this additional usage quickly packet loss. On the other hand, in Network 2, once CU-UP
adds up as the network scales, leading to the assumption 1 reaches saturation, additional traffic from incoming cells
that disaggregation is not inherently scalable. However, as is moved to CU-UP 2, ensuring that the network is able to
shown in Fig. 8, by allowing multiple DUs to share a single maintain the target per-cell throughput of 100 Mbps with no
CU, HexRAN contributes to a significant reduction in the packet loss, showcasing HexRAN’s performance advantage.
compute utilization associated with disaggregated deploy-
ments. The advantage is especially apparent in large-scale 3.3 RAN Slice State Machine Impact
cases such as the 15-cell scenario wherein HexRAN’s single Leveraging our hardware radio test environment, in this
CU with multiple DUs deployment helps bring the CPU uti- section, we quantify the performance impact of the RAN
lization down to 85% and the memory utilization down to slice state machine through a series of experiments aimed at
90%. Owing to differences in compute utilization associated analyzing the throughput, latency, and resource utilization
with downlink and uplink traffic, we conduct this experiment associated with slices in different states, as well as the relative
for the uplink traffic scenario too (Appendix C). performance of users having different RAN priorities.
Load Balancing through Logical Traffic-centric Cells. Fine-grained Network Control. We begin by deploying
Next, from Fig. 8, we note that the disaggregation of the a gNB with 106 RBs that can achieve a maximum downlink
monolithic CU into the CU-CP and CU-UP does not have a throughput of 130 Mbps. The gNB is configured with two
significant impact on the compute utilization. However, the RAN slices, 1 and 2, that are initially operating in the shared
ability to interface multiple CU-UPs with a single CU-CP state, and are thus allocated an equal share of the radio re-
presents HexRAN with a significant load balancing advan- sources, as shown in Fig. 10. Then, at 𝑡 = 20 s, in response
tage. To that end, we consider a scenario with two networks– to a change in the network policy, the Near-RT RIC’s RSH
Network 1 having a single monolithic CU, and Network 2 Configuration xApp sends a control request that changes the
with a single CU-CP and two CU-UPs. Then, a number of configuration for Slice 2 to dedicated with 85 RBs causing
cells are added to each network, wherein upon cell instantia- its throughput to rise to 103 Mbps, at the expense of shared
tion, the DU interfaces with the lone CU in case of Network Slice 1. However, since both slices have sufficient resources
1, whereas for Network 2, while the cell’s DU interfaces with to meet their respective target throughputs, congestion is
the lone CU-CP, the network can assign either CU-UP 1 or not present, as evidenced by the relatively low round-trip
 Ahan Kak, Van-Quan Pham, Huu-Trung Thieu, and Nakjung Choi

(c) Resource allocation and

(a) Per-slice throughput. (b) Per-slice round-trip time. utilization.

Figure 10: Performance impact of the RAN slice state machine.

Slice 3
Slice 1 Slice 2
(c) Slice-level resource
(a) Per-slice throughput. (b) Per-slice round-trip time. allocation.

Figure 11: Comparing dedicated and prioritized states under dynamic network conditions.

time (RTT) values. Next, at 𝑡 = 40 s, all active users leave As shown in Fig. 11, from 𝑡 = 0 − 19 s, Slices 1 and 2 are
Slice 2 causing its traffic to drop to zero, at the same time, a each assigned 40% of the available resources, with the shared
second change in the network policy mandates a 130 Mbps pool containing the remaining 20% for Slice 3. With the
downlink throughput for Slice 1. Since Slice 2 is in the dedi- throughput requirements for each slice being in line with
cated state, its unused resources do not revert to the shared their respective resource assignments, the network does not
pool. Following from Fig. 10, we note that overall gNB re- suffer from congestion. Then, at 𝑡 = 20 s, all active users
source utilization plummets to 20%, and Slice 1 is not able to leave Slices 1 and 2. Slice 1 remains in the dedicated state,
increase its throughput beyond 27 Mbps, leading to conges- while Slice 2 gives up its prioritized resource assignment and
tion and a sharp spike in its RTT. To restore performance, at switches to the idle state. Thus, Slice 3 now has access to
𝑡 = 60 s, a second control request from the RIC changes the 60% of the network’s resources, and its downlink throughput
state of Slice 2 to prioritized. Now, all unused resources from rises to 78 Mbps. Next, at 𝑡 = 40 s, Slice 1 gains active users,
Slice 2 go to the shared pool, and are thus available to Slice and at the same time, owing to a change in network policy,
1. Consequently, Slice 1 is able to achieve its target downlink the Near-RT RIC assigns 80% of the available resources to
throughput of 130 Mbps. In this manner, while the dedicated Slice 1. Predictably, from the figure, we note a rise in through-
and prioritized states can be used to enforce both resource put for Slice 1 and a fall for Slice 3. Then, at 𝑡 = 60 s, Slice
isolation as well as fine-grained performance requirements, 3 too gains active users and transitions from the idle state.
the flexibility to switch between different states ensures that Since Slice 3 was prioritized previously, it now moves to the
HexRAN is able to adapt to changing network conditions. shared state, albeit with a target throughput of 52 Mbps as
However, the wastage of unused resources associated with before. However, at this point, both Slices 2 and 3 are sharing
dedicated slices might lead one to question the utility of the the same shared pool having only 20% of the total resources.
dedicated state, as the next experiment will show, dedicated With a 10% resource assignment, Slice 2 is not able to meet its
slices do have a critical role to play in the network. target throughput, resulting in a congestion-induced spike
Comparing Dedicated and Prioritized Slices. We de- in its RTTs. These results underscore the importance of the
ploy three slices on the gNB– Slice 1 in the dedicated state, dedicated state. The ability to switch to the dedicated mode
Slice 2 in the prioritized state, and Slice 3 in the shared state. is ideal for critical use cases such as public safety networks
HexRAN: A Programmable Multi-RAT Platform for Network Slicing in the Open RAN Ecosystem

FlexRIC Agent [23]1 and the SD-RAN RIC Agent [26]2 . We

UE 2
begin by comparing the following key features that are vital
to a high-performance yet easy-to-use E2 Agent.
Modularity and Extensibility. While both the HexRAN

UE 1
UE 1 RP: 1 UE 1 RP: 1 UE 1 RP: 1
and FlexRIC agents support seamless addition of new service
UE 2 RP: 1 UE 2 RP: 2 UE 2 RP: 5 models, the design of the SD-RAN RIC Agent is closely cou-
pled with the service models implemented within SD-RAN,
(a) Per-user throughput. (b) Slice 1 allocation.
thereby limiting its extensibility.
Deployment Flexibility. While HexRAN’s E2 Agent is com-
Figure 12: RAN priority-based user prioritization. patible with both monolithic as well as fully disaggregated
deployments, the FlexRIC agent supports monolithic nodes
only, while the SD-RAN RIC Agent supports disaggregated
CU-DU deployments only.
during emergencies, thereby guaranteeing a minimum level RAT-agnosticism. Both HexRAN and FlexRIC maintain a
of performance that is isolated from changing network con- universal agent architecture across LTE, 5G NSA, and 5G SA,
ditions. Once the emergency scenario is over, these slices however, the SD-RAN RIC Agent supports LTE only.
can be switched back to the prioritized mode in the interest Multi-RIC Support. The agents within both HexRAN and
of resource efficiency. This experiment also showcases the FlexRIC support interfacing the RAN with multiple Near-RT
performance isolation inherent within HexRAN, with Slices RICs, while SD-RAN supports a single RIC only.
1 and 3 being unaffected by the congestion in Slice 2. Decoupled Processing. While HexRAN’s E2 Agent sup-
Flexible User Prioritization. The slicing framework can ports fully decoupled processing, SD-RAN only decouples the
differentiate between users that otherwise have the exact execution stage from the message processing before it, while,
same QoS configuration by leveraging the RAN priority met- the FlexRIC Agent has a tightly coupled message pipeline.
ric. To that end, we consider a scenario with two slices– Slice Incoming messages at the E2 interface are only processed by
1 in the dedicated state and Slice 2 in the shared state. Slice FlexRIC’s agent after the action corresponding to the previ-
1 contains two UEs 1 and 2, while Slice 2 contains UE 3. All ous message has been executed.
three users are configured with the same 5QI, 9. At 𝑡 = 0, Load Balancing. As detailed in Section 2.4, the HexRAN
the RIC assigns 85 RBs to Slice 1, and this assignment re- E2 Agent incorporates load balancing in the interest of im-
mains fixed throughout the experiment. Our focus here is proved performance. This feature is notably absent from
on the two UEs in Slice 1, both of which are initially config- both FlexRIC as well as SD-RAN.
ured with RAN priority (RP) value 1, and thus share Slice RAN Slicing. In terms of slicing support, while both the
1’s resources equally, as shown in Fig. 12. At 𝑡 = 20 s, the FlexRIC and SD-RAN agents support LTE only, HexRAN’s
Near-RT RIC changes the RP for UE 2 to 2. Since the gNB is E2 Agent incorporates support for RAN slicing across LTE,
using a weighted proportional fair scheduler, an increase in 5G NSA, and 5G SA.
the RAN priority metric is interpreted as a decrease in user Next, we conduct a quantitative performance comparison
priority, consequently, UE 2 is allocated a lower share of the of HexRAN’s E2 Agent with the aforementioned solutions.
resources, and its throughput falls. A second change in UE For the following set of experiments, in the interest of a
2’s RP to 5 at 𝑡 = 40 s, leads to further deprioritization, and fair comparison, we implement our RSH RAN function on
a 80 − 20 resource split in favor of UE 1, which increases its both the FlexRIC and SD-RAN Agents. All three platforms,
throughput to 83 Mbps. Thus, HexRAN allows the Near-RT i.e., HexRAN, FlexRIC, and SD-RAN, are deployed in the
RIC fine-grained control over the users’ QoS performance, hardware radio test environment and interface with our
which is particularly useful in scenarios such as infrastruc- testbed’s Near-RT RIC [25].
ture sharing, wherein tenants may not have control over Message Processing Latency. We fist compare the mes-
classical QoS parameters such as the 5QI. sage processing delay across all three agents as the number
of RAN function instances increases from 10 to 100. For
each instance that is added, the Near-RT RIC sends a control
3.4 E2 Agent Feature and Performance request every 50 ms, and we measure the time elapsed be-
Comparison tween when a request message is received at the E2 interface
In this section, we perform a feature comparison of HexRAN’s and when the corresponding RAN function action execution
E2 Agent with the state-of-the-art, followed by an extensive
performance comparison. The state-of-the-art is character- 1 Commit SHA-1 ID 2547045286adfa59927a375b535ac2c243f52588
ized by two open source E2 Agent implementations– the 2 Commit SHA-1 ID 39f09cc369c3d726e02de720096c19ba5b72aee0
 Ahan Kak, Van-Quan Pham, Huu-Trung Thieu, and Nakjung Choi

same slice as they move between 4G and 5G. To that end,

slice mobility of this kind is necessary for ensuring a seam-
less user experience. Furthermore, an optimized mapping
of QoS parameters between 5G and 4G, for e.g., from 5G’s
5QI to 4G’s QCI is a key enabler for slice mobility. Thus, a
multi-RAT slice-aware mobility framework forms a prime
focus of our future work.
Conflict Mitigation in Multi-xApp Environments.
(a) Processing delay. (b) Processing reliability. While HexRAN’s Protocol-level APIs incorporate basic con-
flict mitigation support, as the number of xApps and RAN
Figure 13: E2 Agent performance comparison. functions increase, HexRAN’s FIFO approach to conflict mit-
igation will be rendered sub-optimal. To that end, going
forward, we will also be augmenting HexRAN with a robust
API is called. The delay metric thus obtained represents the real time conflict mitigation framework.
message processing delay showcased in Fig. 13a. From the
figure we note that while the message processing delay for
the FlexRIC Agent increases linearly, hitting 5500 𝜇s for 100
instances, the delay values for both HexRAN’s E2 Agent and
SD-RAN’s RIC Agent remain relatively constant at around 5 RELATED WORK
100 𝜇s. This result follows from the fact in the FlexRIC Agent, The domain of open source radio access networks is ex-
incoming messages have to wait for all prior messages to clusively centered around two projects– OpenAirInterface
finish execution. As the number of RAN function instances (OAI) [24] and srsRAN [18], with OAI being the more feature-
increases, each arriving message ends up to having to wait complete of the two. However, as noted in Section 2.1, OAI
for an increasingly longer duration, thereby impacting the has been designed for 3GPP-compliance with O-RAN falling
system’s scalability. On the other hand, both HexRAN and outside its scope. Furthermore, while the O-RAN Software
SD-RAN employ decoupled processing and are therefore not Community does provide a reference software stack [25], it
bound by execution delays. is extremely limited in functionality. Therefore, there exists a
Message Processing Reliability. Next, we compare mes- vacuum when it comes to O-RAN-compliant RAN platforms.
sage processing reliability across the three agents, wherein Therefore, the research community has rallied to address this
reliability represents the ratio of messages for which the gap with both academia as well as industry attempting to
corresponding control action is executed to the total number develop O-RAN compliant access networks. Early research
of control messages received by the RAN. To that end, we efforts in terms of platform design and implementation have
increase the message frequency from 10 to 100 messages primarily focused on the development of monolithic LTE-
per second, with the results thus obtained being showcased focused platforms through initiatives such as NexRAN [20]
in Fig. 13b. From the figure we see that both HexRAN and and NextG [16], with both solutions building upon srsRAN.
FlexRIC offer 100% reliability across all message frequencies, However, these works are primarily exploratory in nature,
while SD-RAN’s message processing reliability falls with an with much work remaining to be done in terms of key fea-
increase in the message frequency, reaching 9% for a mes- tures such as disaggregation, multi-RAT operations, and per-
sage frequency of 100. This follows from the fact that the formance considerations.
execution of slice control messages within SD-RAN is tied More recently, centered around OAI, the FlexRIC [28] and
to the MAC scheduler, with only one control message being SD-RAN [26] projects, have endeavored to bring support for
executed every frame, i.e., 10 ms. Furthermore, SD-RAN also the E2 interface to the RAN. FlexRIC’s primary focus is on
lacks a message queuing mechanism, with pending control the development of an O-RAN-compliant network controller,
messages being overwritten repeatedly. Ultimately, as the which is largely complementary to our work. However it
message frequency increases, the reliability plummets. also provides an E2 Agent for monolithic eNBs and gNBs,
while SD-RAN enhances OAI’s single CU-DU LTE solution
4 DISCUSSION AND FUTURE WORK with support for an E2 Agent. To that end, we have validated
Slice Mobility and QoS Continuity in Multi-RAT Envi- the performance of HexRAN’s E2 Agent against these solu-
ronments. HexRAN lays a strong emphasis on multi-RAT tions in Section 3. In addition to the E2 Agent, as detailed in
operations at both the platform as well as feature levels. Section 2, HexRAN contains several features not found in
However, as of yet, it does not include a multi-RAT mobility the prior art, thus making it one of the most feature complete
framework that allows users to remain associated with the access network solutions for the O-RAN ecosystem.
HexRAN: A Programmable Multi-RAT Platform for Network Slicing in the Open RAN Ecosystem

6 CONCLUSION [15] Alcardo Alex Barakabitze, Arslan Ahmad, Rashid Mijumbi, and An-
drew Hines. 2020. 5G network slicing using SDN and NFV: A survey
In this paper, we have presented HexRAN, a first of its kind of taxonomy, architectures and future challenges. Computer Networks
purposed-built O-RAN compliant RAN platform with several 167 (Feb. 2020), 106984. https://doi.org/10.1016/j.comnet.2019.106984
novel features and contributions relating to disaggregated [16] Leonardo Bonati, Salvatore D'Oro, Michele Polese, Stefano Basagni,
multi-RAT operations, RAN protocol programmability, inter- and Tommaso Melodia. 2021. Intelligence and Learning in O-RAN
actions between the RAN and the RIC, and network slicing. for Data-Driven NextG Cellular Networks. IEEE Communications
Magazine 59, 10 (Oct 2021), 21–27. https://doi.org/10.1109/mcom.101.
Furthermore, we have implemented HexRAN on an experi- 2001120
mental testbed and conducted a comprehensive performance [17] Dell’Oro Group. 2022. Open RAN Advanced Research Report. Technical
evaluation addressing the key themes of scalability and dis- Report.
aggregation, the slicing framework’s impact, and the per- [18] Ismael Gomez-Miguelez, Andres Garcia-Saavedra, Paul D. Sutton,
formance of HexRAN’s E2 Agent. The results thus obtained Pablo Serrano, Cristina Cano, and Doug J. Leith. 2016. srsLTE:
An Open-Source platform for LTE Evolution and Experimentation.
have showcased that not only is HexRAN the most feature- In Proceedings of the Tenth ACM International Workshop on Wire-
complete RAN platform to date, it also offers a significant less Network Testbeds, Experimental Evaluation, and Characterization.
performance advantage over the prior art. https://doi.org/10.1145/2980159.2980163
[19] Global Mobile Suppliers Association (GSA). 2022. 5G Standalone:
Global Status Update. Technical Report.
[20] David Johnson, Dustin Maas, and Jacobus Van Der Merwe. 2021.
REFERENCES NexRAN: Closed-loop RAN slicing in POWDER -A top-to-bottom
[1] 3rd Generation Partnership Project (3GPP). 2022. Management and open-source open-RAN use case. In Proceedings of the 15th ACM Work-
orchestration; 5G Network Resource Model (NRM); Stage 2 and stage 3. shop on Wireless Network Testbeds, Experimental evaluation & CHarac-
Technical Specification (TS) 28.541. Release 17.6.0. terization. ACM. https://doi.org/10.1145/3477086.3480842
[2] 3rd Generation Partnership Project (3GPP). 2022. NG-RAN; E1 Appli- [21] Sukchan Lee. 2022. Open5GS. GitHub Repository: https://github.com/
cation Protocol (E1AP). Technical Specification (TS) 38.463. Release open5gs/open5gs. Version 2.4.7.
17.0.0. [22] liblfds Project. 2022. liblfds. https://www.liblfds.org/.
[3] 3rd Generation Partnership Project (3GPP). 2022. NG-RAN; F1 Appli- [23] Mosaic5G Project. 2022. Flexible RAN Intelligent Controller (FlexRIC)
cation Protocol (F1AP). Technical Specification (TS) 38.473. Release and E2 Agent. https://gitlab.eurecom.fr/mosaic5g/flexric/-/tree/dev.
17.0.0. [24] Navid Nikaein, Mahesh K. Marina, Saravana Manickam, Alex Dawson,
[4] 3rd Generation Partnership Project (3GPP). 2022. NG-RAN; NR user Raymond Knopp, and Christian Bonnet. 2014. OpenAirInterface: A
plane protocol. Technical Specification (TS) 38.425. Release 17.0.0. Flexible Platform for 5G Research. ACM SIGCOMM Computer Com-
[5] Ian F. Akyildiz, Ahan Kak, and Shuai Nie. 2020. 6G and Beyond: The munication Review 44, 5 (Oct. 2014), 33–38. https://doi.org/10.1145/
Future of Wireless Communications Systems. IEEE Access 8 (2020), 2677046.2677053
133995–134030. https://doi.org/10.1109/access.2020.3010896 [25] O-RAN Software Community. 2021. O-RAN E Release Notes. https:
[6] O-RAN Alliance. 2020. O-RAN Near-Real-time RAN Intelligent Con- //docs.o-ran-sc.org/en/e-release/release-notes.html.
troller E2 Service Model (E2SM) NI. Technical Report ORAN-WG3.E2SM- [26] Open Networking Foundation. 2022. SD-RAN 1.4 Release Notes. https:
NI-v01.00. Version 1.00. //docs.sd-ran.org/master/release_notes/sdran_1.4.html.
[7] O-RAN Alliance. 2022. O-RAN Architecture-Description. Technical [27] Red Hat, Inc. 2022. Ansible In Depth. Technical Report.
Report O-RAN.WG1.O-RAN-Architecture-Description-v06.00. Version [28] Robert Schmidt, Mikel Irazabal, and Navid Nikaein. 2021. FlexRIC:
6.00. An SDK for Next-Generation SD-RANs. In Proceedings of the 17th
[8] O-RAN Alliance. 2022. O-RAN Control, User and Synchronization Plane International Conference on emerging Networking EXperiments and
Specification. Technical Report O-RAN.WG4.CUS.0-v09.00. Version Technologies. ACM. https://doi.org/10.1145/3485983.3494870
9.00.
[9] O-RAN Alliance. 2022. O-RAN Near-Real-time RAN Intelligent Con-
troller Architecture & E2 General Aspects and Principles. Technical
Report O-RAN.WG3.E2GAP-v02.02. Version 2.02.
[10] O-RAN Alliance. 2022. O-RAN Near-Real-time RAN Intelligent
Controller E2 Service Model (E2SM) KPM. Technical Report O-
RAN.WG3.E2SM-KPM-v02.02. Version 2.02.
[11] O-RAN Alliance. 2022. O-RAN Near-Real-time RAN Intelligent
Controller E2 Service Model (E2SM) RC. Technical Report O-
RAN.WG3.E2SM-RC-v01.02. Version 1.02.
[12] O-RAN Alliance. 2022. O-RAN Use Cases Detailed Specification. Tech-
nical Report O-RAN.WG1.Use-Cases-Detailed-Specification-v08.00.
Version 8.00.
[13] Samy Al Bahra. 2022. Concurrency Kit. http://concurrencykit.org/.
[14] Bharath Balasubramanian, E. Scott Daniels, Matti Hiltunen, Rittwik
Jana, Kaustubh Joshi, Rajarajan Sivaraj, Tuyen X. Tran, and Chengwei
Wang. 2021. RIC: A RAN Intelligent Controller Platform for AI-Enabled
Cellular Networks. IEEE Internet Computing 25, 2 (Mar 2021), 7–17.
https://doi.org/10.1109/mic.2021.3062487
 Ahan Kak, Van-Quan Pham, Huu-Trung Thieu, and Nakjung Choi

6HUYLFH0DQDJHPHQWDQG2UFKHVWUDWLRQ functions supported by that node, characterized by a many-

2 1RQ5HDO7LPH5,& to-many mapping between RAN functions and xApps. More-
)&$366XSSRUW
!V $ over, while the E2 interface and its associated procedures pro-
1HDU5HDO7LPH5,& vide a generic RAN-RIC interaction framework, the specific
(&3 &RUH 'LVDJJUHJDWHG event triggers, indication reports, control configuration and
2&8&3 ( (83 J1RGH% policy messages are defined in RAN function-specific E2SMs.
!PV 2&883 &RUH These function-specific E2SMs are specifications in their own
)&
('8 )8 right, describing the different RAN parameters that can be
2'8 controlled and RAN statistics that can be reported back to
5HDO7LPH 25$1)URQWKDXO the Near-RT RIC. The current O-RAN specification includes
258 three such service models– Key Performance Measurement
(E2SM-KPM) [10], Network Interface (E2SM-NI) [6], and
,QIUDVWUXFWXUH RAN Control (E2SM-RC) [11].
2
Logically structured atop the RAN elements, the Near-
Figure 14: The O-RAN reference architecture. RT RIC is an external network controller that operates on
a timescale of > 10 ms, enabling near-real time control of
the underlying RAN through the xApps. Key functions of
the Near-RT RIC include interpretation and enforcement of
A A PRIMER ON THE O-RAN policies from the Non-RT RIC, along with the collection of
ARCHITECTURE statistics to facilitate improved model training. On the other
As shown in Fig. 14, the reference architecture consists of hand, in addition to fault, configuration, accounting, per-
four broad categories of components– the physical infras- formance, security (FCAPS) support, the SMO also includes
tructure, on top of which are deployed the RAN elements, the Non-RT RIC that oversees the control and optimization
the Near-RT RIC, and the Service Management and Orches- of RAN elements on a non-real time, i.e., > 1 s, basis. Such
tration (SMO) Framework [7]. The RAN can be deployed control is enabled through applications called rApps that are
in either a monolithic or disaggregated configuration. The responsible for providing policy-based guidance and enrich-
latter includes an O-RAN CU-CP (O-CU-CP), which con- ment information for the Near-RT RIC. Furthermore, both
tains the RRC and the control plane portion of the Packet the Near-RT and Non-RT RICs can be used for the training
Data Convergence Protocol (PDPC-C), the O-RAN CU-UP and deployment of ML models, depending on the mode of
(O-CU-UP) with the Service Data Adaption Protocol (SDAP) operation.
and user plane portion of PDCP (PDCP-U), the O-RAN DU
(O-DU) with the Radio Link Control (RLC), MAC, and High-
PHY layers, and the O-RAN RU (O-RU) with the Low-PHY B AUTOMATING LARGE-SCALE
layer and RF processing functions. The O-CU-CP and O-CU- EXPERIMENTS THROUGH ANSIBLE
UP communicate over the E1 interface [2], while the O-DU The emulated radio environment consists of over a 100 nodes–
communicates with the O-CU-CP and O-CU-UP over the a node each for the core and CU-CP, two nodes for the two
F1-C [3] and F1-U [4] interfaces respectively. Furthermore, CU-UPs, and 50 nodes each for the 50 DUs. The uplink com-
the O-RAN Fronthaul (O-FH) between the O-DU and O-RU putes utilization experiment in particular leverages all 104
is based on the lower layer split option 7-2x [8]. nodes. Given the scale of this test environment, we lever-
The RAN elements, i.e., E2 nodes, interact with the Near- age Ansible [27] to automate the experiments. Within An-
RT RIC (and xApps) over the E2 interface using the E2AP pro- sible, the host file stores information pertaining to all the
tocol [9], which handles both global interface management as nodes in the testbed, categorized by their respective roles,
well as a set of functional procedures called Subscription, i.e., DUs, UEs, etc., for ease of management. In addition, we
Indication, and Control. On the one hand, we note that have several Ansbile task task files which are responsible
the Subscription procedure is used by the xApps to con- for instantiating the environment and executing the experi-
figure event reporting from the E2 nodes based on specific ments. Accordingly, we separate the management into two
triggers, and the Indication procedure is used by the E2 steps as follows.
nodes to send reports back to the xApps based on the config- Setup, Library Installation, HexRAN Compilation
ured triggers. On the other hand, xApps can use the Control and Distribution. In this step, we install all necessary li-
procedure to configure the functioning of the target E2 node. braries across all nodes, configure the kernel, optimize the
As mentioned in Section 1, the configuration and reporting CPU governor, compile the HexRAN binaries and shared
features exposed by a given E2 node depend upon the RAN libraries, and distribute them to all nodes in the testbed. As
HexRAN: A Programmable Multi-RAT Platform for Network Slicing in the Open RAN Ecosystem

HexRAN helps in increasing the scalability of disaggregated

deployments by bringing down the compute and memory uti-
lization to 97.5% and 88.2% respectively, as shown in Fig. 16.
In this case, the reduction in CPU utilization is marginal
because at the cell-level, the network is processing 6 Mbps
of aggregate traffic only, thereby reducing the GTP-induced
overhead. Instead, PHY layer processing at the DU dominates
the compute utilization, and that value is the same across all
(a) CPU utilization. (b) Memory utilization. three disaggregated deployments.
Furthermore, in comparing the downlink and uplink sce-
Figure 15: Uplink compute utilization comparison for narios in Figs. 7, 8, 15, and 16, we note a few other differences.
the state-of-the-art deployment options. First, while we perform the downlink experiment for 15 cells,
the uplink experiment scales for 50 cells. This follows from
the fact that in cases where a single CU is shared across multi-
ple cells, there is a ceiling to the amount of traffic that the CU
can process before exhausting, in absolute terms, the com-
pute resources available to it. In our testbed, we note that this
ceiling occurs at 450 Mbps of downlink traffic and 300 Mbps
of uplink traffic. Therefore, to merit a fair comparison, we
impose a limit of 15 and 50 cells in the downlink and uplink
respectively. This discrepancy can be explained by the fact
(a) CPU utilization. (b) Memory utilization. that key functions of the uplink traffic processing chain such
as LPDC (low-density parity-check error correction) decod-
Figure 16: Uplink compute utilization comparison ing and DFT (discrete Fourier transform) are more compute
across the state-of-the-art and HexRAN. intensive than their downlink counter parts, thereby result-
ing in a greater compute utilization for the uplink traffic
scenario, and, consequently, a lower traffic ceiling.
and when new nodes are added to the testbed, we include
the corresponding information in the Ansible “host” file and
re-run the setup script.
Experiment Execution. As part of this step, we perform
recurrent runs of each experiment in the interest of repeata-
bility, and collect the data after each run. Our Ansible task
files are based on a template that has been designed with
reusability in mind and supports several actions such as re-
deploying the core as well re-deploying HexRAN and all UEs
with the desired configuration. The experiments detailed in
Section 3 make extensive use of these task files to deploy
the core, HexRAN, and UEs, as well as automate the data
collection process.

C COMPUTE UTILIZATION FOR UPLINK

TRAFFIC
In Section 3.2, we have noted that the uplink and downlink
traffic differs in terms of its compute resource utilization.
Therefore, in this section we focus on the uplink traffic sce-
nario. For this scenario, we initiate an uplink iPerf UDP
session sending 1.2 Mbps of traffic from each UE to the core,
while increasing the number of cells from 1 to 50. Once again,
comparing the two state-of-the-art deployment scenarios,
the single CU-DU pair per cell consumes more resources
than the monolithic gNB, as shown in Fig. 15. Here too,