Weekly Meetings: OOF-SON Meetings 

For the Frankfurt/El Alto Release page, please see: OOF (SON) in R5 El Alto, OOF (SON) in R6 Frankfurt

For the Dublin Release page, please see:
Requirements and Test Cases: OOF-PCI Use Case - Dublin Release - ONAP based SON for PCI and ANR 

OOF-PCI Dublin Release Plan: 5G - OOF and PCI (Casablanca carry-over items)

For the Casablanca Release POC page, please see: Casablanca PoC 


Links to Other Pages/Documents:

Documentation files will be uploaded to this Dublin 5G Use Cases page:  5G Use Case (R4 Dublin)Overview (ppt): https://wiki.onap.org/download/attachments/29788530/OOF_PCI_proposal_v4_20180822.pptx?api=v2

SDN-R Documents page: SDN-R Documents

OOF Architecture page: OOF Casablanca (R3) Architecture Alignment

OOF-PCI API spec: PCI Optimization API

Details of PCI Handler microservice, RAN-simulator (ppt):
 https://wiki.onap.org/download/attachments/29788530/PCI_microservice_proposal_v6_Aug22_2018.pptx?api=v2

Policy Code Changes Planned: https://wiki.onap.org/download/attachments/29788530/5GUseCase_OOFPCI_Policy_Impacts_v_0_3.pdf?api=v2 

Casablanca OOF-PCI PoC Demo - Slides

https://wiki.onap.org/download/attachments/29788530/OOF_PCI_POC_Demo_20181213.pptx?api=v2 

Casablanca OOF-PCI PoC Demo - Call Recording

https://wiki.onap.org/download/attachments/29788530/ONAP%20Casablanca%20OOF-PCI%20Use%20Case%20POC%20Demo.mp4?api=v2

Dublin OOF-PCI PoC Demo - Slides

https://wiki.onap.org/download/attachments/68539437/OOF_PCI_Dublin_POC_Demo_20190724_v_2.0.pptx?version=1&modificationDate=1564034905299&api=v2

Dublin OOF-PCI PoC Demo - Call Recording

https://wiki.onap.org/download/attachments/68539437/zoom_0.mp4?version=2&modificationDate=1563985740000&api=v2



Older content for Casablanca PoC (Need to move Gliffy Diagram below)

PCI Optimization based on trigger from SDN-C (RAN Config Change)



OOF - PCI Optimization - RAN Config Change Copy Copy




  • No labels

