Report out from PTL: Stand-Up & Report Out on Blockers - next week we will start to cover this list. Are there any major items that anyone would like to raise to the TOC this week?
John KeeneyNon-RealTime RIC (RAN Intelligent Controller) (NONRTRIC)
Samsung released the KPIMON xApp under Apache 2.0 license in the Amber release. However, the team has been advised by Samsung legal team that for the KPIMON enhancement in Bronze release should use O-RAN FRAND S/W license. Since only one license is allowed within a repo and the repo name depends on the license, we request a new repo: scp/ric-app/kpimon. The committers are the same as the existing KPIMON repo.
KPIMON xAPP:
Proposed repository name: scp/ric-app/kpimon.
License: O-RAN software license
A brief description: This repo will host the source code for the KPIMON xApp. KPIMON uses E2SM (extended KPM service model) to collect information from the RAN and populate it in two name-spaces (one for cell metrics and other for UE metrics) in the RIC SDL layer.
Jack This is a little different because of the dual license. Is there someone from Samsung project?
Matti: I submitted this request as a RICApp PTL.
Jack: Will the old repo be reitired? Will contributions be split because of dual licenses? Do you know how we are going to treat the new license?
Matti: I was wondering that my self. There are contributions in Amber.
Jack: Once content is released under Apache the content stays. Until we get clarification from Samsung, the way I would categorize is we are leaving the existing repo there and archiving it. Active contributions will go to the new repo and stays in its form.
Peter Moonki Hong: Can I have clarification?
Jack: There has been a request for a new repo and the question I had was what will happen to the old repo. Typically we would archive and close the old repo and have new repo contributions.
Peter Moonki HOng: When it comes to KPI monitoring xApp we want to leave the repo as it is and archiving the repository. We will stop contributing to the old repo and start contributing the new repo for KPI monitoring of xApps.
On motion made by Peter Moonki Hong from Samsung to approve creating the new KPI monitor repo and archiving the existing one
David: Was the archived repo Apache only contributed by other than Apache?
Peter: Motivation is to change their direcition to the FRAND license.
DAvid: All the code is 100% contribution from Samsung.
Matti: It's copyright AT&T and Samsung.
David (DT): This is a lawyer question. If it all code by one company then they can release under new license but if there is code from another company then needs clarification from lawyers.
Jack: This is a new occurrence. The AT&T code would still be under the Apache license and anyone can continue to use it going forward. It is released under Apache. To create the new repo it becomes a mixed repo that has pulled code from the Apache license and made into O-RAN license. I'll have to get clarification on what that means. Action/ John Murray get clarification regarding transfer of AT&T Apache code into the new dual license repo. General rule in the past is the most restrictive license dictates the combined code follows the most restrictive license.
Lusheng: Will AT&T continue contributing to the SCP repo?
Matti: No we had the admission control xApp but the person who wrote the code has left AT&T. I don't see any reason for the Amber release repo to carry on.
Jack: It will be archived and the code is available for people to use.
Lusheng: LF does support making a repo read only (archive) to use for the KPIMON.
John Keeney: I presume it's possible for people who have branched the code can continue using?
Jack: That's why it is archived. It follows the Apache usage rules. The new repo will use the new license with the new contributions with what they pull forward from Apache under O-RAN restrictions.
On motion made by Peter Moonki Hong from Samsung to approve creating the new KPI monitor repo and archiving the existing one.
Jinri: Expresses his sincere gratitude for the hard work.
Copyright updates
Jack: Did we get an official approval of the copyright yet?
Jinri: I believe the voting results have come out. The EC has not announced.
Jack: We will get clarification on the EC call today and let everyone on this team know about the copyright permission from the O-RAN Alliance material.
Marketing of the current release (WG, LF, PR)
Bronze Release PR
Jinri: Preparation for the virtual exhibition is done. I have the website link to the virtual exhibition. There are 13 new demos uploaded to the O-RAN virtual exhibition website. Among the 13 there is one from our open source community provided by Ericsson and their partners.
Jack: Do you have to be an O-RAN member for the virtual space?
Action/William DIEGO update on the coordination with the O-RAN test group
Jack: There is an open item from for the EC to work with the test group on a discussion around the emulator/simulator needs. We need to coordinate that. I got an email but am not sure where we are in the process of meeting. We need to meet to work out a longer approach.
Action/ Jinri Huang notify the EC that the Bronze release has been voted on and approved.
Lusheng: We have a request from LF legal to have a formal process to address the use of external source code licenses? Should we use specific attributions or use a blanket statement. Action / user-d3360 add the topic of license attributions to the agenda. We want to start the pairwise testing.
Our hope is to get the lab prepped by 6-30. We want to get the KPIMON inserted. We've asked Viavi to monitor a trace file that can be delivered by the end of the month we can make the use case more sophisticated. That will lead to the Cherry release to run with a real time simulator. We are counting on Viavi.
The ML enabled traffic steering xApp I want to get a simulator of RAN topology.
rApps and xApps will detail the onflows. How do you deploy the rApp and put it in run time. We also have to think about what kind of training and the training pipeline.
How is O-CU going to talk to O-DU. Introduction of SMO in regards to LCM and pre-release R-1 interface for Cherry will drive R-1 interface for Dawn.
R-1 interface is for introducing R-Apps. It is still being discussed in O-RAN Alliance. Some of it is pre-release and not set in stone. We can drive requirements down and start the ball roling. The DU Low and HIgh P7 is going to be integrated. R-U, D-U, C-U is a challenge. We've come up with a tentative plan of what the combined configuration. We will attempt to attach one UE and have a functional RAN element working. We have to get all the parameters and time. With HARK disabled can we attach a UE? It is important to get a functional end to end stack working.
Lusheng: Do you mean simulated or physical UE?
Rittwik: O-R is a simulated but with the real RAN we want a physical UE.
Is there anything resembling and R-U stub for DU-Low?
Rittwik: Yes, there is an R-U stub that is there already. That is basic functionality.
Tracy: I think you are aware that AT&T will use SMO in stages? Is it ONAP based SMO?
Rittwik: It will be ONAP based.
I wanted to confirm the basic.
Jack: The SMO is a big box that we've thrown some pieces in. It means different things to different people. The O-RAN Alliance WG1 leaves it to implementation. The challenge for us is to decide do we create a formal SMO project or not? There could be more than one if there's enough support in the community or do we avoid that? The issue we have to figure out is to make a working thing we need to pull together all the pieces. If we wrap it with a SMO label. How do we bring it forward enough so that companies understand how to use the pieces to wrap it together and see how somebody comes out with commercial implementation. The work is useful if it ends up with multiple providers across the globe.
Tracy: The SMO are components or subset of building blocks. It has a few components some are being added and dependent on contributor support.
Jack: The SMO needs to be provided by the software community to do the work.
Tracy: AT&T is not the only operator who wants to start implementing the Phase 1 SMO and have some reassurance that phase 2 SMO can be built on phase 1 SMO.
Jack: Industry trends company's lose interest. The SMO has to support a range of functionality but also make it easy for this community to build, test, demonstrate and move the community forward. We will cue this up for the next discussion.
Jack: How are we going to approach pulling the SMO pieces together. Continue to get the O-DU moving forward. Looking at how the O-DU and O-CU work together. What about the O-RU? Those are more targeted discussions. As we mature a lot of discussions become complex.
Jinri: TSC requested we work Acumos team for near Real Time RIC development.
Jack: I will get someone from the project give a presentation here.
Report out from PTL: Stand-Up & Report Out on Blockers - next week we will start to cover this list. Are there any major items that anyone would like to raise to the TOC this week?
John KeeneyNon-RealTime RIC (RAN Intelligent Controller) (NONRTRIC)