Exploring Interactions Among SMO-related Projects in OSC and ONAP

OSC/ONAP SMO Framework
Exploring interactions among
SMO-related projects in OSC and ONAP
June xx, 2023
Incorporating ideas and support from several people, including:
Andrea Buldorini, Rittwik Jana, John Keeney, David Kinsey, Seshu Mudiganti, Timo Perala,
N. K. Shankar, Martin Skorupski, Joseph Thaliath
Summary
Coverage of SMO functionality is increasing in OSC projects
Strong overlap between OSC and ONAP for SMO-related functionality
There is consensus in OSC and ONAP at TOC/TSC level:
SMO-related work in OSC and ONAP should align with trends in SMO-related
discussion in O-RAN Alliance, especially WG1 SMO Decoupled Architecture TR
Avoid duplication, improve synergy and collaboration between OSC and ONAP
Build on existing OSC/ONAP work – improve interworking and alignment
oam (o1,ofh-mp), sdn-c, ves collector, pm handler
aimlfw, dmaap/kafka, policy, cps db
non-rt-ric (a1,r1,rapp)
smo (o2), so
intent
Select end-to-end application use cases to define end-to-end flows
Identify gaps and future direction
Active discussion and ongoing work in O-RAN WG1
ATG on Decoupled SMO Architecture
Decomposition of SMO functionalities
Service Based Architecture (SBA)
SMO Functions (SMOF)
SMO Services (SMOS)
Output: 
Decoupled SMO Technical Report
Links:
Decoupled+SMO+Technical+Report+TR+CR+Trackerhttps://oranalliance.atlassian.net/wiki/spaces/UCOA/pages/2513043516/ATG+Draft+Specificationshttps://oranalliance.atlassian.net/wiki/spaces/UCOA/pages/2217476445/45/O-RAN-WG1.Decoupled-SMO-Architecture-TR-v01.00.09.zip?api=v2https://oranalliance.atlassian.net/wiki/download/attachments/22174764
O-RAN WG1 Decoupled SMO Architecture Work Item
Figure from TR section 4 (July 2022 WG2 view)
Figure from Draft TR section 6 (Recommendation)
Recommendation in O-RAN WG1 Decoupled SMO Architecture TR-R003-v01.00.09
Section 6.2 Recommended Solution
The SMOSs identified in clause 5 of this document are represented in a service-based architecture in the figure 6.2.1-1 below.
Figure 6.2.2  -1: SMOSs in the SMO SBA representation
OSC and ONAP projects related to SMO (draft, expect changes)
Figure 6.2.2  -1: SMOSs in the SMO SBA representation
smo, 
so
oam
ves
sdn-c
non-rt-ric
sim
sim
non-rt-ric
ran-sim
dmaap
/kafka
aimlfw
policy
cps
intent
dcae?
inf
int
acm
idam
a&ai?
aimlfw
Relevant projects
to be placed
oof?
Notes:
Figure is meant to
explore alignment to
O-RAN architecture
Each red/blue label is an
osc/onap open source
project/component
We may/do not have or
need 1:1 mapping
between projects and
architecture blocks
smo-pkg
E
x
a
m
p
l
e
 
o
f
 
S
M
O
 
i
n
t
e
r
a
c
t
i
o
n
:
 
A
I
M
L
F
W
6
AIHP
AWMF-TM
Kubeflow Adapter
SDK
- Feature Store
SDK
- Model Storage
IPS - Kserve
Kserve Adapter
Data Extraction
Data Lake
(Influx DB)
Kafka
O1 Termination
Assit rApp
ML rApp
TPS - Kubeflow
USER
Assist xApp
ML xApp
QoE
Training Pipeline
SDL
(Influx DB)
portal-aiml-dashboard
A
T
H
P
Model storage
(Leofs)
1
A
I
M
L
F
W
N
o
n
-
R
T
 
R
I
C
DME
N
e
a
r
-
R
T
 
