Versions Compared

Old Version 1

changes.mady.by.user Benjamin Cheung

Saved on

compared with

New Version 2

changes.mady.by.user N.K. Shankaranarayanan

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Attendees

DISCUSSION ITEMS LOG


CtgryItemWhoNotes
Meeting Notes Discussion
  1. OOF-SON A1 ORAN & ONAP Coordination - SON U/C - actions ONAP & ORAN Interface. Harmonization. Discussions using SDN-R for O1 I/F. Aspects of U/C done by Near-RT RIC by A1 e.g. (new A1P parameters) USE CASE for neighbor relations: Network to identify nbrs w/ poor hand-offs. To work out how ONAP & ORAN work together. Take part of existing U/C show how it fits w/ A1 I/F. SON branching out A1 adaptor & SDN-R. WG2 A1 (WG3 Near RT RIC). ONAP U/CR 5G Call. krishna moorthy - NearRT RIC to terminate s-bound A1-Link. Nokia OSC NearRT RIC. To introduce new parameters. The A1 link itself is agnostic to the use case. On either end you would need a Driver, existing SON micro-services. Southbound need something to Receive the policy something (simulator) of NearRT RIC. xApp plug-in. Semi-standardized use cases as requirements drivers. New SON case doesn't need to go through standards. Don't need to standardize every use case. If need for multi-vendor. Demo concept, then show need for standardize. 
  2. AP = Application Protocol - ORAN.WG2.A1AP (DOCX) - defines the REST interface to query policy types, create policy instances. CRUD operations of policy instances. Policy type agnostic. The spec that defines the management of A1 Policies.
  3. TP = Type Definitions - ORAN.WG2.A1TP (DOC) Define a particular A1 Policy Type reuse across Use Cases. Policy types are examplar. Defines different types, and the usage of the actual A1 Policy and information for that. for STANDARDIZED type. If the SON team wanted to define their OWN types just for their use case, they would NOT to change the specs. Change the specs only for a multi-vendor coordination. Most use cases wouldn't need to do that. Define types as json schema. Once both ends understand the schema it can be any type, the arch is xApps at the NearRT RIC. at N-bound would have rApps in NonRT RIC.
  4. Use Case Doc - Captures the Use Cases used by the A1 Policy.
  5. xApp from one vendor and an rApp from different Vendor. Friday there is a SON Use Case Call. Saravanan Ayyadurai will be on the call.
  6. For the SON U/C sending policies from N end provide schema to pass as policy JSON schema. Southern end would need a NEW s-termination of A1-interface, look at existing implementations. ORAN OSC Near-RT RIC and simulators.


Bounce from ns2438@exo.att.com  - N.SK. Shankar - (Update: Please send mail to nk.shankar@stl.tech)

USEFUL LINKS for ORAN A1 Policy

ORAN A1 (WG2) DOCUMENT LINKS: https://oranalliance.atlassian.net/wiki/spaces/NonRTRIC/pages/131347/Contributions

ORAN OSC NearRT RIC (xApp) implementation to south-bound end of A1 Policy:

OSC Simulator: https://docs.o-ran-sc.org/projects/o-ran-sc-sim-a1-interface/en/latest/

(Stateful test stub, realistic end-point; terminates the interface, key part of application protocol working, test stub or basis of a new simulator)

OSC near-RT-RIC - Platform: https://wiki.o-ran-sc.org/pages/viewpage.action?pageId=1179659

(Platform is xApp independent terminates the A1/O2/E2 interface)
OSC near-RT-RIC - xApps: https://wiki.o-ran-sc.org/pages/viewpage.action?pageId=1179662

(The Apps is an umbrella project, hot pluggable into near-RT platform, the logic is in the Apps)

Team from Samsung, pushed seed code to demo sleeping cell U/C, had mService taking place of rApp and reuse of simulator s-bound with logic for sleeping cells.

...