WORK IN PROGRESS

Introduction: A1-PMS Compliance with O-RAN Specifications

The A1 Policy Management System (A1-PMS) plays a crucial role in managing policies and configurations within the O-RAN network architecture. As the O-RAN Alliance continually refines its specifications, it becomes essential to assess how well A1-PMS adheres to these evolving standards. In this discussion, I will make the comparison between the latest O-RAN API specifications and the upstream OpenAPI specifications utilized for implementing A1-PMS. Trying to examine the alignment, discrepancies, and potential areas for improvement.


Topics: optional parameters, what can be unimplementable

Simple Comparison of OpenAPI Specifications

I identidy as openapi-oran.yaml the specifications given by O-Ran Alliance revised on 31/03/2024, and openapi.yaml the upstream openapi specifications upstream in the /api folder.

Paths

openapi-oran.yaml Paths:

  1. /policytypes
  2. /policytypes/{policyTypeId}
  3. /policytypes/{policyTypeId}/policies
  4. /policytypes/{policyTypeId}/policies/{policyId}
  5. /policytypes/{policyTypeId}/policies/{policyId}/status

openapi.yaml Paths:

  1. /a1-policy/v2/policy-instances
  2. /a1-policy/v2/policy-types
  3. /a1-policy/v2/policies/{policy_id}
  4. /a1-policy/v2/configuration
  5. /a1-policy/v2/services/{service_id}/keepalive
  6. /a1-policy/v2/services
  7. /a1-policy/v2/policy-types/{policytype_id}
  8. /a1-policy/v2/policies
  9. /a1-policy/v2/services/{service_id}
  10. /a1-policy/v2/policies/{policy_id}/status

Components

openapi-oran.yaml Components:

  • Schemas:
    1. PolicyObject
    2. PolicyStatusObject
    3. PolicyTypeObject
    4. ProblemDetails
    5. JsonSchema
    6. NotificationDestination
    7. PolicyId
    8. PolicyTypeId

openapi.yaml Components:

  • Schemas:
    1. policy_type_definition
    2. error_information
    3. void
    4. status_info
    5. authorization_result
    6. ric_info
    7. service_registration_info
    8. policy_info_list
    9. policy_status_info
    10. service_status
    11. ric_info_list
    12. input
    13. policy_authorization
    14. policy_type_id_list
    15. policy_info
    16. policy_id_list
    17. service_status_list
    18. service_callback_info_v2

Simple Analysis

Paths Analysis

  • Both specifications provide endpoints for managing policies and policy types, but the structure and naming conventions differ.
  • openapi-oran.yaml has a simpler path structure centered around policytypes and nested resources within policytypes.
  • openapi.yaml includes a more complex path structure under the /a1-policy/v2 prefix, indicating versioning and a potentially more hierarchical and service-oriented approach.

Components Analysis

  • openapi-oran.yaml has a focused set of schemas primarily around policies (PolicyObject, PolicyStatusObject, PolicyTypeObject) and identifiers.
  • openapi.yaml has a more extensive and varied set of schemas including policy information, RIC (Radio Interface Controller) information, and service registration, suggesting a broader scope.
  • The schemas in openapi.yaml appear to cater to a more granular level of API operations with various status and info objects (policy_status_info, service_status, ric_info_list).

Summary

  • Paths: The openapi-oran.yaml specification uses a simpler, less hierarchical path structure, whereas openapi.yaml uses a more complex, versioned path structure indicating a possibly broader and more modular API.
  • Components: The openapi-oran.yaml has fewer and more policy-focused components, while openapi.yaml offers a wider range of schemas supporting more detailed interactions with policies and related services.




  • No labels