Use case proposal: 5G- RAN deployment, Slicing, SON

Folks, Please use the "LATEST" document (without change marks) for providing your inputs (comments, suggestions, contributions etc.); this would allow the reader to attribute suggestions/changes appropriately.

The next review of the document is scheduled for August 17, 11-12 EDT - See zoom info below.

5G Use Case Discussion

ONAP Meeting 3 is inviting you to a scheduled Zoom meeting.

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/926506738

Or iPhone one-tap (US Toll): +14086380968,,926506738# or +16465588656,,926506738#

Or Telephone:
Dial: +1 408 638 0968 (US Toll) or +1 646 558 8656 (US Toll)
+1 855 880 1246 (US Toll Free)
+1 877 369 0926 (US Toll Free)
Meeting ID: 926 506 738
International numbers available: https://zoom.us/zoomconference?m=fVEW3lbNLOBQ0oV57R-B2aWXKdzg-VTA

In today's status readout to the Use Case sub-committee, there were some comments (from Alla Goldner, Yoav Kluger & Alexander Vul et al) suggesting that, in addition to capturing the architectural impacts in the document, we post the architectural requirements identified in support of the use case under Architecture Requirements for R2 use cases section in the wiki.

Hi, Shekar

What is the procedure for modification of the document?  Make changes directly in the version N and upload as the version N+1? Submit changes in a separate contribution?

Thanks

Vladimir

Hi Vladimir

As Ciena & Ericsson have done above, please take the "5G_RAN_UseCase_v4-noMarks.docx" version and mark with your suggested edits/changes - once the team discusses the changes on the call, we can include the changes in the subsequent version. Hope that helps.

Regards,

Shekar Sundaramurthy

Hi Shekar,

What happened with the comments and suggestions by Ciena and Ericsson on v4, they seem to have disapeared in the v5 document although they are mentioned in the revision history of the document?

Br, Peter

Peter, I had put in a placeholder with a comment indicating that it is part of the planned discussion for Aug 24 (tomorrow) - I was under the assumption you were going to continue to complete the pre/post items based on comments received - your original/initial suggested text are still in the v4 doc - please let me know if this clarifies - didn't mean to confuse folks.

During the ONAP use case call last week, there was a suggestion to use “standard’ or ‘already established’ names/titles for the use case actors – I was provided an ONAP SDC contact who may be able to help with that (Michael Lando) – however, I haven’t had any feedback about established names for use case ‘actors’.

For now, to keep the exercise simple and focused, my suggestion is to use the following 3 actors:

VNF/PNF Provider:                         The supplier of the network/service function (and it’s underlying infrastructure) – e.g. VNF/PNF vendors

ONAP Service Designer:               The ONAP designer (user of ONAP design studio) that on-boards the VNF/PNF and defines/models the workflows/analytics/policies/extensions
for management/automation using the ONAP Design Studio

Service/Network Operator:                               The ONAP operations user (operator of the realized service managed by ONAP) that processes the various dashboards/reports/logs and responsible for other management functions (change/configuration etc.)

Here are the 3 action items that I took away from today's meeting:

1)      Ericsson (Peter Loborg et al) to continue with the use case description by adding “pre” and “post” conditions for the first 2 cases

2)      Vmware and AT&T (Ramki Krishnan & Sarat Puthenpura) to provide similar edits for the expanded optimization case

3)      A&T (Vimal Begwani) to provide pictorial representation of R1 use case samples (sequence diagrams) to use as reference for depicting these R2 use cases

Regards,

Shekar Sundaramurthy

Hello,

I just uploaded suggestions from Cisco, on the optimization part

Thanks

Vladimir

Uploaded document received from Sarat Puthenpura, Ramki Krishnan et al - further updates on the Optimization section

Hello, All

When/how next version (v6?) will be created? 

Thanks

Vladimir

Based on discussion from the 8/31/17 meeting, I created 5 pages (see top of the page) for direct update of the wiki by the respective section contributors - Feel free to upload your word documents (if you choose) to call out specific changes you have made (with markings). I filled in the "Introduction" sub-page and look to the respective section authors to update the other sub-pages. Hope this helps,

Regards,

Shekar

