| 6am PST | 6am EST | 10:00 UTC | 11:00 CET | 12:00 EET | 15:30 IST | 18:00 CST | 19:00 JST |
https://thorsten-heinze-telefonica-de.webex.com/join/andreas.lattoch.external
(please feel free to correct and update your names Thank you very much!!!)
Time | Item | Who | Notes |
---|---|---|---|
00:00 | chair topic | no update | |
00:00 | Admin | ||
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 | |
00:05 | Firmware | @Eduardo Yusta | Email by Thorsten https://groups.google.com/a/opennetworking.org/g/wireless-transport/c/3BJHnPa5PRU |
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 Backlog | |||
00:05 | Issues in General | INFO: https://github.com/openBackhaul/core/wiki/summary-of-issues | |
00:15 | Firmware | @Eduardo Yusta | Use case discussion challenging the model proposal: Please see updated slides (thanks Eduardo). Feedback from vendors:
Firmware inventory
Firmware operations
|
00:45 | Reboot | 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:
Questions:
General reboot
| |
@Eduardo Yusta | License Management | Questions:
First proposal:
2020-11-18
| |
PureEthernetStructure, HybridMwStructure | Daniela Spreafico | 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. | |
Roberto Servadio | RMON counter
Update: Support is welcome to consolidate with respect to RMON | ||
00:00 | Layering discussion (FCs, FDs etc.) | Thorsten Heinze |
Agenda: 2020-09-30 Discussion and agreement about the following proposal: Discussion 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. [sko] ok Discussion on dependencies between LTPs, FD, FC and between the layers will continue... Agenda: 2020-10-07
|