R
I
C
AIHP
IPS - Kserve
Kserve Adapter
1
Location of AI Training functions is not
fixed and may vary according to usecase.
AIMLFW needs to exchange data
with rApp/Non-RT RIC via DME
RAN NF data is received
over O1 by OAM
(RAN OAM NF)
AI/ML can also be
applied for O2-
related data
SMO interactions: Energy Savings (ES) scenario
Objective: Select a use case scenario to define call flows, identify gaps, and
provide guidance for synergy/collaboration among open source
components – (not to implement a fully functional use case)
Assume one or more rApps for ES use case
Use FOCOM/NFO and O2 to configure O-cloud deploy RAN NFs
Use oam and rApp(s) to configure RAN NF and get RAN data using O1
Assume AI/ML functions/services are trained and available
Use rApp(s) to analyze RAN data
Reconfigure RAN NF as needed via O1, A1 to optimize energy
Pause/restart RAN NF as needed via O2-dms to optimize energy
Modify cloud resources (e.g., cpu performance, turn off) via O2-ims to
optimize energy
Feedback from OSC to O-RAN
1.
OSC is seeking to align SMO-related work with:
O-RAN Architecture TS and TR
Decoupled SMO Architecture TR work - relevant for ongoing trends
MVP-C Use Cases – to highlight interactions between components
2.
Is it correct to use SMO-DEC TR section 6.2 Recommended Solution for WG1 as
basis for SMO architecture?
3.
How will AI/ML functions/services be included in SMO architecture?
4.
How will policy functions and co-ordination across SMO components (e.g,
different rApps, different actions on same interface) included in SMO
architecture?
5.
Is MVP-C Energy Savings Use Case a good choice for a comprehensive scenario
to study interactions between (all) SMO components?
6.
Any comments on options to implement database, inventory?
OSC/ONAP SMO Framework
Objective:
Keep track of ONAP/OSC projects and components related to SMO
Define/study end-to-end application use cases, sequence flows involving
multiple components
Identify interfaces, apis, missing functionality
Alignment with O-RAN Architecture
Maximum synergy/collaboration in ONAP and OSC code development
Process
1)
Socialize among stakeholders
2)
ONAP: Present ONAP SMO Framework “Use Case” to ArchCom
3)
OSC: Present in RSAC/TOC discussions
ONAP Release M plan (draft)
Develop overall architecture/guidance for SMO-related work
Select interaction scenario based on end-to-end application use case
Objective is to highlight interaction
Aligned with O-RAN MVP-C use case trends
Suggestion: Energy Savings scenario
Output:
Wiki pages/documents, sequence diagrams
Feedback to O-RAN WG as needed
Explore feasibility of simple interworking
Background presentations
ONAP and O-RAN SC
John Keeney, Seshu Mudiganti, Timo Perala, N. K. Shankar, Martin Skorupski
March 21, 2023
ONAP/OSC Synergy Discussion presented in RSAC in March 2023
Summary & Objective
O-RAN SC and ONAP have common areas of interest
This is a good time to improve collaboration and synergy
Objective of this presentation:
Provide a high-level overview
List common areas of interest
Highlight areas of ongoing good collaboration
Identify new areas with potential synergy
Discussion – priorities, next steps
O-RAN SC and ONAP
O-RAN Software Community (OSC) (
https://o-ran-sc.org/
  )
Part of Linux Foundation (LF)
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.
ONAP (
https://www.onap.org/
  )
Part of Linux Foundation (LF) 
and Linux Foundation Networking (LFN)
ONAP is a comprehensive platform for 
orchestration, management, and automation of
network and edge computing services 
for network operators, cloud providers, and enterprises.
Real-time, policy-driven orchestration and automation of physical and virtual network
functions enables rapid automation of new services and complete lifecycle management
critical for 5G and next-generation networks
ONAP work is directly relevant to anything related to O-RAN SMO
(
Service Management and Orchestration
)
This figure is from early days of O-RAN (~2020/21) using ONAP concepts (e.g., DCAE, SO, Policy, OOF ..)
Recently posted by Alex Choi in article about importance about SMO (around March 9, 2023)
(
https://www.linkedin.com/posts/alex-jinsung-choi-48a8b61_oran-openran-oranalliance-activity-7039638269231263744-3Lqj?utm_source=share&utm_medium=member_desktop
 )
Service Management and Orchestration functions
of SMO have strong overlap with ONAP
Operators are using ONAP components for SMO
Figure 5.1‑1: High Level Architecture of O-RAN (From O-RAN.WG1.OAD-R003-v08.00)
Southbound interfaces
from SMO to RAN:
Specified by O-RAN
ONAP projects have
goal to align with
O-RAN specs
RAN-Sim
ONAP SON Use Case Example – Aligned to O-RAN O1 and A1
17
 
SON
Handler
MS
SDN-R (SDN-C)
Policy
Config
Change
VES
Coll
O1
REST API
DMaaP
FM, PM, CM
A1
A1 Policy
O1
A1
Control
Loop
O-RAN O1
O1
A1
O1
CU/DU
RAN App
A1 PMS
SLI
CPS DB
OOF
DES
MS
Data
Lake
NCMP
DMI
D
a
t
a
 
A
n
a
l
y
s
i
s
,
S
O
N
 
A
l
g
o
r
i
t
h
m
C
o
n
f
i
g
u
r
a
t
i
o
n
 
(
O
1
)
 
a
n
d
 
P
o
l
i
c
y
 
G
u
i
d
a
n
c
e
 
(
A
1
)
f
r
o
m
 
S
M
O
 
t
o
 
R
A
N
F
M
,
 
P
M
,
 
C
M
I
n
f
o
 
f
r
o
m
 
R
A
N
 
F
M
/
P
M
 
