Versions Compared

Old Version 2

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.

...

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



Option 1Option 2
DescriptionCapacity will

Notion of capacity (soft, hard)

Current resource occupancy levels

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

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) (Possibly also KPI Computation MS) (Also Slice Analysis MS or KPI Computation MS has to invoke DES API for historical PM/KPI data)

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) (Possibly also KPI Computation MS) (Also Slice Analysis MS or KPI Computation MS has to invoke DES API for historical PM/KPI data).

  • To start with, we can only consider if there is dynamic spare capacity. Subsequently, feasibility (and cost) to scale can also be assessed and OOF recommendation can be based on this also. 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, ???

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.

...