Time & Location:
Meeting Detail: Times & Joining Info
Wednesdays at 16:00 UTC in Summer (DST), 17:00 UTC in Winter !
NOTE: During the "Daylight Savings Time" changeover periods (US vs Europe vs Asia) the time of the meetings may fluctuate. See the Calendar: (https://lists.o-ran-sc.org/g/main/calendar)
- Summer Daylight Savings time eventually stabilizes to: 9am PDT | 12pm EDT | 16:00 UTC | 17:00 BST | 18:00 CEST | 19:00 EEST | 21:30 IST | 00:00 CST (Thurs) | 01:00 JST (Thurs)
- Winter (non-DST) time eventually stabilizes to: 9am PST | 12pm EST | 17:00 UTC | 17:00 GMT | 18:00 CET | 19:00 EET | 22:30 IST | 01:00 CST (Thurs) | 02:00 JST (Thurs)
- (During Winter→Summer DST changeover we follow US time. Summer→Winter we follow Europe time)
Zoom Bridge : https://us02web.zoom.us/j/89069708424?pwd=aGJOZm54eTUxd0FXR0VCU1N0ejBrUT09
Joining the meeting:
- Meeting ID: 890 6970 8424
- Dial in: (Local numbers)
+1 646 558 8656 US (New York)
+49 30 5679 5800 Germany
+49 69 3807 9883 Germany
+353 1 240 8941 Ireland
+46 8 4468 2488 Sweden
+46 8 5016 3827 Sweden
+358 3 4109 2129 Finland
+358 9 7252 2471 Finland
Date
Attendees
- John Keeney
- Martin Skorupski
- Alex Stancu
- Kenny Paul
- user-4594e
- Andy Mayer
- Sorry - didn't manage to get a full attendees list for this meeting ... please add yourself
See also / co-located (ONAP/O-RAN-SC/SMO - Meeting)
- Co-located with ONAP 2021-04-14 Meeting notes (ONAP/O-RAN-SC/SMO - Meeting)
Contents:
Recording
Notes:
Housekeeping:
- Reminder from previous weeks:
- OSC SMO calls now move to its own time slot - Thursdays
- See OSC RSAC Calendar: https://wiki.o-ran-sc.org/display/RSAC/calendars
- (Note this meeting to open to anyone, including non-ORAN members)
- We will maintain this slot for ONAP Alignment, and try flag issues/question to/from SMO meetings.
- See OSC SMO Project meeting notes
OSC Project roundup:
NONRTRIC (John Keeney)
- Prototyping building blocks that might be useful in the future for rApps and R1
- Many rApps will likely contain helm charts so working on a function to do basic lifecycle management of helm charts
- A major part of R1 platform will center on service & API exposure. Experimenting with Kong.
- Working hard to increase test coverage & tidy up NONRTRIC control panel.
- Working on updating Gateway function for the Control to use.
- In ONAP: A1 Policy Management needs to maintain state.
- Implemented as persistent state storage to local storage, which can then be realaised as a K8s persistent volume for state to store/share state across k8s pods and pod restarts
- May need to use something more complicated later, e.g. DB-backed.
- Working with OSC IT/DEP and ONAP OOM teams to add these changes to deployment scripts
SIM (Alex Stancu)
- Prepared 2 docker images
- O-RU simulator with Nov train yang models
- O-DU simulator with hello-world usecase yang model
OAM (Martin Skorupski)
VES std-defined event functionality (See last week) to allow other SDOs to inject their schemas into VES body
Unlikely to be demonstrated in D Release
Updated Heloo-World usecase YANG model for O-DU. Still under discussion at RSAC/TOC level - pending reviews. Ref:
RSAC meeting (2021-04-08),
JIRA ODUHIGH_322.,
- wiki page
- O-DU team confirms ability to send PNF registration VES message and see Netconf session established.
- Request to come up a generic OAM adapter (temporary solution/workaround) to translate to O-RAN conforming interface - External to the network function.
- Still under evaluation/discussion. More to follow later.
ONAP-OSC & QA:
- Discussion about LFN 5G Super Blueprint
https://wiki.lfnetworking.org/display/LN/LFN+Demo%3A+5G+Super+Blueprint
https://wiki.lfnetworking.org/display/LN/5G+Super+Blueprint+Timeline
OSC may be involved in Phase 3.
Alot of confusion/discussion about how this could be realized
Ref also RSAC meeting 13/Mar - Recording
Some questions:
Who will do all the integration? Drive requirement?
Kenny Paul provided some additional background
Landing Page: https://www.lfnetworking.org/5g-super-blueprint/
Wiki Page: https://wiki.lfnetworking.org/x/EAADAw
Mailing List/Calendar: https://lists.lfnetworking.org/g/lfn-demo
Encourage anyone to join the bi-weekly meetings, (next Tuesday 20th @3pm UTC)
John Keeney Who's driving this? Has it resources of its own?
- Kenny Paul LFN drives, & depending on resourcing from participating projects
John Keeney Where there are multiple solutions who drives adoption/architecture decisions?Is there a big picture/goal?
Kenny Paul Multiple options exist & need further discussion. Idea to try prove just a small number (or 1) proof point from the many different options.
John Keeney Please confirm relation with US Gov & US military
Kenny Paul Ref https://usgovops.org/ops5g/ & https://www.darpa.mil/program/open-programmable-secure-5g
Open to everyone & everything is opensource. US Gov would be a consumer/user.
- Topology Modelling work ongoing in ONAP Martin Skorupski Andy Mayer
- Looking at use cases
- John Keeney Is there alignment between O-RAN Alliance & ONAP (& OSC) on this?
- Andy Mayer That's the idea, but no concrete plan yet. Still working on it
- Martin Skorupski Need multi-domain topology model - especially for FM for example - so perhaps ONAP is the best home since it's more over arching?
- Must be able to deal with & provide mapping between models & domains. Lots of work!
- Aim for Meta-model first & then support domain models & mappings etc.
- Alarm Dictionary work ongoing in ONAP Martin Skorupski
- O-DU O-RU FH Connection supervision hello-world use case ...
- Will use normal VES collector 1.9.0 from ONAP
- Plan to use DMaaP to pass events to NonRTRIC DMaaP 1.1.8
- Will see a an alarm DMaaP message with FH connection is brought down
- Netconf client will be SDNR/CCSDK.SDNC 2.3.1
- Will expose RESTCONF NBI to configure O-DU to bring FH conenction back up (Adminstrative State → Unlocked) .
- Still examining different options to implement NONRTRIC link monitor function / app. Still not completely clear yet.
- Need to work a little on helm charts for OAM/NONRTRIC/SMO environment for the use case.
- Multiple charts is probably fine - so long as all in same cluster
- Will use AdministrativeState to bring FH connection Up/Down ... probably not the exact purpose for the AdministrativeState value ... but OK for this hello-world use case.
- e.g. O-DU needs to "shut down" the FH conenction when "LOCKED" ... but this might not be "normal" real-world behavior
- O-DU should kill the conenction
- O-RU should send alarm
- user-4594e Will speak next week about CPS