O-RAN O1 Interface Specification specifies the format of the CM Notification VES message sent from the RAN NF (e.g, CU, DU) to the SMO. The SMO has collectors to receive the VES message, which is forwarded to appropriate SMO Functions to update any relevant CM control algorithm and any relevant database. In the London release, we plan to build on existing work and achieve the following for INT-2177 - Getting issue details... STATUS

  1. Define a CM Notification VES format aligned with the latest consensus in O-RAN, OSC, 3GPP
    (e.g. O1 spec v08.00, 3GPP Rel 18
    see OpenAPI/TS28532_ProvMnS.yaml · Rel-18 · SA5 – Management & Orchestration and Charging / Management and Orchestration APIs · GitLab (3gpp.org)
    ref thanks to Martin Skorupski )
  2. Define an efficient, model-driven path to identify the MOI and attribute whose value has been changed

    (e.g. use notifyMOIAttributeValueChanges or notifyMOIChanges as appropriate)

Relevant background on this topic.

  1. OSC work on CM Handling (Nov 2021). The following page
    CM handling guide - Developer Wiki - Confluence (onap.org) 
    describes a CM VES message and procedure for handling it, especially mapping the schema url to a local url. This refers to a 3GGP Rel16 scheme which needs to be updated to https://forge.3gpp.org/rep/sa5/MnS/-/blob/Rel-18/OpenAPI/TS28532_ProvMnS.yaml
  2. ONAP work on defining a CM VES message. This is an older format and does not have a path specified, but may be useful in designing the solution
    https://jira.onap.org/secure/attachment/17656/CMNotificationFormat_son_poc.json



Sample CM VES message for notifyMOIChanges (as of 3/21/2023. See R12 Use Case Files - Developer Wiki - Confluence (onap.org))

{
  "event": {
    "commonEventHeader": {
       "domain": "stndDefined", 
       "eventId": "stnddefined000001", 
       "eventName": "stnddefined_Metrics", 
       "lastEpochMicrosec": 1670938742757000, 
       "nfNamingCode": "CUCP", 
       "nfVendorName": "Capgemini Engineering", 
       "priority": "Normal", 
       "reportingEntityId": "nearrtric-22_cucpserver2", 
       "reportingEntityName": "honeycomb", 
       "sequence": 0, 
       "sourceId": "nearrtric-22_cucpserver2", //strong assumption that this is globally unique among all 
       "sourceName": "Capgemini Engineering", 
       "startEpochMicrosec": 1670938742757000, 
       "stndDefinedNamespace": "3GPP-Provisioning", 
       "timeZoneOffset": "UTC+05:30", 
       "version": "4.0.1", 
       "vesEventListenerVersion": "7.2" 
    }, 
    "stndDefinedFields": {
      "schemaReference": "https://forge.3gpp.org/rep/sa5/MnS/blob/Rel-18/OpenAPI/TS28532_ProvMnS.yaml ", 
      "data": {
         "href": "https://172.16.100.130/restconf/data", 
         // added /restconf/data to be the MIB Root
         // added https://
         // url of ip server hosting the GNBCCU NF
         // 3GPP 28.532 Table 12.1.1.4.1a.8 -1: Definition of type NotifyMoiChanges description is "URI of the local root in the MIB"

         "notificationId": 1, 
         "notificationType": "notifyMOIChanges", 
         "eventTime": "2021-08-23T11:52:10.6Z", 
         "systemDN": "xyz", 
         "moiChanges": [  
           {
             "notificationId": 123, 
             "correlatedNotifications": [], 
             "additionalText": "AdditionalTextDetails", 
             "sourceIndicator": "MANAGEMENT_OPERATION", 
             "path": "/ran-network:ran-network/NearRTRIC=22/GNBCUCPFunction=cucpserver2/NRCellCU=15549/NRCellRelation=14427",
             // Added the leading / See comment from Martin in O1 CM Update Notification VES Message
             // modified to make the path relative to the "MIB Root" as defined in the href above
             // The VES msg from a RANSim GNBCU NF has NearRTRIC in the path to be aligned with the yang model used in RANSim. In general, a real GNBCU (1:1 mapping between GNB and GNBCU) yang model may not show a GNBCUCPFunction as a child of a NearRTRIC. The path identifies the object being changed, with the attributes being listed in the value field.
             "operation": "replace", 
             "value": { 
               "isHOAllowed": "true"
             }
           }
         ]
      }, 
      "stndDefinedFieldsVersion": "1.0" 
    }
  }
}



  • No labels

