Topics covered in the 5G project

RAN
ORAN
Non RT RIC
Near RT RIC
A1 Interface
NEAR RT RIC INTERNAL ARCHITECTURE
E2 Interface
Kubernetes and Docker
Ramakanth A[T00497]
Sadhana palle[T00472]
 RAN
• A Radio access network(RAN) is the part of a telecommunications system that
connects individual devices to other parts of a network through radio connections.

• A RAN resides between user equipment, such as a mobile phone, a computer or

any remotely controlled machine, and provides the connection with its core
network. The RAN is a major component of wireless telecommunications and has
evolved through the generations of mobile networking leading up to 5G.

• Radio access networks have evolved over the years as cellular technology is now at
5G. Today, RANs can support multiple-input, multiple-output (MIMO) antennas,
wide spectrum bandwidths, multi-band carrier aggregation and more.
 O-Ran
• O-RAN refers to the O-RAN Alliance or designated specification. O-RAN Alliance is a
specification group defining next generation RAN infrastructures, empowered by
principles of intelligence and openness.

• O-RAN represents a really exciting opportunity to deliver better coverage, in more

places, more of the time. By opening up our radio access network to smaller
vendors, and a look towards wider adoption of 5G, O-RAN will be part of the
solution to bring the latest connectivity to more people around the country.

OPENNESS INTELLIGENCE
• The O-RAN Software Community (SC) is a collaboration between the O-RAN
Alliance and Linux Foundation with the mission to support the creation of software
for the Radio Access Network (RAN). The RAN is the next challenge for the open
source community. The O-RAN SC plans to leverage other LF network projects,
while addressing the challenges in performance, scale, and 3GPP alignment

• The O-RAN Reference

Architecture is designed to
enable next generation RAN
infrastructures.

• The architecture is based on

well-defined, standardized
interfaces to enable an
open, interoperable supply
chain ecosystem.
 Non RT-RIC and Near RT-RIC
• The Non-Real Time RIC (RAN Intelligent Controller) is an Orchestration and Automation
function described by the O-RAN Alliance for non-real-time intelligent management of RAN
(Radio Access Network) functions.
• The primary goal of the NON RT-RIC is to support non-real-time radio resource management,
higher layer procedure optimization, policy optimization in RAN, and providing guidance,
parameters, policies and AI/ML models to support the operation of near-Real Time RIC
functions in the RAN to achieve higher-level non-real-time objectives.
• NON RT-RIC functions include service and policy management, RAN analytics and model-
training for the near-Real Time RICs.
• The NON RT-RIC implementation will communicate with near-Real Time RIC elements in the
RAN via the A1 interface. Using the A1 interface the NONRTRIC will facilitate the provision
of policies for individual UEs or groups of UEs, provide enrichment information as required by
near-Real Time RICs; and facilitate
ML model training,
distribution and
inference in
cooperation with
the near-Real Time
RICs.
 
 A1 Interface
• A1 is the interface between non-RT RIC and modular CU which contains near-RT
RIC.
• The A1 interface is defined between the non-RT RIC and the near-RT RIC functions.
The A1 architecture and principles are described in A1 General Aspects and
Principles.
• A1 interface is used to apply the policies that have been created by the Non RT-RIC
based on the configuration and the current performance of the RAN.
• Functions and Protocol Stack:
 TCP provides the communication service at the transport
layer.
 TLS is used to provide secure HTTP connections.
 HTTP/1.1is used as application level protocol.
 The data interchange layer constitutes the transport of documents in the JSON format.
Near-RT RIC Internal Architecture

E2 Interface
 Near-RT RIC Internal Architecture
Explanation
• xApp: An application designed to run on the Near-RT RIC. Such an application is likely to consist of one or
more microservices and at the point of on-boarding will identify which data it consumes and which data it
provides. The application is independent of the Near-RT RIC and may be provided by any third party.
• Messaging infrastructure: which enables message interaction amongst Near-RT RIC internal functions.
• Conflict mitigation: which resolves potentially overlapping or conflicting requests from multiple xApps.
• Security: which provides the security scheme for the xApps.
• Management services:
Fault management,
configuration management
performance management
E2 termination: which terminates the E2 interface from an E2 Node.
• A1 termination: which terminates the A1 interface from the non-RT RIC.
• O1 termination: which terminates the O1 interface from SMO.
• E2 Node: a logical node terminating E2 interface.
 E2 Interface
• E2: Interface connecting the Near-RT RIC and one or more O-CU-CPs, one or more O-CU-UPs,
and one or more O-DUs.
• The E2 enables a direct association between the xApp and the RAN functionality.
• Real-time data dispatching from E2 termination to multiple xApps.
• E2 related APIs enable the exchange of information between xApps and E2 termination.
• Functions hosted by xApps, which allow services to be executed at the Near-RT RIC and the
outcomes sent to the E2 Nodes via E2 interface.

Near-RT RIC E2
Interface

DU
CU C-Plane RLC
CU U-Plane MAC
PHY
 E2 Termination

• E2 Termination terminates the SCTP connection from each E2 Node.

• E2 Termination routes messages from the xApps through the SCTP connection to
the E2 Node.
• E2 Termination decodes the payload of an incoming message enough to determine
message type.
• E2 Termination handles incoming E2 messages related to E2 connectivity.
• E2 Termination receives and respond to the E2 Setup Request from the E2 Node.
• E2 Termination notifies xApps of the list of RAN functions supported by an E2 Node
based on information derived from E2 Setup and RIC Service Update procedures.
• E2 Termination notifies the newly connected E2 Node of the list of accepted
functions
 Kubernetes and Docker
