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.

NSI Selection

Options while instantiating a new NSI that can be shared:

...

Note: This is a draft proposal and will be taken up for discussion. This is a stretch goal for Istanbul.



Option 1Option 2
Instantiation of new (shareable) NSI (and its constituent NSSIs)

Instantiate the NSI (and constituent NSSI) so that it can cater to some additional dimensions, e.g., allow for 20% buffer (the 20% may come from Policy or be pre-configured).

Impacts: SO (NSMF and NSSMF), SDN-R/C ???

Note: This could also come from NST (and OOF shall determine appropriate NST considering dimension attribute values in Service Profile), but it will result in many NSTs needed to be created. Alternatively, we could also have T-shirt size policies (small, medium, large) for every NST. This could be used by SO/OOF.

Instantiate it only with the required dimensions as required by the Service Profile.

Reuse of existing NSI
  • Consider (static) spare capacity based on allocated resources and ability to cater to the new Service Profile. Good short-term solution.

Impacts: OOF (logic) - the (example) 20% configuration should be accessible to both SO and OOF

(OR)

  • Consider (predicted) dynamic spare capacity (considering also peaks) (and minimum guarantees for existing Service Profiles), and ability to cater to the new Service Profile. This will be a good long-term solution if implemented properly.

Impacts: DCAE (Slice Analysis MS - data analysis, API/interface for querying by OOF), OOF (query DCAE, logic)

This solution could work with Option 1 and Option 2.

  • Consider (predicted) dynamic spare capacity (considering also peaks) (and minimum guarantees for existing Service Profiles), and ability to cater to the new Service Profile. This will be a good long-term solution if implemented properly.

  • Impacts: DCAE (Slice Analysis MS - data analysis, API/interface for querying by OOF), OOF (query DCAE, logic)

Consider 
  • To start with, we can only consider if there is dynamic spare capacity. Subsequently, feasibility (and cost) to scale can also be assessed. This will also help to cover slice "modification" scenario to some extent.
Reuse of existing NSSISimilar approach as for NSI.Similar approach as for NSI.
Closed Loop

If SLAs of one or more services mapped to a shared NSI/NSSI are impacted adversely, scaling or re-mapping (including slice splitting/creating a new NSI/NSSI) should be considered.

If SLAs of one or more services mapped to a shared NSI/NSSI are impacted adversely, scaling or re-mapping (including slice splitting/creating a new NSI/NSSI) should be considered.
Points to consider

Which dimension attributes to consider - maxNumberofUEs, bandwidth, throughput, ???

Notion of capacity (soft, hard)

Current resource occupancy levels

Scaling and modification (expansion of coverage area, resource reallocation)

...

What minimum guarantee should we ensure such that the existing services are not disrupted unnecessarily?

What about attributes such as endpoints and coverageArea? Perhaps they will be a second step.

Which dimension attributes to consider - maxNumberofUEs, bandwidth, throughput, ???

What minimum guarantee should we ensure such that the existing services are not disrupted unnecessarily?

What about attributes such as endpoints and coverageArea? Perhaps they will be a second step.