Also added a section for "ONAP Optimization Framework (ONAP-OF) and Multi Cloud (ONAP-MC)"

Regards,

Shekar

Thanks for incorporation of the contribution by Cisco!

(I will appreciate adding the name of the company to the list of contributors.)

Vladimir

Is there any way we could make wiki pages out of those documents? Attaching documents instead of generating wiki pages is really not best practice for ONAP use cases (this is the only one)  and makes it very difficult to find the current version tracking history. 

Oliver

I don't know if in Wiki, version tracking would be possible at all.

That said, I agree that we need better the version management. Having some experience, I can propose the process, of course, if the group is interested

Thanks, Raghu. Let me ask this.

We need to

1. Publish the clean baseline version N

2. Collect change proposals based on N (with rev. marks)  - sort of branching

3. Discuss and approve (some of) the proposed changes

4. Create clean version N+1.

How this can be done in Wiki? 

All,

Please use the instructions in the attached document to create flow diagrams for each sub-case.

Vimal Begwani

Dear All,

  I have created the attached response to the set of questions from the Architecture subcommittee regarding our 5G RAN / Slicing / Optimization use case.  Please review and let me know if you have additional comments.

Regards,

Vimal

Dear Vimal and All,

> 4.    Do we need to consider enhanced networking features (e.g., underlays)

> Not applicable

In the scenario when a network slice is instantiated (or modified), cannot underlays be involved, e.g. in the part of networking resources allocation (re-allocation)?

Thanks

Vladimir

All

  I have created a page for "Summary Functional Requirements arising from 5G Use Case" at 

Summary of Functional Platform Requirements arising from 5G Use Case

Please review and enhance with your comments/updates.

Regards,

Shekar

Hi all! Whom can i reach out to discuss potential collaboration and contribution to 5G use case development?

Dmitriy,

  I just forwarded meeting invitations for our group discussions.

Vimal,

I did not receive any invitations. Can you please advise where/how the invitations were posted?

Vladimir Yanover (Cisco)

Hi, Vimal

Should we add one more Sub Case about Transport?

This is also main part of 5G Network, provide connectivity between Central and Edge Clouds, and also area for Slicing and Optomisation.

Thanks, Evgeniy.

Shekar,

Thanks for the ControllerScope_v3 contribution. Now it looks much better.

Still, I have a couple of comments/questions. I understand that some of the parts mentioned below are not new, but should not we try to be as clear as we can? 

1. I am not sure what "Disaggregated core" means. At this level of details, there is only one 5G core architecture in 3GPP specified in 23.501 which is not using the term "disaggregated".

2. The diagrams  show separated CP and UP nodes; seems natural to show also CP and UP connectivity separated

3. The terminology "Front Haul"/"Mid Haul" does not match that of 3GPP where Fronthaul means link between CU and DU

4. "5G Base Station" usually means the combination RU + DU + CU-UP + CU-CP.  

5. Generic VNF Controller is said to provide for network application configuration of various nodes. In this context I wonder why it is marked as L4-L7. Much of configuration (e.g. in RAN) is applied to lower layers. So if it is about what is configured, "L4-L7" must be wrong. If it is about what entities provide configuration, in 3GPP management system is not explicitly associated with any of network layers, so again "L4-L7" is wrong.

Thanks

Vladimir

PNF Onboarding (ONAP Plug & Play) Use Case and architectural flow. (Note you should download the slides, the previewer sometimes shows just mathematical symbols in the web-PPT-viewer).

Best regards, -Ben Cheung

Meeting today (2/15/18) discussed the establishment of a liaison between ONAP and 3GPP - there were 3 volunteers (Anatoly-Nokia, Vladimir Yanover-Cisco, Benjamin Cheung-Nokia) whose names are being referred to the use-case subcommittee chair. If you are interested in adding your name to the volunteer list please reach out to Vimal or Alla.

Shekar Sundaramurthy

Team,

  As per our discussion yesterday. I have started capturing requirements for Casablanca release to support 5G network deployment and Radio Slice Segment creation.  Please review them and add your comments or suggest changes.  Requirements for optimization and OOF are still under construction.  Marge-Nokia please feel free to add requirements under optimization section.  Sarat-ATT will work on OOF.

Vimal Begwani

