A Discussion on: A1-PMS Compliance with O-RAN Specifications

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

TODO: use v3 api spec

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, 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.