This page will contain the schedule, agenda, and minutes summary/details for meetings of the O-RAN SC Requirements and Software Architecture Committee.
wiki page cannot be updated; David Kinsey [AT&T] has been notified on this issue.
CU image does not support O1. If O1 is needed, BM is the only option
We would like to cloud native approach. To test E2E, better to use containerized image. Release is at the end of this month.
bimo fransiscus asisiOpen RAN summit at Taipei. Topics: Open Ran and 6G; Open RAN and open source; Speed up the SMO decoupled project. Use OSC Taiwan as the implementation testbed; Energy savings use cases have been demonstrated; Viavi RIC tester.
Need to wrap near-RT RIC and non-RT RIC and SMO on top of O-Cloud for OSC Taiwan lab
peng Lu Intel is waiting for Prof Rathi's code base changes on xFAPI related to Flex RAN ODU low; Legal clearance has been obtained; Still waiting for detailed information on how to access the code;
OSC Taiwan lab can potentially obtain the code (binary) from Netweb;
Peng Lu (Intel) - Update from 3rd party company, Netweb - Works with Prof. Rathi integrating latest code base xFAPI - Sindhu from Intel to obtain license for O-DULOW FlexRAN from Netweb - Netweb got authorization from Intel - No info from Netweb yet - Can Intel authorize NTUST directly? - Due to legal issues, pls obtain license from Netweb
NTUST labs (Bimo, Prof. Ray) - Prepare for Open RAN summit after F2F in Taipei demo
Ankit - Prepare for release doc and final changes - Try to complete in 2 weeks time - O-CU support O1 and E2 i/f? - Docs are available from Radisys website - Bimo looking for support of E2 and O1 - Not written in tech doc; is it possible to get support from Radisys? - Ankit will check and get back to Prof. Ray
Prof. Rathi - xFAPI P5 is working - P7 msg are being tested. errors ar ebeing resolved - will be able to connect OAI with ODU high soon after P7 success - Can you upload some src code if possible? Request from NTUST - How to modify ODU - high? - No need to change ODU-high since WLS is supported - Planning to release doc soon
TOC mtg - mentioned about add detail on FAPI for WG8 - standardize shared memory architecture - David K is coordinating a session in the F2F?
Still waiting for final legal clearance from Intel. Technical issues have been resolved, currently it is more of a business issue/process to finalize the legal clearance.
Also waiting for access from Prof. Rathi pending presentation at the TOC which was cancelled last week. Expect that to occur this week.
In the architecture presented last week the WLS code is part of the ODULOW project and is used by ODUHIGH. Since the xFAPI is below the WLS layer it should be part of ODULOW even though it provides implementation access to current ODULOW base or the OAI L1 or potentially other L1 implementations.
Plan to request a WG8 session with OSC/O-RAN members to discuss Interoperability testing of different L1 implementations using the FAPI interface, which may include the transport protocols (WLS) interfaces.
@ankit OAI development for P5 messages for FAPI requested Prof. Rathi to share xFAPI code to O-DU high team
Prof. Rathi provided an overview of xFAPI; had discussions with Intel on how to release xFAPI code to OSC one more week before sharing code created a blueprint on how to use xFAPI for integration xFAPI is already on K8s cloud native architecture milestone: try to release xFAPI end of month
discussions with WG8 starting to introduce xFAPI to O-RAN
@bimo requested license extension from Radisys for CU to share with NTUST Ankit to check with Ganesh and get back to Bimo
@johnkeeney NONRTRIC - trying to tidy up svc mgr for release timeline
@martin OAM - implemented and tested published YANG model from Nov train and looking into March train
@alexstancu SIM - AI/ML telefonica dataset analyzing it
SMO - K8s profile implementation is going well, Tacker update FM/PM discussions are in progress, sequence diagrams started
Ankit Barve Requesting Prof. Rathi's xFAPI code base to be uploaded to OSC repo
peng Lu Intel still having conversations re Flex ran version for OSC going forward (deprecate old version and move to a new version
Ray-Guang Cheng Requesting Intel to provide resources to support the O-DU low / O-DU high integration work and also with xFAPI integration in NTUST OSC lab. peng Lu is looking to support this work in NTUST lab.
Need plan from ODULOW (peng Lu ) on how the FAPI update from the x-FAPI (Prof Vipin) will be incorporated so we can establish some timeline expectations.
lab status of NTUST 1. @ankit @ganesh the current O-CU binary is DPDK based, and we need a socket-based. The socket-based release needs to be tested then it will be released and the license will be provided at the same time. Ankit Barve is assisting.
lab status of NTUST 1. @ankit @ganesh pls provide license extension of Radisys CU to NTUST 2. raise this issue in the TOC re license renewal 3. ODU high and low integration contact Prof. Vipin Rathi 4. OAI and ODU high status - what is the status? 5. NTUST - odu high and low integration decided to postpone mtg with Prof. Rathi, he made some changes to flex ran code 22.07 version Intel (@Penglu) is going to evaluate this code, in the mean time two options - continue to support the old release - wait to use Prof Vipin's codebase for the new version NTUST may also need some NDA 5. near-RT RIC - found some issue of I rel deployment - CI/CD pairwise testing issue needs to be addressed (@JamesLi) - E2SM CCC code base is not updated or missing - G rel K8s v1.22 - already deprecated, need to move to v1.28 - Needs to update the helm chart - @Bimo to send email to PTL of near-RT RIC
ODULOW has discussed progress with Prof. Vipin Rathi. It seems that there are some changes to the FlexRAN code. ODULOW believes there is some ability to use his FAPI changes into the ODULOW base and they will be collaborating with Prof Rathi to incorporate those. We then should be able to move away from the Release "F" baseline we have been using.
OSC Taiwan Lab still waiting on Radisys to renew the OCU License so that we can continue to use the binaries in the end-to-end service path.
Integration: Ankit Barvearranging call to test with Intel OAI testing call is in progress Almost done with O-DU high release development features
Ashwini (Intel) - repetitive messages observed on Uplane UL Daniel from Viavi has proposed a testing call today
Prof. Ray (NTUST) has linked Prof. Vipin Rathi from Delhi university They have successfully integrated 23.07 version flexran with OSC DU-high, connected to commercial RU plans to move 23.11 version any more info on FAPI interface? Did they write their own FAPI? Ashwini is sending an email to Prof. Rathi for clarifications
Update on TUWU fransiscus bimo problem in ODULOW but there is also a problem in RUSIM. Working on closing the RUSIM while the resource is available. Then need to work on OSC ODULOW.
ODULOW is working on a plan on how to upgrade to a newer release. Intel is working this. It is hard to get developers/students to sign up for work on an outdated version.
ODULOW peng Lu will look into being able to match the Viavi configuration for OAI ODULOW. This will allow easier transitions from one implementation to another.
Ankit Barve(O-DU high) dynamic uncompressed mode - Intel to respond on header length issue OAI L1 L2 data transfer OAI making NFAPI msg implementation changes WLS shared memory OSC has provided the changes 2 months for changes to be implemented multiple UE per slot almost done XML based config of ODU-High
bimo fransiscus asisiRay-Guang Cheng (NTUST lab) No updates from Intel raise to Ubuntu based version for basic testing Prof Ray or Ankit to raise this issue Is it possible to add the FAPI i/f to the WG8 spec? it is not clear which version of FAPI i/f is supported in WG8 new version of FAPI can support MIMO
Radisys O-CU O1 and E2 and E2SM versions? Free 5GC is connectd with Radisys CU in NTUST lab PDU session established between O-DU high and Radisys O-CU NTUST lab to send Ankit O-CU config multi UE testing error - No HARQ (being worked on separate branch) A1 msg interactions being tested in NTUST lab
Martin SkorupskiAlex Stancu Martin/Alex OAM/SIM working on A1 simulator for latest spec ONES summit feedback on YANG compliance is delayed transition from WG5 to WG10 fixed OAM controller on netconf side porting back to previous releases to ONAP SDN-R working on deployment in NTUST lab
John Keeney (Ericsson EST) Non-RT RIC continuing on rApp mgr svc exposure 1st version available uses a service registry registration and discovery i/f uses a API g/w A1 policy starting to see some specs for WG2 cleanup of existing API with acls and documentation getting support requests from HCL, Fujitsu, Samsung, universities looking for help from INT project (James Li ) - for a unified deployment script - proper integration tests for A1 policy controller and A1 mediator traveling to ONES summit
James Li , INT project update pairwise testing for A1 mediator ONES mtg should get started for labs updates
POWDER looking for joint news publication which will help POWDER. James providing information on how OSC uses POWDER for Integration. James might eventually bring such a news release to the TSC for approval.
AIML ES Data set available (TIM), Viavi data is semi-private, password protect the file. A procedure needs to be in place for users to request access. Who approves this but it should be a “written” response to provide access traceability. Another option is to have the data in the labs but not in a repo/nexus. Access to the lab would provide access to the data. We need to bring to TOC to ask Viavi what procedure we should use. Update on ODUHIGH, ODUHIGH now working again with ODULOW, tomorrow working ODUHIGH+ODULOW+TM500. SIM • Simulators to align with latest YANG models. No feature requests. OAM • Looking for November Train specifications for testing. Already noticing schema version mismatches. NONRTRIC • rApp Management/Execution • Some work on Service Exposure INT • More Pairwise testing
The data is parsed, meaning we pruned the voice and SMS usage, keeping only the Internet traffic. The values themselves for the usage are normalised to a value known only to TIM (assuring some anonymisation).
ES MVP was presented by Awn the Rapporteur. There are specific details in the feature for mapping progress and alignment. Suggestion is for PTLs to review the material and identify their alignment for F2F reporting and updates to the TSC.
Look to Project documentation
Discussion for "J" Planning regarding Energy Savings MVP
rApp
"I" ES rApp targeting Cell On/Off
xApp
"J" ES xApp targeting TBD
Near-Rt RIC
Integration for MME and Inference deployments
NonRT RIC
New Performance KPI/Metrics for ES
SMO
New Performance KPI/Metrics for ES
OAM
New Performance KPI/Metrics for ES
AIML
MME for Near-RT RIC and Inference deployments
ODU-HIGH
New Performance KPI/Metrics for ES
ODU-LOW
Need to check with Intel for potential gap for ES
INT
Need individual projects to develop pairwise Xtest
INT will work with SIM for data for simulated/emulated part of environment
INT will work with labs for setting up E2E environment
INF
Initial steps towards ES in "J", internal to O-Cloud
External exposure for ES in O-Cloud to SMO targeted for "K"
SIM
New Performance KPI/Metrics for ES
New E2SM for Energy Savings
Labs
Look to Powder integration in "J", possibly integrating with srsRAN to open other opportunities for radio integration
DOCS
no new features
ES data sets,Ultan.Kelly to provide recreated synthetic data set for ES; mtg with bimo fransiscus asisi to discuss the details week of Sept 28th
NYCU deployed ArgoCD for a SMO CI/CD environment
briefly summarized their work on the O-Cloud, SMO, and OSC Component deployment as follows for your reference: 1. O-Cloud (Kubernetes): Have built a multi-node O-Cloud on bare-metal and virtual machines, with and without leveraging StarlingX. 2. OSC ONAP-based SMO (OSC IT/DEP Project): Have also deployed OSC ONAP-based SMO on top of the multi-node O-Cloud, again with and without StarlingX. 3. O-RAN Deployment Container: To facilitate and speed up the deployment of ONAP-based SMO, we made a portable container image that contains necessity scripts, ansible books, and prebuilt Helm charts for ONAP-based SMO deployment. 4. CD for ONAP-based SMO deployment: Currently working on Argo CD GitOps for ONAP-based SMO deployment.
1. O-Cloud: per your demo at the RSAC meeting a few weeks back, it’s a manual process to provision/install a multi-node O-Cloud. Is there a way to automate the process for a single-node or multi-node O-Cloud?
What is the target environment?
VM or physical servers
With/without Starlingx (more hard to automate)
Should we recreate an O-Cloud for each integration test?
2. Per my understanding, the deployment from the it/dep repository of the SMO will just include the OSC non-RT RIC, but without the OSC OAM components
OSC OAM wiki also refers to it/dep repository for Kubernetes deployment.
The OSC OAM reuses ONAP components such as O1ves, ODL, ...
The id/dep repository contains ONAP helm charts for deployment of the OSC OAM components.
3. Do you have any plan to commit the code as part of the “O-RAN Deployment Container” to OSC to facilitate and speed up the deployment of SMO as suggested? What is it different from the current deployment mechanism as part of the it/dep repo?
The “O-RAN Deployment Container” is a walkaround solution to reduce helm chart building time.
The better one is that OSC hosts its helm chart repository on OSC Nexus.
4. What’s the granularity of your existing CD for ONAP-based SMO deployment?
We use Argo CD to deploy it/dep ONAP-based SMO with helm charts on Kubernetes.
The ONAP helm chart is too large for the helm, so ONAP provides a script to solve this problem.
It is not straightforward to integrate Argo CD and this script to deploy ONAP components (OAM), we will present the details in the RSAC meeting
5. It’s desired to set up an O-Cloud and then SMO on top of it as the CI/CD base for further OSC components onboarding. Do you happen to see that your existing work can serve this purpose for OSC?
CI: Should we rebuild the O-Cloud and the SMO for each integration test
Shankar needs to understand what the data set is for E2E flow.
Need UL and DL throughput and ingress and egress from a cell
with an overlapping cell coverage area.
Basic algorithm is predicting when to turn cells off and on so as not to cause too few resources to handle the capacity while saving energy when capacity is not needed.
Switching Cell On/Off
Doesn't actually turn off or on, but puts the cell to sleep and then "wakes" it up.
When RU is put to sleep the corresponding DU infrastructure can utilize p-state and c-state policies to limit the power usage of the DU.
RICAPP nor NON-RT RIC have resources identified to create rApp. We might look to AIML to see if they have resources available.
TUWU may also contribute to AIML algorithm which should be able to be done separate from the rApp implementation.
Can look at Publicly available TIM dataset for current values and initial approach analysis.
We can use ARM if it is built as an O-Cloud then the SMO should be able to deploy to it.
INF project needs to assess viability
Energy Savings
ONF - Proposal #1 use Viavi to synthesize the data
Requires OSC $ which are not available
ONF - Proposal #2 use RANSIM and synthesize the data
How can we generate
Alex Stancu Will look at available TIM Snapshot data sets to find if there is one. Rittwik Jana We just need UL and DL throughput data per cell.
Martin Skorupski 3GPP data Cells have sectors. Is our data One sector, One Frequency, per cell. Or should we plan ahead for Frequency management. Rittwik Jana Each "Site" has two frequencies. 5 sectors, 1 coverage, 4 capacity which can be turned down when capacity is not required.
Prof Ray
They are looking at using Viavi RICTest to generate some data. They may have a topology that can be used. Will report back next week.
OSC Taiwan Lab Update:
We pushed slice-enabled implementation to the ODU repo.
Shared the system design and guideline of #1 to ODU PTL via email
TM500 power installation still ongoing
O-Cloud has an issue with refusing to establish SSH connection. Will discuss with Jackie(WR) but he is currently OOO
Defined questions to be answered by each lab opening an interconnect. 1. The bandwidth required to interconnect the three Labs2. Do we want to use IPVPN?3. One or multiple VLAN is required?4. ISP used for each Lab?5. What protocol gateway?
AP David Kinsey [AT&T]: Draft initial interconnect requirements. Discussion on 8/1 next RSAC call.
Preparation for I-Release
I planning
OSC + OAI interactions
n/w lab interconnection (Phase 1) - Bedminster NJ lab operation mid Oct - Taiwan lab, TM500 O-DU integration, OAI-CU with OSC DU still ongoing integration test - CA lab - COSMOS lab OTIC (Phase 2, after I rel.) - POWDER lab OTIC+PAWR... - Northeastern uni lab (Coliseum)
need an IP assignment network plan (OAM, CP, UP are internal to each lab currently; Can we interconnect all planes across all labs?) - David/Rich/Ajay Bedminster lab rep - Bimo, Taiwan lab rep - James Li CA lab rep - Martin/Ivan COSMOS lab rep - [AI] bimo fransiscus asisi Bimo to come up with rough n./w plan - stand up an e2e phone/data call in 1 lab
timeline - something e2e integrated up by end of Sept
use cases 1. e2e orchestration NF onboarding with placement/homing in 1 lab, across multiple labs [Seshu] - onbaoarding IMS, deploy DMS, O1 health and registration of CNF, how to add AI/ML SMOF?, - Radisys O-CU CNF image as an example NF (SMO orchestrated); TM-500 not needed - gaps: - risk: need to get candidates inside OSC and outside orgs [ONAP,...] 2. Document Disaggregated SMO draft call flows identified from OSC as a contribution to WG1 [Shankar] - focus on flows and interactions between SMOFs (e.g., with energy savings) - what dependencies do we have? 3. Policy SMOS/F? [defer to J rel.] - bring policy out to a centralized place - A1 policy vs SMO policy 4. Can we discuss with Sunil on an energy savings app? [Sunil, Start in I], Tue RICAPP call - carrier RF on/off intermittent - cloud energy savings (C/P state reconfiguration) 5. Establish an E2E call session with OSC components [James] - what is needed to stand up an e2e data session? UE -> RAN -> CORE -> OTT
For demos in Osaka (in case of pre-recorded videos) I would like to share a few suggestions aiming to improve the delivery of messages to the audience:
Make the videos rather short (2-3’) – attendees to F2F meetings may not want to spend long time in front of a screen, as the F2F agenda is very busy
If possible, include schemes/charts to visualize the demo scope in an easy way
Make the video in high quality to look good at a large screen from close look
Display each demo title clearly during the whole video (someone who comes in the middle of a demo could still understand what it is)
If possible, provide captions for the voiceover (or at least a word document with the voiceover text for postprocessing) – the sound of the screens may not be possible to be too loud and reading subtitles could help understanding
Would any postprocessing be required from O-RAN Office side, for the Osaka demo videos?
Note: For the demos that were shown in Madrid (Oct 2022), O-RAN office arranged adding demo titles to the screen and some further postprocessing to allow playing the videos in a loop. In case any assistance needed for Osaka demos, we would need the videos in advance – the postprocessing takes some days…
General note: If I recall the way OSC demos were presented in Madrid, Oct 2022, in my opinion – frankly – the content of the demos wasn’t easily digestible in the way it was presented. The videos were long (10+ minutes), rather poor quality, sound was hard to understand (and couldn’t be played loud to avoid disturbing the networking space). As O-RAN office could observe, not that many people looked at them. Hence the above suggestions to improve the presentation and delivery of desired messages.
Demo/Discussion of CAPIF-based Service registry/discovery. The 3GPP CAPIF approach seems to be gaining traction as a basis for R1-SME, and we would like to show the progress we have made with our implementation. Since R1-SME (and SME in general) cross cuts several SMO-related projects
Demonstrate ASD-based LCM for CNFs using ONAP CNFM. The function, originally from the ONAP SO project, is used in standalone mode without the need for the rest of SO, A&AI or SDC. While this demo is quite SMO/NFO-specific I think it would also be of interest to the wider OSC community
The agenda of this slides is to give a brief intro to Nephio.
Explain what and how K8s operator works.
Use of a K8s operator in the automation through Gitops.
Slide 20, depicts the different ways of integrating the operator with other open source solutions, this is NOT to promote using all of them together, but to show how and what part of the solution is being tackled by each of them and a possible way to re-use the O-cloud operator across them.
NTUST Lab: Ankit was unclear if lab was reverted. Prof Ray indicates the server is the same they have been using. Bimo there was some work for integration to real RU but now is connected to the TM500. Ankit to verify if change corrects the blocking issue.
O-DULOW no plan to upgrade to newer version. Willing to provide bug fixes as needed.
ONAP projects with OSC synergies not yet available. Work is in progress.
SMO Function Flows. Discussed current work for O2IMS Cloud Registration and Discovery flow and Homing Flow.
AI: Ankit Barve requesting NTUST lab to revert to old lab so that O-DU high testing can progress. Integration testing is stalled for the moment due to ATT lab's unavailability. Dennis to ask Prof Ray and Bimo (bimo fransiscus asisi) and report back to RSAC.
AI: Ankit Barve requesting O-DU Low PTL (Lvfarias (Deactivated)) for new release s/w version 22. O-DU high is currently using version 21 of O-DU low s/w.
2/8/2023
Timo Perala (ONAP requirements co-chair) provided an update on ONAP projects that are related to OSC.
"H" Release Planning - Are we ready for O-RAN F2F?
AIML
DME Integration
Training pipeline Enhancement
SMO - InfluxDB Integration
KServe adapter
Deployments to Near-RT RIC
Suggest Deployments to Non-RT RIC as well
O-DU HIgh
End-to-End Integration
TDD/MU1/100Mhz
FDD/MU0/20Mhz
Feature Enhancement - Stub-based Testing
Alignment WG-8 AAD Specification
Inter CU Handover Support
E2 Interface enhancement
TACKER
Need to find out how to fill in the SMO Gaps
OSC/ONAP
Trying to establish more structure around the relationship.
NTUST
Upcoming Open RAN Workshop
12/28/22
Cancelled for Holidays
12/20/22
Cancelled for Holidays
12/14/22
Blockers for Release "G"
Tacker (SMO) - Ready
AI/ML - Ready
O-DUHIGH - Move blockers to "H" Backlog
Some Cleanup is needed, this will drop the Lines of Code this will be done during the maintenance release. This will not result in any functional change.
"H" Activities
OSC - OAI Integration
Possible Options: End-to-End using OSC RAN and OAI Mobile Core can be incremental in where the workloads execute. Target would be to use O-Cloud? Goal: End-to-End 5G Open Source Network
Possible Options: OSC SMO Integration with OAI Elements Goal: Would standard manageability
Possible Options: RIC-RICAPP Portability OSC RIC with OAI RICAPPs, and vice-verse Goal: xApp Portability
Step 1: What would it take for SMO to deploy in a (OSC or OAI) lab a OAI CN element. Goal: Explore the gap between OAI NF and OSC Infrastructure/SMO.
OSC - ONF Integration
Possible Options: RIC-RICAPP Portability OSC RIC with OAI RICAPPs, and vice-verse Goal: xApp Portability
Tacker "G" Update
Supporting 02DMS-ETSI looks like part of Cloud
Can be configured with K8s API which would be like a consumer of the O2DMS-K8s and therefore deployed as part of the SMO
For "H" we need new SMO functions for Homing, Inventory, and NFO. These can be minimal in which ASD support by Tacker would consume the O2DMS.
Need to work out how Tacker for ETSI as a O2DMS-ETSI is registered with SMO, vs Tacker as a NFO extension, uses the O2DMS-ETSI. Could NFO then just use the passed Tacker instance as its orchestration end point?
12/7/22
12/6/22
SMO/OAM/AI-ML/NonRT RIC/O-Cloud Integration for Release H
No RSAC calls in 2022 after the 12/14 meeting.
Focus of "H" will be "SMO Integration" to be further discussed on 12/7/22 RSAC after the SMO project meeting.
NFs to work on packaging and PNF/CNF Registration
SMO Blueprints (SMO/OAM/Non-RT RIC/AIML)
INF to support VMs for SMO components
Lab O-Cloud Build-out to move off of Lab OpenStack VMs
12/5/22
Release H Planning
O-DU
Lab Status
Update on OSC US East Lab Network update
11/30/22
Release H Planning
SMO
Tacker Capability - SOL001 and SOL003 (VM/CNF)
"F" Tacker integrated with CISM
"G" Tacker integrated with VIM
"H" Tacker integrated with OAM (Packaging)
ETSI NFV first
K8s second
Extend to support ASD
FM/PM requires O-RAN WG6 specification
Need Contributions outside of Tacker for:
Cloud Registration (FOCOM)
Cloud Inventory (FOCOM)
Homing
INF
Do we need OpenStack support for SMO/Tacker deployments via the O-Cloud?
AI/ML
Interface prototyping
AI/ML to DME?
What is the data interface for xApps
Integrated Installs
Lab Planning
David to get with Rich for server network interface to support OAM, Control, and User Plane connections. Then configure Core Simulator for Control and User Plane network connections.
Next week video submission 10/11/22 deadline to RSAC https://lf-o-ran-sc.atlassian.net/wiki/display/RSAC/Contributions SMO - O-DU and SMO video (Mahesh) OAM, SIM - Martin, video for O1 notify PNF registration, 3GPP alarms, WG4 and WG10 (Martin, Alex) Integration - James to update the current video AI/ML framework - Joseph to show the dashboard and initial training flow video O-DU - O-Du setup and handover video (10 min video Ankit) Non-RT RIC - prepare a short presentation (Status update by John K) Near-RT RIC - 30 min video (Thoralf) INF - O-Cloud ?? send email to Jackie
- H planning SMO and O2 integration TAacker vs K8s native, both DMS available AOSX, AODX, AODX+ selection attribute in DMS 5G super blueprint OAI ?? Can only run in Taiwan lab (Academia) AI/ML framework and SMO flows Where does AIML f/w derive its data from (training data)? SMO -> R1 -> DME -> O1 -> AI/ML Non-RT RIC R1 implementation and rApp mgmt, start enforcing the use of R1 i/f SME module rApp LCM enforcement DME will have examples of the use of PM jobs over R1 (Streamed and file based)
OAM - Received in e-mail - In project will add to Release
SIM - In project will add to Release
AI/ML
"G" Standalone, possible RICAPP deliverable too
"H" begin cross-project integrations
Lab Status
US WEST
AI/ML Project Proposal
7/19/22 9PM Eastern
Release "G" Feature Planning
ODUHIGH
End to End Integration support (Spillover from previous releases) 1.TDD/Mu1/100MHz 2.FDD/Mu0/20MHz *
Feature verification (Spillover from previous releases)
Closed-Loop Automation
Link Failure Detection and Recovery
Slicing PM Reporting and PRB Reservation
16QAM and 64 QAM
Feature Development 1. Implementation of Discontinuous Reception (DRX) 2. Inter CU Handover support 3. Aligning all modules and interfaces to latest specifications
Question to INT for Health Check requirement, request parameters and expected results.
It has integration touch points with several projects
inside one may cause neglecting others (NonRTRIC, RICAPP, RICPLT)
Clear boundaries need to be defined to ensure non-overlapping scope.
Propose separate project - Avinash will work project description containing details articulated by John-Paul and Thoralf:
John-Paul Lane: If we decide the AI/ML proposal should be in its own dedicated project, we need a project proposal which TOC can review and vote on. As John Keeney (Ericsson EST) has pointed out, understanding scope of the project, its ambition and how it interacts with other projects is key input to the proposal.
Thoralf Czichy : in Order to define the scope in more detail…
(1) discuss data architecture (data flows)
(2) overlap in model manegement and r/xApp LCM
(3) define interfaces with existing projects
(4) define an example set of r/xApps that are being developed in parallel as a proof of concept
From John-Paul Lane: Some pointers to creating a new project proposal are included here Seed Code Contribution/ New Project Proposal Process (DRAFT) Also, it is interesting that there is an attempt to define when a new project can / should be created. There are examples of new project proposals which have been presented to TOC previously. Maybe @Mahesh could share the SMO proposal? Or if there are others they could be shared too.
Scope noted as large, suggestion from other PTL was to commit to a focus initially and expand over time
Some LCM may overlap with Non-RT RIC rAPP LCM this needs to be refined such that a clear demarcation exists between the two projects
With four projects for the overall SMO one project will need to be responsible for ensuring they can all be assembled into an O-RAN SMO. Suggestion was for the SMO project to be this point but the PTL was unable to make the meeting.
Topic: Zoom1 O-RAN SC's Personal Meeting Room Date: Jun 15, 2022 08:07 AM Eastern Time (US and Canada)
Action Item: David will get with Rich to verify if 190 is connected to the O-RU or 191?
OCU deployment on O-Cloud progress (5 minutes)
Binaries have been released from Radysis.
Action Item: David will get with Bin (INF) to verify IP and availability of AIO-SX.
Action Item: Ankit will FTP to lab and work with Bin (INF) to deploy onto AIO-SX,
Release G Planning and O-RAN F2F Synch (45 minutes)
Only the ODUHIGH and INT PTLs were present. Planning was not able to occur.
ODUHIGH "F" Features were held up by lack of O-RU availability, therefore "F" Features are backlogged into "G".
INT "F" Features were held up by OTF no longer maintained and thus non-viable. Therefore "F" Features are backlogged and will have to be replanned into "G". PTL is working with LF to find out how their CI/CD Toolchain might be used. Will require participation by each PTL in "G".
Action Item: David to bring up to TOC that RSAC is only effective if PTLs participate.
DUPLEX+
Walk Ons:
Samsung proposal for AI/ML Framework project. John Keeney had to drop and Mahesh was not in attendance. We need those projects and preferable OAM and INT as well to understand how the SMO is assembled from the potential 4 projects.
Action Item: Samsung will start an e-mail thread and hope we will have a quorum to discuss either on the SMO+RSAC or the next RSAC+SMO calls.
Tacker development team still needs lab access for SMO project
Action Item: David to reach out to Rich to make sure the request didn't get missed.
5/18/22
IXR Should be ready by 5/20/22. We found a bad optic cable and are replacing it.
OTF is permanently down, we are soliciting ideas from PTLs for new test automation tooling or ideas.
INT needs each PTL to create a "Healthcheck" type of test/script in which the project can be deployed and verified as "healthy". INT will then look for interoperability across projects. This will require participation from the individual projects and is not something INT can do entirely on its own.
We identified while working towards the OTF workshop that projects sometimes assume things still work, when in fact they don't. This verifies the need for automated testing.
O-DU HIGH needs O-DU LOW to install/verify the latest build in installed in the OSC lab. David and Rittwik will reach out to ODULOW to ensure there are not any blockers.
5/10/22
OTF workshop postponed to next week.
Here is the progress in Taiwan OSC Lab (Prof. Ray):
Extension of VES Measurement Domain. Will be StdDefined in "F" Release
Started work on "F" JSON; more is still needed
Config still not baselined, critical for rAPP work
Martin will finalize HelloWorld to work for us
ODU-H is good with this
Not available
10/12/21
CR Status
On Track for First Nov O1 Meeting
Lab Status
Viavi "Demo" Equipment
IXR
PTP-GM
Slice Use
10/7/21
CR Status
Alex provided link to GNMI Flow for incorporation into CR
Integration Status
Interfaces are not defined for the closed loop Use Case
Need PM interface between O-DU-HIGH→SMO
We have a non-3GPP Plan, using VES Measurement Domain
Need PM Interface between SMO→ rAPP
TopicName: MeasurementEvent (4 Values)
Need CM Interface between rAPP → OAM
Driven by YANG of O-DU-HIGH (RESTCONF)
Need CM Interface between OAM → O-DU-HIGH
Driven by YANG of O-DU (In Discussion)
Believe we can use 3GPP in build and reference forge path but cannot tag the replicated file used for the build for the Release in order to preserve 3GPP Copyright.
3GPP
OAM/SIM will work on Best Practice for using 3GPP (forge) documents in builds/documentation without publishing as part of the release.
MCC/MNC (aka PLMN) should be same as known by Core
Will use rRMPolicyDedicatedRatio for Managed slice
PM is Average DL/UL UE Thoughtput
Collection Interval same as Reporting Interval
Reporting Interval will be every 60s
One counter for each (UL/DL) (Uint32, kbits/sec)
DRB.UEThpDI.SNSSAI
DRB.UEThpUI.SNSSAI
SLA for the Managed slice is a throughput of 1Mb/s
Initial Managed slice has PRBs with a 40% reserved/quota
The rAPP should have a configuration value for enabling and disabling the control loop to allow the test controller to identify when the SUT has a stable traffic load.
When throughput drops below the 1MB/s SLA by 10% (900Kb/s) then the rAPP increases the reserved/quota by 10%
When throughput goes above the SLA of 1MB/S by 10% (1.1MB/s) then the rAPP decreases the reserved/quota by 10%; this cannot go below the baseline slice reservation (40%)
Reviewed Slicing End-to-End call flows presented by Former user (Deleted). Need verification from Viavi on pre-configuration of Slices within Core and UE simulator to request admission to a Slice.
Reviewed VES Project to EPIC list presented by David Kinsey [AT&T], need to work on iteration and resource mapping. Need OAM, SMO, and SIM PTLs
Discussed PTP Grand Master availability in the lab. David Kinsey [AT&T] to reach out to Nokia for status on FHG and how it provides/interfaces to PTP. E-mail sent today.
Discussed using format of ODU-HIGH Release "E" plan to formulate a release plan with one for each project. David Kinsey [AT&T]to send that. E-Mail sent with proposed template. This would replace the single 9MB growing powerpoint with a per-release plan.
Meeting Held for discussion on Release "E" Disaggregated VES
Reviewed proposal and discussed options. No Conclusions yet as this was more informatory. Next Meeting will try to work on specific deliverables by project.
The attached presentation includes comments and on-going work between David Kinsey [AT&T] and Martin Skorupski which will be reviewed with the larger team at the next RSAC call.
near-RT RIC will get the O-DU ID and send the change state to "ACTIVE".
David Kinsey [AT&T]took an action to get an OTF/INT project representative for the RSAC.
3/11/21
9am EST
Meeting recording listed to the right.
Went through Release "D" Control Loop:
Alignment of DMaaP Topics across projects
Confirmed proposed YANG for O-DU is being analyzed by the O-DU team, should have an answer by next weeks call.
Confirmed Config was sent to O-RU team, ODU Team needs to know how to initiate pairwise testing
Reaching out to contributors for E2SIM modifications for Traffic Steering Use case
David Kinsey [AT&T]will Reach out to OTF team for OTF E2SIM integration at the same time
David Kinsey [AT&T] will work with Former user (Deleted) to work with Taiwan University to see how best to use them for Integration Project. They likely will not have a FHG in their environment and therefore are missing O-DU functionality for Hybrid or Hierarchical support models to the O-RU.
SMO discussion was deferred as Mahesh had another meeting commitment. Nothing major pending.
3/1/21
9 PM EST
Former user (Deleted)to share Config spreadsheet to Ken Trudgeon (O-DU--O-RU interactions
Mahesh Jethanandani Review recording for APP onboarding schema (from David K) for D rel implementation
O-DU and O-RU stub testing (Bronze maint.) (Zhimin Yuan (Deactivated) , Former user (Deleted) ); Have access to the box, waiting for Windriver to complete SW install before their SW can be installed
