OOF API updates are available in Network Slicing API Specifications. The updated swagger is available at https://gerrit.onap.org/r/#/c/optf/osdf/+/100477.

OOF impacts are described in OOF_impacts_v1.0.pptx.

Assumptions

1. The  capability set in the template will not contain range of values
2. Subnet template details will be loaded as Subscriber policy
3. NSI Name will be unique in AAI
4. Slice profile in NSSI is chosen based on latency (Conductor)

Illustrations

1. Call from SO to OOF to Get suitable NST

Inputs: Service Profile parameters

Assume Service Profile contains throughput =7, BW = 10, latency = 22.

Assume that the following NSTs are present in the inventory (at present maintained locally within OOF)

Based on above inventory, and attributes in service profile (not attribute values), (NST1, NST3) are shortlisted.

Attribute Policy contains the value ranges (capability set of each NST). For e.g.:

OOF selects NST3 by comparing the attribute value ranges with attribute values in service profile (it has only NST1 and NST3 to choose from).

2. Call from SO to OOF to get suitable NSI

Inputs: Service Profile parameters, NST id

Assume Service Profile contains latency = 22 ms, and NST is that of a URLLC slice (say NST_URLLC1). Assume that the request indicates that the provided NSI can be shared with another service.

NST_URLLC1 has NSST_URLLC_RAN2, NSST_URLLC_Core1, NSST_URLLC_TRAN2 as its constituent NSSTs - this is specified using Subscriber Policy.

The Attribute Policy specifies the latency capability for NST_URLLC1 as (20..100 ms) (as discussed above).

Assume the latency ranges supported by the above NSSTs which are part of NST_URLLC1 are as follows (fetched from Attribute Policy).

Now there are 4 possible solution categories that OOF can provide in the response to SO.

1. Provide an existing NSI which can be reused/shared
2. Create a new NSI with existing NSSIs
3. Create a new NSI with some existing NSSIs and some new NSSIs
4. Create a new NSI with all new NSSIs

To address all cases above, HAS is invoked with 3 demands (NSST-RAN, NSST-Core, NSST-Transport).

Let us assume that the NSI inventory is as follows:

Say, HAS returns the foll. solutions:

Solution 1 = (NSSI-R-1, NSSI-C2, NSSI-T1)

Solution 2 = (NSSI-R-1, (Core-slice profile), NSSI-T-3) (assuming NSSI-T-3 has NSST_URLLC_TRAN2 as its template).

OSDF then does the following:

• For Solution 1, it sees:

NSSI-R1 is part of NSI-1,NSI-4
NSSI-C2 is part of NSI-1, NSI-10
NSSI-T1 is part of NSI-4, NSI-1

There is a common "NSI" which is "NSI-1". So NSI-1 can be reused. It fills the shared NSI solutions part of response to SO with NSI-1.

• For solution 2, NSSI-R-1, NSSI-C-new, NSSI-T-3 => It fills New NSI solutions part of the response to SO with NSSI ids and slice profile(s).