ONAP SON Guilin Demo & Roadmap Collaborators
5
G
S
e
l
f
-
O
r
g
a
n
i
z
i
n
g
N
e
t
w
o
r
k
(
S
O
N
)
u
s
i
n
g
O
N
A
P
O
p
t
i
m
i
z
a
t
i
o
n
F
r
a
m
e
w
o
r
k
(
O
O
F
)
:
G
u
i
l
i
n
D
e
m
o
&
R
o
a
d
m
a
p
Collaborators : AT&T, Wipro, IBM, highstreet technologies, Tech Mahindra, Ericsson,
Nokia, Reliance Jio, Rutgers Winlab, Verizon
Presenters: N.K. Shankaranayaranan, Swaminathan S, Krishna Moorthy
Demo: Niranjana Y
Introduction to ONAP-based SON
2
RIC (non-RT)
•
OOF-SON use case has built a
foundation for ONAP/O-RAN integration
•
Radio network uses common
netconf/yang model
D
a
t
a
f
l
o
w
s
•
SDN-R to RAN: netconf-based
configuration
•
RAN to DCAE: VES format for FM
alarms, PM KPI, CM Notification
•
RAN to SDN-R: Netconf ack
Config ack
Data, FM, PM
A-1/O-1
A-1/O-1
RIC (near RT)
O-RAN Radio
Network
Config notify
•
SON
Control Loop (CL)
•
ONAP: Open-source platform, with basic
open-source code
•
Companies can use framework to add
proprietary SON solutions, including
optimization algorithms, etc.
Release Roadmap
3
•
CM-Notify
handling
•
Control Loop Co-
ordination (CLC)
first steps
•
Introduced
Adaptive SON
functionality
•
Checked in RAN-
Sim into ONAP
repo
R6 Frankfurt
•
ML-based SON –
first steps (training
done offline),
additional input
from ML-model for
PCI optimization
(based on PM
data
)
•
Preparation work
for 3GPP/O-RAN
yang model
•
O-RAN alignment
(O1 for configuration
and CM notification)
•
CPS - RAN config
data base (first
steps), cell models,
initial alignment with
3GPP NRM
•
SON coordination
(preparation/initial
steps)
•
CLC interaction
(stretch)
•
O-RAN alignment
(FM/PM over O1)
•
CPS – Full-fledged RAN
data base, full
alignment with 3GPP
NRM
•
Control Loop Co-
ordination, SON
function co-ordination
•
New SON use cases &
interaction with
Network Slicing
•
SON in context of
LCM, SON function
deployment
R7 Guilin
R8 Honolulu
R9 Istanbul & beyond
G
u
i
l
i
n
r
e
c
a
p
ONAP SON aligning with O-RAN:
Release 7 POC
DCAE
DMaaP
SON Handler
MS
OOF
SDN-R
(SDN-C)
Policy
2
1b
1c
Config Change
9
1d
1a
8
11b
FM/PM KPIs
VES
Collector
FM/PM
DB
1e
4f
FM/PM Collector
and Database
3d
[3a] 4a
12
O-RAN O1
interface
9
10
12
4a
ConfigDB
1f
CM
n
10
13
13
O-RAN O1 interface
5
7a
4c
4d
4b
4c
4e
4d
Simulated RAN
•
~2000 Cells
•
Nbrlist, PCI
•
Cells/GNBs
•
RIC
•
Yang model
O1 -
Netconf
interface
O1 -
VES
outputs
Note
: DES MS is a new MS introduced in Release 7.
•
Network yang model update based on 3GPP/O-RAN (to prepare for Rel. 8)
•
Config DB (RCDB) Rel 6
REST API
DMaaP Control Loop messages
CM-FM-PM messages from RAN
Config updated to RAN (netconf)
Interface enhancements
6
DES MS
7b
Offline-training
for ML-based
SON function
ML-based
m
New interface
11a
Key enhancements
done in Guilin release
DCAE
ML-based SON: Approach
6
•
ML training should be done
outside ONAP
– use “
offline training
”, and then onboard the ML
models on to ONAP.
-
Future enhancement can include updating the model after it is onboarded to ONAP (interface,
mechanism, etc. to be worked out)
•
SON function applying an ML model can be incorporated in OOF or DCAE. Since it is a SON
use case, possible scenarios include:
-
M
L
p
r
o
v
i
d
i
n
g
a
d
d
i
t
i
o
n
a
l
‘
i
n
p
u
t
s
’
t
o
t
h
e
S
O
N
o
p
t
i
m
i
z
a
t
i
o
n
a
l
g
o
r
i
t
h
m
i
n
O
O
F
-
ML techniques can be employed for the optimization, and consider Policy-based decision to pick from
multiple ML models
-
Detection of need for optimization (e.g., hidden neighbors)
-
Multi-step optimization, with one or more steps involving ML
-
Etc.
S
o
,
w
e
c
o
n
s
i
d
e
r
e
d
i
t
i
s
m
o
r
e
a
p
p
r
o
p
r
i
a
t
e
t
o
h
a
v
e
a
n
o
f
f
l
i
n
e
-
t
r
a
i
n
e
d
S
O
N
m
o
d
e
l
h
o
s
t
e
d
i
n
O
O
F
.
Approach
chosen in Guilin
Remarks
7
•
ML model will get invoked when OOF is invoked for PCI optimization by SON-
Handler.
•
ML sub-component will invoke DES APIs to fetch last ‘n’ PM samples (HO).
•
It is assumed that the historical PM samples are stored in the MongoDB by DL
Feeder.
•
In Guilin, the ML model will be very simple (just illustrative).
•
Beyond Guilin, we will also consider aspects such as the foll
owing
:
-
A way to “update” the model later?
-
Should we consider training/re-training also to happen inside ONAP?
-
ML used in detection of hidden neighbors, PCI collision, etc.
-
ML-based optimization
-
Other SON use cases
-
…
OOF Architecture: Guilin
8
Container/POD
Policy
Placement
Solver
Container/POD
Mini zinc
Mini Zinc
Generic Solver
API
CRUD(mzn)
solve
(model-id, data-json)
InvokeSolver
(model, data, solver_params,
timeout)
placementAPI(json)
Provides App users direct access to model repo:
•
No development needed for model changes that do not change data i/f
•
Tighter access control to model DB – better security
•
Triggers for validation when models get inserted into DB
•
Version control for models
Layered container images:
•
Allows use of base image from ONAP
•
Push common data interfaces/transforms into common base
•
Build secret sauce as
•
Models going into model repo
•
API/data enhancements built on top of base image
CRUD(mzn)
App
user
Compile time (API/Data) separated from the runtime (Gen-solver):
•
Enables common interface to generic & custom solvers
•
Allows Generic solver to scale independently (vs for each optimization)
•
Allows user to on-board models during runtime (provided data APIs remain
same)
Platform
component
App
user
Allows interfacing with
custom optimizers
App component
App
data
plugins
Platform Data APIs
pciAPI(json)
OSDF lib
base
ML model
(SON)
Model repos
Enhancement in Guilin
ML-based SON: Flows
DCAE
9
OOF
OSDF
Minizinc
SON-Handler
MS
VES Collector
DL-Feeder
Mongo DB
DES
SDN-R
Simulated RAN
Policy
Config
DB
1
2
PM data over O1
FM data over O1
4
7
3
12
13
14
Existing CL flow
New CL flow/action
New flow for use case, but
Implemented in ONAP
PM data flow (collection)
a
b
c
P
G
Offline Trained
SON ML model
5
8
9
a
b
c
•
Cells/GNBs
•
RIC
•
Yang model
O1 - Netconf
interface
O1 – VES outputs
6
REST API
DMaaP Control Loop messages
FM-PM messages from RAN
Config updated to RAN (netconf)
DB R/W
Flow details
10
Blue
– New step
Notes
1.
DES can provide last ‘n’ samples of PM
data. No additional functional impact in
DES or its APIs.
2.
The ML model will be hosted in OOF. In
Guilin release, it will be quite simple.
3.
Format of PM data reported by RAN – no
changes are foreseen in G-release.
4.
DL-feeder configuration to be considered.
ML model working
Based on HO PM data reported from the
RAN, and by looking at the trend (last ‘n’
samples), ML model shall provide a list of
cells whose PCI values shall not be changed
during PCI optimization (FixedPCI cells). This
shall be considered by Minizinc during PCI
optimization.
11
WINLAB at Rutgers University
W
I
N
L
A
B
T
e
c
h
C
e
n
t
e
r
F
a
c
i
l
i
t
y
WINLAB founded in 1989 as a collaborative
industry-university research center with
specialized focus on wireless networking
~25 faculty/staff, most from the ECE and CS
departments at Rutgers
~40-50 grad students (80% PhD, 20% MS)
•
Center’s research portfolio spans information theory, radio technology, wireless systems, mobile networks and computing
•
Extensive experimental research infrastructure including ORBIT & GENI testbeds, SDR, SDN, …
Selected as an ONAP integration and testing laboratory for North America
G
u
i
l
i
n
d
e
m
o
PCI Optimization: Pre-Guilin
DCAE
13
OOF
OSDF
Minizinc
SON-Handler
MS
VES Collector
DL-Feeder
Mongo DB
DES
SDN-R
Simulated RAN
Policy
Config
DB
1
2
PM data over O1
FM data over O1
4
3
7
8
9
PM data flow (collection)
a
P
G
a
•
Cells/GNBs
•
RIC
•
Yang model
O1 - Netconf
interface
O1 – VES outputs
REST API
DMaaP Control Loop messages
FM-PM messages from RAN
Config updated to RAN (netconf)
DB R/W
Step 2
Step 1
Step 3
Step 4
Steps illustrated in demo
Step 5
Demo Sequence: Pre-Guilin
Step 1: Modify Neighbors (Chn0005)
Modify neighbors for Chn0005
Step 1: Modify neighbors for Chn0005
Original neighbors for Chn0005
After addition of 3 neighbors
Step 2: SON-Handler MS -> OOF trigger
No “fixedPCI cells”
Step 3: Optimization Result
PCI of Chn0012 is changed
Step 4: Policy -> SDN-R (Actor)
Step 5: PCI optimization completed
Before optimization
After optimization
ML-based PCI Optimization: Guilin Demo
DCAE
21
OOF
OSDF
Minizinc
SON-Handler
MS
VES Collector
DL-Feeder
Mongo DB
DES
SDN-R
Simulated RAN
Policy
Config
DB
1
2
PM data over O1
FM data over O1
4
7
3
12
13
14
Existing CL flow
New CL flow/action
New flow for use case, but
Implemented in ONAP
PM data flow (collection)
a
b
c
P
G
Offline Trained
SON ML model
5
8
9
a
b
c
•
Cells/GNBs
•
RIC
•
Yang model
O1 - Netconf
interface
O1 – VES outputs
6
REST API
DMaaP Control Loop messages
FM-PM messages from RAN
Config updated to RAN (netconf)
DB R/W
Step 1
Step 3
Step 2
Step 4
Step 5
Step 6
Step 7
Step 8
Steps illustrated in demo
Demo Sequence: Guilin
Step 1: Generate PM data
This is to initiate PM data
generation from RAN-Sim.
In RAN-Sim, we pre-configure
that the handovers for
Chn0012 is very high.
Step 2: High Handovers for Chn0012
Handovers for Chn0012 is very high (compared to other cells)
Step 3: Modify Neighbors (Chn0005)
Modify neighbors for Chn0005
Step 3: Modify neighbors for Chn0005
Original neighbors for Chn0005
After addition of 3 neighbors
Step 4: SON-Handler MS -> OOF trigger
No “fixedPCI cells”
Step 5: OOF<->DES interaction for HO data
Step 6: Optimization Result
PCI of Chn0012 is
not
changed (fixed),
but PCI of Chn0001 is changed to
solve the confusion.
Step 7: Policy -> SDN-R (Actor)
Step 8: PCI optimization completed
Before optimization
After optimization
Recap
Solution without ML-SON
Solution with ML-SON
ML-based SON takes additional inputs (cells whose PCI
values should remain unchanged) from ML models during
PCI optimization and then performs the optimization
H
o
n
o
l
u
l
u
r
e
l
e
a
s
e
&
f
u
t
u
r
e
r
o
a
d
m
a
p
Release Roadmap
34
•
CM-Notify
handling
•
Control Loop Co-
ordination (CLC)
first steps
•
Introduced
Adaptive SON
functionality
•
Checked in RAN-
Sim into ONAP
repo
R6 Frankfurt
•
ML-based SON –
first steps (training
done offline),
additional input
from ML-model for
PCI optimization
(based on PM
data
)
•
Preparation work
for 3GPP/O-RAN
yang model
•
O-RAN alignment
(O1 for configuration
and CM notification)
•
CPS - RAN config
data base (first
steps), cell models,
initial alignment with
3GPP NRM
•
SON coordination
(preparation/initial
steps)
•
CLC interaction
(stretch)
•
O-RAN alignment
(FM/PM over O1)
•
CPS – Full-fledged RAN
data base, full
alignment with 3GPP
NRM
•
Control Loop Co-
ordination, SON
function co-ordination
•
New SON use cases &
interaction with
Network Slicing
•
SON in context of
LCM, SON function
deployment
R7 Guilin
R8 Honolulu
R9 Istanbul & beyond
Summary of Requirements
Blue
Topics for which there is commitment in R8, other topics will be taken up based on resource availability, timelines & PTL agreement.
ONAP SON aligning with O-RAN:
Release 7 POC
36
DMaaP
DCAE
SON Handler
MS
OOF
SDN-R
(SDN-C)
Policy
2
1b
1c
Config Change
9
1d
1a
8
11b
FM/PM KPIs
VES
Collector
FM/PM
DB
1e
4f
•
FM/PM Collector and Database
CL setup
3d
[3a] 4a
12
O-RAN O1
interface
9
10
12
4a
ConfigDB
1f
CM
n
10
13
13
O-RAN O1 interface
5
7a
4c
4d
4b
4c
4e
4d
Simulated RAN
•
~2000 Cells
•
Nbrlist, PCI
•
Cells/GNBs
•
RIC
•
Yang model
O1 -
Netconf
interface
O1 -
VES
outputs
Note
: DES MS is a new MS introduced in Release 7.
•
Network yang model update based on 3GPP/O-RAN (to prepare for Rel. 8)
•
CM notification msg – Rel 6 “pre-standard” msg ,Config DB (RCDB) Rel 6
REST API
DMaaP Control Loop messages
CM-FM-PM messages from RAN
Config updated to RAN (netconf)
Interface enhancements
6
DES MS
7b
Offline-
training
for ML-based
SON function
ML-based
m
New interface
11a
ONAP SON aligning with O-RAN:
Release 8 target
CL setup
Policy
DMaaP
37
DCAE
SON Handler
MS
OOF
SDN-R
(SDN-C)
2
1b
1c
Config Change
9
1d
1a
8
11b
FM/PM KPIs
VES
Collector
FM/PM
DB
1e
4f
•
FM/PM
Collector & DB
3d
3a
12
O-RAN O1
interface
9
10
12
4a
1f
CM
6
10
13
13
O-RAN O1 interface
5
7
4d
4b
4c
4e
4d
4a
Simulated RAN
•
~2000 Cells
•
Nbrlist, PCI
•
Cells/GNBs
•
RIC
•
Yang model
O1 -
Netconf
interface
O1 -
VES
outputs
•
CM via VES collector
•
CPS DB model based on O-RAN network yang model
Offline-training
for ML-based
SON function
ML-based
CM-FM-PM messages from RAN
Config updated to RAN (netconf)
REST API
DMaaP Control Loop messages
n
Interface enhancement
DES MS
7b
11a
5G use case for CPS, intention is to have an API mapper that
maps existing APIs to appropriate Xpath queries
Functional enhancement
4c
TDMT
TDMT = Template-based Data Model Transformer
CPS
Rel 8 OOF-SON dependency on
ONAP CPS and O-RAN
•
OOF-SON use case created ConfigDB in Rel 5/Rel6/Rel7 which was the seed for CPS
•
OOF-SON has a
strong dependency
on, and is an early adopter of, working instance of CPS
•
REQ: Identify/support RAN yang model aligned with O-RAN/3GPP – can be a very small sub-
graph for Rel.8. SON use case with cellid, pci, neighbor cell relation – (mostly DONE)
•
REQ: Support database API similar to existing Rel.7 ConfigDB API
-
Use a
mapper service (TDMT)
which maps the existing APIs to Xpath queries to CPS
Our understanding is this will be
available for H-release.
Yang model for R8
39
•
For Rel 5/6/7, OOF-SON used a sub-tree from Broadband Forum RAN model based on
3GPP
•
For Rel 8 of OOF-SON, we have identified a yang model based on the ORAN/3GPP (TS
28.541 Rel. 16) model for SON and Network Slicing
•
Basic ids for GNB and cell: gNBDUId, nCI etc
•
PCI property: nRPCI
•
Neighbor Relations – for PCI and ANR functions
•
SON use case has prior work (MS, OOF, SDNR, RAN-Sim) using Rel 6 APIs and model.
Non-trivial effort to map the existing API/model to the CPS-DB based on New Yang model
•
Consensus is to rely on model/api mapping (TDMT)
•
RAN-Sim will also need to be modified to support new Yang model
Yang model update has impacts in
SDN-R and RAN-Sim, and this work
may take I-release to be completed.
FM (alarms) support in
ONAP-SON
40
•
RAN-SIM sends single FM alarm message, e.g., PCI-Conflict (step 3d)
•
DCAE Collector places FM message on DMaaP (step 4d)
•
SON-Handler MS processes FM message and stores in FM/PM DB – (step 4f)
•
Goal: Release 8/9: ONAP-SON should align with ORAN model for FM
•
What is appropriate scope in ONAP to handle alarms?
-
What are the FM message formats / types as per ORAN
-
What are the assumptions for single v. repeated alarms
-
How does the SON loop determine that an alarm has been addressed?
YANG Model Tree Used for Rel. 5/6/7 OOF
PCI/ANR POC
1
•
The platform ready to support any YANG Model
1
https://gerrit.onap.org/r/gitweb?p=ccsdk/features.git;a=tree;f=sdnr/northbound/oofpcipoc/model/src/main/yang;h=5b3ef2c03cf516ba716f69076a780a95e96fadc2;hb=refs/heads/dublin
RPC
RPC
Number & List of Cells
PCI and PNF-NAME for a Cell
List of Neighbors
Netconf Notification
Network Resource Models (NRM):
3GPP 28.541 Rel 15
F
i
g
u
r
e
4
.
2
.
1
.
1
-
1
:
N
R
M
f
o
r
a
l
l
d
e
p
l
o
y
m
e
n
t
s
c
e
n
a
r
i
o
s
F
i
g
u
r
e
4
.
2
.
1
.
1
-
3
:
N
R
M
f
o
r
<
<
I
O
C
>
>
N
R
S
e
c
t
o
r
C
a
r
r
i
e
r
a
n
d
<
<
I
O
C
>
>
B
W
P
f
o
r
a
l
l
d
e
p
l
o
y
m
e
n
t
s
c
e
n
a
r
i
o
s
F
i
g
u
r
e
4
.
2
.
1
.
1
-
4
:
C
e
l
l
R
e
l
a
t
i
o
n
v
i
e
w
f
o
r
a
l
l
d
e
p
l
o
y
m
e
n
t
s
c
e
n
a
r
i
o
s
Network yang models & ONAP DB
models/API – Rel 6 & 7
DMaaP
Config Change
11
VES
Collector
1e
3a
12
ORAN O1 CM
interface
10
CM
Notification
ORAN O1 interface
4e
4a
Simulated RAN
•
~2000 Cells
•
Nbrlist, PCI
•
Cells/GNBs
•
RIC
•
Yang model
O1 -
Netconf
interface
O1 -
VES
outputs
Network
Yang
Model
Netconf
Configuratio
n
Database
•
Schema
•
API
DB-Update
Read network
configuration
“PCI” value:
BBF Yang model
lte-ran-rf-g/
phy-cell-id
“PCI” value:
ONAP Rel 4
implementation
Cell.pciValue
4b
“Data model”
used at interfaces
:
ConfigDB
RAN
•
SON-H
MS
•
OOF
7
4a
SDN-R
(SDN-C)
Config
DB
1f
1d
Model Mapping
4c
Network yang model & CPS DB
models/API – Rel 8/9
DMaaP
44
Config Change
11b
VES
Collector
1e
3a
12
ORAN O1 CM
interface
10
TDMT
CPS
-
DB
CM
Notification
ORAN O1 interface
4e
4a
Simulated RAN
•
~2000 Cells
•
Nbrlist, PCI
•
Cells/GNBs
•
RIC
•
Yang model
O1 -
Netconf
interface
O1 -
VES
outputs
Network
Yang
Model
Netconf
Configuratio
n
Database
•
Schema
•
Xpath API
DB-Update
1f
“PCI” value:
(ORAN or 3GPP
Yang model)
NRCellDU/nRPCI
“PCI” value:
ONAP Rel 8
implementation
NRCellDU/nRPCI
4b
“Data model”
used at interfaces
:
CPS DB
RAN
•
SON-H MS
•
OOF
7
SDN-R
(SDN-C)
1d
11a
4c
Maps DB API
calls to suitable
yang-based
Xpath queries
CPS overview
DCAE VES
collector
•
Data/API normalization (if
needed) happens in the
Application space
•
xNF proxy is the owner
and single point of entry
for native xNF data
•
xNF proxy interacts with
mediation/controllers and
keeps the CPS data up-
to-date
DB
CPS
<core>
xNF
Proxy
SON
normalizer
xNF
SDN
Controller
1
2
3
SON-
Handl
er MS
Data model/API normalization
OOF
Template-based
Data Model
Transformer
SON co-ordination: Stretch Goal
46
•
CLC in Policy is currently designed to co-ordinate actions AFTER
individual micro-services (components) have decided to take an
action and trigger Policy.
•
SON co-ordination involves the impact of one SON function on
another before or during the determination of action (e.g.,
optimization)
-
For example, when a cell outage is being compensated, coverage and
capacity optimization should be deferred or should take cell outage into
consideration.
•
SON co-ordination could be viewed as a platform enhancement =>
Policy and/or SO shall do the co-ordination.
N
o
t
e
:
W
e
w
i
l
l
s
t
a
r
t
w
i
t
h
i
n
i
t
i
a
l
s
t
e
p
s
w
.
r
.
t
o
S
O
N
c
o
-
o
r
d
i
n
a
t
i
o
n
,
a
c
t
u
a
l
i
m
p
l
e
m
e
n
t
a
t
i
o
n
m
a
y
h
a
p
p
e
n
b
e
y
o
n
d
R
8
.
Control Loop Co-ordination: Stretch Goal
47
•
Interaction between Target lock and CLC
•
Definition of target – PNF, VNF, cell, service, NSI, etc.
•
Queueing/de-queuing of CL messages by CLC logic
•
Separate DMaaP topic for each CL response (e.g., DCAE-CL-RSP)
We are working with Policy Team to address these enhancements.
All consequent updates in SON-Handler MS and SDN-C will be
handled by our SON use case team.
Introduction to the ONAP-based Self-Organizing Network (SON) using the Optimization Framework (OOF) in Guilin Demo & Roadmap. This technology involves SON control loop coordination, decisions optimization, and collaboration with key industry players like AT&T, Wipro, IBM, and more for the successful integration of SON functionalities. The release roadmap includes advancements towards aligning with O-RAN specifications and enhancing the SON functionality for future network deployments.
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
5G Self-Organizing Network (SON) using ONAP Optimization Framework (OOF):Guilin Demo & Roadmap Collaborators : AT&T, Wipro, IBM, highstreet technologies, Tech Mahindra, Ericsson, Nokia, Reliance Jio, Rutgers Winlab, Verizon Presenters: N.K. Shankaranayaranan, Swaminathan S, Krishna Moorthy Demo: Niranjana Y Sensitivity: Internal & Restricted
Introduction to ONAP-based SON SON Control Loop (CL) Co-ordination, Decisions (Policy) Optimization (OOF) ONAP: Open-source platform, with basic open-source code Data Collection, & Analysis (DCAE) Companies can use framework to add proprietary SON solutions, including optimization algorithms, etc. Action (SDN-R) OOF-SON use case has built a foundation for ONAP/O-RAN integration Radio network uses common netconf/yang model Control loop RIC (non-RT) Data, FM, PM Data flows SDN-R to RAN: netconf-based configuration RAN to DCAE: VES format for FM alarms, PM KPI, CM Notification RAN to SDN-R: Netconf ack A-1/O-1 RIC (near RT) A-1/O-1 Config notify Config ack O-RAN Radio Network Sensitivity: Internal & Restricted
Release Roadmap R6 Frankfurt R7 Guilin R8 Honolulu R9 Istanbul & beyond O-RAN alignment (FM/PM over O1) CPS Full-fledged RAN data base, full alignment with 3GPP NRM Control Loop Co- ordination, SON function co-ordination New SON use cases & interaction with Network Slicing SON in context of LCM, SON function deployment O-RAN alignment (O1 for configuration and CM notification) CPS - RAN config data base (first steps), cell models, initial alignment with 3GPP NRM SON coordination (preparation/initial steps) CLC interaction (stretch) CM-Notify handling Control Loop Co- ordination (CLC) first steps Introduced Adaptive SON functionality Checked in RAN- Sim into ONAP repo ML-based SON first steps (training done offline), additional input from ML-model for PCI optimization (based on PM data) Preparation work for 3GPP/O-RAN yang model Sensitivity: Internal & Restricted
Guilin recap Sensitivity: Internal & Restricted
ONAP SON aligning with O-RAN: Release 7 POC Network yang model update based on 3GPP/O-RAN (to prepare for Rel. 8) Config DB (RCDB) Rel 6 Key enhancements done in Guilin release Simulated RAN ~2000 Cells Nbrlist, PCI DMaaP 4d 12 4a 10 9 13 10 4c 12 4c 9 13 ML-based OOF O1 - Netconf interface SDN-R (SDN-C) Config Change 11b O-RAN O1 interface Policy 1d 8 6 1c SON Handler MS 2 5 1a 1b 4b 11a Cells/GNBs RIC Yang model 4e ConfigDB 7a 1f 4d 4f 7b [3a] 4a DCAE DES MS CM FM/PM DB O1 - VES outputs VES Collector 1e Offline-training for ML-based SON function O-RAN O1 interface 3d DCAE FM/PM KPIs FM/PM Collector and Database m New interface Note: DES MS is a new MS introduced in Release 7. n Interface enhancements REST API DMaaP Control Loop messages Config updated to RAN (netconf) CM-FM-PM messages from RAN Sensitivity: Internal & Restricted
ML-based SON: Approach ML training should be done outside ONAP use offline training , and then onboard the ML models on to ONAP. - Future enhancement can include updating the model after it is onboarded to ONAP (interface, mechanism, etc. to be worked out) SON function applying an ML model can be incorporated in OOF or DCAE. Since it is a SON use case, possible scenarios include: - ML providing additional inputs to the SON optimization algorithm in OOF - ML techniques can be employed for the optimization, and consider Policy-based decision to pick from multiple ML models - Detection of need for optimization (e.g., hidden neighbors) Approach chosen in Guilin - Multi-step optimization, with one or more steps involving ML - Etc. So, we considered it is more appropriate to have an offline-trained SON model hosted in OOF. Sensitivity: Internal & Restricted
Remarks ML model will get invoked when OOF is invoked for PCI optimization by SON- Handler. ML sub-component will invoke DES APIs to fetch last n PM samples (HO). It is assumed that the historical PM samples are stored in the MongoDB by DL Feeder. In Guilin, the ML model will be very simple (just illustrative). Beyond Guilin, we will also consider aspects such as the following: - A way to update the model later? - Should we consider training/re-training also to happen inside ONAP? - ML used in detection of hidden neighbors, PCI collision, etc. - ML-based optimization - Other SON use cases - Sensitivity: Internal & Restricted
OOF Architecture: Guilin Container/POD Policy Models Container/POD Container/POD Container/POD Container/POD CM APP Placement API APP-Y APP PCI APP APP-X APP Data Transform App data plugins Data transform Data transform Data transform App user data APIs OSDF lib base data APIs OSDF lib base data APIs OSDF lib base data APIs data APIs OSDF lib SDK OSDF lib base Policy solve (model-id, data-json) placementAPI(json) Allows interfacing with custom optimizers pciAPI(json) Generic Solver API Platform component Platform Data APIs CRUD(mzn) OSDF lib base App user Placement Solver Model repos PCI heuristic Solver InvokeSolver (model, data, solver_params, timeout) Mini Zinc App component Layered container images: Allows use of base image from ONAP Push common data interfaces/transforms into common base Build secret sauce as Models going into model repo API/data enhancements built on top of base image ML model (SON) Mini zinc Container/POD Container/POD Provides App users direct access to model repo: No development needed for model changes that do not change data i/f Tighter access control to model DB better security Triggers for validation when models get inserted into DB Version control for models Compile time (API/Data) separated from the runtime (Gen-solver): Enables common interface to generic & custom solvers Allows Generic solver to scale independently (vs for each optimization) Allows user to on-board models during runtime (provided data APIs remain same) Enhancement in Guilin Sensitivity: Internal & Restricted
ML-based SON: Flows a PM data flow (collection) b c 10 Minizinc Existing CL flow New CL flow/action New flow for use case, but Implemented in ONAP Config DB 4 5 9 OSDF Offline Trained SON ML model OOF 8 6 Simulated RAN O1 - Netconf interface 11 3 SON-Handler MS Cells/GNBs RIC Yang model Policy DES DL-Feeder 12 P G c 13 7 b 2 14 O1 VES outputs VES Collector Mongo DB SDN-R PM data over O1 a DCAE FM data over O1 1 DMaaP Control Loop messages REST API Config updated to RAN (netconf) DB R/W FM-PM messages from RAN Sensitivity: Internal & Restricted
Flow details Step Description ML model working Based on HO PM data reported from the RAN, and by looking at the trend (last n samples), ML model shall provide a list of cells whose PCI values shall not be changed during PCI optimization (FixedPCI cells). This shall be considered by Minizinc during PCI optimization. 1 PCI collision/confusion alarm from RAN to VES collector 2 PCI collision/confusion alarm posted on DMaaP by VES Collector 3 SON-Handler triggers OOF for PCI optimization 4 OOF (OSDF) queries ConfigDB to obtain cells, PCI and neighbor details 5 OSDF invokes the ML function for any additional inputs to the optimization 6 ML function queries DES for PM data samples from MongoDB 7 DES fetches PM data samples from MongoDB Notes 1. DES can provide last n samples of PM data. No additional functional impact in DES or its APIs. 2. The ML model will be hosted in OOF. In Guilin release, it will be quite simple. 3. Format of PM data reported by RAN no changes are foreseen in G-release. 4. DL-feeder configuration to be considered. 8 DES provides the PM data samples to ML function 9 ML function provides updated fixed PCI cell list based on the ML model 10 Optimizer is invoked along with additional inputs from ML model 11 OOF returns PCI optimization result to SON-Handler MS 12 SON-Handler MS triggers a Control Loop towards Policy 13 Policy invokes SDN-R as the actor of the CL to update PCI values 14 SDN-R sends updated PCI values to the RAN Blue New step Sensitivity: Internal & Restricted
WINLAB at Rutgers University WINLAB founded in 1989 as a collaborative industry-university research center with specialized focus on wireless networking ~25 faculty/staff, most from the ECE and CS departments at Rutgers ~40-50 grad students (80% PhD, 20% MS) WINLAB Tech Center Facility Center s research portfolio spans information theory, radio technology, wireless systems, mobile networks and computing Extensive experimental research infrastructure including ORBIT & GENI testbeds, SDR, SDN, Low Power IoT Device Massive MIMO SDR ORBIT Radio Grid Testbed GENI Rack SDN CloudLab Rack Selected as an ONAP integration and testing laboratory for North America Sensitivity: Internal & Restricted
Guilin demo Sensitivity: Internal & Restricted
PCI Optimization: Pre-Guilin a PM data flow (collection) 5 Minizinc Steps illustrated in demo Config DB 4 OSDF Step 3 OOF Step 5 Simulated RAN O1 - Netconf interface 6 3 Step 2 SON-Handler MS Cells/GNBs RIC Yang model Policy DES DL-Feeder 7 P G 8 2 Step 4 9 O1 VES outputs VES Collector Mongo DB SDN-R PM data over O1 a DCAE FM data over O1 Step 1 1 DMaaP Control Loop messages REST API Config updated to RAN (netconf) DB R/W FM-PM messages from RAN Sensitivity: Internal & Restricted
Demo Sequence: Pre-Guilin Trigger PCI alarm (collision/confusion) from RAN-SIM UI Step 1: UI Show SON-Handler MS triggering OOF Step 2: Logs Show OOF response (PCI optimization result) Step 3: Logs Show Policy triggering SDN-R (Actor) Step 4: Logs Show that the PCI optimization has solved the problem Step 5: UI Sensitivity: Internal & Restricted
Step 1: Modify Neighbors (Chn0005) Modify neighbors for Chn0005 Sensitivity: Internal & Restricted
Step 1: Modify neighbors for Chn0005 After addition of 3 neighbors Original neighbors for Chn0005 Sensitivity: Internal & Restricted
Step 2: SON-Handler MS -> OOF trigger No fixedPCI cells Sensitivity: Internal & Restricted
Step 3: Optimization Result PCI of Chn0012 is changed Sensitivity: Internal & Restricted
Step 4: Policy -> SDN-R (Actor) Sensitivity: Internal & Restricted
Step 5: PCI optimization completed Before optimization After optimization Sensitivity: Internal & Restricted
ML-based PCI Optimization: Guilin Demo a PM data flow (collection) b c 10 Minizinc Existing CL flow New CL flow/action Config DB 4 5 9 OSDF Offline Trained SON ML model New flow for use case, but Implemented in ONAP Step 6 OOF Step 8 8 6 Simulated RAN O1 - Netconf interface 11 3 Step 5 Step 4 SON-Handler MS Cells/GNBs RIC Yang model Policy DES DL-Feeder 12 P G c 13 7 b Step 7 2 14 Step 2 O1 VES outputs VES Collector Mongo DB SDN-R Step 1 PM data over O1 a DCAE FM data over O1 Step 3 1 Steps illustrated in demo DMaaP Control Loop messages REST API Config updated to RAN (netconf) DB R/W FM-PM messages from RAN Sensitivity: Internal & Restricted
Demo Sequence: Guilin Guilin enhancement Trigger PM data reporting (with high HO for some cells) Step 1: UI PM data (with high HO for 1 cell) stored in Data Lake Step 2: Logs Trigger PCI alarm (collision/confusion) from RAN-SIM UI Step 3: UI Show SON-Handler MS triggering OOF Step 4: Logs While keeping PCI unchanged for a cell with high HO OOF<->DES interaction for fetching HO data Step 5: Logs Show OOF response (PCI optimization result) Step 6: Logs Show Policy triggering SDN-R (Actor) Step 7: Logs Show that the PCI optimization has solved the problem Step 8: UI Sensitivity: Internal & Restricted
Step 1: Generate PM data This is to initiate PM data generation from RAN-Sim. In RAN-Sim, we pre-configure that the handovers for Chn0012 is very high. Sensitivity: Internal & Restricted
Step 2: High Handovers for Chn0012 Handovers for Chn0012 is very high (compared to other cells) Sensitivity: Internal & Restricted
Step 3: Modify Neighbors (Chn0005) Modify neighbors for Chn0005 Sensitivity: Internal & Restricted
Step 3: Modify neighbors for Chn0005 After addition of 3 neighbors Original neighbors for Chn0005 Sensitivity: Internal & Restricted
Step 4: SON-Handler MS -> OOF trigger No fixedPCI cells Sensitivity: Internal & Restricted
Step 5: OOF<->DES interaction for HO data Sensitivity: Internal & Restricted
Step 6: Optimization Result PCI of Chn0012 is not changed (fixed), but PCI of Chn0001 is changed to solve the confusion. Sensitivity: Internal & Restricted
Step 7: Policy -> SDN-R (Actor) Sensitivity: Internal & Restricted
Step 8: PCI optimization completed Before optimization After optimization Sensitivity: Internal & Restricted
ML-based SON takes additional inputs (cells whose PCI values should remain unchanged) from ML models during PCI optimization and then performs the optimization Recap Solution without ML-SON Solution with ML-SON Sensitivity: Internal & Restricted
Honolulu release & future roadmap Sensitivity: Internal & Restricted
Release Roadmap R6 Frankfurt R7 Guilin R8 Honolulu R9 Istanbul & beyond O-RAN alignment (FM/PM over O1) CPS Full-fledged RAN data base, full alignment with 3GPP NRM Control Loop Co- ordination, SON function co-ordination New SON use cases & interaction with Network Slicing SON in context of LCM, SON function deployment O-RAN alignment (O1 for configuration and CM notification) CPS - RAN config data base (first steps), cell models, initial alignment with 3GPP NRM SON coordination (preparation/initial steps) CLC interaction (stretch) CM-Notify handling Control Loop Co- ordination (CLC) first steps Introduced Adaptive SON functionality Checked in RAN- Sim into ONAP repo ML-based SON first steps (training done offline), additional input from ML-model for PCI optimization (based on PM data) Preparation work for 3GPP/O-RAN yang model Sensitivity: Internal & Restricted
Summary of Requirements Category Requirement Content Priority 1. Receive Configuration Management (CM) notifications over VES 2. Align with relevant aspects of O-RAN O1 interface (netconf configuration, PM and FM notifications) O-RAN alignment (VES, O1 interface) Interoperability HIGH RAN Database (CPS DB), including new RAN models (stretch goal) 1. Data models/DB schema & APIs to be generated from yang models 2. Details of cells to be stored with PNF reference in AAI 3. Modeling of RAN functions and objects (align with NRM) Functional HIGH Control Loop Coordination (CLC) extensions Platform Collaborate on CLC extensions (queueing, priority, ) (stretch goal) HIGH Functional SON co-ordination Co-ordination across SON functions initial steps MEDIUM 1. (New) SON use case based on data/KPI analysis 2. Machine Learning (ML) SON aspects in DCAE (enhancements) 3. Interaction with Network Slicing (stretch goal) 4. CLC interaction (stretch goal) SON function to evolve ONAP platform MEDIUM Functional Functional SON in the context of LCM Role of SO (e.g., new cell discovery/addition) (beyond H-release) LOW Platform SON function deployment SDC & CLAMP (for SON service/feature deployment) (beyond H-release) LOW Interoperability Real gNB interaction Interaction with real gNodeB in lab (over O1 interface) LOW Blue Topics for which there is commitment in R8, other topics will be taken up based on resource availability, timelines & PTL agreement. Sensitivity: Internal & Restricted
ONAP SON aligning with O-RAN: Release 7 POC Network yang model update based on 3GPP/O-RAN (to prepare for Rel. 8) CM notification msg Rel 6 pre-standard msg ,Config DB (RCDB) Rel 6 Simulated RAN ~2000 Cells Nbrlist, PCI DMaaP 4d 12 4a 10 9 13 10 4c 12 4c 9 13 ML-based OOF O1 - Netconf interface SDN-R (SDN-C) Config Change 11b O-RAN O1 interface Policy 1d 8 6 1c SON Handler MS 2 5 1a 1b 4b 11a Cells/GNBs RIC Yang model 4e ConfigDB 7a 1f 4d 4f 7b [3a] 4a CL setup DES MS CM FM/PM DB O1 - VES outputs VES Collector 1e Offline- training for ML-based SON function O-RAN O1 interface 3d DCAE FM/PM KPIs FM/PM Collector and Database Note: DES MS is a new MS introduced in Release 7. n m New interface Interface enhancements REST API DMaaP Control Loop messages Config updated to RAN (netconf) CM-FM-PM messages from RAN Sensitivity: Internal & Restricted
ONAP SON aligning with O-RAN: Release 8 target CM via VES collector CPS DB model based on O-RAN network yang model 5G use case for CPS, intention is to have an API mapper that maps existing APIs to appropriate Xpath queries Simulated RAN ~2000 Cells Nbrlist, PCI DMaaP 4d 10 12 4a 9 13 10 12 4c 4c 9 13 ML-based OOF O1 - Netconf interface SDN-R (SDN-C) Config Change 11b Policy 1d 1c 8 SON Handler MS 1a 2 1b 4b TDMT CPS 6 O-RAN O1 interface 11a 5 4e Cells/GNBs RIC Yang model 7 1f 4d 4f 7b 4a CL setup DES MS Offline-training for ML-based SON function FM/PM DB CM O1 - VES outputs 3a O-RAN O1 interface VES Collector 1e 3d DCAE FM/PM KPIs FM/PM Collector & DB n Functional enhancement Interface enhancement TDMT = Template-based Data Model Transformer REST API Config updated to RAN (netconf) DMaaP Control Loop messages CM-FM-PM messages from RAN Sensitivity: Internal & Restricted
Rel 8 OOF-SON dependency on ONAP CPS and O-RAN OOF-SON use case created ConfigDB in Rel 5/Rel6/Rel7 which was the seed for CPS OOF-SON has a strong dependency on, and is an early adopter of, working instance of CPS REQ: Identify/support RAN yang model aligned with O-RAN/3GPP can be a very small sub- graph for Rel.8. SON use case with cellid, pci, neighbor cell relation (mostly DONE) REQ: Support database API similar to existing Rel.7 ConfigDB API - Use a mapper service (TDMT) which maps the existing APIs to Xpath queries to CPS Dependency Mitigation Availability of O-RAN yang models. Use 3GPP TS 28.541 NRM based attribute definitions and yang from https://forge.etsi.org/rep/3GPP/SA5/data- models/tree/master/yang-models. Continue to use custom-defined CM_Notify, however, there will be no additional value for Honolulu release. Continue to use ConfigDB APIs if CPS is not ready Use Xpath queries of CPS if the mapper service is not ready Availability of CM_Notify VES Spec, and confirmation that VES Collector will be updated to receive this. CPS readiness Our understanding is this will be available for H-release. Sensitivity: Internal & Restricted
Yang model for R8 For Rel 5/6/7, OOF-SON used a sub-tree from Broadband Forum RAN model based on 3GPP For Rel 8 of OOF-SON, we have identified a yang model based on the ORAN/3GPP (TS 28.541 Rel. 16) model for SON and Network Slicing Basic ids for GNB and cell: gNBDUId, nCI etc Yang model update has impacts in SDN-R and RAN-Sim, and this work may take I-release to be completed. PCI property: nRPCI Neighbor Relations for PCI and ANR functions SON use case has prior work (MS, OOF, SDNR, RAN-Sim) using Rel 6 APIs and model. Non-trivial effort to map the existing API/model to the CPS-DB based on New Yang model Consensus is to rely on model/api mapping (TDMT) RAN-Sim will also need to be modified to support new Yang model Sensitivity: Internal & Restricted
FM (alarms) support in ONAP-SON RAN-SIM sends single FM alarm message, e.g., PCI-Conflict (step 3d) DCAE Collector places FM message on DMaaP (step 4d) SON-Handler MS processes FM message and stores in FM/PM DB (step 4f) Goal: Release 8/9: ONAP-SON should align with ORAN model for FM What is appropriate scope in ONAP to handle alarms? - What are the FM message formats / types as per ORAN - What are the assumptions for single v. repeated alarms - How does the SON loop determine that an alarm has been addressed? Sensitivity: Internal & Restricted
YANG Model Tree Used for Rel. 5/6/7 OOF PCI/ANR POC1 The platform ready to support any YANG Model Number & List of Cells PCI and PNF-NAME for a Cell List of Neighbors RPC RPC Netconf Notification 1https://gerrit.onap.org/r/gitweb?p=ccsdk/features.git;a=tree;f=sdnr/northbound/oofpcipoc/model/src/main/yang;h=5b3ef2c03cf516ba716f69076a780a95e96fadc2;hb=refs/heads/dublin Sensitivity: Internal & Restricted
Network Resource Models (NRM): 3GPP 28.541 Rel 15 Figure 4.2.1.1-1: NRM for all deployment scenarios Figure 4.2.1.1-3: NRM for <<IOC>>NRSectorCarrier and <<IOC>>BWP for all deployment scenarios Figure 4.2.1.1-4: Cell Relation view for all deployment scenarios Sensitivity: Internal & Restricted
Network yang models & ONAP DB models/API Rel 6 & 7 Data model used at interfaces: ConfigDB RAN Simulated RAN ~2000 Cells Nbrlist, PCI DMaaP Netconf Configuratio n 10 4a Read network configuration SON-H MS OOF 12 DB-Update 4c O1 - Netconf interface Config Change 11 SDN-R (SDN-C) Config DB 4b 1d 4e 7 1f Network Yang Model ORAN O1 CM interface Model Mapping Cells/GNBs RIC Yang model Database Schema API 4a PCI value: BBF Yang model lte-ran-rf-g/ phy-cell-id 3a PCI value: ONAP Rel 4 implementation Cell.pciValue O1 - VES outputs ORAN O1 interface 1e VES Collector CM Notification Sensitivity: Internal & Restricted
Network yang model & CPS DB models/API Rel 8/9 Data model used at interfaces: CPS DB RAN Maps DB API calls to suitable yang-based Xpath queries Simulated RAN ~2000 Cells Nbrlist, PCI DMaaP Netconf Configuratio n 4b 10 12 DB-Update 1f O1 - Netconf interface Config Change 11b 4c SDN-R (SDN-C) 1d SON-H MS 4e 7 TDMT 11a Network Yang Model OOF ORAN O1 CM interface CPS-DB Cells/GNBs RIC Yang model 4a PCI value: (ORAN or 3GPP Yang model) NRCellDU/nRPCI Database Schema Xpath API 3a O1 - VES outputs ORAN O1 interface 1e VES Collector CM Notification PCI value: ONAP Rel 8 implementation NRCellDU/nRPCI Sensitivity: Internal & Restricted
CPS overview SON- Handl er MS Data model/API normalization Data/API normalization (if needed) happens in the Application space xNF proxy is the owner and single point of entry for native xNF data xNF proxy interacts with mediation/controllers and keeps the CPS data up- to-date SON normalizer OOF xNF Proxy CPS <core> DB Template-based Data Model Transformer SDN DCAE VES collector Controller 1 2 3 xNF Sensitivity: Internal & Restricted
SON co-ordination: Stretch Goal CLC in Policy is currently designed to co-ordinate actions AFTER individual micro-services (components) have decided to take an action and trigger Policy. SON co-ordination involves the impact of one SON function on another before or during the determination of action (e.g., optimization) - For example, when a cell outage is being compensated, coverage and capacity optimization should be deferred or should take cell outage into consideration. SON co-ordination could be viewed as a platform enhancement => Policy and/or SO shall do the co-ordination. Note: We will start with initial steps w.r.to SON co-ordination, actual implementation may happen beyond R8. Sensitivity: Internal & Restricted
Control Loop Co-ordination: Stretch Goal Interaction between Target lock and CLC Definition of target PNF, VNF, cell, service, NSI, etc. Queueing/de-queuing of CL messages by CLC logic Separate DMaaP topic for each CL response (e.g., DCAE-CL-RSP) We are working with Policy Team to address these enhancements. All consequent updates in SON-Handler MS and SDN-C will be handled by our SON use case team. Sensitivity: Internal & Restricted