21 Comments

  1. Ranny Haiby

    Could you please clarify under which project will the PCI-Handler micro-service be developed? SDN-C(R)? OOF? DCAE?

  2. N.K. Shankaranarayanan

    Ranny,

    PCI-Handler microservice will be part of OOF or DCAE, and not SDNC(R). We show it separately to highlight the interfaces and data flow, so that the community can jointly decide where it belongs.

    Regards,

    Shankar

  3. Arash Hekmat

    Up until now, OOF has not been a part of Closed-Loop with CLAMP. So far (Beijing), the analytics micro-services run in DCAE and from DCAE they call operational Policies to make configuration changes to the network.

    Isn't DCAE the right place for the PCI-Handler-MS? Of course, as shown above, the PCI-Handler-MS running in DCAE can still ask OOF for optimization decisions.

    Specially given that SON is a big functional area and theoretically many more much more complex SON related micro-services need to be implemented in the future, isn't DCAE the right place for them? Given DCAE's recent features for on boarding and deployment of micro-services. These capabilities don't exist in OOF.

  4. Damian Nowak

    I think, it depends, if the PCI-Handler-MS makes decisions based on events sent by a Network Function (FMs, PMs, RT-PMs) or on the configuration fetching (site-survey).
    There was a site-survey approach idea in SDN-R PoC, that has been discussed in the public forums; and a DCAE MS operating on FM/PM/RT-PM events.

    I`d say – if PCI-Handler-MS makes decisions based on events generated by Network Function only - then clearly - DCAE.
    If based on anything else - then probably OOF is the right place.

    Perhaps, that PCI-Handler-MS shall split to 2 x micro-service – and we`d have the FM/PM/RT-PM analyzer in DCAE, and a PCI-Handler in OOF.
    PCI-Handler would then take the results of the FM/PM/RT-PM analyzer as one of it`s inputs.

    What would be the MVP here? (Minimum Viable Product)
    Do the community see that the PCI-Handler use-case shall act based on FM/PM/RT-PM streams, or is it enough to make decisions based on other information sources (e.g. site-survey from a controller only)?

  5. Arash Hekmat

    Where would the UI controlling all this be? How does the user trigger an optimization or track/monitor the state of the ongoing optimizations? (if it is not closed-loop/CLAMP)

    1. N.K. Shankaranarayanan

      My understanding is that CLAMP is not in scope for 5G for Casablanca and so we are leaving that for a future stage. For a POC using this flow, we can simulate a change in the RAN and send a NbrList change notification to SDN-C.

      1. Damian Nowak

        All right, so this would mean, that we really run this 5G RAN optimization service as part of OOF, rather than DCAE, at least for the PoC.

  6. Dhruv Gupta

    For Flow B, step 3(b) (PCI, NBR list config data change notification):

    1) Is the expectation that RAN element will use Netconf notification capability to provide periodic updates to SDNC(R)?

    2) If yes for (1), what is the status of ODL support in SDNC(R) to support such notifications? What exact RFCs are supported, or planning to be supported? If no for (1), what methodology is used for getting config change notifications?

    1. N.K. Shankaranarayanan

      There has been discussion in SDN-R calls of such change notification being done via Netconf. We plan to discuss this and SDN-C support in SDN-R team call on 7/25.

  7. N.K. Shankaranarayanan

    To make progress in Casablanca, we are focusing only on Flow B and a minimum viable product. The previous content has been moved to the OOF section, with the link in the note at the top of the page. Some steps have been removed, and the flow numbers re-assigned to make it easier to read. The table with test cases has also been updated.

  8. N.K. Shankaranarayanan

    This is a response to both Arash and Damian re. location of the PCI Handler MS. Based on discussions, we see more support for the PCI Handler MS to be onboarded on to DCAE. The MS calls OOF in a Request for Optimization / Get Results mode. Regarding the minimum viable product, the objective is to make progress in ONAP with the disaggregated flows. It is easier to start with the trigger from SDN-C in keeping with the spirit of choosing PCI as the simplest SON function. In later work, we can bring in the FM/PM data and other functions. 

    1. Damian Nowak

      Fair enough, thanks.
      What were the pros of selecting DCAE to host the PCI-Handler-MS? Is this a long-term goal or a solution for PoC?

  9. Shanth Ramakrishnan

    Reg. Step 3 - Config change notification,

    a. what information is present in the notification?

    b. How are the nbr's represented/identified in the notification?

    c. how often is this notification expected to happen during normal operations? (may not be a question for the PoC).


    Thanks,

    Shanth Ramakrishnan

    1. N.K. Shankaranarayanan

      Some context: For this use case, we wanted to develop the interface between SDN-R and the RAN, including notifications. We picked the NbrList (neighbor list) as a config parameter that is related to PCI. We assume we can simulate a NbrList change separately (e.g. to mimic something like ANR). We should leverage any standard methods available. Therefore, the answers are:

      a) Notification is for a change in NbrList, with the new NbrList. Could be just the delta for add / delete if we assume that the old NbrList is in the database.

      b) It would be based on the format used for the cellid in the model. Could be the full list of cellids, or the set for add / delete.

      c) I don't have a number. We should consider the impact of several changes occurring simultaneously.  And also what level of activity would stress the ONAP loop. Note that every change does not trigger a re-optimzation, and we envision that there is logic in the MS to determine when to send an optimization request. .

  10. Ferri Tafreshi

    Since PCI Handler MS is not taking any action on the results of OOF, the steps 8 and 9 are waste steps in the process. Step 6 would suffice in providing the results to the Policy. 

    Also 4 needs to be bidirectional as different types of Handlers require different information. 

    1. N.K. Shankaranarayanan

      Thanks. Agreed that step 4 is bidirectional. It is perhaps good to separate it into step 4a with a DMaaP notification and step 4b where PCI-Handler MS gets more information from SDN-C.

      Regarding the comments for step 8/9 and step 6, we need more discussion. Policy may not have enough context for the OOF results without some input from PC-Handler MS.

  11. Andrew Baxter

    Please can you explain where the PCI numbers are being allocated from or is the algorithm simply working off the live cell data? Thank you.

  12. N.K. Shankaranarayanan

    The algorithm has as an input the range of PCI integers that are available. In this use case, the network has an existing assignment and changes have to be made. So it will also have the currently assigned values from the database and try to minimize changes. The algorithm could also start from scratch for a completely new assignment.

    1. Andrew Baxter

      Thank you. Where does the available set of PCI numbers come from?

  13. N.K. Shankaranarayanan

    Updated slides for Dublin plans uploaded to https://wiki.onap.org/download/attachments/38119661/OOF_SON_CM_for_Dublin.pptx?api=v2 

  14. N.K. Shankaranarayanan

    We had a great PoC demo on Dec 13! Thanks to all those who have contributed and supported the PoC! Here are the links for the slides and the recording of the call.

    Casablanca OOF-PCI PoC Demo - Slides

    https://wiki.onap.org/download/attachments/29788530/OOF_PCI_POC_Demo_20181213.pptx?api=v2 

    Casablanca OOF-PCI PoC Demo - Call Recording

    https://wiki.onap.org/download/attachments/29788530/ONAP%20Casablanca%20OOF-PCI%20Use%20Case%20POC%20Demo.mp4?api=v2