Page tree

Meeting minute for O-RAN SC TOC f2f meeting in Costa Rica

 

       Date: Oct. 14-16, Monday to Wednesday

       Time: 4:30-7:45pm

  •  
  • Purpose:

            Consolidate alignment with O-RAN WG

            Discussion on Release B

            Copyright issue discussion

            require PTL to report the status

            Amber release discussion

            Process, criteria, expectation etc.

            Project work progressing

 

Attendees: ~30

Meeting recording:

 

(day2)

https://zoom.us/recording/share/rQQqPYSpp5QbwSwbIn858s8yaC2rGelcBKv8zy_-ZKWwIumekTziMw?startTime=1571179316000

 

(day1) https://zoom.us/recording/share/YRS3pz66PAdPdZrk8wYC9EFD3qTkISJWxqjQlCBTOD-wIumekTziMw?startTime=1571093128000

 

File list:

https://wiki.o-ran-sc.org/display/EV/File+list+for+2019+Costa+Rica+f2f+meeting

 

 

Meeting minutes:

 

TOC-WG alignment

 

            It is suggested not to use the word of “pre-spec” which is confusing. It is suggested to use “document”;

            It is agreed that there are some difference points at the current Release A which shall be fixed by Release B or during the maintenance release. This point should be reflected/reported in the TSC report.

 

WG2 alignment:

 

            Conclusion: the current implementation is in a pre-spec. mode since the A1 interface specification was just approved and released in WG2 some time ago. The update to ensure the alignment will be done by maintenance release while the complete alignment will be by Release B;

 

            There is one concern on the E2E use case demonstration/development by WG8. The reason is that traditional flow is that the E2 specification from WG3 will be developed first, then WG8 takes it over and make the design. After that the work will be transferred to SC. If working in this way, too much delay could be foreseen. To reduce the delay and speed up the software development, it is requested WG8 and O-CU/O-DU project leads to start communicating with WG3 as early as possible.

 

            It is indicated that NRT RIC project is working closely with WG2 to ensure the alignment. They are preparing feedback to further improve the A1 specification based on the observation and experience learned from project development in SC, although the feedback is not yet provided. Currently the A1-P/restful interface is substantially different between the two (i.e. SC project and WG2).

 

            Regarding the NRT RIC functions:

            It is still on the very early stage.

            The initial focus is on the A1 controller;

            The boundary b/w NRT RIC and SMO is blurry. For this, there are different opinions. Currently the SMO does not have a clear definition and there seems to be different views on this. Some think the SMO is implementation-dependent and there is no need for the definition. The others think that O-RAN should clearly define the SMO concept. Otherwise, the work scope of NRT RIC would be unclear.

 

            Regarding the relationship with ONAP, it is indicated that SC need to drive back requirements to ONAP and should avoid overlapping, i.e. not develop what ONAP plans to do.

 

            Regarding the nRT RIC SW architecture, the major concern is the synchronization b/w SC and WG3 due to the relatively slow progress in WG3.

 

 

 

 

 

WG3-OSC alignment

 

            Previously there was an contribution from SC submitted to WG3 which was rejected.

 

            It is clarified that X2 IE is never designed as a final spec for WG3 E2 interface; on the other hand, the pre-spec E2 implemented in OSC is heavily relies on the E2 being specified by WG3

            There is an E2AP document (not specification) available in the OSC wiki

 

            The misuse of the word “X2 IE” caused many confusion and thus discussion. It is finally clarified that IE has actually nothing to do with X2. IE has already been defined in 3GPP. The implementation here in SC is to use X2 as the transport method.

 

WG8

            Samsung indicated their interest in contribution to the SC. Yet it looks to be in the form of binary code.

 

O-DU-Low:

            The fronthaul library contribution is source code. It has been tested to be compliant with O-RAN spec. before submission, with some O-RU vendors. One is O-RAN member while the other is not.

            Risk and issue: the current L1 code contribution from Intel is in the form of binary due to license issue

            OAI showed their interest in the cooperation with O-RAN SC. There will be a presentation on Wednesday.

            BBDev: There are already some source codes in other open source projects. Some discussion in WG6, WG7 and WG8 are ongoing and the result will impact how SC could use the BBDev code. If the result is good, the SC would simply adopt the BBDev. Otherwise, there could be new requirements from the WGs and correspondingly the code needs to be extended.

 

O-DU-High

            Risk is raised on the lack of committed resource.

 

            Summary on WG8 status: relatively lag due to late start of the O-CU/O-DU-HIGH/O-DU-LOW projects in SC. Good thing is the WG8 specification is ahead of the development and thus SC could follow the spec. and ensure the alignment.

 

WG6 alignment

            The PTL, Xiaohua Zhang from Windriver is actively participating in both the WG6 and the SC, which ensured the well alignment b/w the two.

 

WG1-OAM alignment

            WG1-OAM has developed the specification. Thus the methodology that OAM project is taking is to simply follow the spec.

 

Release B planning

            Different from Release A, a targeted E2E use case could be used for the Release B, which is traffic steering use case.

            For this, as a starting point, there have already been some initial set of epics.

            Regarding the timeline, at the end of November, an initial draft set of epics will be ready. Then the WG representative and PTL should work together to check e.g. whether we need the episodes, is the epic accurate, is there any other epic etc.. The target is to freeze the Release. B planning by December.

            Following this, it is requested that each WG to send a representative to work with RSAC.

            Meantime, RSAC will work with WG2 to generate the traffic steering use case document as detailed as possible. The document will be sued as a guidance to epic design.

 

 

Amber release discussion

            Slides presented by Lusheng Ji, see here.

 

Collaboration with OAI

            Presentation from Orange on behalf of OAI, indicating the interest in collaboration with O-RAN SC. However, the concrete way is still very unclear. SC TOC co-chair will follow with Orange on this.