PosterPDF Available

5G End-to-End Open-Source Network: Architecture and Use Cases

Authors:
  • Orange Labs Poland

Abstract and Figures

Following the convergence of the mobile communications and cloud computing industries, current 4G services evolve towards 5G cloud native ones. Mobile Network Operators (MNOs) leverage cloud-computing paradigms for reducing Operational Expenditures and injecting automation in their mobile network infrastructure. To achieve this vision, multiple components from the orchestration to the infrastructure level, including the applications and terminals, need to be integrated and tested. In this paper we present an integrated mobile networking system based on Open Source Software (OSS). We propose an ONAP-based automation framework to deploy Cloud Native Functions (CNFs) such as CloudRAN based on OpenAirInterface (OAI). Finally, we introduce the design and implementation of a prioritization mechanism inside OAI.
Content may be subject to copyright.
5G End-to-End Open-Source Network: Architecture
and Use Cases
Mohamad Yassin, Łukasz Rajewski∗†, Tomasz Osi´
nski∗†,
Grzegorz Panek, Louiza Yala, Ayoub Bousselmi, Sofiane Imadali
Orange France, Paris, France
Orange Polska, Warsaw University of Technology, Warsaw, Poland
first.second@orange.com
Abstract—Following the convergence of the mobile commu-
nications and cloud computing industries, current 4G services
evolve towards 5G cloud native ones. Mobile Network Opera-
tors (MNOs) leverage cloud-computing paradigms for reducing
Operational Expenditures and injecting automation in their
mobile network infrastructure. To achieve this vision, multiple
components from the orchestration to the infrastructure level,
including the applications and terminals, need to be integrated
and tested. In this paper we present an integrated mobile
networking system based on Open Source Software (OSS).
We propose an ONAP-based automation framework to deploy
Cloud Native Functions (CNFs) such as CloudRAN based on
OpenAirInterface (OAI). Finally, we introduce the design and
implementation of a prioritization mechanism inside OAI.
Index Terms—5G, NFV-MANO, ONAP, OAI
I. INTRODUCTION
The work presented in this paper is a part of the 5GPPP
5G EVE1European project. This project involves a validation
platform for extensive trials. The objective of the project is to
implement and test advanced 5G infrastructures in Europe. In
particular, 5G EVE is focused on developing and interconnect-
ing existing sites in France, Greece, Spain and Italy in order to
form a single 5G end-to-end (E2E) facility. Each site proposes
5G solution elements that will be deployed and implemented.
The European 5G facility will host a selection of use-cases to
be deployed by verticals (a.k.a. OTT)2. As a part of 5G EVE,
the french site facility is based on Open Source building blocks
and distributed on several facilities interconnected through a
Virtual Private Network (VPN) and viewed as a unique site
facility that itself should be interconnected with the other
European sites for E2E transmission. In this paper we mainly
focus on the orchestration part, which is supported by ONAP
and implemented in each part of the french site.
II. 5G END -TO-END OPEN-SOURCE NETWOR K
Figure 1 illustrates the overall sites interconnected in the
5G EVE experimentation cluster. The architecture includes a
mobile networking cloud that verticals can use to leverage
connectivity in a specific geographical location with a specific
SLA. Use cases may involve different OTTs: entertainment
and media companies, MVNOs, or public transportation.
1https://5g-ppp.eu/5g-eve/
2Note that in the rest of the paper we use the terms verticals and OTT
interchangeably
The orchestration layer is supported by ONAP which is
a carrier-grade and complete open-source NFV orchestration
platform. It is used for on-demand deployment of OAI Cloud
RAN on top of virtualized infrastructure. The bottom layer
represents a virtualized, OAI-based 4G OSS mobile network
composed of the enhanced NodeB (eNodeB) and the Evolved
Packet Core (EPC). The mobile network is run on a Com-
mercial Off-The-Shelf (COTS) servers and is responsible for
handling UEs or IoT devices connected to the system.
A. ONAP orchestration for OAI-based Cloud RAN
Figure 2 summarizes the architecture of our experimental
testbed to orchestrate an OAI-based Cloud RAN. It consists
of two NFV sites orchestrated by ONAP Casablanca version.
Both sites are configured in a hybrid approach: an Open-
Stack cloud with Kubernetes cluster instantiated on top of
it. OpenStack allows to install VNFs as Virtual Machines
(VMs), while Kubernetes provides containers as an execution
environment for VNFs. Unlike OpenStack which is already
NFV-compliant, Kubernetes still requires progress to meet
NFV requirements. Even though, it allows to take advantage of
container technology for minimization of latency and footprint.
ONAP Casablanca cannot orchestrate CNFs into Kubernetes
cluster. In order to orchestrate virtual services composed of
CNFs and VNFs we deploy Kubernetes and OpenStack as hy-
brid site with Kubernetes deployed on-demand on OpenStack.
Such approach is an intermediate step before ONAP reaches
a full support for container-based workloads in next releases.
In order to overcome the issue of double networking stack a
interne France Télécom - Orange
UEs
Streaming
Server
Car
Joystick
Onboard
Camera
RAN Core Applications
Orchestration
RRHs
eNodeB vEPC
Fig. 1. 5G End-2-End Open-Source system architecture
Fig. 2. ONAP framework with orchestration flow
hybrid networking solution is used, called Kuryr3.
In our case, core network elements of OAI (i.e. vEPC) are
instantiated as VMs on OpenStack, while OAI Cloud RAN
components run on top of Kubernetes-on-OpenStack deploy-
ment. For that, virtual service contains Kubernetes cluster
VNF (proxy-VNF) that is instantiated with Heat template
like vEPC VNF. Further and with life cycle management
(LCM) operations, post-instantiation configuration of proxy-
VNF, CNFs are deployed into Kubernetes cluster.
Figure 2 shows the simplified architecture of ONAP and the
orchestration flow steps. For the use case purpose only a subset
of ONAP’s components is used. The framework highlighted
in figure 2 is based on ONAP architecture defined in [1].
The orchestration flow begins at ONAP Portal which provides
graphical user interface. In step 0, the user registers OpenStack
regions, where VNFs will be instantiated, to ONAP. Their
configuration must be provided before any orchestration action
into the Active and Available Inventory (A&AI), the major
database of ONAP holding the state and relations of virtual
services. In step 1, the user creates virtual service and on-
boards VNFs (vEPC and Kubernetes proxy-VNF) with Service
and Design Creation (SDC) visual modeling tool. Afterwards,
in step 2 the SDC distributes service model to A&AI and
passes VNFD to Service Orchestrator (SO). When distribution
is completed, the user triggers the orchestration workflow
responsible for service’s deployment from the Virtual Infras-
tructure Deployment (VID) portal (step 3). Afterwards, an
orchestration request is sent to the SO (step 4). In step 5, the
SO interacts with the Software Define Network - Controller
(SDN-C) to exchange configuration parameters, which are
required for the VNF’s deployment. In step 6, the deployment
process starts and SO instantiates VNFs directly on OpenStack
3https://wiki.openstack.org/wiki/Kuryr
with its HEAT REST API. Steps 7 and 8represent LCM
operations being processed by Application Controller (APP-
C). They are triggered by SO to configure vEPC, but in our
case they are used mainly to deploy OAI CNFs over proxy-
VNF. APP-C interacts with Ansible configuration management
tool to upload appropriate Helm Charts and to deploy them
by Kubernetes for containers’ instantiation.
B. OAI Flow Prioritization Use Case
In a previous work [2] a cross-layer design for an IP centric
QoS model was presented. In this IP-centric model, all the
flows belonging to a given user are transported on his unique
multi-QoS bearer. QoS is further managed at packet level (flow
prioritization), according to the Differentiated Services Code
Point (DSCP) field for example. A set of priority queues per
UE should further be implemented in the eNodeB. In this
paper we extend the OAI OSS to implement the proposed
Inter-bearer arrangements, in which the radio scheduler takes
into account the traffic mix waiting for transmission of each
UE when radio resources are allocated. In this case, the
scheduling algorithm should know the state of each queue in
the eNodeB and weighting the allocation of radio resources
according to the prioritized traffic volume. The implementation
details are out of the scope of this paper and will be detailed
in a future work. UEs are equipped with Subscriber Identity
Module (SIM) cards allowing them to connect to our network
once correctly provisioned within the EPC. We are currently
using two type of UEs: COTS smartphones and connected car
(IoT type machine) equipped with a 4G dongle.
III. CONCLUSION
Our end-to-end open source mobile network is based on
multiple Open Source software: ONAP, OAI, Docker and
Kubernetes. At the time of writing, ONAP Casablanca does
not support Kubernetes natively. Therefore, we proposed a
hybrid approach that overcomes this limitation. The design
and implementation of a prioritization mechanism inside OAI
is also proposed. Native deployment and management of CNFs
will be the subject of our future work.
ACKNOWLEDGMENT
This work was partly funded by the European Commission
under the European Union’s Horizon 2020 programme - grant
agreement number 815074 (5G EVE project). The paper solely
reflects the views of the authors. The Commission is not
responsible for the contents of this paper or any use made
thereof.
REFERENCES
[1] ONAP Architecture Overview, https://www.onap.org/wp-
content/uploads/sites/20/2018/11/ONAP CaseSolution
Architecture 112918FNL.pdf. (visited on 02/18/2019).
[2] W. Diego, I. Hamchaoui, and X. Lagrange, “Cross-layer
design and performance evaluation for ip-centric qos
model in lte-epc networks,” in 2015 8th IFIP Wireless
and Mobile Networking Conference (WMNC), Oct. 2015,
pp. 88–95.
ResearchGate has not been able to resolve any citations for this publication.
Conference Paper
Full-text available
Mobile operators are today facing the daunting challenge of providing cheap and valuable services to ever more demanding customers. As a matter of fact, mobile standards have not yet really addressed this expectation of open, cheap and flexible web oriented internet access. As an alternative, we introduced an IP-centric QoS model mainly inspired by IP policies commonly found in fixed networks. In the present paper we further describe a possible cross-layer design for this model. Some implementation challenges have been highlighted, together with possible solutions implying only minor modifications in evolved Node B, and none in terminals. Performances of this proposal compared to various implementations of the 3GPP QoS model have been evaluated using the ns-3 simulator in realistic scenarios. Some good properties of our IP-centric proposal compared to the standardized QoS model have been brought into evidence.