E2E Network Slicing use case: Honolulu Architecture Review

Owned by Swaminathan Seetharaman
Last updated: Dec 08, 2020
3 min read

1- Brief Project Overview (brief as it should be known)

This use case intends to demonstrate the modeling, orchestration, assurance and optimization of end-to-end network slices, including RAN, Transport and Core slice sub-nets. This use case shall support different deployment scenarios of the Slice Management & Orchestration functions through a modular architecture and standards-based interfaces.

5G Network Slicing is one of the key features of 5G. The essence of Network Slicing is in sharing network resources (PNFs, VNFs, CNFs) while satisfying widely varying and sometimes seemingly contradictory requirements to different customers in an optimal manner. Same network is expected to provide different Quality of Experience to different consumers, use case categories and industry verticals including factory automation, connected home, autonomous vehicles, smart cities, remote healthcare, in-stadium experience and rural broadband. An End-to-End Network Slice consists of RAN, Transport and Core network slice sub-nets. This Use Case intends to demonstrate the modeling, orchestration and assurance of a simple network slice (e.g. eMBB). While 3GPP standards are evolving and 5G RAN and core are being realized, this Use Case will start with realizing an E2E Network Slice with a simple example of a 5G RAN, Core and Transport Network Slice sub-nets. It will also align with relevant standard bodies (e.g., 3GPP, ETSI, IETF, TM Forum) as well as other open initiatives such as O-RAN where relevant, w.r.to both interfaces as well as the functional aspects.

2- New component capabilities for Guilin, i.e. the functional enhancements, if applicable

  1. UUI

    • Enhancements related to endpoints

    • TMF 641 APIs for Slice orchestration (stretch goal)

  2. SO

    • NSMF enhancements and NSSMF workflow enhancements for all 3 subnets (mainly fixing Guilin gaps and any minor enhancements for RAN, Core, TN for e2e slice stitching)

    • Endpoints related enhancements

    • RAN NSSI related enhancements (RAN)

    • Reuse of TN NSSI (TN)

    • Core NF config updates (Core)

    • Closed Loop related enhancements (RAN)

    • Support of Option 2 in RAN NSSMF

  3. OOF

    • NST selection enhancements

    • Use of endpoints for NSSI selection

    • CoverageArea → TA list mapping

    • TN NSSI selection enhancements (if any)

    • Generic functional enhancements (Slice profile generation, etc.)

    • Slice Profile decomposition (in RAN)

    • NSI/NSSI selection based on resource occupancy levels (under discussion)

  4. DCAE

    • Enhancements in PM Mapper/New MS for KPI computation

    • DES for historic KPI retrieval

    • Enhancements in Slice Analysis MS for Closed Loop

    • Use of CPS instead of Config DB

  5. CCSDK/SDN-C

    • Align with CPS interface

    • A1 interface towards Near-RT RIC

    • TN NSSI reuse - config updates

  6. CDS

    • Core NF config updates

  7. AAI

    • Modeling enhancements (Slice Profile, End points)

  8. CPS

    • Support models related to Network Slicing

    • API mapper service (to be discussed)

  9. ExtAPI (stretch goal)

    • TMF 628 support

3- New or modified interfaces

  • Interface to CPS (from OOF, SO, DCAE, SDN-C)

  • SO ↔ OOF

  • OOF ↔ DCAE (under discussion)

  • SO ↔ CCSDK/SDN-C

  • OOF ↔ SDC

  • SDN-C ↔ RAN (O1 interface)

  • SDN-C ↔ RAN (A1 interface)

  • Internal interfaces within SO (NSMF ↔ NSSMF Adaptor ↔ NSSMF)

4- If they are modified, are they backwards compatible?



6- Interface naming (point to an example)



7- Consumed API from other projects

Project

API Dependency

Notes

APi Specs

(Swagger)

Project

API Dependency

Notes

APi Specs

(Swagger)


























































































8- Published API

Project

API

Notes

APi Specs

(Swagger)

Project

API

Notes

APi Specs

(Swagger)



































9- Reference to the interfaces.

(Reference to the the swagger.json file(s) whenever possible)

10- What are the system limits?

.

11- Involved use cases, architectural capabilities or functional requirements.



12- Listing of new or impacted models used by the project (for information only).

  • Identify any High Level Information Model Requirements.   See: ONAP R7 Modeling High Level Requirements

    • Models based on information exchanges from Use Cases

    • Models documenting existing implementations

    • Forward looking models that may be implemented in future releases

  • Describe how exposed APIs are mapped to information models

(list all the relevant Jira tickets)



13-Test plan/Testing Strategy

  1. Unit Testing

  2. Dev-to-Dev Testing  and

  3. Integration



14- Any other details that are specific to this functional enhancement or UseCase.