t
o
 
S
 
FM/PM DB
TBDMT
C
M
 
u
p
d
a
t
e
t
o
 
C
P
S
 
D
B
C
M
N
o
t
i
f
n
S
i
m
u
l
a
t
e
d
R
A
N
(
O
-
R
A
N
)
Figure 4.1‑3: SBA representation of the documented SMO services in July 2022 specifications (From O-RAN WG1 Decouple SMO Architecture TR v01.00)
Editor’s Note:
1)
The naming of the interfaces is to be further analyzed and refined in section 5 and 6.
2)
The figure needs to be reviewed with WG2 for non-RT RIC architecture part, so it might be further updated if needed, as per latest agreed version with WG2.
3)
Though the figure does not explicitly illustrate, an objective would be to represent a common set of possible abstracted SMOSs’ across SMOFs. For example,
it would be desirable to represent a common set of SMOSs for FM to query and acknowledge Faults, as well as an associated common information model for
fault LCM, irrespective of whether that Fault originates in the O-Cloud Resources Management and Orchestration Services SMOF or the RAN NF OAM
Services SMOF.
O-RAN WG1 ATG
Decoupled SMO TR
will show separation
of SMO functionalities
Ongoing work
Service Based
Architecture (SBA)
SMO Functions (SMOF)
SMO Services (SMOS)
Relevant to ONAP and
OSC design choices
ONAP/OSC Harmonization
Ongoing effort among group of stakeholders seeking to find synergies
Good collaboration - especially for o1/ofh-mp, oam, sim, non-rt-ric, a1
Weekly calls: Wed 12 noon ET
Approach:
Share information, review status, seek synergy
Avoid duplicate effort, re-use code, use one repo when possible
Stay flexible and accommodate variations of modules
New areas are coming up: O2, R1, intra-SMO interfaces, AI/ML …
Harmonization effort has largely been from ONAP side to work with OSC
Good time to review and establish joint objectives! (ONAP TSC, OSC TOC)
Operators interested in O-RAN are using ONAP components
Objective today: Review and find/prioritize common areas of interest
Common ONAP/OSC areas – O1 and A1
O1 / OFH-MP interfaces (RAN NF OAM SMOF and SMOS) -> WG10, WG4
Good ongoing ONAP/OSC harmonization and collaboration since early days
CU/DU/RU yang model development and refinement
Strong support in OSC sim and ONAP RAN-Sim simulators
O1 FM/PM/CM development and refinement
ONAP use cases: Control loops, 5G SON, Network Slicing etc.
Feedback to O-RAN WGs
Would be helpful to make release timelines and versions better aligned.
A1 interface (non-rt-ric – related SMOF/SMOS) -> WG2, WG10
Good ongoing ONAP/OSC harmonization and collaboration since early days
SDN-R/CCSDK to A1-Termination
ONAP projects exploring rApp and control loop designs – 5G SON use case, rAppification etc.
ONAP RAN-Sim extended to provide ran-app abstraction and A1 Termination
We can build on existing collaboration model
Common ONAP/OSC areas – O2
O-Cloud/NF orchestration and management is relatively new area for open source
O2-ims (O-RAN FOCOM-related SMOF/SMOS) -> WG6
Cloud domain orchestration and management
ONAP multi-VIM
O2-dms (O-RAN NFO-related SMOF/SMOS) -> WG6
NF orchestration and management
O-RAN WG6 has ETSI and K8s profiles
ONAP NF orchestration and management more relevant for K8s (ASD) profile ?
Very timely area for harmonization of open-source efforts
Worthwhile to also consider synergy/sharing with other projects
Nephio (LF), O-RAN OSFG, … ??
Choose use cases needing co-ordination across O2-ims/O2-dms/O1
Contribute to WG1/6/10 re. interaction between FOCOM, NFO, RAN NF OAM
NEW
AREA
NEW
AREA
Common ONAP/OSC areas – Non-RT RIC
rApp, Applications, R1 interface:  → WG2 (WG10, app mgmnt, WG1)
ONAP use cases for applications which manage RAN – (pre-rApp, pre-R1)
Good amount of work in OSC
Already reusing ONAP functions as part of  rApp management/LCM
“rAppification” 
- Ongoing effort to leverage ONAP control loops, Policy,
microservices, 
use cases, 
and 
align with O-RAN R1 interface
SMO Policy Functions -> WG2 (WG10, app mgmnt, WG1)
ONAP has a Policy Enforcement Function to provide policy-based c
o-
ordination across applications and interfaces
N
o clear placeholder in current O-RAN SMO architecture or OSC
rApp might use multiple SMO services
rApp might contains Policies (ref work in ONAP ACM / App manager)
Should co-ordination across rApps and interfaces be an SMO capability?
NEW
AREA
NEW
AREA
Common ONAP/OSC areas – Intra-SMO, Northbound
Several integral ONAP components are “intra 
SMO” or
“northbound/external”
S
ervice management, orchestration, data handling, LCM etc. – part of ONAP charter
End-to-end implementation can highlight design/scalability/operational issues
Can be r
elevant to SMO southbound interfaces – e.g., modelling
Key takeaway: 
Consider reusing existing work when use cases grow to new areas
Service Orchestration, Service Design, Data Handling (SO, SDC, DCAE)
Higher level than Cloud Orchestration and NF Orchestration
Creation and orchestration of 
SMO Services 
as well as 
End-to-end Services 
which
need to be instantiated to implement a use case
Inventory (resources, models, connections), Configuration database
ONAP has A&AI for 
resource/NF/service inventory and CPS DB for NF configuration
e.g., CPS DB using O-RAN yang model for CU, DU, RU config
Northbound interfaces (Portal etc)
Intent-based networking
NEW
AREA
NEW
AREA
Common ONAP/OSC areas – Overall
AI/ML → WG2
Previous 
AI/ML work is generic without specific role 
for 
Non-RT and Near-RT RIC.
Implications on implementation choices for 
rApp, 
database, data exposure etc.
SMO Architectural choices  -> WG1
Consider SMO Functions/SMO Services approach in implementations
Provide feedback to WG1 – promote efficient approaches
Design choices 
can enhance relevance of 
open-source efforts to industry
End-to-end use cases -> WG1, OSC
Consider choosing common use cases in OSC and 
ONAP
Consider end-to-end use cases which highlight inter-operability i
nterfaces
Security → WG11
Share/use best practices 
- interfaces, design, system implementation, code design etc
Success example: Sharing of best practice for logging from ONAP to O-RAN WG11
Simulation -> OSC
Ongoing effort to leverage/harmonize work in OSC sim and ONAP RAN-Sim etc.
OSC oriented towards CU/DU functions, ONAP oriented towards use case
NEW
AREA
NEW
AREA
O
S
C
 