• Kubernetes is an open-source Container Management tool which automates
container deployment, container scaling, and descaling and container load
balancing.
• Kubernetes provides a platform to schedule and run containers on clusters of
physical or virtual machines.
• Kubernetes is a portable, extensible, open-source platform for managing
containerized workloads and services, that facilitates both declarative
configuration and automation. It has a large, rapidly growing ecosystem.
Kubernetes services, support, and tools are widely available.
 Why you need Kubernetes and what it can do ?
• Service discovery and load balancing
Kubernetes can expose a container using the DNS name or using their own IP address.
If traffic to a container is high, Kubernetes is able to load balance and distribute the
network traffic so that the deployment is stable.
• Storage orchestration
Kubernetes allows you to automatically mount a storage system of your choice, such as
local storages, public cloud providers, and more.
• Automated rollouts and rollbacks
You can describe the desired state for your deployed containers using Kubernetes, and
it can change the actual state to the desired state at a controlled rate.
• Automatic bin packing
You provide Kubernetes with a cluster of nodes that it can use to run containerized
tasks. You tell Kubernetes how much CPU and memory (RAM) each container needs.
• Self-healing
Kubernetes restarts containers that fail, replaces containers, kills containers that don’t
respond to your user-defined health check, and doesn’t advertise them to clients until
they are ready to serve.
• Secret and configuration management
Kubernetes lets you store and manage sensitive information, such as passwords, OAuth
tokens, and SSH keys.
 Docker
• Docker is the containerization platform which is used to package your application
and all its dependencies together in the form of containers so to make sure that
your application works seamlessly in any environment which can be development
or test or production. Docker is a tool designed to make it easier to create, deploy,
run applications by using containers.
• Docker is designed to benefit both developers and system administrators making it
a part of many Devops toolchains.
• Developers can write code without worrying about the testing and production
environment. Sysadmins need not worry about infrastructure as Docker can easily
scale up and scale down the number of systems.
• Docker comes into play at the deployment stage of software development cycle.
Components of Docker
• Docker Clients and Servers
• Docker Images
• Docker File
• Docker Registries
• Docker Containers

Advantages of Docker
• Speed
• Portability
• Scalability
• Density
Concepts covered related to 5G

OOPS in C++
Basics of Networking
TCP/IP
HTTP
TLS

Ramakanth A[T00497]
 OOPS in C++
• Object means a real word entity such as pen, chair, table etc. Object-Oriented
Programming is a methodology or paradigm to design a program using classes and
objects. It simplifies the software development and maintenance by providing
some concepts:
• Object -> Any entity that has state and behavior is known as an object.
• Class -> Collection of objects is called a class.
• Inheritance -> When one object acquires all the properties and behaviors of parent
object
• Polymorphism -> When one task is performed by different ways
• Abstraction -> Hiding internal details and showing functionality
• Encapsulation -> Binding code and data together into a single unit

Practice problems –
www.hackerearth.com
 Basics of networking
• Computer Network:
It is the interconnection of multiple devices, generally termed as Hosts connected using
multiple paths for the purpose
• OSI and OSI Layers:
OSI stands for Open Systems Interconnection. It is a reference model that specifies
standards for communications protocols and also the functionalities of each layer.
• Protocol:
A protocol is the set of rules or algorithms which define the way how two entities can
communicate across the network and there exists different protocol defined at each
layer of the OSI model. Few of such protocols are TCP, IP, UDP, ARP, DHCP, FTP and so
on.
• IP Address (Internet Protocol address):
Also, known as the Logical Address, is the network address of the system across the
network.
• Port:
Port can be referred as a logical channel through which data can be sent/received to an
application.
• DNS:
DNS is basically a server which translates web addresses or URL into their
corresponding IP addresses.
 TCP/IP
•  TCP/IP was designed and developed by Department of Defense (DoD) in 1960s
and is based on standard protocols. It stands for Transmission Control
Protocol/Internet Protocol. The TCP/IP model is a concise version of the OSI
model. It contains four layers, unlike seven layers in the OSI model.
The layers are:
• Process/Application Layer
• Host-to-Host/Transport Layer
• Internet Layer
• Network Access/Link Layer

• Implemented programs :
– TCP/IP Client server program -[
https://gist.github.com/haikentcode/c1199e87b8c8ca974469#file-server-cpp-L125]
– Tic Tac Toe game
[https://github.com/edgul/Tic-Tac-Toe]
 TLS
• Transport Layer Security (TLS), and its now-deprecated predecessor, Secure
Sockets Layer (SSL), are cryptographic protocols designed to
provide communications security over a computer network. Several versions of the
protocols find widespread use in applications such as web browsing, email, instant
messaging, and voice over IP (VoIP). Websites can use TLS to secure all
communications between their servers and web browsers.
• Transport Layer Securities (TLS) are designed to provide security at the transport
layer. TLS was derived from a security protocol called Secure Service Layer (SSL).
TLS ensures that no third party may eavdrops or tamper with any message.
 HTTP
• Network protocol of the web.
• Virtually delivers all files and resources(data).
• Takes place through TCP/IP.

Browser - HTTP Client

Web Server - HTTP Server

Structure of HTTP:
The format of the HTTP request and HTTP response messages are similar, and English-
oriented. Both kinds of messages consist of:
• an initial line (GET, POST, HEAD)
• zero or more header lines,
• a blank line (i.e. a CRLF by itself), and
• an optional message body (e.g. a file, or query data, or query output).

Implemented program - https://github.com/boostorg/beast