4 Comments

  1. Vishal Varvate

    sample_ves_message.json

  2. N.K. Shankaranarayanan

    Added the sample CM json VES msg in wiki (also uploaded file) we presented on 2/16/2023 at LFN DTF. 

  3. kieran mccarthy

    Priyank Maheshwari N.K. Shankaranarayanan Toine Siebelink 


    Same comment as added to R12 Use Case Files...

    Following on from meeting earlier today ...

    On the cm_ves_rel12.json,  Suggest that the path makes more sense to be relative to the model and the href is the root of the MIB which for me is the root of the model tree.

    Suggested updates to href and path as below ...

        "stndDefinedFields": {
          "schemaReference": "https://forge.3gpp.org/rep/sa5/MnS/blob/Rel-18/OpenAPI/TS28532_ProvMnS.yaml ", 
          "data": {
             "href": "172.16.100.130/restconf/data",    // added "/restconf/data" to be the MIB Root
             // url of ip server hosting the GNBCCU NF
             // 3GPP 28.532 Table 12.1.1.4.1a.8 -1: Definition of type NotifyMoiChanges description is "URI of the local root in the MIB"
             "notificationId": 1, 
             "notificationType": "notifyMOIChanges", 
             "eventTime": "2021-08-23T11:52:10.6Z", 
             "systemDN": "xyz", 
             "moiChanges": [  
               {
                 "notificationId": 123, 
                 "correlatedNotifications": [], 
                 "additionalText": "AdditionalTextDetails", 
                 "sourceIndicator": "MANAGEMENT_OPERATION", 
                 "path": "ran-network:ran-network/NearRTRIC=22/GNBCUCPFunction=cucpserver2/NRCellCU=15549/NRCellRelation=14427",      // modified to make the path relative to the "MIB Root" as defined in the href above
                 // The VES msg from a RANSim GNBCU NF has NearRTRIC in the path to be aligned with the yang model used in RANSim. In general, a real GNBCU (1:1 mapping between GNB and GNBCU) yang model may not show a GNBCUCPFunction as a child of a NearRTRIC. The path identifies the object being changed, with the attributes being listed in the value field.
                 "operation": "replace", 
                 "value": { 
                   "isHOAllowed": "true"
                 }
               }
             ]
          }, 
          "stndDefinedFieldsVersion": "1.0" 
        }


    Additionla Note on Root.

    Restconf specification Section 3.1 details getting the root (at least up to "data" or "operation"). 
    Following from that the proposal above is that CM notifications are relative to "{restconf-root}/data" as the root of the yang tree data.

  4. Martin Skorupski

    If  the VES message transport information from a RESTCONF Server, then please add also the protocol:

    "href": "https://172.16.100.130/restconf/data"

    Please see all the examples in 3GPP TS 28.532 -search for 'href:',

    I need to stress that O-RAN management interfaces such as O1 and OpenFronthaul-Management-Plane specifying NETCONF as protocol. 


    Regarding the 'path' value:

    Unfortunately, the examples are not right clear if there should a leading "/" or not - from "case 8" onwards the "/" is "missing".

    Looking to the examples of https://www.rfc-editor.org/rfc/rfc8040.html#section-3.5.3 (as referenced by 3GPP TS 28.532 12.1.3.2.5 Notification notifyMOIChanges ) I assume the "path" value should better start with "/":

    "path": "/ran-network:ran-network/NearRTRIC=22/GNBCUCPFunction=cucpserver2/NRCellCU=15549/NRCellRelation=14427"