Security

considerations
of Open RAN
Ensuring network radio systems
are open, interoperable, and secure
by design

August 2020
2 Security considerations of Open RAN

Contents

03 RAN evolution

04 RAN virtualization

05 O-RAN security risks

09 Areas of concern not exclusive to open networks

10 Security best practices

11 Conclusions

12 Author biographies

13 Acronyms
3 Security considerations of Open RAN

RAN evolution

5G technology will benefit society and industries with enhanced Architectural changes in 5G have created the opportunity for network
Mobile Broadband (eMBB), Ultra-Reliable Low Latency virtualization to maximize flexibility and reduce costs to meet use-
Communications (URLLC), and massive Machine Type case-specific requirements. Virtualization means that security needs
Communications (mMTC). In addition to higher bandwidth and lower to be handled in a new way. As the industry evolves towards RAN
latency, 5G has the promise to be the secure digitalization platform for virtualization, with virtual RAN (vRAN) or Open-RAN (O-RAN), it is
industry and society by providing secure connectivity for everything important that a risk-based approach is taken to adequately address
and everyone. 3GPP has standardized many security improvements security risk. vRAN leverages the 5G split-RAN architecture, interfaces,
with 5G, including: and security protection mechanisms standardized by 3GPP. Building
• improved signaling plane and user plane protection upon the foundation set forth by 3GPP, O-RAN is standardized by the
• International Mobile Subscriber Identity (IMSI) encryption with O-RAN Alliance with new functions and open, interoperable interfaces.
Subscription Permanent Identifier (SUPI) / Subscription Concealed The O-RAN Alliance has recently formed a security task group, in
Identifier (SUCI) which Ericsson will participate, within O-RAN WG1 (Use Cases and
• device and network mutual authentication with the home network Overall Architecture) to address new security risks. With any nascent
• use of TLS between 5G Core functions, with option to use DTLS to technology, including O-RAN, security cannot be an afterthought and
protect signaling between RAN and Core should be built upon a security-by-design approach. Ericsson,
• Security Edge Protection Proxy (SEPP) for secure roaming leveraging its experience, will continue its leadership role with the
• network slicing for traffic segmentation O-RAN Alliance to define security best practices. The purpose of this
paper is to provide guidance on security best practices to ensure that
(Additional information about 5G security can be found at: https:// O-RAN is ready to meet the level of security expected by service
www.ericsson.com/en/security/a-guide-to-5g-network-security) providers and their customers.
4 Security considerations of Open RAN

RAN virtualization

The discussion of RAN virtualization has three commonly used terms: Open RAN, vRAN and O-RAN. Each of these three terms is
explained below:

Open RAN is the industry’s generic term for vRAN refers to the virtualization of RAN O-RAN refers to the Open RAN standardized
an open radio access network architecture. functions, particularly the higher layer and by the O-RAN Alliance. The O-RAN
An Open RAN has open interoperable lower layer function of the baseband unit. Alliance has four main objectives: Open
interfaces, RAN virtualization, and support for 3GPP Release 15 CU-DU split architecture Interfaces, Virtualization, Intelligence, and
big data and AI-enabled RAN. Open RAN is a facilitated this journey to begin by separating Interoperability. O-RAN enables service
vehicle for innovation in an open ecosystem the centralized and distributed functions of providers to deploy radio units (RU) and
while providing seamless coexistence with RAN. With vRAN, 5G becomes software- distributed units (DU) from different vendors
traditional RAN in a zero-touch management defined and programmable, generating with a new Lower Layer Split (LLS) split,
framework. Providers deploying an Open additional RAN architecture flexibility, called Option 7-2x, transported over eCPRI
RAN can choose between a between a platform harmonization and operational protocol.
3GPP or O-RAN architecture. The functional simplification. vRAN enables baseband units,
components of this chosen architecture typically in centralized hub location, to be
can be realized over a tightly integrated virtualized and connected to remote radio
hardware/software platform or COTS-based units using standard CPRI (Common Public
disaggregated platform. Figure 1 below Radio Interface) or enhanced CPRI (eCPRI)
shows the comparison of the 3GPP and protocols.
O-RAN architectures.