A
I
M
L
F
W
U
p
d
a
t
e
 
f
o
r
 
T
O
C
Joseph Thaliath
May 11
th
, 2023
OSC AIML example of interworking between OSC projects
C
u
r
r
e
n
t
 
A
I
M
L
F
W
 
A
r
c
h
i
t
e
c
t
u
r
e
 
F
l
o
w
28
AIHP
AWMF-TM
Kubeflow Adapter
SDK
- Feature Store
SDK
- Model Storage
IPS - Kserve
Kserve Adapter
Data Extraction
Data Lake
(Influx DB)
Kafka
O1 Termination
Assit rApp
ML rApp
TPS - Kubeflow
USER
Assist xApp
ML xApp
QoE
Training Pipeline
SDL
(Influx DB)
portal-aiml-dashboard
A
T
H
P
Model storage
(Leofs)
1
A
I
M
L
F
W
N
o
n
-
R
T
 
R
I
C
DME
N
e
a
r
-
R
T
 
R
I
C
AIHP
IPS - Kserve
Kserve Adapter
1
Location of AI Training functions is not
fixed and may vary according to usecase.
A
I
M
L
F
W
 
O
v
e
r
v
i
e
w
Release “H” Status
Diversify training data source for Training host (DME Integration testing in progress)
Demo of feature group creation with DME data source
Kserve adapter (Code commits in progress )
Kserve adapter for Near-RT RIC
 Training pipeline Enhancement (Completed)
Provide sample pipelines by default
AIMLFW feature enhancements (Code commits in progress )
Options for edit, retrain and delete training jobs
O-RAN Alliance Alignment
Release “I” Plan
29
O
-
R
A
N
 
A
l
l
i
a
n
c
e
 
A
l
i
g
n
m
e
n
t
April 07, 2023
O-RAN Alliance - Working Group 10
30
R
e
l
e
a
s
e
 
I
 
P
l
a
n
 
(
O
n
g
o
i
n
g
)
31
Following are high level topics to be considered:
Model deployment options
Training Pipeline abstractions
Integrated install with Non-RT RIC/ Near-RT RIC/SMO
Model Performance monitoring
Model validation
Advanced Feature selection
Model services
Advanced retraining options
AIMLFW installation optimizations
Integrate Non-RT RIC and Near-RT RIC AI/ML usecases
https://jira.onap.org/browse/DCAEGEN2-3067
To prioritize and select based on brainstorming and feedback
O
p
e
n
 
t
o
p
i
c
s
Access to data available at Near-RT RIC for training models in SMO.
Deployment of ML model
Will it be considered as xApp or rApp deployment?
Will it provided as service from platform?
Will model be integrated within xApp and rApp and will not require support from inference
platforms?
Model formats
Training function inputs
32
Slide Note
Embed
Share

