The A1 is Mediator listens on the northbound interface in of the RIC for policy guidance. The northbound caller (e.g., non RT RIC, RIC Dashboard, SMO, etc.) creates policy types and and policy instances through A1, and subsequently A1 exchanges messages are exchanged with xappsxApps via RMR.
You can find the A1 RESTful API in the A1 repoPlease see here for the docs: https://gerrit.o-ran-sc.org/r/admin/repos/ric-plt/a1 under the file ("a1/openapi.yaml")You can find the documentation here: https://docs.o-ran-sc.org/projects/o-ran-sc-ric-plt-a1/en/latest/. Exactly what belongs there and what belongs here is a bit murky.
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.
Xapps supporting A1
This wiki page may be useful for discussion about the A1 Mediator, feel free to post comments here.Please see: Supporting A1 policies