3GPP O-RAN

3GPP-based Architecture O-RAN Architecture to O-Cloud

(Rel 15 CU-DU Split) Lower Layer Spilt (LLS) 7-2x

O2

Service Management and Orchestration (e.g., ONAP) M-Plane

Management and (Optional for SMO)
Orchestration (e.g., ENM) Non-RT RIC
O1

A1

CU E2 Near-RT RIC

E2
E1
CU-CP CU-UP
E1
O-CU-CP O-CU-UP

F1-C F1-U F1-C F1-U

O-DU

DU Open Fronthaul

O-RU

O-RAN introduces additional interfaces, functional splits and disaggregation.

Figure 1: Open RAN Architectures: 3GPP versus O-RAN

5 Security considerations of Open RAN

O-RAN security risks

The O-RAN architectural diagram is shown • Address threat to trust chain introduced by Please note that the security threats
in Figure 2 below. Security measures should decoupling of functions. associated with ‘public exposure to Open
be taken to address security risks specific to • Ensure management interfaces are secured Source code’ and ‘defense from physical
O-RAN deployments. These security measures according to industry best practices. attacks’ are not exclusive to open network
include the following recommendations: • Practice a higher level of due diligence for deployments such as O-RAN. Each of these
• Protect expanded threat surface. exposure to public exploits from use of security risks specified above are addressed in
• Close security vulnerabilities associated Open Source code. the subsections below.
with Near-RT RIC . • Implement defenses from physical attacks.

Service Management and Orchestration Framework

Non-Real-Time RIC O1

O2 O1 A1

Near-Real-Time RAN
Intelligent Controller (RIC)

E2 X2-c
E2 X2-u
O-CU-CP E1
O-eNB E2 O-CU-UP NG-u
Xn-u
E2
Open Fronthaul Xn-c
M-Plane NG-c
F1-c F1-u

O-DU
Open Fronthaul CUS-Plane Open Fronthaul M-Plane

O-RU

O-Cloud

Figure 2: O-RAN Architecture (Source: O-RAN Alliance)

Expanded Threat Surface

The O-RAN architecture introduces new 3GPP O-RAN
functions and interfaces, as shown in
Figure 3 below. The introduction of additional Functions Additional Functions
interfaces and nodes, and the decoupling of • Management and Orchestration • SMO
hardware and software, expands the threat • CU-CP/CU-UP • Non-Real-Time RIC
and attack surface of the network. These • DU • Near-Real-Time RIC
new security risks are explained in the
following sections: Interfaces Additional Interfaces
• Lower Layer Split (LLS) 7-2x • E1 • A1
• Near-RT RIC • F1-C/F1-U • E2
• disaggregation of software and hardware • O1
using cloud • O2
• additional interfaces (O1, O2, and Open • Open Fronthaul
Fronthaul M-Plane)
Modified Architecture
• O-RAN LLS (7-2x)

Figure 3. O-RAN Expanded Threat Surface

6 Security considerations of Open RAN