Coverage of SMO functionality is increasing in OSC projects with strong overlap between OSC and ONAP for SMO-related functionality. Consensus at TOC/TSC level in OSC and ONAP to align with trends in SMO-related discussions in O-RAN Alliance, especially WG1 SMO Decoupled Architecture TR. Efforts to avoid duplication and improve synergy and collaboration between OSC and ONAP by building on existing work and enhancing interworking and alignment across various components. Ongoing work in O-RAN WG1 on Decoupled SMO Architecture and decomposition of SMO functionalities into Service Based Architecture, SMO Functions, and SMO Services. Recommendations for implementing SMOS in SMO SBA representation.


Uploaded on Apr 17, 2024 | 5 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

E N D

Presentation Transcript


  1. OSC/ONAP SMO Framework Exploring interactions among SMO-related projects in OSC and ONAP June xx, 2023 Incorporating ideas and support from several people, including: Andrea Buldorini, Rittwik Jana, John Keeney, David Kinsey, Seshu Mudiganti, Timo Perala, N. K. Shankar, Martin Skorupski, Joseph Thaliath

  2. Summary Coverage of SMO functionality is increasing in OSC projects Strong overlap between OSC and ONAP for SMO-related functionality There is consensus in OSC and ONAP at TOC/TSC level: SMO-related work in OSC and ONAP should align with trends in SMO-related discussion in O-RAN Alliance, especially WG1 SMO Decoupled Architecture TR Avoid duplication, improve synergy and collaboration between OSC and ONAP Build on existing OSC/ONAP work improve interworking and alignment oam (o1,ofh-mp), sdn-c, ves collector, pm handler aimlfw, dmaap/kafka, policy, cps db non-rt-ric (a1,r1,rapp) smo (o2), so intent Select end-to-end application use cases to define end-to-end flows Identify gaps and future direction

  3. O-RAN WG1 Decoupled SMO Architecture Work Item Figure from TR section 4 (July 2022 WG2 view) Active discussion and ongoing work in O-RAN WG1 ATG on Decoupled SMO Architecture Decomposition of SMO functionalities Service Based Architecture (SBA) SMO Functions (SMOF) SMO Services (SMOS) Output: Decoupled SMO Technical Report Links: https://oranalliance.atlassian.net/wiki/download/attachments/22174764 45/O-RAN-WG1.Decoupled-SMO-Architecture-TR-v01.00.09.zip?api=v2 https://oranalliance.atlassian.net/wiki/spaces/UCOA/pages/2217476445/ ATG+Draft+Specifications https://oranalliance.atlassian.net/wiki/spaces/UCOA/pages/2513043516/ Decoupled+SMO+Technical+Report+TR+CR+Tracker Figure from Draft TR section 6 (Recommendation)

  4. Recommendation in O-RAN WG1 Decoupled SMO Architecture TR-R003-v01.00.09 Section 6.2 Recommended Solution The SMOSs identified in clause 5 of this document are represented in a service-based architecture in the figure 6.2.1-1 below. Figure 6.2.2 -1: SMOSs in the SMO SBA representation

  5. OSC and ONAP projects related to SMO (draft, expect changes) Relevant projects to be placed smo-pkg aimlfw intent int acm policy cps a&ai? oof? dcae? non-rt-ric idam Notes: Figure is meant to explore alignment to O-RAN architecture Each red/blue label is an osc/onap open source project/component We may/do not have or need 1:1 mapping between projects and architecture blocks dmaap/kafka smo, so oam ves sdn-c non-rt-ric aimlfw ran-sim inf sim sim Figure 6.2.2 -1: SMOSs in the SMO SBA representation

  6. Example of SMO interaction: AIMLFW Example of SMO interaction: AIMLFW 1AIMLFW Non-RT RIC portal-aiml-dashboard AWMF-TM Assit rApp ML rApp USER ATHP AIHP AIMLFW needs to exchange data with rApp/Non-RT RIC via DME SDK QoE SDK Kserve Adapter Kubeflow Adapter - Model Storage Training Pipeline - Feature Store IPS - Kserve Data Extraction DME TPS - Kubeflow Model storage (Leofs) RAN NF data is received over O1 by OAM (RAN OAM NF) Kafka Data Lake (Influx DB) O1 Termination Near-RT RIC AI/ML can also be applied for O2- related data AIMLFW AI/ML Framework AWMF AI Workflow Management Function TM Training Manager Assist xApp ML xApp TPS Training Platform Service (e.g. Kubeflow) AIHP ATHP AI Training Host Platform IPS Inference Platform Service (e.g. Kserve) Kserve Adapter SDL AIHP AI Inference Host Platform IPS - Kserve (Influx DB) 1Location of AI Training functions is not fixed and may vary according to usecase. 6

  7. SMO interactions: Energy Savings (ES) scenario Objective: Select a use case scenario to define call flows, identify gaps, and provide guidance for synergy/collaboration among open source components (not to implement a fully functional use case) Assume one or more rApps for ES use case Use FOCOM/NFO and O2 to configure O-cloud deploy RAN NFs Use oam and rApp(s) to configure RAN NF and get RAN data using O1 Assume AI/ML functions/services are trained and available Use rApp(s) to analyze RAN data Reconfigure RAN NF as needed via O1, A1 to optimize energy Pause/restart RAN NF as needed via O2-dms to optimize energy Modify cloud resources (e.g., cpu performance, turn off) via O2-ims to optimize energy

  8. Feedback from OSC to O-RAN 1. OSC is seeking to align SMO-related work with: O-RAN Architecture TS and TR Decoupled SMO Architecture TR work - relevant for ongoing trends MVP-C Use Cases to highlight interactions between components Is it correct to use SMO-DEC TR section 6.2 Recommended Solution for WG1 as basis for SMO architecture? How will AI/ML functions/services be included in SMO architecture? How will policy functions and co-ordination across SMO components (e.g, different rApps, different actions on same interface) included in SMO architecture? Is MVP-C Energy Savings Use Case a good choice for a comprehensive scenario to study interactions between (all) SMO components? Any comments on options to implement database, inventory? 2. 3. 4. 5. 6.

  9. OSC/ONAP SMO Framework Objective: Keep track of ONAP/OSC projects and components related to SMO Define/study end-to-end application use cases, sequence flows involving multiple components Identify interfaces, apis, missing functionality Alignment with O-RAN Architecture Maximum synergy/collaboration in ONAP and OSC code development Process 1) Socialize among stakeholders 2) ONAP: Present ONAP SMO Framework Use Case to ArchCom 3) OSC: Present in RSAC/TOC discussions

  10. ONAP Release M plan (draft) Develop overall architecture/guidance for SMO-related work Select interaction scenario based on end-to-end application use case Objective is to highlight interaction Aligned with O-RAN MVP-C use case trends Suggestion: Energy Savings scenario Output: Wiki pages/documents, sequence diagrams Feedback to O-RAN WG as needed Explore feasibility of simple interworking

  11. Background presentations

  12. ONAP/OSC Synergy Discussion presented in RSAC in March 2023 ONAP and O-RAN SC John Keeney, Seshu Mudiganti, Timo Perala, N. K. Shankar, Martin Skorupski March 21, 2023

  13. Summary & Objective O-RAN SC and ONAP have common areas of interest This is a good time to improve collaboration and synergy Objective of this presentation: Provide a high-level overview List common areas of interest Highlight areas of ongoing good collaboration Identify new areas with potential synergy Discussion priorities, next steps

  14. O-RAN SC and ONAP O-RAN Software Community (OSC) (https://o-ran-sc.org/ ) Part of Linux Foundation (LF) 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. ONAP (https://www.onap.org/ ) Part of Linux Foundation (LF) and Linux Foundation Networking (LFN) ONAP is a comprehensive platform for orchestration, management, and automation of network and edge computing services for network operators, cloud providers, and enterprises. Real-time, policy-driven orchestration and automation of physical and virtual network functions enables rapid automation of new services and complete lifecycle management critical for 5G and next-generation networks ONAP work is directly relevant to anything related to O-RAN SMO (Service Management and Orchestration)

  15. Service Management and Orchestration functions of SMO have strong overlap with ONAP Operators are using ONAP components for SMO This figure is from early days of O-RAN (~2020/21) using ONAP concepts (e.g., DCAE, SO, Policy, OOF ..) Recently posted by Alex Choi in article about importance about SMO (around March 9, 2023) (https://www.linkedin.com/posts/alex-jinsung-choi-48a8b61_oran-openran-oranalliance-activity-7039638269231263744-3Lqj?utm_source=share&utm_medium=member_desktop )

  16. Southbound interfaces from SMO to RAN: Specified by O-RAN ONAP projects have goal to align with O-RAN specs Figure 5.1-1: High Level Architecture of O-RAN (From O-RAN.WG1.OAD-R003-v08.00)

  17. ONAP SON Use Case Example Aligned to O-RAN O1 and A1 Configuration (O1) and Policy Guidance (A1) from SMO to RAN Data Analysis, SON Algorithm SDN-R (SDN-C) SON Handler MS A1 PMS Simulated RAN (O-RAN) Policy A1 OOF SLI FM/PM to m mS A1 Policy O1 RAN-Sim Control Loop CM Notifn FM/PM DB Config Change A1 RAN App DES MS TBDMT O1 VES Coll Data Lake CU/DU O1 DMI CM update to CPS DB FM, PM, CM Info from RAN NCMP DMaaP REST API CPS DB O1 A1 Public

  18. O-RAN WG1 ATG Decoupled SMO TR will show separation of SMO functionalities Ongoing work Service Based Architecture (SBA) SMO Functions (SMOF) SMO Services (SMOS) Relevant to ONAP and OSC design choices Figure 4.1-3: SBA representation of the documented SMO services in July 2022 specifications (From O-RAN WG1 Decouple SMO Architecture TR v01.00) Editor s Note: 1) The naming of the interfaces is to be further analyzed and refined in section 5 and 6. 2) The figure needs to be reviewed with WG2 for non-RT RIC architecture part, so it might be further updated if needed, as per latest agreed version with WG2. 3) Though the figure does not explicitly illustrate, an objective would be to represent a common set of possible abstracted SMOSs across SMOFs. For example, it would be desirable to represent a common set of SMOSs for FM to query and acknowledge Faults, as well as an associated common information model for fault LCM, irrespective of whether that Fault originates in the O-Cloud Resources Management and Orchestration Services SMOF or the RAN NF OAM Services SMOF.

  19. ONAP/OSC Harmonization Ongoing effort among group of stakeholders seeking to find synergies Good collaboration - especially for o1/ofh-mp, oam, sim, non-rt-ric, a1 Weekly calls: Wed 12 noon ET Approach: Share information, review status, seek synergy Avoid duplicate effort, re-use code, use one repo when possible Stay flexible and accommodate variations of modules New areas are coming up: O2, R1, intra-SMO interfaces, AI/ML Harmonization effort has largely been from ONAP side to work with OSC Good time to review and establish joint objectives! (ONAP TSC, OSC TOC) Operators interested in O-RAN are using ONAP components Objective today: Review and find/prioritize common areas of interest

  20. Common ONAP/OSC areas O1 and A1 O1 / OFH-MP interfaces (RAN NF OAM SMOF and SMOS) -> WG10, WG4 Good ongoing ONAP/OSC harmonization and collaboration since early days CU/DU/RU yang model development and refinement Strong support in OSC sim and ONAP RAN-Sim simulators O1 FM/PM/CM development and refinement ONAP use cases: Control loops, 5G SON, Network Slicing etc. Feedback to O-RAN WGs Would be helpful to make release timelines and versions better aligned. A1 interface (non-rt-ric related SMOF/SMOS) -> WG2, WG10 Good ongoing ONAP/OSC harmonization and collaboration since early days SDN-R/CCSDK to A1-Termination ONAP projects exploring rApp and control loop designs 5G SON use case, rAppification etc. ONAP RAN-Sim extended to provide ran-app abstraction and A1 Termination We can build on existing collaboration model

  21. Common ONAP/OSC areas O2 O-Cloud/NF orchestration and management is relatively new area for open source O2-ims (O-RAN FOCOM-related SMOF/SMOS) -> WG6 Cloud domain orchestration and management ONAP multi-VIM O2-dms (O-RAN NFO-related SMOF/SMOS) -> WG6 NF orchestration and management O-RAN WG6 has ETSI and K8s profiles ONAP NF orchestration and management more relevant for K8s (ASD) profile ? Very timely area for harmonization of open-source efforts Worthwhile to also consider synergy/sharing with other projects Nephio (LF), O-RAN OSFG, ?? Choose use cases needing co-ordination across O2-ims/O2-dms/O1 Contribute to WG1/6/10 re. interaction between FOCOM, NFO, RAN NF OAM NEW AREA NEW AREA

  22. Common ONAP/OSC areas Non-RT RIC rApp, Applications, R1 interface: WG2 (WG10, app mgmnt, WG1) ONAP use cases for applications which manage RAN (pre-rApp, pre-R1) Good amount of work in OSC Already reusing ONAP functions as part of rApp management/LCM rAppification - Ongoing effort to leverage ONAP control loops, Policy, microservices, use cases, and align with O-RAN R1 interface SMO Policy Functions -> WG2 (WG10, app mgmnt, WG1) ONAP has a Policy Enforcement Function to provide policy-based co- ordination across applications and interfaces No clear placeholder in current O-RAN SMO architecture or OSC rApp might use multiple SMO services rApp might contains Policies (ref work in ONAP ACM / App manager) Should co-ordination across rApps and interfaces be an SMO capability? NEW AREA NEW AREA

  23. Common ONAP/OSC areas Intra-SMO, Northbound Several integral ONAP components are intra SMO or northbound/external Service management, orchestration, data handling, LCM etc. part of ONAP charter End-to-end implementation can highlight design/scalability/operational issues Can be relevant to SMO southbound interfaces e.g., modelling Key takeaway: Consider reusing existing work when use cases grow to new areas Service Orchestration, Service Design, Data Handling (SO, SDC, DCAE) Higher level than Cloud Orchestration and NF Orchestration Creation and orchestration of SMO Services as well as End-to-end Services which need to be instantiated to implement a use case Inventory (resources, models, connections), Configuration database ONAP has A&AI for resource/NF/service inventory and CPS DB for NF configuration e.g., CPS DB using O-RAN yang model for CU, DU, RU config Northbound interfaces (Portal etc) Intent-based networking NEW AREA NEW AREA

  24. Common ONAP/OSC areas Overall AI/ML WG2 Previous AI/ML work is generic without specific role for Non-RT and Near-RT RIC. Implications on implementation choices for rApp, database, data exposure etc. SMO Architectural choices -> WG1 Consider SMO Functions/SMO Services approach in implementations Provide feedback to WG1 promote efficient approaches Design choices can enhance relevance of open-source efforts to industry End-to-end use cases -> WG1, OSC Consider choosing common use cases in OSC and ONAP Consider end-to-end use cases which highlight inter-operability interfaces Security WG11 Share/use best practices - interfaces, design, system implementation, code design etc Success example: Sharing of best practice for logging from ONAP to O-RAN WG11 Simulation -> OSC Ongoing effort to leverage/harmonize work in OSC sim and ONAP RAN-Sim etc. OSC oriented towards CU/DU functions, ONAP oriented towards use case NEW AREA NEW AREA

  25. OSC AIML example of interworking between OSC projects OSC AIMLFW OSC AIMLFW Update f Update for TOC or TOC Joseph Thaliath May 11th, 2023

  26. Current AIMLFW Architecture Flow Current AIMLFW Architecture Flow 1AIMLFW Non-RT RIC portal-aiml-dashboard AWMF-TM Assit rApp ML rApp USER ATHP AIHP SDK QoE SDK Kserve Adapter Kubeflow Adapter - Model Storage Training Pipeline - Feature Store IPS - Kserve Data Extraction DME TPS - Kubeflow Model storage (Leofs) Kafka Data Lake (Influx DB) O1 Termination Near-RT RIC AIMLFW AI/ML Framework AWMF AI Workflow Management Function TM Training Manager Assist xApp ML xApp TPS Training Platform Service (e.g. Kubeflow) AIHP ATHP AI Training Host Platform IPS Inference Platform Service (e.g. Kserve) Kserve Adapter SDL AIHP AI Inference Host Platform IPS - Kserve (Influx DB) 1Location of AI Training functions is not fixed and may vary according to usecase. 28

  27. AIMLFW Overview AIMLFW Overview Release H Status Diversify training data source for Training host (DME Integration testing in progress) Demo of feature group creation with DME data source Kserve adapter (Code commits in progress ) Kserve adapter for Near-RT RIC Training pipeline Enhancement (Completed) Provide sample pipelines by default AIMLFW feature enhancements (Code commits in progress ) Options for edit, retrain and delete training jobs O-RAN Alliance Alignment Release I Plan 29

  28. O O- -RAN Alliance Alignment RAN Alliance Alignment Working group/Committee Subgroup/Meetings/Topic Further Details WG2 WG2 Non-RT RIC Architecture Deriving requirements for AIMLFW AI/ML Draft meeting Monitoring ongoing AIML services discussed https://oranalliance.atlassian.net/wiki/ spaces/NonRTRIC/pages/2635628700/ AI+ML+Drafting+Meeting WG3 Near-RT RIC architecture https://oranalliance.atlassian.net/wiki/spaces/Near RTRIC/pages/2709356787/AI+ML+in+O-RAN CMCC-2023.2.6-WG3-AIML-in-O-RAN- F2F-v02.pptx CMCC-2023.04.18-WG3-CR-001-AIML Support Function-v02.docx AI/ML support consists of 4 services: Data Pipeline, Model Management, Training and Inference WG1 https://oranalliance.atlassian.net/wiki/download/a ttachments/2217476445/O-RAN-WG1.Decoupled- SMO-Architecture-TR-R003.v01.00.08.docx?api=v2 MVP-C AIML Work item https://oranalliance.atlassian.net/wiki/spac es/MVPC/pages/2594832816/MVP- C+AI+ML+for+O-RAN April 07, 2023 O-RAN Alliance - Working Group 10 30

  29. Release I Plan (Ongoing) Release I Plan (Ongoing) Following are high level topics to be considered: Model deployment options Training Pipeline abstractions Integrated install with Non-RT RIC/ Near-RT RIC/SMO Model Performance monitoring Model validation Advanced Feature selection Model services Advanced retraining options AIMLFW installation optimizations Integrate Non-RT RIC and Near-RT RIC AI/ML usecases https://jira.onap.org/browse/DCAEGEN2-3067 To prioritize and select based on brainstorming and feedback 31

  30. Open topics Open topics Access to data available at Near-RT RIC for training models in SMO. Deployment of ML model Will it be considered as xApp or rApp deployment? Will it provided as service from platform? Will model be integrated within xApp and rApp and will not require support from inference platforms? Model formats Training function inputs 32

Related


More Related Content

giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#