# Service Management and Orchestration (SMO)

:::info
Service Management and Orchestration (SMO) is a project that is intended to find document gaps in open-source when compared against O-Ran's documentation. And to provide software documentation and implementation of integrated tested SMO deployments.
:::
[toc]

## Introduction

:::success
The Service Management and Orchestration (SMO) componet that superintends orchestration, management, and automation of RAN elements. Supporting O1, A1, and O2 interfaces
:::

:::info
Addtional Notes
- SMO can handle end-to-end network slicing where RAN slicing is an important component
- SMO needs to simultaneously handle life cycle management of
- PNFs, VNFs and CNFs
- Non-Real time RIC is essential to SMO because it:
- Hosts the ecosystem of applications acting across RAN
- Generates and applies new policies along with network optimizations

:::
## Deployment Types
SMO has 3 different deployment types

1.) SMO Dev: This is used by O-RAN-SC developers, and focuses on improving the developer's experince. Areas of focus are A1, O1, Pre-O2, ModelCatalog, ServiceConfig, VirtualInventory and OTF test harness.

2.) SMO-MVP “Minimum Viable Product”: A significantly lighter version of SMO, predomenitally used for module testing. However, to properly show O-Ran functions it needs O-RAN-SC simulators to be included. Currently it is mostly used for testing of OTF scripts, but in the future they want to include machine learning training for xApps and rApps.

3.) SMO-full (future releases): SMO-full is intended to be the future commerical release of SMO. This version will include features such as one click deployment and geo-redundency.


## Orchestration Challenges

:::success
The dramatically different requirements of 5G have completely redefined and shifted the architecture of 5G when compared to previous generations. As networks become evermore sophisticated and complex. Leading the the devlopment of many new and unque challenges:

- Network virtualizations leading to functions being divided among physical, virtual, and cloud domains.
- Services have the ability to flow across different network functions and in multiple domains
- New techniques such as network slicing are enabling services to become even more advanced
- Domains may have their own OSS systems
:::

## Machine Learning

As mentioend in the deployment types, one goal of SMO-MVP is the itegration of machine learning to enhance xAPPs and rApps.

:::warning

Both supervised and unsupervised learning in SMO only make use of the A1 interface between Non-RT-RIC and Near-RT-RIC, whereas reinforcement learning makes us of O1 and A1 interfaces. Thisis becasue the ML training host and ML model host/actor are supposed to be co-located as part of either Non-RT RIC or Near-RT RIC.
:::


:::info
There are threee possible locations for ML training to be executed
- Non-RT-RIC
- Near-RT-RIC
- O-DU

Most initial testing of machine learning implementations have be in Non-RT-RIC, as their phase one goal.


:::

## O1 Integration

:::info
Integration of the OAM Architecture into a Service Management and Orchestration Framework

- O1 supports management functions, such as FCAPS, between ORAN components and the Service Management and Orchestration Framework

Addditional functions performed by the O1 interface are:
- Discovery/registration
- Configuration of addressing
- Versioning
- Monitoring

:::

Sources:

https://wiki.o-ran-sc.org/pages/viewpage.action?pageId=20875862

https://wiki.o-ran-sc.org/display/OAM/OAM+Architecture#OAMArchitecture-IntegrationintoSMO

https://www.ericsson.com/en/blog/2020/11/next-generation-cloud-ran-management-and-orchestration

https://hackmd.io/@akmalns/HJsFzXeJP

https://static1.squarespace.com/static/5ad774cce74940d7115044b0/t/5e95a0a306c6ab2d1cbca4d3/1586864301196/O-RAN+Use+Cases+and+Deployment+Scenarios+Whitepaper+February+2020.pdf