ORAN is based on xRAN.
Martin explained ORAN. Depends on whether SON is targeting O-DU, O-RU or Fronthaul.
Target is O-DU and O-CU. There are CCSDK projects with interface to O-RU for Fronthaul. But we can assume that all FM/PM/CM will
come via VES. In some cases messages are copied over to VES.
O-DU: FM would be VES message. Decision of whether to use VES 7.1 (FM domain) or VES 7.2 (generic domain or fault domain). 7.2 with fault domain will be translated to 7.1. Implementations are using generic domain.
Martin and Caludio recommend using VES 7.1 since there is a working implementation.
Re. alarm sequence, the intent is to sned an alarm clear message. However, there can be errors. So the software should be prepared to handle missing and repeated alarm_clear message. Similarly, the alarm message may or may not repeat.
Image Added
Image Added
Discussion and tentative conclusions:
- Use VES7.1 with fault domain
- Use a VES structure that works for SON and generic FM.
- alarmCondition is the type of alarm. This should remain same for the alarm for subsequent messages. When the alarm is cleared, the eventSeverity goes to NORMAL for the same source/alarmCondition. In this case, alarmAdditionalInformation should change to 0 number of issues.
- reportingEntityName is the name of the netconf server with the O-1 interface
- sourceName is the entity having the alarm. WE had a discussion on whether this is the netconf device, or DU or cell. General sense was to put detail of information if it is available. e.g. it can be the yang path of the entity. It can be any of the following
ncserver, ncserver/DU, ncserver/DU/cell, ncserver/DU/cell/nbr-relation" if the information is available. - There would need to be documentaiton of what kind of sourceName is expected for each alarmCondition
- In the short-term, the choice will be guided by what makes sense for implementation, with a view towards being aligned to any longer-term target.
- This has impact on RAM-Sim which will need to generate the FM messages.
