Page History

A1 is the northbound interface in the RIC for policy guidance. The northbound caller (non RT RIC, RIC Dashboard, SMO, etc) creates policy types and instances through A1, and subsequently messages are exchanged with xapps.

...

...

...

...

Policy Overview

There are two "object types" associated with policy: policy types and policy instances. 

Policy types define the name, description, and most importantly the schema of all instances of that type. Think of policy types as defining a JSON schema for the messages sent from A1 down to xapps.

Xapps do not receive policy types from A1, types are used only by A1 to validate instance creation requests from north of the RIC. However, xapps must register for instances of type ids in their xapp descriptor. 

Xapp developers can also create new policy types if they invent new policies; the exact process of where these are stored is still TBD. For practical purposes, when the RIC is running, a CURL needs to be send from somewhere to load the type. 

Policy instances are concrete instantiations of a policy type. They give concrete values of a policy. There may be many instances of a single type. Whenever a policy instance is created in A1, messages are sent over RMR to all xapps registered for that policy type; see below.

Xapps can "sign up" for multiple policy types using their xapp descriptor. 

Xapps are expected to handle multiple simultaneous instances of each type that they are registered for. 

RMR Communication

See https://rancodev.atlassian.net/wiki/spaces/RICPLT/pages/60784719/RIC+message+types

A1 to Xapps

Please see for this documentation

...

: https://

...

docs.o-ran-sc.org/

...

projects/o-ran-sc-ric-plt

...

-a1/en/latest/overview.html#integrating-xapps-with-a1

For message types, see https://rancodev.atlassian.net/wiki/spaces/RICPLT/pages/60784719/RIC+message+types

...

All policy instance requests get sent from A1 using message 20010

Xapps to A1

There are three scenarios in which Xapps are to send a message to A1:

...