O-RAN LLS 7-2x possibly be achieved via the Open Fronthaul Near-RT RIC
The ORAN Alliance promotes the support interface, depending upon the design of the The Near-RT-RIC also has potential security
for LLS, also referred to as Open Fronthaul, hardware-software system and how different vulnerabilities, such as the following:
with the goal to increase the flexibility functions are segregated in the node. An • Near-RT RIC signaling conflicts with
and competition on the telecom market. adversary could, in such case, either harm gNodeB
LLS refers to the split between the Radio the node, create a performance issue by • Near-RT RIC xApps signaling can conflict
Unit (RU) and the Distributed Unit (DU) as manipulation of parameters, or reconfigure • xApp Root of Trust
illustrated in Figure 4. The O-RAN fronthaul the node and disable the over-the-air ciphers • UE identification in the RIC
interface can be transported on eCPRI. The with the purpose of eavesdropping or other
CPRI corporation (see http://www.cpri.info/) type of breaches. Each of the potential vulnerabilities is
has worked together with industry to evolve The management and control traffic explained further in the subsections below.
the existing CPRI specification to create across the Open Fronthaul interface are not Further study is required to identify the best
eCPRI. The eCPRI specification is designed protected in the current standards for this split solutions to close these security risks.
to support 5G fronthaul requirements architecture. This opens the risk of Man-in-
and offers several advantages to existing the-Middle (MITM) attacks over this interface. Near-RT RIC conflicts with gNodeB
radio base station designs. One difference An adversary could possibly manipulate The Near-RT RIC is a logical entity that
comparing traditional CPRI with the eCPRI the management and control traffic that enables near-real-time control and
interface is that eCPRI enables the efficient runs between the O-DU and O-RU. The user optimization of a subset of the Radio
use of packet-based transport technologies plane and control plane traffic to/from the Resource Management (RRM) functions
and allows RAN payloads to be carried over UE may still be protected by the air interface performed by the gNB (CU-CP, CU-UP and/
Ethernet technology. The higher layers of the protection. Finally, the O-RU can be subject or DU). The Near-RT RIC is composed of a
O-RU interface are implemented on top of for an attack with the purpose of reaching software platform with applications, referred
eCPRI, with several different LLS options to the network beyond the O-DU or with the to as xApp, running on top. Each xApp can
split the functionality between the O-RU and purpose of gaining access to the O-DU. enable the Near-RT RIC to control one or
the O-DU. This depends on the vendor’s implemented multiple RRM functions. This is achieved
The traditional CPRI interface covers security controls such as access control, HW by exchanging data between the xApps
Layers 1 and 2 of the OSI stack, including and SW design. and the gNB over the E2 interface with
all the necessary items for transport, The following recommendations mitigate control loops having timing in the order of
connectivity and control. The higher layers LLS security risks: 10ms to 1s. The RRM functions that can be
of the interface between the RU and the DU • Mutual authentication between O-RU and controlled by the Near-RT RIC depend on the
are implemented by each RAN vendor as a O-DU to assure that no unauthorized xApps and the capability of the RAN nodes
vendor-specific protocol on top of the open equipment can be connected to the O-DU exposed over the E2 interface. For example,
standard Common Public Radio Interface via the Open Fronthaul interface the Near-RT RIC can control mobility and
(CPRI). • Mutual authentication of management load balancing by exchanging information
The security challenges with an LLS RU to management system between a specific xApp and the CU-CP over
solution is that many of the benefits with • Integrity protection and encryption of E2. Another example is that the Near-RT RIC
traditional type of deployments will become a management plane and control plane can control scheduling policies by exchanging
challenge unless the right security measures between RU/DU information between another xApp and
are in place. When having two different • Signed software and secure boot in the DU. It is important to note that the RAN
vendors, the O-RU and the O-DU needs to O-RU and O-DU must be able to operate and provide services
be managed as different entities. The O-DU • Network Access Controls for filtering u also without the Near-RT RIC or in case of
will still control the other vendor’s O-RU, nauthorized/unexpected traffic in the DU Near-RT RIC failure.
but not fully. Instead, the O-DU will have to over the fronthaul interface The challenge with this definition of
bridge the management traffic between the • Segregation of O&M for O-DU with Open the Near-RT RIC is that there is no clear
management system and the O-RU. Hence Fronthaul interface functional split between the Near-RT RIC and
the possibilities to reach the northbound • User access control in O-RU (if local the gNB (CU-CP, CU-UP, DU). The functional
systems beyond the O-DU through the Open management ports exists) split depends on the available xApps and
Fronthaul interface become a possible attack • Open Fronthaul interface security logging the capabilities exposed by the gNB. This
vector in this split architecture. In addition, in O-RU and O-DU (for CP, UP, and creates possible conflicts between the
access to the O-DU configuration could Management) decisions taken by the Near-RT RIC and the
gNB vendors that could lead to instability in
the network, which introduces vulnerabilities
O-RUs Cell Site that could be exploited by threat actors. For
example, a threat actor can utilize a malicious
xApp that intentionally triggers RRM
decisions conflicting with the gNB internal
O-DU decisions to create denial of service.
Open Fronthaul
Transport

Vendor A Vendor B

Figure 4: O-RAN Open Fronthaul

7 Security considerations of Open RAN

xApps conflict scenarios Performance degradation and instabilities these risks, a solid trust chain, preferably
The xApps in the Near-RT RIC can be that result from these xApps conflicts from hardware up to the applications, (in this
provided by different vendors. For example, introduce vulnerabilities that could be case 3PP xApp) is necessary, which makes it
one vendor can provide the xApp for mobility exploited by threat actors. O-RAN is working possible to authenticate xApps before loading
management and another vendor provide on solutions to mitigate the impact of and starting them.
the xApp for load balancing. This creates these identified xApps conflicts. However,
the risk that different xApps will take as of today, no solution is defined in the UE Identification in the RIC
conflicting decisions, unless they are properly specifications. Indirect and implicit conflicts As the E2 interface (similar to A1 interface)
coordinated. For example, the xApps for are especially difficult to mitigate due to lack can point out a certain UE in the network,
mobility management and load balancing of observability. this will create a correlation between the
can trigger different handover decisions at randomized (anonymized) UE identities
the same instance in time for the same user xApp Root of Trust between the RAN nodes. For example, a 3PP
with the risk to trigger a radio link failure. In xApps in the Near-RT-RIC have the xApp can potentially be used as a “sniffer” for
ORAN WG3 specifications, O-RAN.WG3. capability to manipulate behavior of a UE identification. The additional challenge
RICARCH-v01.00, the following possible certain cell, a group of UEs, and a specific for the Near-RT RIC / E2 compared to the
conflicts between xApps are identified: UE. A malfunctioning xApp from a 3PP could Non-RT RIC / A1 is that more frequent
• Direct conflicts: different xApps request potentially cause issues on the network. signaling is expected over the E2 interface to
change for the same parameter. For example, the xApp could track a certain enable near-real-time operation. Therefore,
• Indirect conflicts: different xApps request subscriber or impact service for a subscriber the UE identifier will be exchanged more
change to different parameters that will or a dedicated area. In addition, an xApp frequently over the E2 than over the A1. To
create opposite effects, for example, can receive order via A1 to control a certain alleviate this, Ericsson is proposing solutions
antenna tilt and measurement offset. UE and if a malfunctioning xApp receives an that reuse randomized UE identifiers defined
• Implicit conflicts: different xApps request order to prioritize this UE, then the owner of in 3GPP over the E2 and A1 interfaces. These
change to different parameters that are the malfunctioning xApp knows a VIP that solutions are currently under discussion
not creating any obvious opposite effect they want to track is in a certain area. With within the O-RAN Alliance for inclusion in
but result in an overall network this command exposure, the attacker can future releases of the specifications.
performance degradation. These conflicts obtain a rough location of a very important
are most difficult to mitigate since person and change the order from prioritize
dependencies are impossible to observe. to deprioritize for a UE. In order to mitigate
8 Security considerations of Open RAN

Decoupling increases threat to Trust Chain To establish a secure and trusted functions. Together with standardized and
Virtualization and the use of cloud platforms communication channel between two interoperable APIs, there must also be a
give the possibility to utilize hardware endpoints, one needs first to authenticate transparency into how the different layers use
resources better between different each side before a secure (confidentiality- and provide the security functions in the chain.
application, but it will also introduce security and integrity-protected) channel can be Security assurance and supply chain best
risks as isolation between applications are established. To authenticate each endpoint, a practices will give a better transparency.
only “logical” in software without physical unique identifier and one or more credentials
isolation across hardware resources. Recently that shall be kept secret are needed. Management interfaces may not be secure
discovered vulnerabilities like Meltdown To protect the credentials in computer to industry best practices
and Spectre (https://meltdownattack. environment, hardware security functionality O-RAN’s O1, O2, A1, and E2 are the
com/) reveal that there are security risks such as Trusted Platform Module (TPM), new open interfaces that allow software
when sharing hardware resources. More Hardware Security Module (HSM), and secure programmability of RAN. These interfaces
vulnerabilities are likely already part of enclaves, is used to get a hardware root of may not be secured to industry best
firmware and software to be discovered in trust. Newer processors and chipsets also practices. For example, the use of SSH on
the future. provide secure enclaves so specific software the O1 interface does not meet industry best
A cloud-native or a virtualized environment and date can processed in an isolated part of practice. The O-RAN O1 interface allows
includes many different layers, each with its the processor. optional use of TLS (reference O-RAN-WG1.
own security functions. From an application In the case of virtualization and cloud O1-Interface-v02.00), but industry best
perspective the use of all these security environment, there are many layers that need practice recommends use of TLS. An
functions at the different layers involves trust to be considered to ensure the trust chain is implementation that does not implement
at all layers. The host operating system has maintained between applications and the TLS, since it is optional, may become the key
access to all RAM memory, disk volumes underlying hardware. The authentication source of vulnerability that a malicious code
mounted on virtual machines, and containers. process is the base for establishing a secure will exploit to compromise the RAN system.
This means that a malicious host operating communication channel based on the security The O1 interface should meet industry best
system can get access to all data processed in association established in the authentication practice to establish a secure management
the workloads. There are techniques in newer process. As there are different layers between connectivity based on strong digital identities,
CPUs/chipsets that intend to provide trusted the hardware and its security functions and such as X.509 certificates, with mutual
computing like secure enclaves. In this case, a the application, one needs standardized authentication, confidentiality and integrity
workload can use a secure enclave to protect interfaces and APIs to use the hardware protection using TLS. In addition, access
data and processing from the host system, security functions. This is important as different controls for 3PP hardware should also be
but the application will be hardware-instance hardware vendors may have different security implemented to maintain the trust chain.
dependent.
The virtualization layer includes the
hypervisor that is executed on the host
environment and is providing its own security
functions and APIs to the host systems
security functions. Hardware security
functions also need to be accessed via the
hypervisor as APIs, which means that the
hypervisor (and cloud environment) can
intercept all security functionality from the
lower layers and hence needs to be trusted
if these security functions are used. To get
a fully trusted virtualized application, one
needs to trust all the layers in the stack from
hardware to firmware to virtualized software,
as it is impossible to protect a virtual machine
or containers from the host system.
In a cloud-native environment using
containers there is no hypervisor. A container
management system, for example, Docker
plus the Linux kernel, provides isolation
between the host operating system and the
container environment. Containers don’t have
a full operating system and use name spaces
to isolate from other containers. Containers
on shared hardware resources are not meant
to be used in multi-tenancy environment.
Separate hardware and k8s clusters are
needed for multi-tenant workloads.
9 Security considerations of Open RAN

Areas of concern not exclusive

to open networks
Increased exposure to public exploits due practices as described in the Security Best attacks will persist for virtual deployments
to use of Open Source code Practices section. There have been notable running on third-party hardware. Potential
The O-RAN Software Community is a Linux vulnerabilities from downloading open new risks from physical attacks, as well
Foundation project, supported and funded source libraries and dependencies, as well as as applicable mitigation techniques, are
by O-RAN to lead the implementation of supply chain risks when downloading Open ongoing areas of study. Some National
the O-RAN specifications in Open Source; Source code from untrusted repositories. Institute of Standards and Technology (NIST)
further guiding security principles and It is recommended that vendors practice a recommendations are provided here.
overviews of using Open Source software higher level of due diligence for exposure to NIST SP 800-161, Supply Chain Risk
can be found at https://www.o-ran.org/ public exploits when using Open Source code. Management Practices for Federal
software, https://o-ran-sc.org/, https:// Recognized industry best practices include Information Systems and Organizations,
www.lfnetworking.org/ and https://www. security-by-design principles from SAFECode FAMILY: PHYSICAL AND ENVIRONMENTAL
linuxfoundation.org/blog/2019/04/how- (see https://safecode.org/) and OWASP PROTECTION states that “The physical
o-ran-sc-completes-the-open-source- SAMM (see https://owasp.org/www-project- and environmental protection policy should
networking-telecommunications-stack/. samm/) and supply chain security from NIST ensure that the physical interfaces of the ICT
Industry has recognized that Open Source SCRM (see https://csrc.nist.gov/Projects/ supply chain infrastructure have adequate
code introduces security risks. Open Source cyber-supply-chain-risk-management) and protection and audit for such protection.”
vulnerabilities are publicly available on the CISA ICT SCRM (see https://www.cisa.gov/ NIST Special Publication 800-82
National Vulnerability Database (NVD). ict-scrm-task-force). Guide to Industrial Control Systems (ICS)
While this is intended for developers to Security, Table C-5 Physical Vulnerabilities
disclose vulnerabilities, it is also used by Lack of defense from physical attacks and Predisposing Conditions includes
hackers to exploit those vulnerabilities. Use of 3PP hardware opens a new attack hardware vulnerabilities due to radio
Vulnerabilities frequently propagate as surface of physical attacks. Physical attacks frequency, electromagnetic pulse (EMP),
developers re-use free open source code include adversarial threats against power to static discharge, brownouts and voltage
enabling backdoors to attacks. Vendors disrupt availability, or hardware interfaces spikes. NIST recommends that hardware
using Open Source code must enhance its to gain access to information. It is expected provide proper shielding, grounding, power
security by applying industry coding best that requirements to protect against physical conditioning, and/or surge suppression.
10 Security considerations of Open RAN

Security best practices

It is important to implement security best • Trust stack with software anchored to implementation and operation. The vendors
practices in a multi-vendor environment reliable, trusted supply chains and trusted should also consider security assurance
using Open Source code to build open, operations with well-defined processes to across the product life cycle. For example,
interoperable, secure network systems. This reduce risk Ericsson’s process takes a holistic approach
enables vendors and network providers to • Vulnerability management with across technology and services ensures that
minimize the number of vulnerabilities and intelligence to continuously track, identify security is built in from the start, across supply
quickly respond in case a new vulnerability and remediate vulnerable applications chain, software and hardware development,
is found or exploited. These best practices • Multi-vendor system integration (SI) with testing, implementation and operation.
should be implemented by each vendor at the continuous verification to ensure all The Ericsson Security Reliability Model
individual product level and by the service vendors share the same interpretation and provides risk assessment, privacy impact
provider at the network level: implementation of functions report, secure code review, vulnerability
• Life Cycle Management (LCM) with early analysis and hardening guidelines for every
integration of security to implement Vendors should ensure that its software release. Product Security Incident Response
“security by design” meets 3GPP SA3 Security Assurance Team (PSIRT) keeps track of any new
• Continuous development and continuous Methodology (SECAM) and GSMA Network vulnerabilities that are found outside of
integration (CD/CI) with continuous Equipment Security Assurance Scheme that process and is ready to act on customer
regression testing and software security (NESAS) guidelines for development and product security incidents and reported
auditing testing process. A holistic approach across security issues affecting Ericsson products,
• Supplier Relationship Management with technology and services ensures that security solutions and services.
an inbound development process and strict is built in from the start, across supply chain,
security controls for FOSS software and hardware development, testing, (Additional information about 5G security
best practices can be found at https://www.
ericsson.com/en/blog/2020/6/security-
standards-role-in-5g)
11 Security considerations of Open RAN

Conclusions

Several service providers intend to leverage It is recommended by Ericsson that O-RAN Ericsson will continue its leadership role
virtual RAN in an Open RAN architecture implementations provide the following within the O-RAN Alliance to incorporate
to build secure, open, interoperable, security measures: security best practices. This will ensure that
disaggregated, virtual networks based upon • Protect expanded threat surface due to when O-RAN is ready to meet the level
industry standards. RAN virtualization means more interfaces and functions. of security expected by service providers
that security needs to be handled in a new • Close security vulnerabilities with and their customers. Ericsson’s integrated
way. As the industry evolves towards RAN Near-Real-Time RIC. and open network solutions will allow our
virtualization, with 3GPP or O-RAN, it is • Address threat to trust chain introduced by customers to build robust, secure and trusted
important that a risk-based approach is taken decoupling of functions. 5G networks.
to adequately address security risk. Secure, • Ensure management interfaces are
Open RAN systems will require additional secured according to industry best
security measures not fully addressed in the practices using TLS and digital signing.
standards, a trusted stack for software and • Practice a higher level of due diligence for
hardware, and interoperability between exposure to public exploits from use of
vendors with common understanding and Open Source code.
implementation of security requirements. • Implement defenses from physical attacks.
12 Security considerations of Open RAN

Author biographies

Jason S. Boswell is Ericsson North America’s expert in

telecommunications and network security, advising Ericsson’s
technicians, engineers and customers in creating and maintaining
secure Ericsson solutions across the region.
Mr. Boswell brings over 20 years of experience from within the
domains of telecommunications security design, engineering,
consulting, sales and thought leadership for global service providers,
governments and enterprises.

Scott Poretsky is an Ericsson North America leader in

telecommunications and network security, advising Ericsson’s
technicians, engineers and customers in creating and maintaining
secure Ericsson solutions across the region.
Mr. Poretsky brings over 25 years of network architecture and
security design experience. He has served in numerous industry
leadership roles and currently represents Ericsson in working groups,
industry fora and government committees to provide thought
leadership in security.
13 Security considerations of Open RAN

Acronyms

3GPP 3rd Generation Partnership Project

5G 5th Generation
CD/CI Continuous Integration/Continuous Delivery
CISA Cybersecurity and Infrastructure Security Agency
CP Control Plane
CPRI Common Public Radio Interface
DTLS Datagram Transport Layer Security
EMP Electromagnetic Pulse
FOSS Free Open Source Software
GSMA Global System for Mobile Communications Association
eMBB enhanced Mobile Broadband
HSM Hardware Security Module
ICS Industrial Control Systems
ICT Information and Communications Technology
IMSI International Mobile Subscriber Identity
LCM Life Cycle Management
LLS Lower Layer Split
MITM Man-in-the-Middle
mMTC massive Machine Type Communications
NESAS Network Equipment Security Assurance Scheme
NIST National Institute of Standards and Technology
NVD National Vulnerabilities Database
O-CU O-RAN Central Unit
O-DU O-RAN Distributed Unit
O-RAN Open-Radio Access Network
O-RU O-RAN Radio Unit
OWASP Open Web Application Security Project
PSIRT Product Security Incident Response Team
RAN Radio Access Network
RRM Radio Resource Management
RT-RIC Real-Time Radio Intelligent Controller
SAMM Software Assurance Maturity Model
SCRM Supply Chain Risk Management
SECAM Security Assurance Methodology
SEPP Security Edge Protection Proxy
SI System Integration
SSH Secure Shell
SUCI Subscription Concealed Identifier
SUPI Subscription Permanent Identifier
TLS Transport Layer Security
TPM Trusted Platform Module
UP User Plane
URLCC Ultra-Reliable Low Latency Communications
vRAN virtual Radio Access Network
About Ericsson Ericsson enables communications service providers to capture the full value of
connectivity. The company’s portfolio spans Networks, Digital Services, Managed
Services, and Emerging Business and is designed to help our customers go digital,
increase efficiency and find new revenue streams. Ericsson’s investments in
innovation have delivered the benefits of telephony and mobile broadband to billions
of people around the world. The Ericsson stock is listed on Nasdaq Stockholm and on
Nasdaq New York. www.ericsson.com

www.ericsson.com/5G The content of this document is subject to © Ericsson 2020

SE-126 25 Stockholm, Sweden revision without notice due to continued
Telephone +46 10 719 00 00 progress in methodology, design and
manufacturing. Ericsson shall have no
liability for any error or damage of any kind
resulting from the use of this document.