Matti HiltunenI request a repo that will be managed by the RICAPP project (for now):
com/asn-to-json-converter
Summary: A streaming application that receives ASN.1 messages via Kafka and publishes them as JSON via Kafka
Description: The ASN1 to JSON converter is a Kafka Streamer application that received from the E2Terminator messages with ASN1 Binary payload (PER) that is encoded in Base64 and convert it to textual JSON that can be consumed by other applications. The converter receives the packed messages on an input Kafka Topic and publishes the input on dedicated output topics. Aligned with O1 tracing. Can be used for traces from any component that uses ASN.1 message format.
Source code repo is a recipe. The source code is not imported into the repo. It is the recipe that puts it there.
During build time the upstream.
Is the resulting build unique to our project so O-RAN SC will use that work.
Yes, it is optimized kernel and the packages.
Be careful in impacting all of our other resources and projects.
How often do you need to rebuild this?
No, we want to build once per release or patch releases. Maybe one or two times per release should be good.
Concerns about managing the resource consuming job. Work with Lusheng to schedule time early in the process so we can be efficient in the resources across projects and not block others.
Lusheng - tonight will provide the full report at the f2f.
We thought seed code is possible through open source. Binary is not an option on the table. We are reluctant to open our code to binary code. We learned binary code is being submitted by another vendor.
Jack - This is a rich topic for discussion. In open source the code is open and people can look and contribute. We've had discussions with companies about including the binary code as an option. Binary code is not a contribution to the open source community. However binary code can be used for integration and test. For example Intel wanted to keep their layer 1 software. They didn't have to contribute that software. Instead they are contributing a loader module that will pull in their binary from their location. The process to get their code is consistent. The open source community doesn't treat it as open source but instead uses it for test and integration. In this case the O-DU could choose to license from Intel and build it into their process. Intel would contribute the loader. The binary itself is not open source. The company would have to deal with Intel directly for their binary. They are not open source but are build, test, and integration options. The build APIs are open source.
Jinri - Do we need to discuss this with the O-RAN legal team?
The broader issue for us is that it is hosted by the Linux Foundation. These contributions aren't in source code. Theoretically, if you could contribute binary it would have to under one of our two licenses meaning people could use it. That is not their intent. It is best for them to keep their code under their management. If we use it for integration and test then O-RAN would have to set up how to make it available for us to use.
Jun Hyuk Song TOC membership. There are open vacancies for the TOC membership.
Jack - We want to promote open source developers. Interest in viable candidate to contribute open source code.
Jun Hyuk Song What about xApps? Are there requirements for that?
Jack- We didn't put a hard requirement on contributing magnitude of code. Demonstrate your interest in the activity and the community.
F2F Summary
Samsung - contributions in the form of binary code.
Planning for Next Meeting
Open Discussion
Any Other Business (AOB)
Meeting Summary (resolutions, new action items, etc.)
Matti Hiltunen document the simulator test on the RSAC space in the wiki.
user-59b16 place a formal approval request for code freeze extension.
Extend the code freeze to October 18 or October 25.
user-59b16 publish the meeting details on the RSAC page regarding WG3 and E2.
We had two meetings today to align all the WGs and projects. ODU and Infra still have to update but we are in good shape for the f2f.
user-d3360 talk to Jack about which use cases are being covered by the test and integration team, for release B.
Trying to get people from other projects and companies more involved because it requires a lot of activities that need to test their items. Code testing and end to end use cases drive the OSC solutions that we promote work. The integration and test team will be driven by the end to end use cases that we pick as a community for our release. This is important for the discussion next week. RSAC have a clear managable set of use cases that demonstrate the value and capability of where we are in the O-RAN stack to the community and beyond. You can only have a certain amount of end to end use cases. The team has to focus on these use cases as a primary goal. End to end use cases are the primary driver to demonstrate what the release can be used for.
Rittwik - If you want a full stack ete demo it will require CUs and DUs who won't be ready until the B release.
The goal is trying to demonstrate functionality towards the goal. Simulators can be used. We have to show the community is advancing in it's goals. The spirit of end to end is talking about broader functionality and not just the individual. Write an end to end use case around Martin's demo. Integration and Test team should develop a plan to evaluate an end to end use case.
John Keeney discuss renaming of near non real time RIC.
People are complaining about which is the real name of RIC? People don't like typing the extra words "near real time..." or "non real time ..."
Jinri spoke to O-RAN TSC. There are difference of opinions in WG1. Keep it open until later.
Martin - Do you have a proposal because it has implications to O-RAN Alliance.
John - I propose that we don't change it.
Jack - Better to change it now rather than later. It will become harder to make the changes across documenation and it will have a ripple effect throughout the projects.
John Keeney discuss the relationship with the upstream projects such as Acumos and Akraino.
Asking for feedback on relationships with upstreams projects. Do other people have other discussions?
Yes lots of discussions in the background. See new Partnerships link in the top navigation bar. We have slides we will share and put on the agenda in the coming weeks. We will pick one of the projects and talk through it. We are starting to document which ones we are interacting with and we have develop a breakdown of what our interactions is with.
Irfan Ghauri - Are there collaboration agreements?
In open source there are no formal collaborations except for O-RAN Alliance, 3GPP, and ETSI. They require formal collaborations
Jinri raised a concern about the putting the O-RAN Alliance in the Partnership category.
It is not owned by O-RAN Alliance.
Peter Moonki Hong - How do the open source developers refer to the other collaborative projects such as Akraino? For example I am a developer who would like to test O-RAN software stack and there are other components from Akraino. Could you provide formal guidance of how we interact with the partnerships?
Jack - In the near term start by reaching out to Lusheng about integration. Akraino is a part of the INF project it's early. We have contacts from Akraino. Acumos is being used by the Near real time RIC dashboard. Reach out to the TSC in those projects. We will expand the partnerships with a list of contacts.
Jinri Huang discuss PTLs slide preparation for the F2F meeting.
Top mission is the complete the alignment with the working group at the face to face meeting.
Rittwik - preparing one slide deck for discussing the near real time RIC. We should sit in the WG3 meeting.
From Non Real Time RIC we presented our alignment with WG2. WG1 and WG6 I am quite confused about the scope and architecture when it comes to the Non real time RIC.
Can you share the slides with the community?
Yes, there is one slide.
Jinri needs to see whether these items are aligned.
There is a formal request. In the Amber release this schedule was ambitious process. One of the goals is to get people to get familiar and start contributing. Code freeze is supposed to occur at the end of this week. The developers enter a maintenance cycle. To get a release out we add a maintenance release. So the developers can continue to fix defects while everyone plans on what the new features are in the B release. This next window October 14 - November 2 is time to work on fixing bugs on the software only for this release. We should allow this extension because there is not enough code to do end to end testing.
The proposal is to move the code freeze date to add a development sprint 5. Focus on getting the code as mature as possible for Amber to make it useful. This is a one time event.
Jinri agrees to delay.
Extend the release schedule code freeze from October to November 2. On motion made by Jinri Huang seconded by user-2057e
VOTE: Vote taken, item passed
Report out from PTL: Stand-Up & Report Out on Blockers
For legal reasons we need a controlled way to define the scope of the near-RT RIC platform. Concrete suggestion is here. The basic idea is a description of scope and RICP project meeting approval for changes to that scope plus TOC approval for new repos. Additionally we would like the following sentence in the beginning of each file (in addition to the copyright and license statement): "This source code is part of the near-RT RIC (Radio Intelligent Controller) platform project (RICP)." (suggested by legal dept.). Jack's opinion on the extra sentence needed. The rest of the procedure was ok-ed by RICP project meeting.
Jack will review the proposal.
David - keep Paul in the loop to avoid surprises.
John - The title should be updated.
Action/TOC continue review the proposal and return with feedback