The core slicing feature introduced in the Guilin release included the functionality to instantiate 5G core NFs as part of the slice order scenario. The 5G core dummy Helm charts and the CDS CBA packages created as part of the use case demonstration accepted the S-NSSAI as an input to configure the 5G core NFs.

However, there are several other parameters that would also be required to be configured after the 5GC NFs are instantiated. Typical parameters include –

  • List of PLMN IDs
  • List of TACs
  • List of DNNs
  • Certain QoS parameters
  • Any other

By design it is expected that there would be no need to change the core NSSMF code to support configuration of additional parameters in the 5GC NFs. It is expected that CDS CBA package could be designed to resolve the required parameters and then use the resolved values to configure the NFs. Some of the values could be resolved from NSI and NSSI service instances from the AAI.

However for two scenarios as below, the approach still needs to be decided –

  1. DNN configuration – Since DNN is not part of any slicing data, it needs to be seen how to obtain this value and use it for the slicing scenarios (Same applies for QoS parameters)
  2. Configuration of UPF IPs in SMF and configuration of SMF IPs in AMF – The CNF instantiations in ONAP currently may not support this. It would be advisable that the 5G core NFs – AMF and SMF use the NRF to discover the poll of NFs that they are supposed to manage

As part of this release we are planning to extend the CDS CBA blueprint to include some additional parameter apart from S-NSSAI to be configured in the NF.

  • No labels

7 Comments

  1. Srinivasa Addepalli

    Milind Jalwadi


    Thanks for posting this. 


    One question that I did not get the answer from above :  Say that you have X number of locations (K8s clusters) where CN CNFs are expected to be deployed for a given slice (say it is non-shared).  Where is that information on which locations & CNFs that need to go each location specified?  There are two possibilities I can think of:


    • Possibility 1:
      • Let it be job of NFVO.  Let the admin create network service on  behalf of each slice.  When network service is created (Composite application in case of EMCO), one can specify the locations for each CNF (helm chart) as the placement intent.
      • Use this network service reference in CN NSSMF Sliceprofile (Is this part of Sliceprofile or is it part of something else?)
      • When Slice is configured, let the CN NSSMF instantiates the network service and let the NFVO take care of instantiating at multiple locations as specified by network service intents. 
    • Possibility 2:
      • NFVO is configured with generic network service with no placement intents. 
      • CN NSSMF is configured with the information related to placement.
      • CN NSSMF dynamically creates placement intents in NFVO and then instantiates the network service with new placement intents.


    Based on the code, I get an impression that we are going with possibility 1.  Is that right understanding?


    I guess, during activation of the slice,  CN NSSMF assumes that any configuration being made is applied to all CNF instances in that network service. That is, even if SMF/AMF/UPF are instantiated Y number of times across X locations,  CN NSSMF only makes one call to NFVO/CDS  and expects NFVO/EMS  propagates configuration information (SNSSAI) to all CNF instances. Is that right understanding?


    1. Milind Jalwadi

      Hi Srinivasa Addepalli- Much of what you have stated in possibility 1 would happen. Also you are correct in your observations in the last para.

      The placements of NFs as part of NS instantiation which would get triggered by core NSSMF shall happen thru' the ONAP mechanisms utilizing the existing components such as SO, OOF, CDS etc. I guess the NST / NSST templates specify the tracking area or location info - which should be used by OOF to determine the placements of the NFs within the NS. 

      But from core NSSMF perspective it shall only be doing two things -

      A. Instantiating a NS associated with NSST

      B. Configuring the existing NS associated with a NSST during slice LCM operations


      All other placement and configuration logic should be catered by OOF / Policy / CDS


      Thanks.

  2. Srinivasa Addepalli

    Milind Jalwadi ,


    While going through the code (https://github.com/onap/so/blob/6a96e6067400fbc0b4b64e4cbadeb9a74ed72eb9/bpmn/so-bpmn-infrastructure-common/src/main/groovy/org/onap/so/bpmn/infrastructure/scripts/DoAllocateCoreNonSharedSlice.groovy), I see that there is bh_endpoints variable that is supposed to have CN UPF IP address related information and that information is getting stored in A&AI. I guess 'bh' means backhaul.

    Is that functionality used in G release? I did not see any code that is setting up the bh_endpoints variable with IP addresses.  In any case, I had these questions.


    1.  I guess there would be multiple UPF instances. So, is it that there would be multiple IP addresses and routes in A&AI.  is that right?
    2.  Who is expected to use the information that is stored in A&AI?


    Thanks
    Srini


    1. Milind Jalwadi

      Sorry Srinivasa Addepalli- I don't think we have done these changes. May be Swaminathan Seetharaman can comment on this. 

      1. Swaminathan Seetharaman

        With ref. to the endpoints both in RAN and Core side for backhaul, only some basic implementation has been done in G-release, and it cannot be said to be fully functional. With ref. to having multiple UPFs in Core, yes, this is a realistic scenario, however, it is not just about endpoints alone, but we should also set up the TN NSSI to connect with these multiple UPFs, and if there are multiple RAN nodes, we are looking at Multipoint to multipoint connectivity in Transport side. I don't think that part has been fully addressed in TN NSSMF, and would require more work as we go forward. Only the foundation has been done in G-release. Henry Yu can also comment reg. the transport aspects.

        Reg. the endpoint info users, it would be NSMF and TN NSSMF to my understanding.

  3. Srinivasa Addepalli

    Milind Jalwadi ,   based on your understanding, what are the core functions that can be dedicated or what functions have to be global across the slices?  I understand that NSSF (Network Slice Selection Function) is expected to be global as this is the one referred by gNB to select the AMF as part of PDU session establishment.   I do understand that AMF, SMF, UPF, NRF can be on per slice basis.  How about other core network functions.  I would imagine that they also could be specific to each slice.  Any thought?


    It seems to me that every time new slice is added, there is an expectation that NSSF is configured with right information about slice specific NRF URIs, Slice & TA/RA/PLMN specific AMF policies etc..  Which module is taking care of configuring NSSF. BTW, I do get an understanding S-NSSAI is being configured in various NFs via CDS.  But, did not see anything related to NSSF.  Did I miss something?

    1. Swaminathan Seetharaman

      Srinivasa Addepalli All your comments are valid (smile) In the Guilin release, we have looked at a limited set of Core NFs, and when deciding to spin up a new Core NSSI, we instantiate ALL Core NFs; similarly, when deciding to reuse an existing Core NSSI, we reuse ALL Core NFs of the existing Core NSSI. In a real deployment, we are likely to have situations where some Core NFs have to be instantiated (in the appropriate DC) while some can be reused when instantiating a new Core NSSI. This has implications in the way Core NSSI is modeled, and as well in orchestration workflows, and as well as the (re)configuration of the (reused) Core NFs.

      Regarding the (re)configuration of Core NFs, at present only S-NSSAI is being sent to the Core NFs from ONAP. There is a proposal to extend it further in H-release (as briefly described by Milind in this wiki page). Reg. NSSF and its (re)configuration, we haven't considered it yet.

      We would certainly welcome inputs and contributions in this space from you. Kamel Idirwanted to also contribute to this area.