Skip to main content

SLA Policy Enforcement

This diagram describes the sequence of interactions involved in creating, deploying, and monitoring an SLA policy in an O-RAN architecture. It includes components such as the SLA rApp, Non-RT RIC (Policy and DynxApp Controllers), OAM, Near-RT RIC (SLA xApp), and gNB.

SLA Policy flow

Overview​

An SLA policy is initiated by the SLA rApp and handled by the Non-RT RIC. The Non-RT RIC performs validation, identifies target Near-RT RIC instances, and determines which xApps need to be deployed to fulfill the policy. These xApps are dynamically deployed via the DynxApp Controller and OAM.

Once the xApps are operational, the Non-RT RIC sends the policy to the Near-RT RIC over the A1 interface. The SLA xApp, now running on the Near-RT RIC, uses the E2 interface to communicate with the gNB to send RAN Cotrol (RC) and KPM subscription.

A control loop is established to maintain the requested throughput defined by the SLA. The gNB periodically sends KPM Indication Messages to the SLA xApp on the Near-RT RIC. Based on these metrics, if the SLA xApp detects a performance issue or deviation from policy objectives, it can proactively adjust slice parameters by sending RC Requests to the gNB to adjust the number of PRB allocated to the slice.

The SLA rApp can query the policy status via the Non-RT RIC to ensure enforcement.

Sequence of Operations​

  1. Create Policy Request

    • SLA rApp → Non RT RIC (Policy Controller)
    • Interface: R1 - SDK
    • Action: Submit SLA policy request
    • Payload:
      • nearRtRicId
      • policyTypeId
      • policyObject

  2. Policy Controller Processing

    • Validate the policy
    • Generate a unique PolicyID
    • Identify target Near-RT RIC
    • Determine appropriate xApp(s) for enforcement

  3. Return Policy Response

    • Non RT RIC (Policy Controller → SLA rApp)
    • Action: Return confirmation with PolicyID

  4. Request xApp Deployment

    • Non RT RIC (Policy Controller → DynxApp Controller)
    • Interface: CR
    • Action: Instruct deployment of identified xApp(s)
    • DynxApp Controller monitors xApp startup and readiness

  5. Deploy xApp

    • DynxApp Controller → OAM
    • Action: Request physical deployment of xApp(s)

  6. xApp Operational

    • DynxApp Controller confirms xApp is operational

  7. Send Policy to xApp

    • Policy Controller → Near RT RIC (SLA xApp)
    • Interface: A1
    • Action: Push policy to SLA xApp using A1 interface
    • Payload: policyObject

  8. E2 Interface Setup

    • SLA xApp → gNB
    • Action:
      • Send RC Request to create a slice in RAN
      • Subscribe to KPM data via KPM Subscription Request
    • Receives:
      • RC Response
      • KPM Subscription Response

  9. A1 Policy Acknowledgement

    • Near RT RIC (SLA xApp) → Policy Controller
    • Action: Confirm policy enforcement

  10. Get Policy Status

    • SLA rApp → Non RT RIC (Policy Controller)
    • Action: Query enforcement status of the policy using PolicyID
    • Response: Policy is Enforced

  11. Control Loop

    • gNB ⇄ SLA xApp
    • Action (Periodic):
      • Send KPM Indication Messages with performance metrics to the SLA xApp
      • Process and respond to RC Requests from the SLA xApp to adjust slice parameters dynamically

You can run the SLA rApp and observe this workflow in the rApp training lab.