Versions Compared

Old Version 5

changes.mady.by.user Swaminathan Seetharaman

Saved on

compared with

New Version Current

changes.mady.by.user Swaminathan Seetharaman

Saved on

Key

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

...

1. Frankfurt Improvements

No.TrackDescriptionJiraPriorityImpactsRemarks
1.1NST selectionImplementation of NST selection in HAS
1HASCommon understanding of how to fetch template details from SDC
1.2Implement callback for NST selection
1OSDF, SO
1.3NSI
/NSSI
selectionAPI improvements - For
NSSI
NSI selection, NSST details should be provided in the request from SO
1To be updatedDuring NSI/NSSI
(NSMF). NumSolutions should be provided by SO. Service/Slice Profile attributes, json blob at the end
1
Domain type (AN/TN/CN) should be also included in the Slice Profile (Modeling consideration?)
1.4OOF response shall NOT contain NSSI info (only NSI if available/usable, and Slice Profiles will be sent back).
1

1.5

During NSI selection, when the attribute (e.g., reliability) in Threshold Policy is not part of Slice Profile, it should be ignored by HAS (error should not be returned)



HASAlready implemented
1.
5
6

Aggregate policy to be implemented, e.g., latency of all

NSSIs

Slice Profiles (across subnets) chosen to be < latency in Service Profile.


1
-

independent improvement
To be done only for Slice Profile determination, not needed for NSSIs.
1.
6
7

When considering existing NSSI as a candidate, consider ALL slice profiles (not just “best” one).


2

1.
7
8Slice profile generation - candidates should be generated at appropriate granularity
1
  • To be generated even when reusing an existing NSI
?
  • Which parameters to generate (per domain type) to be policy driven or come from Slice Profile Template, as well as should depend on the parameters received in the service profile 
1.
8
9Slice profile selection - choose best one, based on service profile, subnet capabilities (and optionally existing NSSIs, if sharing is allowed???)
1
Priority can be revisited
1.
9
10Implement callback for NSI
/NSSI
selection
1OSDFAdditional components - SO
1.
10API alignment - service/slice profile parameters, json blob at the end1OSDF1.
11Selecting "final" solution(s) by OOF based on policy - minimum change policy, maximum slice count policy, reuse policy, etc. subject to the numSolutions limit sent by SO.
2
OSDF?

HAS


OOF API

also to be updated to remove the

shall still contain 'list' of solutions

OSDF -

policy

translation of Policy

1.12NSI
/NSSI
TerminationAPI and response for NSI termination - yes or no (check Policy also)

1 - functionality

2- OOF impacted

OSDF, SORequest should come from SO acting as NSMF


2. NSSI Selection

.13
No.TrackDescriptionJiraPriorityImpactsRemarks
2.1NSSI Selection

Select appropriate NSSI, return "no solution" if no solution exists

(Send Slice Profiles also in case of RAN NSSI selection for Option 1)


1
Intention is to make NSSI selection domain agnostic.
2.2Implement callback for NSSI selection
1

2.3NSSI TerminationAPI and response for NSSI termination - yes or no (check Policy also)

1 - functionality

2 - OOF impacted

OSDF, SORequest should come from SO acting as NSSMF

NSI selection - NST and NSST info will be provided by SO (NSMF). OOF response shall NOT contain NSSI info (only NSI if available/usable, and Slice Profiles will be sent back).

NSSI selection - NSST, and any constituent NSSTs will be provided by SO (NSSMF).

API improvements - number of solutions to be given by SO.

2. NSSI Selection

...