| 6am PST | 6am EST | 10:00 UTC | 11:00 CET | 12:00 EET | 15:30 IST | 18:00 CST | 19:00 JST |
(please feel free to correct and update your names Thank you very much!!!)
|00:00||chair topic||no update|
2020-12-02: Thorsten Heinze
2020-12-09: Martin Skorupski
|00:00||INFO: Demo Day|
2020-12-03 16:00 CET- 18:00 CET
Joint PoC "Proof of Concept" O-RAN/OSC/ONAP
O-RAN-SC: C-Release: https://wiki.o-ran-sc.org/x/D4w_AQ
Email by Thorsten
|00:04||VLAN FC creation||Thorsten Heinze|
Creation of objects
S1 use case
new proposal by SIAE:
In order to provide to the application the "next" uuid an option could be the following:
1) Add in the model in the section "status" the "next-uuid" parameter
2) In case this "next-uuid" is influenced by some value: add in the section "configuration" the corresponding "influencer" values
i.e. with reference to the VLAN creation, in VlanFd we could have something like:
- In section "configuration": "next-vlan-fc-vlan-id"
- In section "status": "next-vlan-fc-uuid"
End of the meeting
|00:05||Issues in General|
Use case discussion challenging the model proposal:
Please see updated slides (thanks Eduardo).
Feedback from vendors:
As a result of the discussion about Firmware, their might be a need for a "restart" trigger.
The "software activation trigger" usually also leads to a "restart" but with new software, which a "restart" reboots using the currently running software.
Other terms for the same? or similar? function:
|@Eduardo Yusta||License Management|
Please see email_
Please see related issues:
Please confirm by email to Martin Skorupski by end of this week (Nov6) that keeping FM and PM for xyzStructure is ok?
Status: positive feedback to keep it as it is:
Decision: we keep xyzStructure as they are and close the issues above.
Support is welcome to consolidate with respect to RMON
|00:00||Layering discussion (FCs, FDs etc.)||Thorsten Heinze|
Discussion and agreement about the following proposal:
The following aspects are proposed to be decided by the 5G-xhaul subproject.
- The ForwardingDomain shall be interpreted as a Potential for Forwarding (e.g. SDH Matrix).
[sko] Potential: something which allows the creation of “forwarding” based in the FD:LTP
- The ForwardingConstruct shall be interpreted as an Actual Forwarding (e.g. Connection between two VC-12 endpoints at the SDH Matrix).
[sko] Actual: configured Forwarding – check operational states and traffic flow
- There might be 0 .. * ForwardingConstructs inside a ForwardingDomain.
Discussion on dependencies between LTPs, FD, FC and between the layers will continue...