Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Current »

This page captures the details of the updated FM message (alarm) reported by RAN (Sim) towards ONAP over VES, and the associated processing.

Niranjana Y and krishna moorthy to note.

Assumptions

  1. A separate alarm will be sent for each collision and each confusion.
  2. An explicit alarm_off condition will be sent by RAN to ONAP (severity: NORMAL).
  3. An alarm on/off shall be sent only once by RAN-Sim. We don't cover cases of alarm message getting "lost".
  4. Though the alarm itself shall contain sufficient information for triggering OOF, we shall not make updates to CPS based on it. CPS updates for neighbor list changes shall be done only by SDN-R and only upon reception of CM-Notify and a Control Loop message from Policy.

Updated FM message

{

   "event":{

      "commonEventHeader":{

         "version":"4.0.1",

         "vesEventListenerVersion":"7.0.1",

         "domain":"fault",

         "eventName":"Fault_RansimAgent-Wipro_RanPCIProblem",

         "eventId":"fault000001",

         "sequence":1,

         "priority":"High",

         "reportingEntityId":"de305d54-75b4-431b-adb2-eb6b9e546014",

         "reportingEntityName":"ncserver2",

         "sourceId":"cc305d54-75b4-431b-adb2-eb6b9e541234",

         "sourceName":"Chn0025", //denotes the cell experiencing the issue, this can continue to be the same

         "startEpochMicrosec":1451772223000000, // denotes the start time of the problem, can be same until issue is resolved.

         "lastEpochMicrosec":1451772403000000, // indicates the current event time. This value will be updated for each subsequent event for a given fault, hence updated each time.

         "timeZoneOffset":"UTC-05:30",

         "nfNamingCode":"RansimAgent",

         "nfVendorName":"Wipro"  

         "eventCategory: "PCICollision" (or) "PCIConfusion"

      },

      "faultFields":{

         "faultFieldsVersion":"4.0",

         "alarmCondition":"RanPciCollisionConfusionOccurred",

         "eventSourceType":"other",

         "specificProblem”: “<Cell-id(s) of the cell(s) causing the problem, separated by commas>”

         "eventSeverity":"CRITICAL", //NORMAL for clearing

         "vfStatus":"Active",

         "alarmAdditionalInformation":{ //This is not needed now

           "networkId":"NTWK005",

            "collisions":"1",

            "confusions":"1"

         }

      }

   }

}

Impacts

Enhancement

Impact details

Use the above updated layout for further processing

  • SON-Handler MS: Receive and process the message.
  • RAN-Sim: Generate the message.

Note: To be checked if VES 7.2 spec shall be used (and any impacts due to using it).

VES 7.2 schema

Send 1 alarm for each collision/confusion

  • SON-Handler MS: Time/count to wait before triggering OOF to be fine-tuned
  • RAN-Sim: Generate separate alarm onset messages. Alarm messages also have to be stored in DB and used when sending alarm-clear notification.

Send 1 alarm clear message for each collision/confusion getting cleared (eventSeverity: NORMAL)

  • SON-Handler MS: Clean up local DB only upon receipt of alarm cleared notification
  • SON-Handler MS: We have to maintain an interim state wherein alarm was received and handled (but alarm-clear is not yet received) to differentiate it from alarm-received and not handled case. Enhancement: There should be a timeout for this interim state, which should correspond to the timeout for (n)ack from Policy for the CL. Upon expiry of the timer, it should be moved to "alarm-received and not handled state".
  • RAN-Sim: Send alarm clear message upon receipt of config update from ONAP, after verifying that the problem is resolved. Clear the local DB entry.

Components Impacts:

SON Handler MS


RAN-SIM + Honeycomb




  • No labels