| min | O-RAN | Martin | Introduction to the O-RAN work Nigel explained the rationale of invitating Martin to give us an introduction of the O-RAN work - O-RAN is using Papyrus in the modeling of topology, alarm, spec, etc.
- Which are closely related to the OIMT & TAPI works
Martin's introduction - O-RAN is big. It has 10 Working Groups and many Focus Groups. Only a few people drive this (modeling work)
- There is the WG-10, which is for operations and maintenance, basically is FCAPS, interfaces, modeling, and data modeling.
- The group has decided to use the IISOMI guidelines for modeling - UML guidelines, UML-YANG guidelines.
- One of the modeling languages used is YANG. So, the group is also interested in UML-YANG mapping.
- Basically it looks at the works in IISOMI and OIMT.
- Recently TAPI was introduced into O-RAN and WG-10 to check if the TAPI topology could be used as an umbrella model for all the entities which are in the typical RAN network, including not only the RAN elments but also the transport elments for mobile core network for 3GPP.
- O-RAN:
- "Operator Defined", needs membership in order to access documents
- O-RAN Software Community (o-ran-sc.org)
- It is a Linus Foundation Project. It is open.
- Has very close relationship with O-RAN
- Martin is the chair person
- https://wiki.o-ran-sc.org/display/OAM/OAM+Architecture
 - Right - Mobile network; Bottom - user equipment; middle - RAN network; top - SMO (Service management and orchestration).
- Use what 3GPP has defined interfaces. F1 & E1 interfaces
- O2 for instantiate VN
- A1: between Near-Real-Time RIC (RAN Intelligent Controller) and Non-Real-Time RIC for policy management, which will be translated into E2 interface
- O1: FCAPS for operation and maintenance
- Martin is leading O-RAN SC and O-RAN WG10
- ND: OIMT's TR-512.A.15 might be of interests to Martin regarding O2 and O1 interfaces
- MS: Network slicing, VN needs to be set up for mobile core and RAN.
- ND: build up network resource and build up control resource, might want to discuss together.
- MS: O2 interface is also discussed in WG6 (Cloudification & Orchestration)
- The Open Fronthaul interface between O-DU and O-RU involves transport resources
- The WGs need to agree to the same terminologies and understanding across all interfaces. Thus is motivated to look into TAPI topolgy and IISOMI, UML, UML guidelines
Discussion - CH: Has the Apache Kafka been looked into? (https://kafka.apache.org/)
- MS: yes.
- It is use in the Message Bus of SMO.
- Also has high level discussion on using Kafka in the communication for the Resource pools (data center). Push validation down in the edge cloud. Not specified yet. See there is advantage of using it, but there is also concern.
- CH: Need alignment with Kubernetes and Kafka
- MS: Concern with all the RAN nodes need to learn the Kafka API
- ND: Could be sealed. Use more basic streaming in the Kafka environment. (Not XMPP) In TAPI streaming, use shoket as front end .
- CH: Domain Driven Design (DDD) Aggregation
- ND:
- TAPI streaming aggregate, TAPI compactive log, delta log, might be useful to O-RAN.
- Maybe using the core model in the same way as TAPI; Core model → implementation model to reduce the variety
- MS: Agree; so many models from 3GPP and other entities; try to map into the TAPI topology,
- CH: See any gaps in TAPI?
- MS: No.
- Everyone has node, link, termination, ...;
- This makes it easy to map to IEEE and IETF;
- Alex has a mapping table excel
- KL: Core mode TR-512.TM is Terminology Mapping
- CH: For YANG, do you look into the IEEE YANG, IETF YANG, or Open Config YANG?
- MS: have to use all of them. open-config, ...
- ND: Do you try to rationalize cases where unidirectional or bidirectional should be use ...;
- MS: O-RAN uses bidirectional, Service level defined as uni,
- ND: Everything is unidirectional, but there are cases benefit from bidirectional treatment.
- ND: Processing construct (PC) in the core model
- MS: TAPI Node, NEP, Layer protocol, CEP,
- CH: The core model got rid of NE, changed the focus to functions; O-RAN is more function base (MS: yes); Constraint Domain to group things; There are uniquqe forward looking things in the core model
- MS: The red boxes in the architeture diagram are more functions rather than network element.
- CH: Security policy enforcement point
- ND: to further discuss for presentation to O-RAN
- CH: contributions in the ONF wiki page is open to public.
- MS: 3GG has ManagedElement (ME), which groups all the functions below it.
- ND: might want to look into Control Port, Control Domain, Exposure Context (session),
- MS: In O-RAN, its model extend the 3GPP model. They see the O1 interface (for FCAPS) terminate on the ME, not on the function.
- ND:
- Actual functions,
- Representation of an assembly of the functions;
- Talk to X about Y,
- Talk to a view controller about a view;
- MS: Need to group the functions and treat them
- ND: Component-System pattern
- MS: Another discussion would like: Moving of function from one data center to another data center
- MB: need to distinct the function and the underlying supporting infrastructure; need to separate the function & the view of the function from the thing that supports the function,
- ND: key thing is separation of the view; multiple views, view mapping function, each view is a subset of the resources of the underlying network
- CH: Partitioning and aggregation are two fundamental concept in the inventory areas, see that in storage technology, data center, compute
- ND: Recursive, general recursive pattern,
- MB: separation of the infrastructure and the ..
Follow up - Nigel and Martin to have 1-1 discussion, including providing help in O-RAN
- Then update to OIMT
Liaison - MS: O-RAN has liaison process but not very effective. Usually more effective through individauls. Lyndon? ONF is more open than O-RAN.
- CH: Before careful about IPR
|
| 4 min | Progress of TR-512 (rel. 1.5) | Nigel | Nigel reported on the progress of TR-512 release 1.5. - Previously done: .2 (F/T), .4 (Topo), .5 (Resi), .6 (Phy)
- Newly done: .8 (Contr). Will send to Kam to verify.
- Will do TR512.3 (N/I), TR-512.7 (Spec; has diagram problem), TR-512.17 (Stat)
|