Explanations to the "Cisco proposed changes 5GucCasablanca-031618"

The purpose of the proposed changes is mostly to align with 3GPP terminology.

Slide #3

1. Radio Slice Segment => Radio Network Slice Subnet Instance (3GPP term)
2. “Focus initially on RAN Slices Using A Simple Model” – not clear what the simple model is. Deleted
3. “Use complex services (composite, allotted resource, etc.) to manage (model, on-board, create, configure, monitor) the slices” – not clear what “complex” means in this context (nested?). Replaced with “Lifecycle management of Radio Slice Subnet Instances” (that can be nested per 3GPP definition)

Slide #4

1. The term "Disaggregated core" does not exists in 3GPP – deleted
2. The role of the (incomplete) list of the 5G Core nodes is not clear – deleted
3. The term “5G Base Unit” is not common - deleted. If “Base Unit” means Base Station, it’s CU+DUs+RRUs, not the CU alone
4.  “Low and high” partitioning in the “CU-CP – Centralized Control Plane (low and high)” and “CU-CP-H/L” is not defined in any (known to me) standard. So it should be either clearly defined (which is not really in the scope of ONAP.org) or referenced or removed. In the meantime it’s deleted.
5. “Macro Radio & Small Cell Antennas” – modified to the “Radio Antennas”.
6. The diagram does not match the first phase of 5G, so called Non-Stand-Alone (NSA) architecture where the gNB is backhauled to the 4G RAN. To address this, a separate diagram may be needed – to discuss in the group.
7. “Edge Analytics” - made a separate bullet as it is not necessarily combined with the Near-real Time Data Collection.

Slide #5

1. “Disaggregated 5G RAN consists of hybrid network elements (PNF and VNF) and will require a cloud infrastructure deployment at the edge.”   => “Disaggregated 5G RAN may include VNFs” in which case cloud infrastructure deployment at the edge is required.  Beijing implemented the first phase of PNF discovery and instantiation
2. The term “PNF Radio Element Controller” is not defined in ONAP (neither “Radio Element Controller” nor “Element Controller“) – deleted
3. “such as Assign, configure, deactivate, etc.” Where these LCM examples come from? Need to add reference or remove - deleted

Slide #6

1. The term "Disaggregated core" is not used in 3GPP – deleted
2. “E2E Slice Instances (NSIs)” => “Network Slice Instances (NSIs)”, per 3GPP definition
3. “Core Network Slice Segments (NSSIs)” => “Core Network Slice Subnet Instances (NSSIs)” , per 3GPP definition
4. “Transport Slice Segments (NSSIs)” => “Transport Network Slice Subnet Instances (NSSIs)” , per 3GPP definition
5. “RAN Network Slice Segment (NSSIs)” => “Radio Network Slice Subnet Instances (NSSIs)” , per 3GPP definition
6. The blue frame extended to include “Transport Abstraction Model” and all xHauls
7. Added blue frame to associate the Core NSSIs and “Core Abstraction Model” with the Centralized Cloud
8. “Macro Radio & Small Cell Antennas” – modified to the “Radio Antennas”.
9. The role of the (incomplete) list of the 5G Core nodes is not clear, particularly for the slice management (e.g. AMF is not there) – deleted

Slide #7

1. “and Services implemented across PNFs & VNFs” – there is no concept of sharing the services as a part of slicing in 3GPP where “service” means the service provided to the end user. Modified to “sharing network functions and network slice subnet instances”
2. Multiple changes “Slice segment” => “Network Slice Subnet Instance”, per 3GPP terminology
3. “Define and instantiate monitoring and management of slice segments, slice instances and slice services”  – “slice services” need explanation (Slice as a Service?); in the meantime deleted
4. “Slice segments supported and demonstrated in Casablanca will be limited to two smple slices, eMBB (enhance Mobile Broad Band) and URLLC (Ultra-Reliable, Low-latency Communications) in the RAN” – not clear why these two slice types are considered “simple”. The URLLC probably is the most complex in implementation as it requires extremely low latency. The sentence is made less restricting.

Based on today's call, there are seemingly at least two processes for ONAP's role in RAN slicing:

Process-1: ONAP takes "service requirements" as input and translates this into a slice request (e.g., Service A uses Slice X) for "5G slice management system". The gap here is that ONAP needs to collect a minimum set of data (e.g., what slices are running in the 5G cloud, their performance characteristics, utilization, etc.) to correlate the service requests with an existing RAN slice.

Process-2: ONAP is used to onboard, configure, instantiate an e2e 5G slice that will be consumable by new services at the end of the process-2 (where Process-1 kicks in).  For this to work, there should be a vendor agnostic workflow for onboarding and configuring VNFs/PNFs with vendor-specific (most likely opaque) software and configuration. The model here is that vendor X deploys a network slice over operator Y's cloud infrastructure. There are many options here: (1) Existing VNFs & PNFs already have the slice implementation and they are simply configured to activate/deactivate these preloaded slices. (2) Existing VNFs & PNFs are upgraded/loaded with new software/hardware. (3) New VNFs & PNFs are deployed, configured, launched.

Both processes can be done without ONAP knowing anything about RAN-specific configuration, radio resource management, etc., that are internal to the vendor provided functions.

Blue boxes and interfaces are to be implemented by ONAP components.

I have a few questions related to this:

1. In 3GPP specifications, do PNFs in the 5G network have to support Network Slicing as well as the VNFs? (I assume Yes)
2. Does 3GPP specify exactly what is a Network Slice and how it should work or does 3GPP leave it open to the vendors to decide?
3. Have 5G vendors converged on what exactly is a Network Slice and how it should work or is each vendor implementing it in a different way?
4. Does 3GPP specify a Configuration protocol (i.e. NETCONF/Yang) for configuring 5G network components or does 3GPP leave it open to the vendors to decide?

Thanks.

Thanks Ulas.

It appears that the concept of "Network Slices" is very much similar, or modeled after, "MPLS Tunnels" in core IP networks. A "Pipe" with a "QoS Contract".

The job of provisioning a pipe with a specific QoS contract through a large network is not an easy task. In core IP networks, there are long established protocols for "Traffic Engineering" and "Path Calculation" defined for this purpose. Whatever entity (ONAP?) that is responsible for calculating a slice path, that guarantees a QoS contract through the network, needs to be aware of all consumed and available resources on every physical network equipment and cloud infrastructure equipment involved in the network.

Hi Shekar,

Can you please upload the latest slides which were discussed today?

Thanks,

Ramki

Shekar Sundaramurthy - please tweak 'midhaul' to 'fronthaul-II' in figures .... similar to slide 4 in http://sites.ieee.org/sagroups-1914/files/2017/12/tf3_1710_maiden_ngnm_xran_1.pdf, ie., RU--(NGFI-I)--DU---(NGFI-II)–CU. Midhaul is typically for between cell sites, eg., macro<>small or macro<>macro, for example. So, in the 5G view, gNB <> gNB as a whole versus within gNB.

Sigmar Lust - regarding soft/hard isolation, see clause 10 in https://www.itu.int/dms_pub/itu-t/opb/tut/T-TUT-HOME-2018-PDF-E.pdf. It is essentially about impact to one slice vs another. One example i suggested was a separate CU-UP instance, e.g., identified by a different flow ID (eg., VLAN in a eCPRI frame) and processed by a different VNF/server/etc. depending on what isolation level we want. For the purposes of our initial efforts, we can decide that soft isolation is a reasonable starting point.

@Shekar Sundaramurthy - can you please make the following changes in the latest casablanca requirements deck in slide 7 "Radio Network Slice Management – ONAP Requirements"

• Add in Description 
  • Enhance Multi-Cloud and A&AI to support Guarantee (hard isolation), Burstable (soft isolation) and Best Effort (no isolation) QoS classes for Edge Clouds

• Add in Impacted ONAP components

  • Multi-Cloud, A&AI

Ramki, can you please clarify what hard/soft/no isolation mean?

Explanation to the changes made in 5GucCasablanca-03222018v3_Cisco.pptx.

The main issue is request for extending the OF functionality to network optimization like SON. We think feasibility of such extension needs additional study, for the following reasons:

1. The OF so far is to optimize very few parameters. There are exactly three types of NFVI resources; the optimization goal can be easily expressed in terms of utilization of these resources.

