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 10 Next »





The scope of this page is to explore the use of ETSI  (Nested) Network Services model at Design Time and Run Time in the context of the Network Slicing. 


The Guilin Service IM allows for a (nested) Network Service (NS) model that is referenced from an ONAP Service.

Since the NS can be composed VNFs, CNFs, PNFs and nested NSs, the ETSI NS model is well suited to describe the hierarchical structure of 3GPP Network Slice Subnets.

3GPP TS.541 Slice Model


Design Time:

  



Design Sequence:

  1. Onboard 5G Core NFs (NRF, PCF, UDM, AUSF, NEF, AMF, SMF, UPF) into SDC
  2. Onboard RAN NFs (vCU, vDU) insto SDC
  3. In SDC, design a "Central" Network Service composed of
    1. "central" NFs (NRF, PCF, UDM, AUSF, NEF)
    2. Virtual Link (Control Network) for the SBA interface
    3. SAP(s) for all of the exposed entry points
  4. SDC distribute the resulting SOL007 NS package to the ETSI Catalog (and any one else interested, SO??)
  5. In SDC, design a "User Plane" Network Service composed of:
    1. "user plane" NFs (AMF, SMF, UPF)
    2. Virtual Link (Control Network) for the SBA interface
    3. Virtual Link (RAN Network) for the interface to the RAN components
    4. Virtual Link (Data Network) for the (external) data/internet interface
    5. SAP(s) for all of the exposed entry points
  6. SDC distribute the resulting SOL007 NS package to the ETSI Catalog (and any one else interested, SO??)
  7. In SDC, design a "RAN" Network Service composed of:
    1. "RAN" NFs (CU, DU)
    2. Virtual Link (Control Network) for the SBA interface
    3. Virtual Link (RAN Network) for the interface to the RAN components
    4. SAP(s) for all of the exposed entry points
  8. SDC distribute the resulting SOL007 NS package to the ETSI Catalog (and any one else interested, SO??)
  9. In SDC, design a "Complete" Network Service composed of:
    1. Scalable reference to the RAN NS
    2. Scalable reference to the UP NS
    3. Scalable reference to the RAN NS
  10. SDC distribute the resulting SOL007 NS package to the ETSI Catalog (and any one else interested)
  11. In SDC, Design a "Central" Service composed of
    1. A reference to the "Central" Network Service
    2. A CDS blueprint (CBA) for configuring the "Central" Service
    3. Behavioral policies for the "Central" Service
  12. SDC distribute the resulting "Central" Service package
  13. In SDC, Design a "User Plane" Service composed of
    1. A reference to the "UP" Network Service
    2. A CDS blueprint (CBA) for configuring the "UP" Service
    3. Behavioral policies for the "UP" Service
  14. SDC distribute the resulting "UP" Service package
  15. In SDC, Design a "RAN" Service composed of
    1. A reference to the "RAN" Network Service
    2. A CDS blueprint (CBA) for configuring the "RAN" Service
    3. Behavioral policies for the "RAN" Service
  16. SDC distribute the resulting "RAN" Service package
  17. In SDC, Design a "Complete" Service composed of
    1. A reference to the "Complete" Network Service
    2. A CDS blueprint (CBA) for configuring the "Complete" Service
    3. Behavioral policies for the "Complete" Service
  18. SDC distribute the resulting "Complete" Service package

Runtime

Starting state:

  1. SOL004 Packages for Central, UP and RAN NFs in the ETSI Catalog
  2. SOL007 Packages for Central, UP, RAN and Complete NSs in the ETSI Catalog
  3. Service Packages Central, UP, RAN, and Complete NSs in SO Catalog
  4. Policies available in DCAE
  5. CBAs in CDS
  6. VIM & CISM regions (NE, SE, S, C, N, NW, SW) in A&AI
  7. NS Configuration data available for each instance:
    1. NE (UP, RAN)
    2. SE (UP, RAN)
    3. S (UP, RAN)
    4. C (Central)
    5. N (UP, RAN)
    6. NW (UP, RAN)
    7. SW (UP, RAN)

Instantiate:

  1. NE (UP, RAN)
  2. SE (UP, RAN)
  3. S (UP, RAN)
  4. C (Central)
  5. N (UP, RAN)
  6. NW (UP, RAN)
  7. SW (UP, RAN)


NOTEs:

1) CST chain of objects and NST chain do not have any relation at DT. 

  • Alloted resource is used to tell the relationship that will be defined at Run Time. The NST will be selected at runtime.

2) The VF:NSTAR is defined as an allotted Resource (see step 3) and it is composed by the Allotted Resource v1.0 template. 

Allotted Resource v1.0 is a default template already present in ONAP SDC, it is NOT an object created by a user.




----

Only relevant slides for the modeling discussion have been capture in the next pages.



Design EmbbCn Service Template

Design EmbbNst Service Template


Design Allotted Resource



Observation #1: The VF:NSTAR is defined as an allotted Resource (see step 3) and it is composed by the Allotted Resource v1.0 template. 

Allotted Resource v1.0 is a default template already present in ONAP SDC, it is NOT an object created by a user.



Question #1 : Are the providing_service_uuids (variant and invariant) defined at DT  ?

Answer: Providing_service_invariant_uuid and providing_service_uuid are declared input in SDC but NOT filled in at DT, which will be filled in the runtime with the selected NST service invariant id and service id.

CST and NST has NO relation at Design Time


Design Service Profile Template







Question #2 : Are the allottedresource_providing_service_uuids (variant and invariant) defined at DT  ?

Answer:  allottedresource_providing_service_uuids


Question #3:  the fact that for the realization of a CST, it will be required a NST at run time, it seems it is NOT indicated at Design Time so I was wondering where it will be indicated to ensure the orchestrator will look for a NST instead of ANY other type of object (i.e. a NSST or a generic Service or even a Resource). 



Question #4: I was also trying to prepare a similar representation from a resource/service instances prospective. Do you have any picture you can share ?





  • No labels