2021 Q1 (Jan, Feb, Mar)
2021 03 31
Recording: TOC 20210331
Agenda
Call for Scribe (minutes owner): Jinri Huang (CMCC). Starting in April, David will take over the scribe role.
Roll Call & Quorum Check
*Quorum: 50% or more of total TOC voting members unless excluded due to attendance. // Manasi from Radisys attended on behalf of Ganesh. Yes, we have a quorum and can vote on activities.
Review and Agree to Minutes of Previous Meeting
Decision: For the 3/24/2021 TOC meeting minutes, Motion by Jinri, seconded by David. Motion approved by all TOC members present.
Review of Today's Agenda
Release Votes and Approval.
Rittwik: need to make clarifications on the OSC lab and report the status of the OSC lab
Copyright update
Jack: This Friday's meeting was canceled due to a religious holiday. Will pick it up in a week and continue the discussion. We made progress going through the document. We've adopted a policy to add the documentation to the existing license to deal with it all together. We still have a couple of key issues on the wording and the goal is to get this ready for the next O-RAN board meeting. There will also be an update to the O-RAN IPR Policy.
O-RAN-related business (marketing, WG interaction, TSC/EC update etc.)
Jinri: It’s confirmed the June meeting is still to be virtual. A patch of specifications has been approved by the TSC and it is now under the process of EC barrel. For MWC Barcelona there will be an industrial event on June 29th. There will also be a board meeting by the end of June. For other working groups now they are discussing the MVP process and their opinions are gradually converging from multiple players. In the EC meeting they were also continuing the discussion of MVP process. Within MVPC they are discussing the massive MIMO use case, but I don't have too many details.
Tracy: A new working group, working group 10 is established, and it's been formally approved. And this is dedicated to OAM. On O-RAN Wiki you'll see all the information, the charter and the scope of work and so on for working group 10.
Jack: Jinri, there's an action item that's with you and me on the TOC membership.
Jinri: I'm working on this, probably will be ready by tomorrow, or the day after tomorrow the latest. If we get this done within two days, then we can bring this to the next EC meeting on next Wednesday.
Jack: We're a little behind, but the action items are: a) to re-approve the current members; b) add the additional member that meets the requirements; and c)address the changes in the EC regarding Verizon's, non-participation. So we'll probably recommend a change there.
Jinri: So definitely we can bring this to EC next week. I wonder whether you want to get approval of the candidates, the new interested party, Wind River. Then we can bring this decision results to the EC together next week.
Jack: It's really the EC's decision. They approve the TOC member community makes a recommendation. We have the three recommendations which is: 1) re-approve everyone because everyone said they wanted to continue; 2)We have the new candidate who said they were interested in and they meet the requirements. And 3)Verizon has not been participating, also they've changed their EC status. We’re looking to the six operators from the EC representatives to provide their guidance on that. I also wanted to add to the agenda today which is the discussion on the alignment with ONAP.
Old business and Status of Open Action Items.
Action Point: Rittwik Jana to set up a meeting with TIFG Co-Chair.
Rittwik: I'm still trying to set that up.
Action Point: TOC members and whole community to indicate what do we really need to deliver in D- and E-releases to be successful and useful?
Rittwik: We've been busy setting up the OSC lab and we've got most of this setup. The RIC is not in the picture and that's in a separate installation. We've got the virtual machine for the CU Radisys provides. It's important to point out that there is no O1 or E2 in Radisys’ CU binary. It's a conventional CU, not an O-RAN compliant one. But we're using this CU to make sure that we can have UEs attached completely so that the full stack is actually going to get used. This is not the open source CU, which is one item that we are currently pending. The other item is the SMO. I need help from Felix to provide the IP addresses and the networking related to the SMO and the nonRT RIC that sits inside the SMO.
Tracy: Is this the SMO as currently defined within OSC, release C or D or some other flavor of SMO?
Rittwik: It’s the same what we had trialed in the C release. We've gone through three releases where we do kind of pairwise testing. In D release. we're actually trying to get the full view working. Everything needs to interconnect with each other to make sure that the full stack is actually working. That's one major accomplishment. In D release this will be the standing environment with the RIC controller. It will be essentially an environment that will be up and running with all the simulators, so everybody can just keep working on it. Another item is this need for this frontal switch. It's a special switch and we have one version of it in AT&T. We're still trying to see if we can make that work. Without that we can't get DU/RU interaction to happen.
Mahesh: I wanted to point out that O-RAN CU doesn't have an O1 interface so even if the SMO has O1 interface working, there's no way for the SMO to verify the O1 interface connectivity to the CU. In D release it leaves the near real time RIC and the DU the only two modules that we'll be able to verify. I'm not sure what the plans for the near real time RIC, whether they would be ready to the O1 interface testing in this release.
Thoralf: we didn't plan much on the O1 interface
Mahesh: so no O1
Jack: is the health check messages over O1 or something else?
Martin: it’s OAM according to the specification
Jack: So that should at least be a basic O1 there. So maybe Thoralf if you could check on that a little bit more and we cover it next week.
Rittwik: The open test framework is helping to bootstrap a lot of the automated testing and scripting access to this infrastructure. We need something like a CI/CD pipeline so that when people come in, they can automatically write their code, inject the code, it gets automatically tested, and bug reports come out. I think that is pending on Felix's table. I wanted to mention that this infrastructure is going to be up and running. And we should keep moving along this line so that all use cases and projects reside on this. And then we have a working environment, full stack to stack, and then eventually a CU will be enhanced with O1 and E2.
Jack: We need a road map for this. If you can add the near real time RIC even if it's a dotted line for now until it's ready so people can see it. And in SMO, you probably need to put a box that says a non real time RIC.
Rittwik: Mahesh has a couple of components inside the SMO to get filled in.
Jack: I really appreciate everyone's efforts as it’s a big step when you cross from pair wise to system testing. But it does also highlight some of our challenges, particularly getting broad utilization of O1 as an example. You were going to highlight this front hall gateway, right?
Rittwik: There’s a direct connection right now that does the synchronization, the timing synchronization that is already happening. But what's lacking is the CU message that originates at the upper DU via the app interfaces into the lower DU. There is a couple of bugs that Radisys is trying to figure out once that is there. Then basically, you have the DU talking to the RU, not just synchronization, but the actual message. The ETA for the TM 500 is second half of April, at which point we should be able to turn up some UEs and have the full message interaction going all the way to CU and back.
Jack: Are you still looking for a front call gateway?
Rittwik: Yes, I may have located one, but I've asked Intel also to see if they can provide us one. I'm trying to follow that up on AT&T side. But if Intel can help, or anybody in this community can help with this switch I think that will be helpful.
Jinri: I have two questions. The first question is whether the fronthaul gateway is mandatory in this configuration? You have mentioned that currently there is the direct connection between the ODU low and ORU.
Rittwik: For the M-plane it needs to have that switch so that connection can be made to the SMO.
Jinri: And the second question is, you mentioned that the current OCU doesn't support O1 and E2, how can we address this?
Rittwik: Radisys has a plan to enhance their product with O1 and E2 support. But we will not have it in D release, maybe in E release.
Jack: We need a road map for the lab. Maybe a quick spreadsheet to show what functionalities there and what's coming in the future. But that's the challenge with the lab in the development environment when it has to continue to evolve as software matures and capabilities are there. And that's part of the challenge with looking at these more sophisticated use cases. There's a lot of work to be done, and I appreciate everyone's contribution towards those activities, I think it's a major accomplishment to be able to start talking to as many pieces as possible. But the pressure is on PTLs to look at how each of your pieces has to continue to mature to meet all parts of the specifications to meet the use cases.
Jinri: to take the Action Point to prepare a briefing report for TOC membership renewal
Action Point: Trishan to get the presentation from Lincoln and share to the group. The presentation can be found here: O-RAN Badging Intro.pptx
Old buisness: CII badging
Action Point: discuss https://lists.o-ran-sc.org/g/toc/message/402 LFX security for OSC subprojects // CII badging
Action Point: Trishan to come up with a presentation regarding certified badge from other projects e.g. ONAP. In this context we also need to discuss the usage of the LF Security tool (as raised in this mail: https://lists.o-ran-sc.org/g/toc/message/402)
Trishan: We have the non real time RIC project as the first one passing and we have five other projects that are over 80%. I had a couple of requests to directly access from the PTLs to edit their entries. So if anyone else wants access and to make updates please shoot me an email.
Jack: Trishan can you just send a short email with where we're at so we can forward that onto the security focus group to give them an update on the progress we're making. You can send to the general TOC list, or just to me and Jinri.
Action Point: Trishan to send a short email to the TOC list or Jack and Jinri, regarding certified badge from other projects and/or usage of LF security tool, so that OSC could fordward it to the security focus group and give them an update on our progress.
Tracy: Jack, you expressed an interest in exploring some sort of a badger badging process for the models. If there's still an interest, I will follow up and put a call in the calendar with the right folks next week.
Jack: It's to our interest to promote progress that we're making on badging or other ways within the software community and drive some events that would help raise the awareness.
Tracy: We can build on some of the work we've done with early adopters who are actually using or have implemented the models that are now approved for use by O-RAN and in some cases also standardized within 3gpp.
Trishan: I would encourage folks if interested to look at the non real time RIC entry if they're looking for how they answered some of the questions.
Standing Agenda Items (Brief Status of Ongoing Activities)
Release Manager @Trishan de Lanerolle /Release Planning: Weekly TOC Scheduling
@Former user (Deleted) Requirements Software Architecture Committe
Jack: It's March 31st, we're in the last week of the second development Sprint, about halfway through. People should be making significant progress by now on their user stories and on their deliverables. We still have a huge gap in the sense that we haven't had anyone else step up for the integration and test activities. We need people to get involved, particularly as you look at the requirements are growing. And with this whole discussion about needing the CI/CD pipeline to be improved working with the Linux foundation, we need a couple more participants out there. Otherwise, we're going to run into a problem at the end of the release and not have enough testing done. The release is at risk here of completing integration and testing without more participation. I don't know exactly how to solve this problem, but we need additional help. One of the ways to get that help is to partner with something like Lincoln's proposal last week where we pay for some support that would help in some areas with the activities.
Rittwik: The massive MIMO team is calling out to all working groups members to take a look and see how they can interact or how they can shore up their requirements. So if the TOC feels that we need to involve ourselves in that process let us know more actively. Look at those requirements that come out of each of the working groups and then maybe cherry pick which ones we need to go do E release?
Jack: I'm really asking the participants here to engage with Rittwik about how do we move the solutions forward. The E releases should be a big release for us if we're getting closer to interoperating. How do we push the O1 requirement? We need to get closer to the target architecture across the board and by E we should be having a more functional system coming together to do more sophisticated use cases. I suspect that the massive MIMO use case probably isn't an e release. It’s 18 months away, so three releases. We need to start pushing on more minimum deliverables for each module.
Martin: this week is M3. So there's an API freeze. If somebody has something in terms of API changes in the pipeline, just let me know.
@Zhe Huang (Felix) (Felix) Integration and Test
Report out from PTL: Stand-Up & Report Out on Blockers
@John Keeney (Ericsson EST) Non-Real Time RIC (RAN Intelligent Controller) (NONRTRIC)
@Matti Hiltunen RIC Applications (RICAPP)
@Thoralf Czichy RIC Platform (RIC)
@gusu O-RAN Centralized Unit (OCU)
@Sachin Srivastava O-RAN Distributed Unit High (ODUHIGH)
@Zhimin Yuan (Deactivated) O-RAN Distributed Unit Low (ODULOW)
@Martin Skorupski Operations and Maintenance (OAM)
@Alex Stancu Simulations (SIM)
@Xiaohua Zhang Infrastructure (INF)
@Weichen Ni Documentation (DOC)
@Mahesh Jethanandani Service Management and Orchestration (SMO)
(TBD) O-RAN Radio Unit (ORU)
New Agenda Items (New Business): New Items Submitted (+speaker) & Open Call to TOC For Additional Items.
Planning for Next Meeting
Any Other Business (AOB)
Meeting Summary (resolutions, new action items, etc.)
2021 03 24
Recording: TOC 20210324
Agenda
Call for Scribe (minutes owner): Jinri Huang (CMCC)
Roll Call & Quorum Check
*Quorum: 50% or more of total TOC voting members unless excluded due to attendance. // Yes, we have a quorum and can vote on activities.
Review and Agree to Minutes of Previous Meeting
Decision: For the 3/17/2021 TOC meeting minutes, Motion by Jinri, seconded by Ganesh. Motion approved by all TOC members present.
Review of Today's Agenda
Jack: We have a guest speaker, Professor Lincoln Lavoie from University of New Hampshire, and he's going to talk about their badging process and their labs and the activities that they support in partnership with Linux Foundation. Trishan was nice enough to arrange for him to come and speak.
Ganesh: Small Cell Forum has been looking for some examples of open source implementation. And I mentioned our effort in open source regarding 5G HAPI standard and they are interested in exploring this further. Probably they would like to do some press release or something.
Jack: We're all in favor of reusing software and O-RAN standards. So we're happy to have a discussion.
Ganesh: Let me share that email.Professor Lavoie gave the presentation about the University of New Hampshire InterOperability Lab (UNH-IOL) in the context of badging and testing approaches within open standards and open source. Action Point: Trishan to get the presentation from Lincoln and share to the group.
William: I’m a bit confused as this kind of certification and compliance is handled by the test and Integration focus group in the O-RAN Alliance.
Jack: TIFG is setting up a program to validate the specifications. The opportunity here in the open source community is more on the validating the software and trying to build more activity around the software that is available, such as the interoperability of xApps or rApps. We have to figure out how to promote the open source software capability to the developers who are not yet O-RAN partners. So there's a range of opportunities here that I wanted to make sure the community was aware of. Both the University of New Hampshire and Linux Foundation participate in similar programs across the open source community, for testing of the specifications, and testing of the interoperability with the software that's being created in the community. So it's just a little different focus. Anyway, we need to find ways to continue to promote the use of the software and different aspects of the software.
William: my understanding for this topic was to talk more about the badging best practices around the open source implementation in the software community
Jack: that's basically correct. But our work is coupled to the O-RAN specifications. There will always be some references as to what version are released ties to what version of the specifications. Our job here is to really talk about interoperability, and the badging associated with use of the software. Lincoln's presentation is very open to the whole space and each software community has to sort out for themselves how they handle these issues. Rittwik, are you still working on setting up a talk with TIFG?
Rittwik: I’ve made some progress on that and I will finish that work item.
Jack: Lincoln, have you talked to the TIFG group in O-RAN?
Lincoln: We have not yet spoken with that group.
Tracy: Actually, we had a talk a while ago. I don't think it was you, Lincoln. We spoke with you guys and a couple of people from broadband Forum and got some excellent ideas. Jack, I found the note from late 2019. I'm forwarding it to you and Rittwik.
Rittwik: The TIP consortium also has a pretty mature certification and badging process. Maybe we can take a look.
Jack: The focus here is to promote the software that's available through the open source community and how it’s maturing, how products interoperate with each other. The intent here is never to do every aspect of the O-RAN specification testing. That's more where the TIFG Is focused. We're more focused on the software and APIs which maybe not as forefront in some of the TIFG’s focus.
Lincoln: The other opportunity is that any work that you guys do can feed into their badging work or vice versa. If you were to focus on the API space, they might be able to then leverage that in some of their testing requirements down the road as they move forward and develop what will be the formal O-RAN approach.
Trishan: would it make sense to have a follow up meeting with Jinri, Tracy and Lincoln offline?
Jack: Certainly. Please post the time on Wiki or send email when you set up a time to continue the discussion so people are aware.
Release Votes and Approval.
Copyright update
Jack: We continue to meet on Fridays. The legal team is in reviewing this proposed new license and process for handling specification copyrighted materials in the open source. They’re refining the several points in the license to make sure that the broader legal team is comfortable. They’re working on specific critical wording areas that the legal team is making sure everybody is clear on and frequently asked questions to give guidance to more users on what they think are critical aspects of using the new license.
O-RAN-related business (marketing, WG interaction, TSC/EC update etc.)
Jack: Another item to let the group know is about the update on the TOC membership process. We need to work with the EC.
Jinri: My understanding is that currently we still have some seats vacant and I don't expect a voting for this. We also have already requested the top members to indicate whether they're interested to continue this membership or not by email. What kind of process are you talking about?
Jack: We have one seat from that is changing. And we have one new proposed. We have two new EC candidates. We also have a new TOC candidate from the community. So those issues are to be formalized as part of the annual process.
Jinri: I will take the Action Point to prepare a briefing document for this.
Old business and Status of Open Action Items.
Action Point: Rittwik Jana to set up a meeting with TIFG Co-Chair.
Action Point: TOC members and whole community to indicate what do we really need to deliver in D- and E-releases to be successful and useful?
Old buisness: CII badging
Action Point: discuss https://lists.o-ran-sc.org/g/toc/message/402 LFX security for OSC subprojects // CII badging
Action Point: Trishan to come up with a presentation regarding certified badge from other projects e.g. ONAP. In this context we also need to discuss the usage of the LF Security tool (as aised in this mail: https://lists.o-ran-sc.org/g/toc/message/402)
Jack: Trishan, any updates on the CII security badging?
Trishan: A couple of groups had reached out to me that we're setting them up with access. The infrastructure project has progressed up and now it's 75%. If anyone wants to edit the entries directly, all you need to do is set up an account in the CII platform and send me the user ID number from your profile.
Jack: The goal is that by the end of this release that we complete the badging for all the active projects. We want to talk a little bit more about it since it’s approaching the mid point of the development cycle.
Trishan: I think the one area that right across the board is the reporting process has to be written out.
Jack: I think we're relying on the security focus group in O-RAN to be the parent organization for that. Because if something gets highlighted, there is an equal part software and equal parts specification that we need to make sure we cover as part of that process.
Trishan: We just need that sort of central reporting line to report an issue. So we'll set that up.
Thoralf: Still one question I heard you talked about two minutes ago. Was it about getting a project into the CII badging page?
Trishan: No. All the projects now have profiles set up in the CII badging entry. If you want to edit your entry directly or add an updated, you can go log in with your Github account to create a user profile and send me the user ID number from that system. And I can add you to that project.
Jack: Is there any PTL that has any items they would like to raise at this point in time?
Thoralf: Is the LF security something that should play a role in the CII badging?
Trishan: That’s a separate tooling. But we can use it if you want, but I think it doesn't support SQL yet, so that may be a gap for us.
Thoralf: That's also my understanding, but it would cover already quite a lot. For instance, in near real time RIC project it can cover 90% of the code.
Trishan: If you need to use that tooling form you need a link to the CII badging. I would just use the search page with all the O-RAN projects listed in the way I've tagged it. We can discuss offline to walk through it.
Jack: I'd like to see how you go through it and then we can learn from it and then look at bringing the other projects to work them through.
Standing Agenda Items (Brief Status of Ongoing Activities)
Release Manager @Trishan de Lanerolle /Release Planning: Weekly TOC Scheduling
@Former user (Deleted) Requirements Software Architecture Committe
@Zhe Huang (Felix) (Felix) Integration and Test
Report out from PTL: Stand-Up & Report Out on Blockers
@John Keeney (Ericsson EST) Non-Real Time RIC (RAN Intelligent Controller) (NONRTRIC)
@Matti Hiltunen RIC Applications (RICAPP)
@Thoralf Czichy RIC Platform (RIC)
@gusu O-RAN Centralized Unit (OCU)
@Sachin Srivastava O-RAN Distributed Unit High (ODUHIGH)
@Zhimin Yuan (Deactivated) O-RAN Distributed Unit Low (ODULOW)
@Martin Skorupski Operations and Maintenance (OAM)
@Alex Stancu Simulations (SIM)
@Xiaohua Zhang Infrastructure (INF)
@Weichen Ni Documentation (DOC)
@Mahesh Jethanandani Service Management and Orchestration (SMO)
(TBD) O-RAN Radio Unit (ORU)
New Agenda Items (New Business): New Items Submitted (+speaker) & Open Call to TOC For Additional Items.
Planning for Next Meeting
Any Other Business (AOB)
Meeting Summary (resolutions, new action items, etc.)
2021 03 17
Recording: TOC 20210317
Agenda
Call for Scribe (minutes owner): Jinri Huang (CMCC)
Roll Call & Quorum Check
*Quorum: 50% or more of total TOC voting members unless excluded due to attendance. // Yes, we have a quorum and can vote on activities.
Review and Agree to Minutes of Previous Meeting
Decision: For the 3/10/2021 TOC meeting minutes, Motion by Jinri, seconded by John-Paul. Motion approved by all TOC members present.
Jinri: per our previous meeting, I put the set of open action items under this under #8 (Status of Open Action Items)
Jack: We often have open items that are not necessarily just action points, but I'm fine with it.
Review of Today's Agenda
Thoralf: I put one item in the beginning to discuss LFX security for OSC subprojects/CII badging
Release Votes and Approval.
Copyright update
Jack: More people from this team had joined last Friday’s meeting. As mentioned before, the license just covers software. The biggest risk is that it's clearly not an open source license from a Linux Foundation perspective. Also it doesn’t address the documentation copyright. The legal team asked me to come back with some firm examples where we need O-RAN specifications. Does anyone have a couple of good examples where separate file under CC 4C of module documentation needs to reference material that would be covered by the copyright from O-RAN specifications? Does anyone have any good examples I can use in the dialogue with the community?
Matti: For example, RIC implements E2AP version 1.1. That's not what you're talking about -- just reference to a version number?
Jack: No, I don't think so. I think it's more like how people could interact with these software components after they are built, such as our error messages that are documented or something that have to be exposed.
Thoralf: I wouldn't come up with anything that we put into the documentation related that is copyrighted material from the spec.
Jack: How about like an error message list that is generated that aligns with what is in a specification?
Thoralf: I think that's a borderline case.
Jack: How about API documentation?
Thoralf: We wouldn't directly copy anything from the original specification for a description of what an API is supposed to do.
Matti: Would there be an issue if we refer to some variable name, such as E2SM has some fields in the ASN.1 and we show in the documentation how you construct that object in an xApp. So you need to assign value to a field with that name -- we are essentially copying the same field name from the ASN.1 specification, but not the whole specification.
Thoralf: I don't think so. There has to be some significant intellectual value in the part that you copy.
Jack: Remember this is not patent. This is copyright, it’s image and representation. There's a threshold in general practice of how much you have to represent before it's unique enough to be considered copyright in the representation.
Martin: For O1 we have a figure in the documentation about the overall architecture. We made it ourselves as a figure out of the O-RAN architecture. Could that be an issue or not?
Jack: That’s something considered as a derivative work, depending on how significant it is. The issue for us as a larger community is if we want to address this problem, now is the time. If we don't raise it now and it becomes an issue in the future, it will be very difficult to reassemble.
Thoralf: I don't see a documentation issue.
Jack: OK, we’ll then de-emphasize the issues with getting some documentation licensing in peace. If anyone comes up with anything, let me know.
O-RAN-related business (marketing, WG interaction, TSC/EC update etc.)
Status of Open Action Items (Old Business).
Jinri: I gave a brief report at last Friday’s O-RAN alliance TSC meeting. And I mentioned there was a lab from a university in Taiwan that shows interest in OSC testing. The TSC wants to encourage this lab to apply for OTIC as well. In TIFG I believe they have already developed this guidance and criteria for O-RAN and OTIC. Actually I think two operators, Dutch Telecom and Telecom Italia, have recently submitted their application for an OTIC center. This is kind of encouragement from TSC for this potential OSC lab in Taiwan. I need a contact of this lab to reach out and pass the OTIC related information to them.
Rittwik: I can get you the contact person information
Action Point: John Murray Ganesh Shenbagaramanto close this.
Jack: any update on the OCU license?
Ganesh: let’s consider this as complete. Sphoorthi is on this call and she will take care of it.
Action Point: Rittwik Jana to set up a meeting with TIFG Co-Chair.
Rittwik: I haven’t succeeded in setting up the meeting yet, but I reached out to them and hopefully this week.
Action Point TOC members and whole community to indicate what do we really need to deliver in D- and E-releases to be successful and useful?
Jack: How’s the E release planning shaping up? Are there any points of discussion that we need people to be thinking about?
Rittwik: We haven't started the release yet. Potentially I think that the MIMO requirements would go into the E release. Obviously, the whole MVP package cannot be done in one release, So we'll have to kind of trickle different sets of requirements in E, F and G releases. Another work item is to work through some more details on the SMO package.
Jack: I'll just use the MIMO as an example we need to make sure we have a block diagram of the modules that are needed and then the capabilities in those modules, because that may take a significant effort. How are we progressing on having a functional stack where we're just emulating the UE and the radios? And what percentage are we covering?
Rittwik: There are many different use cases that fall under the larger MIMO umbrella. Specific use case would have specific requirements. For example, grid beam optimization would have a set of inputs and outputs, and beam based mobility management has a different set of input output. We need to see what are the dials and the control knobs that you need for each of these individual use cases. The MVP team is going to collapse multiple use cases to figure out what super set of dials and knobs they need. Once we understand what those dials and knobs are, we can figure out how we’re going to do that in software. From a hardware perspective, we need to think whether we need a MIMO system to do this or kind of simulation can work. I think that the interface compliance check and validation is what OSC can help. In the end the MVP package will come up with specifications that describes those dials and knobs, and the metrics. I think the plumbing needs to happen first. And then once the plumbing is all set, you can actually showcase a specific use case. We’ll have a little bit more clarity once MVP settles down a little bit more.
Jack: We need to focus on things that we can deliver incrementally and what shows the basic capability of the software. We may not choose to implement every use case but to figure out where it's best to spend our resources and our time.
Rittwik: That’s the good part about the MVP package, which helps to set the priority and tell us which use case is the first one out of the gate.
Jack: My only concern is that it might be technically very interesting, but difficult to implement if they pick the most difficult one for us to do first. I encourage the community here to sort through on how we build stepping stones so that we can deliver some of the incremental work in each release on simpler use cases and then still tackle the more complicated one a year out. The community has to decide overall what strategy we can move forward with to keep the software delivering useful value to the community.
Martin: One question from my side: are we targeting also that we have a real end to end use cases with the mobile core in place because I think those are kind of required in order to get all the data which we need to transport over the interfaces. And I'm keeping also in that direction if we can set up an open source mobile core from some other parties. Otherwise, we always send data which we know in advance, and then we try to do machine learning on top of it but it's not very attractive to demonstrate.
Rittwik: Without the metrics and the dials and the control knobs, we will not be able to work through the entire full end to end stack. What's happening is first a parent work item is getting created. Drafted from the parent work item, there will be individual child work items. The child work items are the responsibility of each working groups in O-RAN alliance. Each of the working groups will come up with their child item specifications, and in OSC we will be able pick which ones we are interested in implementing, if not all of them. And once you implement all the child work items classification, then you have a full end to end working stack. I think it's a little ambitious that we can do all of that in E release.
Jack: Let me view it in a slightly different angle. You can have different tracks when building a system. 1) A track that each individual component in the system must achieve, such as resiliency, security, APIs, etc. 2) How the system works when putting the components together, things like deployment, failure recovery. 3)What are the use cases that you want to accomplish using the system? It’s a small number of tracks but you have to work in parallel, pushing progress in each of the different tracks, to continue to make sure the system is mature. You can't just think about the applications and the use cases running on it.
Rittwik: So some of those are management plane tracks, some of those are control plane tracks.
Jack: Yes. The community can decide how many tracks they want to focus on and drive, and progress through them. But we really need to make sure we're progressing in the multiple areas in each release. On one side you can't just abandon other tracks and jump to the end use case. On the other side, a lot of the work you're doing to build the underlying components does not drive much value because they don't see how it comes together to solve the bigger issue if you don't have any use cases. It's important to find the balance across each of these areas.
Martin: I wonder whether we should have a check list in a certain order to show what’s the next step in the road map.
Jack: We need to think about how do we promote ourselves better. How do we expand beyond the 25 members who joined this call? How do find a significant issue, oress on and bring value? The future direction of the community has to be looking at how we bring value and promote the work that we're doing so that the software gets reused.
Rittwik: Would it be okay to for the PTLs to raise awareness on the individual project, and maybe reach out to the community who is actually using all this stuff to let us know what features they would like us to implement. Right now it’s the 25 members who were joining these calls are making all the decisions and pushing the agenda forward as best as we can. We can only think of what's happening here and now. Future looking features need to come from outside of the 25 member groups. I would suggest to get developers outside their opinions on features they like. Make a bullet list and then bring that to this discussion. I'll put it up in the wiki. Otherwise you will just be circulating amongst ourselves.
Jack: I certainly encourage that. The other way for us to do is to come up withour own milestone event to promote ourselves like I was talking a little bit about it last week. Can we come up with a challenge? Can we come up with a badge objective that we can take to TIFG? Do we have a challenge on how we can try to get interoperability between different near real time RIC? But we just need to figure out ways to promote ourselves more and the value of the software.
Action Point Zhimin Yuan to work on CII bading for O-DU-LOW project.
Zhimin: I updated the status in Wiki and it’s 91%
Action Point: Trishan to come up with a presentation regarding certified badge from other projects e.g. ONAP
Trishan: I’ve worked with a couple of folks to fill out their entries so we should have more details on that in the next couple of days. I'll try to get some details for next Wednesday to present. The easy CLA team is working on a V2 release for the CLA Management. Maybe the CLM managers will see a new interface in the coming couple of weeks, so I'll share some more details on that once I have that as well. Just a heads up that a new release is coming out.
Action Point: discuss https://lists.o-ran-sc.org/g/toc/message/402 LFX security for OSC subprojects // CII badging
Thoralf: There are two CII requirements in a container environment. A very narrow view is only about the source code that we publish in Gerrit from OSC. A broader view is about the overall security level of the whole solution which is not only our source code, but also the components pulling from somewhere else. Do we want to be up to date in these binary containers with respect to security or not? Alok from HCL contacted the LF guys and they recommended this LF security tool. First is to organize groups of sub projects into one big project at the community level and then under that we would create sub projects which then can have multiple repositories in them. So that would mirror quite well the structure that we have at OSC. I would actually propose that we start using this LF security tool this way, we can prototype this first with the near real time RIC to see how this works.
Jack: We take it offline during this week, and then we have another discussion next week in the beginning.
Standing Agenda Items (Brief Status of Ongoing Activities)
Release Manager @Trishan de Lanerolle /Release Planning: Weekly TOC Scheduling
@Former user (Deleted) Requirements Software Architecture Committe
@Zhe Huang (Felix) (Felix) Integration and Test
Report out from PTL: Stand-Up & Report Out on Blockers
@John Keeney (Ericsson EST) Non-Real Time RIC (RAN Intelligent Controller) (NONRTRIC)
@Matti Hiltunen RIC Applications (RICAPP)
@Thoralf Czichy RIC Platform (RIC)
@Former user (Deleted) O-RAN Centralized Unit (OCU)
@Sachin Srivastava O-RAN Distributed Unit High (ODUHIGH)
@Zhimin Yuan (Deactivated) O-RAN Distributed Unit Low (ODULOW)
@Martin Skorupski Operations and Maintenance (OAM)
@Alex Stancu Simulations (SIM)
@Xiaohua Zhang Infrastructure (INF)
@Weichen Ni Documentation (DOC)
@Mahesh Jethanandani Service Management and Orchestration (SMO)
(TBD) O-RAN Radio Unit (ORU)
New Agenda Items (New Business): New Items Submitted (+speaker) & Open Call to TOC For Additional Items.
Planning for Next Meeting
Any Other Business (AOB)
Meeting Summary (resolutions, new action items, etc.)
2021 03 10
Recording: TOC 20210310.m4a
Agenda
Call for Scribe (minutes owner): Jinri Huang (CMCC)
Roll Call & Quorum Check
*Quorum: 50% or more of total TOC voting members unless excluded due to attendance. // Yes, we have a quorum and can vote on activities.
Review and Agree to Minutes of Previous Meeting
Decision: For the 2/24/2021 TOC meeting minutes, Motion by Ganesh, seconded by David. Motion approved by all TOC members present. For the 3/3/2021 TOC meeting minutes, Jinri will update the lady’s name spoken for ODUHIGH. Motion by Jinri, seconded by David. Motion approved by all TOC members present.
Review of Today's Agenda.
Rittwik: needs a fronthaul router for the lab, which switches between the RU and DU. The router needs to talk 25G to the DU. It also needs some specific timing associated with this switch. Rittwik has some candidates in mind and will send out via email.
Juha: a couple of weeks ago there were some discussion from those open labs, and if we could get some more information to our website.
Rittwik: will take direction.
Jinri: one comment – Ganesh suggested to collect all action items and put in one place
Jack: add one after “Review of Today’s Agenda” for the collected action items.
Juha: Take the action items out of Item 13 and add after “Review of Today’s Agenda”
Jack: we’ll start this from the next meeting on
Release Votes and Approval.
Copyright update.
update
Jack: had a meeting again last Friday. I think we're pretty close on one part of the discussion to spell out the basic license. For this Friday's agenda we will bring that to beyond O-RAN to 3GPP and others to get feedback. There’s one open item that's still not quite resolved: how to deal with documentation. The license covers the software code, but doesn't cover documentation. Most of the documentation in our projects is covered under CC4, which is a different licensing mechanism than the software code, which uses Apache. In my mind, at least, the documentation takes two forms: one is direct documentation of how the software is written and maintaining the software; second how you use the module that the software builds. Like, how do you use a near real time RIC. Simple examples typically fall into ASN.1 code models and software examples. In addition to the description of the functions, people are going to use APIs and error codes. Would you expect that ASN.1 code examples appear at the high level documentation?
Thoralf: you would probably be able to limit yourself so you would just kind of refer to the IEs by name, but not put their structure there
Jack: there's an action for me to share the legal writeup. The legal team owns the content. Does anyone who doesn't have the latest version and would like a copy of it? If there is just please reach out.
Action Point: @Jack Murrayto share legal team write-up
O-RAN-related business (marketing, WG interaction, TSC/EC update etc.)
Status of Open Action Items (Old Business). i. Ganesh: Stephan did not seem to find the original email so I resent it to him. Hopefully to get his attention and Stefan can review this and the technique steps.
ii. Jack: Jinri, we probably need to set up a summary for the EC on a couple of items, one of them being the OCU discussion about how to proceed. We can periodically review on some of the topics.