As different from that, RAN alone has several dozens of KPIs, hundreds of PM measurements and hundreds OAM parameters that control RAN operations.

2. In the OF, the situation(resource allocation) is under full control of the orchestration system.

As different from that, RAN is an open system, strongly affected by the Core Network, mobility, interference etc.

3. NFV resources are independent while RAN KPIs are not. RAN OAM parameters typically affect multiple KPIs, subject to multiple tradeoffs.

4. In most scenarios, once VMFs are instantiated and provided with certain resources, they do not influence each other in terms of resources

There are multiple aspects in which RAN nodes influence each other: interference, mobility etc.

5. There is a developed and commonly accepted “theory of virtualization”: what are NFVI resources, VNFs and PNFs , which LCM operations exist, what is Network Service (per ETSI) etc.

As different from that, there is no commonly known “theory “of network optimization; existing solutions are proprietary.

To summarize, RAN is much more complex and much more complex and open system than the orchestration system. We can therefore expect that implementation of RAN optimization may differ in many points from what is currently defined in the OF 

In order for OOF to be able to make the right RAN optimization decisions, ONAP has to first implement the discovery and continuous update of RAN resources (PNFs, QoS, OAM, ...) and populate the RAN data in a database (A&AI?) to be used by OOF. This RAN resources discovery function could be implemented in SDN-C or in a new ONAP RAN management module.

Arash, in RAN optimization (SON), there are no "RAN resources" that would be defined / measured /manipulated in same way as NFVI resources. RAN optimization is application level activity where application level performance measurements are collected (example: statistics of call drops) and  application level (OAM) configuration changes are applied to optimize, for example, network coverage 

RAN entity (also known as Base Station) may include virtualized part. ONAP should be able to support the corresponding VNFs as such, i.e. their VNF aspects. This part is different from support of other VNF types in two elements. One is that such VNFs are running in the edge cloud rather than in the central cloud. Second is that specific arrangements for general management are needed. The latter, we assume, will be provided via the SDN-C (SDN-R); currently not available yet. If/when these two elements are addressed, the VNF part of the BS can be made running under ONAP. Another piece of the puzzle is to support the parts of the BS that are not virtualized (PNFs). Having that addition, we will be able to run the whole BS under ONAP. In this configuration we can think of optimization of NFV related aspects of the BS. Probably the OF can be extended to cover this part to optimize resource utilization and similar aspects of the VNF components of the BSs. However all said is not SON, which is application level optimization. In the future, combined optimization of both BS faces (NFV level and application level) may evolve.

Network slices consist of network functions (NFs) which can be virtulaized, fully or partially. Some NFs may be shared between slices. The virtualized parts can be subject to OF-like optimization of NFV resources. However slicing includes also significant application level functionality specified in 3GPP. That application level part is orthogonal to virtualization aspects. It can be subject to (application level) optimization too. 

Well described. Agreed.

Hi guys, I'm lost at what exactly (if anything) is being implemented in R2 (Beijing) release. I see more docs on Casablanca so it is very unclear. Could you please summarize?

Dear Benjamin Cheung:

         I have a little supplement to PNFPlugnPlay in the stage of Design Time step 1 and step 4, I would prefer to add PNF geo-location information in PNF Resource Definition which has been standardized in ETSI NFV IFA014 PNFD definition. It could be used in ONAP too.

         And the reson why I prefer to add this arttibute is that we can do e2e NW orchestration in the specific region, or in order to satify radio interface requirement, deploy virtualized RAN part in a suitable NFVI-PoP, etc.

        The attachmnt adds the attribute, please review? and any comments are welcome?

Best Regards

Li Xiang 

Cisco changes applied on top of v3, resulting in v4; please see comments from March, 26.

Thanks

Vladimir

For the 5G RAN deployment, we’d like to understand more about the workflows, policies and requirements for placement of the VNFs. I’m guessing the same workflows that we used for vCPE in R2 will work, but we should hash it out just to make sure we aren’t missing anything. Here’s a draft based on the VNF placement workflow that is used in Beijing - Homing 5G RAN VNFs.

Agenda for April 19, 2018

- 5G VNF/PNF deployment use case – Scenario 1 (covered by Nokia on 4/5/18)

