Versions Compared

Old Version 4

changes.mady.by.user Swaminathan Seetharaman

Saved on

compared with

New Version 5

changes.mady.by.user Swaminathan Seetharaman

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Note: This is a stretch goal for I-release.

1. General Remarks

  • Though in theory both Options may be supported in a single deployment, it will create a lot of complexities and confusions in practice (and additional side-effects and implementation overheads which have to be handled) as E2E network slicing functionality evolves. So, in a single ONAP deployment, Option 1 OR Option 2 shall be supported but NOT BOTH.
  • SO (TN NSSMF) does not support call to OOF for NSSI selection. This means, when a new NSI is created, TN NSSI (FH, BH and MH) have to be created newly.
  • SO (TN NSSMF) does not support call to OOF for determining if an NSSI shall be terminated or not. So based on the API (deallocate or modify), SO (TN NSSMF) shall decide to terminate the TN NSSI (FH, BH or MH) or not.
  • For FH and MH, we take some assumptions for the short-term: for e.g., pre-provisioned endpoint info for RU, CU and DU. If feasible, endpoints should be a list, to enable multipoint to multipoint connectivity in future. Open points:
    1. How should we specify which RU(s) should be connected to which DU(s)? This will become relevant when we consider multipoint to multipoint connectivity in future.
    2. How will endpoints be specified - will it be by topology discovery or ???

2. High-level requirements

  1. ONAP NSMF shall support Option 1 and Option 2 in a model-driven manner.
  2. ONAP RAN NSSMF shall support Option 1 and Option 2 in a model-driven manner.
  3. In case of Option 2, NSMF shall communicate with TN NSSMF for FH and MH NSSI LCM calls. This shall be aligned with the calls done by RAN NSSMF to TN NSSMF for Option 1, to keep it uniform.For FH and MH, we take some assumptions for the short-term: for e.g., pre-provisioned endpoint info for RU, CU and DU. If feasible, endpoints should be a list, to enable multipoint to multipoint connectivity in future. Open point: how should we specify which RU(s) should be connected to which DU(s)?

3. High-level Impacts

SDC

No code impacts expected. Templates have to be defined for NST containing 5 NSSTs (RAN NF, Core, TN FH, TN MH and TN BH). Suitable Service and Slice Profile templates should be available.

OOF

...

  • Ensure that the Service Profile decomposition is done into Slice Profiles, wherein the Slice Profiles to be created are determined from the NSSTs within the NST.
  • Ensure that the RAN Slice Profile decomposition is done into constituent Slice Profiles, where in the constituent Slice Profiles to be created are determined from the NSSTs within the RAN NSST.
  • Policies may have to be adapted accordingly.

SO (NSMF)

Important Note: Almost all actions below can be implemented in a model-driven manner. For example, SO (NSMF) can invoke appropriate calls to the NSSMFs for each of the (first-level) NSSI associated to the NSI or for each Slice Profile received from OOF. This will enable future extension and customization based on deployment needs without any code impacts (e.g., Fronthaul may not be "sliced" in some deployments).

...

  • Clear workflow separation to be ensured between top-level RAN NSSI (as in Option 1), and RAN NF NSSI (for both options).
  • RAN NSSI workflow should invoke RAN NF NSSI workflow for RAN NF NSSI related actions for Option 1 (due to workflow separation). This shall be in the same format as NSMF would invoke RAN NSSMF for Option 2 (for RAN NF NSSI related actions).
  • Upon receiving a call from NSMF, SO (RAN NSSMF) should determine if the top-level RAN NSSI workflow or RAN NF NSSI workflow should be invoked. RAN NSSI workflow should invoke RAN NF NSSI workflowHow/where this decision shall be taken shall be left to the implementation (API Handler or ...).
  • RAN NF NSSI workflow should be concerned only about RAN NF NSSI actions, including:
    • (Both options) RAN NF NSSI selection (may not exist today for Option 1) upon allocateNSSI call for RAN NF NSSI. (Note)
    • RAN NF NSSI modification (Option 1: During NSI/RAN NSSI reuse scenarios during slice allocation, as well as when NSI/RAN NSSI is decided not to be terminated; Option 2: During NSI reuse scenario as well as when NSI is decided not to be terminated)
    • (Both options) RAN NF NSSI termination determination by calling OOF (this may not exist today for Option 1, and RAN NF may be automatically terminated when a RAN NSSI is decided to be terminated), and associated actions upon deallocateNSSI call for RAN NF NSSI.
    • RAN NF 

...

    • (Both options) RAN NF NSSI activation and deactivation.

Note: This may require some modeling updates in the manner in which RAN NSSI and RAN NF NSSI are associated (templates and in AAI).

  • RAN NSSI shall invoke TN NSSMF in a model-driven manner, i.e., based on the RAN NSSI constituents or the Slice Profiles returned by OOF for selectNSSI API call for RAN NSSI selection. This will enable extensibility and customization (e.g., no Fronthaul slicing in the short term).

AAI

No changes foreseen. Schema shall support both 3 as well as 5 NSSIs linked to an NSI, and 3 or 5 Slice Profiles linked to a Service Profile.