- 5G VNF/PNF deployment use case – Scenario 2 (covered by Ericsson on 4/12/18)

- 5G slicing use case for Casablanca - All

- Discuss definition/scoping

- identify volunteer/leads for different sections

        - UC description/scenario/scope/Functional Requirements

        - Service Model (ONAP, 3GPP)

        - ONAP Design phase items/flow

        - ONAP Execution phase items/flow

- 5G Optimization/Framework use case – (Vmware/AT&T)

- Mapping Nokia/Ericsson presentations on PNF/VNF Deployment to Functional Requirements for Casablanca - All

- Other items?

Regards,

Shekar Sundaramurthy

I uploaded a Functional Requirements (1st draft) for the deployment (to capture the requirements from the 2 flows/presentations from Nokia & Ericsson) - Please review to add/edit additional items to the flow - we can discuss on the call. I think this format may lend itself to discussing the details for each component with the PTLs.

 https://wiki.onap.org/download/attachments/10784151/5G-NFD-funcReqmts.xlsx?api=v2

Regards,

Shekar Sundaramurthy

Following the discussion on the call, I have a couple of comments on the SW management in the presentation.

 5Guc-RAN Deployment (SWCfg_Mgmt)-Casablanca-Huawei 04282018v3.pptx

My first point is that the description does not include the step of reboot (after #4 in the slide 5). I think it should; otherwise there is a new requirement for the RAN node: capability of the SW upgrade without service interruption. If this requirement is OK for RAN vendors, fine. If not, the step of reboot is mandatory and this changes the whole picture, triggering a batch of questions on what exactly the device "remembers" after the reboot:

- does it "remember" IPs /IDs of ONAP modules (APP-C)?

- does it "remember" the context created with ONAP ?

- does it "remember" the application level context, such as Radio configuration?

- how other peers (e.g. CN nodes) update the context associated with this RAN node, but created before the SW upgrade/reboot?

- does it preserve secure association with the ONAP system (which may require also certain arrangement in the ONAP system)?

- ...

Every of these bullets triggers a new requirement to the RAN node implementation, and some of them impose requirements also on the CN nodes. If we want to avoid this, the simplest way would be to use same process as for bootstrap. Then the only thing needed from the ONAP system, would be to supply the new SW version to the Initial EM and trigger the reboot.

I have some questions on the application-level configuration in the presentation

 5Guc-RAN Deployment (SWCfg_Mgmt)-Casablanca-Huawei 04282018v3.pptx

(slides 6 - 7)

1. Please clarify the following terms:
   

   - "service" and how it's related to the RAN node to be configured

   - "service instantiation" and how it's related to the RAN configuration action. Cannot application-level configuration be required in the context other than "service instantiation"?

2. In slide 6, please clarify "generate configuration data from Vendor Adapter": which function is generating the configuration data? Which data model is used? Is this data model proprietary?

3. In slide 6, "configure PNF/VNF separately (for DU, cfg data contains CU IP for DU homing to a CU)" - where this data comes from? Where the information on the inter-connect comes from?

4. In slide 6, "CU-DU inter-connect" - What exactly happens in this step?

5. In slide 6, "configure PNF/VNF separately (for DU, cfg data contains CU IP for DU homing to a CU)" - is it assumed that the CU is VNF and the DU is PNF? Will the process work if the CU is PNF too?

6. In slide 7, "generate configuration data" (by the EM) - Which information is used to generate the data? Which data model is used for the configuration data? Is this data model proprietary?

7. In slide 7 "(4) configure PNF/VNF via EM" - must be "by EM"?

   I also have a general question: how this process is aligned with what the SDN-R group is doing?

   Thanks

   Vladimir

   
   

   
   

   
   

   
   

   
   

   
   

   
   

SDN-R is intended to replace both SDN-C & APP-C for RAN.

SDN-R Use Cases and Objectives

It is intended to use standards specified Yang model definitions and use NETCONF to manage configuration deployment for RAN components.

SDN-R Documents

I added "target software management" to 5G Use Case Casablanca Summary on the "deployment" bullet (slide 3). Since Service Configuration Improvement and Life-cycle Management Support rows (slides 4 and 5) may cover this, I did not add a new entry in the tables.