V2X and Network Slicing

Marie-Paule Odini (marie-paule.odini@hpe.com), HPE Distinguished Technologist

IEEE Softwarization, December 2017

 

This article will explore V2X – Vehicle to Everything – leverage of Network Slicing and more specifically 5G Network Slicing, going into architecture and use cases.

With more and more vehicles on the roads, over one billion cars today but also trucks, trains and other motorized vehicles two main drivers are defining how this industry is moving to V2X, Vehicle to Everything communication (Figure 1): one is regulation, mainly to reduce casualties on the road; the other is user experience which ranges from enhancing driving experience for those who will still want to drive, to session continuity between home, work environment and driving. Many other use cases and value propositions address other segments: transportation industry, city management teams, road management teams, electric grid companies, operators that manage communication networks etc.

Figure 1

Fig. 1. Vehicle to Everything (source: HPE)

The number of sensors in both vehicles and road infrastructure is increasing and multiple communication channels exist between those different elements: infrared, 802.11p which is a protocol defined by IEEE and endorsed by ETSI ITS (International Transport System) standards, or more recently C-V2X (Cellular V2X) defined by 3GPP, all complementary as described in Figure 2.

Figure 2

Fig.2. V2X Evolution (Source: HPE)

With 5G, the hope for V2X is to leverage 5G architecture which supports heterogeneous access to the same 5G Core and enables features such as higher bandwidth, higher density and ultra reliable low latency. Network Slicing is an additional key features of 5G in the context of V2X, and will be further expanded in the remainder of the article.

Network Slicing as defined by 3GPP [9] is ‘a network created by the operator and customized to provide a specific market scenario which demands specific requirements with end to end scope. For instance, an emergency car would typically access a low latency (and reliable?) network slice to communicate with emergency services, while people in a car watching a HD video streaming in the back seat would access a high bandwidth network slice. As the car moves from one cell to the other, the operator needs to deliver a continuous service with same QoS and ‘slice parameters’. Moreover, when the car is roaming to another operator’s network, the expectation is that the same type of slice is delivered by the new operator to ensure service continuity with no degradation of performance or level of service as shown in Fig. 3.

Figure 3

Fig. 3. V2X and 5G Slicing with roaming (Source: HPE)

The situation can actually be more complex, since a given 5G ‘device’ could access simultaneously up to 8 slices. A given vehicle can have sensors sending maintenance data in a few small data packets per day; but some other sensors can be video cameras detecting a road hazard and broadcasting to near vehicles and informing the network for appropriate use: this requires high bandwidth and low latency. Similarly, radar sensor or cameras could detect an imminent collision with a high speed vehicle and require ultra low latency to stop the vehicles immediately. Futuristic scenarios even envision taking control of a vehicle remotely in case of some emergency or for safety reason in some industrial applications. The range of these use cases varies from low throughput to high bandwidth, low range to long range, no latency requirements to Ultra Reliable Low Latency Communication (URLLC), etc.

In addition, for privacy reason, some data being exchanged with the vehicle should be highly secured: data encrypted, traffic and management of the slice isolated and restricted to a limited set of users. The network slice would then be designed either with dedicated resources or shared resources, virtual or physical. Many combinations are theoretically possible and operators will have to decide which options they want to support and which service they want to offer.

In Fig. 4. Below, multiple slices are represented. The scenario describes an ambulance taking a patient to the closest hospital. The ambulance is using its GPS based itinerary to optimise the route to the hospital. Below is a set of services used and associated slices:

1) The ambulance is asking the cars in front to step aside to bypass them (1). It is also asking the traffic lights to turn green on the way to the hospital and other crossroad traffic lights to turn red (2).

These two set of communications will be sending short messages but require low latency. So they will use a “low throughput low latency highly secure” network slice, Slice A.

2) The second set of messages is to share the echography of the patient between the ambulance and the targeted hospital. This communication requires a “high bandwidth and low latency, privacy” network slice, Slice B.

Figure 4

Fig. 4. V2X and 5G Network Slicing (Source: HPE)

If we try to map the previous scenario on the 5G architecture as defined by 3GPP [10] we have a set of devices, or User Equipments (UE) -  the ambulance, the car, the traffic lights, the hospital – that share information via certain slices, or access applications. We also have different services: 1) V2V Use case for emergency vehicle warning, 2) V2I Emergency Stop Use Case, 3) V2N Traffic Flow Optimization. These services are actually listed in 3GPP V2X [5] as supported by LTE today but with limitations, i.e. the size of the messages exchanged in case 1) is 50-300 bytes, while with 5G these messages could be aggregated videos consolidating views from other vehicles and road units around, and transmitted with lower latency for the car to be able to process this information and automatically divert the car to the best place to let the emergency vehicle drive through. As described in Fig.5. multiple devices access the same slice, for instance the ambulance, the cars and the traffic lights access the low throughput low latency Slice A. Some devices access multiple slices, typically the ambulance access Slice A and Slice B. In that diagram, another slice has also been added for classical 5G mobile broadband that a pedestrian with his mobile would use, consciously or not. This is also to show that the V2X emergency and sensitive traffic is isolated from the enhanced Mobile Broadband (eMBB) traffic.

Figure 5

Fig.5. V2X and 5G Network Slicing architecture (Source: HPE)

While V2X and more specifically C-V2X and Network slicing have been defined in LTE and could be deployed today, current product implementation and testing for V2X in most regions such as in Europe, US and Asia, have been done with 802.11p. Different scenarios are now envisioned by 3GPP and 5GAA, including co-existence of 802.11p and C-V2X in the same channel [8] with sensing, time sharing etc, but enhancements would be required to achieve this today and they would need to be standardized.

Conclusion

With 5G, multiple communication channels may occur from a car, including safety V2X, maintenance IoT, entertainment mobile broadband over cellular or Wi-Fi, etc. It is likely that with 5G supporting heterogeneous access to a common core, different access technologies could co-exist to deliver V2X, i.e. 5G with URLLC and High Bandwidth while moving, Wi-Fi reaching home, LORA for collecting sensor data and parking applications, 802.11p for anti-collision. While these communication channels could be used concurrently to deliver different services, the other requirement could be to deliver all these services with the same communication when available, i.e. with a unified 5G network, and rely on the infrastructure to provide appropriate gateways to reach out to other devices using different access technologies. This is one of the scenarios also explored by 3GPP [8]. Then use network slicing and SDN to provide different quality of service, isolation, etc depending on the service & devices.

As 3GPP progresses 5G specifications towards completion of Release 16 by end of 2019, a number of topics related to V2X still require work, including further study on enhanced use cases and architecture update to map with the 5G architecture. Some areas would benefit research from the academic part of the community on coexistence of 802.11 and cellular technologies in the same channel for instance, or V2X slicing continuity across heterogeneous access.

References:

[1] GSMA positioning on V2X, Sept 2017

[2] ETSI ITS TR 101 607 (2013-05) – Cooperative ITS, Intelligent Transport System

[3] ETSI ITS TR 102 638 V1.1.1 (2009-06) - Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Definitions

[4] ETSI TS 102 637-1 V1.1.1 - Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Part 1: Functional Requirements

[5] 3GPP TR 22.885 v14.0.0 (2015-12) - Study on LTE support for Vehicle to Everything (V2X) services

[6] 3GPP TS 23.285 V14.4.0 (2017-09) – Architecture enhancements for V2X Services; 5G Americas C-V2X

[7] 3GPP TR 23.785 V14.0.0 (2016-09) – Study on architecture enhancements for LTE support of V2X

[8] 3GPP TR 36.885 V14.0.0 (2016-06) – Study on LTE based V2X Services – Release 14

[9] 3GPP TR 23.799 14.0.0 (2016-12) - Study on Architecture for Next Generation System

[10] 3GPP TS 23.501 Rel. 15 – System Architecture for the 5G Systems

[11] 3GPP TR 28.801 – Study on management and orchestration of network slicing

 


 

Marie-Paule OdiniMarie-Paule Odini is Distinguished Technologist in HPE with over 25 years of telecom experience. She is focusing on customer innovation and emerging trends in the communication industry including NFV, SDN, IoT, big data and 5G and leads technology discussions and solution roadmaps towards 5G inside HPE. She is also involved in industry forums and standard organization such as ETSI NFV Vice Chair, IEEE SDN Chair and Editorial board member, 5G Americas co-author of Network Slicing and V2X white paper and more recently as co-chair of TIP (Telecom Infra Project) new E2E network slicing project.

 

Editor:

Catalin MeirosuCatalin Meirosu joined Ericsson Research in Stockholm, Sweden in 2007 and is currently a master researcher there. He drives research and innovation for network management for unified cloud and carrier networks infrastructure. Prior to Ericsson, he was a project development officer with TERENA (now GEANT) in Amsterdam. Catalin holds a BSc (1999) from Transilvania University in Brasov, Romania, an MSc (2000) and a PhD in telecommunications (2005) from Politehnica University, Bucharest, Romania. Throughout his PhD studies, Catalin was a project associate at CERN, Geneva, Switzerland, working on network technologies for the data acquisition system of the ATLAS experiment at the Large Hadron Collider. Catalin has six granted patents and co-authored over thirty-five scientific papers. He worked on network measurements, monitoring, self-management and DevOps in the European-funded international research projects ESPRIT SWIFT, FP6 NoAH, FP7 4WARD and UNIFY. Catalin was a guest editor for the 2015 IEEE Communications Magazine Special Issue on Network and Service Virtualization and is a guest editor for the International Journal of Network Management Special Issue on Software-Defined Operations to appear in 2016.

 

Network Slicing and 3GPP Service and Systems Aspects (SA) Standard

Tony Saboorian (tony.saboorian@huawei.com) and Amanda Xiang (amanda.xiang@huawei.com), Huawei

IEEE Softwarization, December 2017

 

Network slicing is an important capability to bring network resource utilization efficiency, deployment flexibility and support fast growing over the top (OTT) application and services. 3GPP is considering network slicing as one of the key features of 5G. It is spending significant effort to develop comprehensive network slice related standards in various working groups, particularly SA1 (service requirements), SA2 (architecture), SA3 (security) and SA5 (network management). This article gives an overview of current 3GPP Service and Systems Aspects (SA) standard status for the development of mobile network slicing for 3GPP Release 15 whose target completion date is June 2018.

1. 3GPP architecture for network slicing

The 3GPP SA2 Working Group, responsible for overall system architecture, is currently working on specifying the 5G Core (5GC) architecture with Network Slicing being a main feature of 5GC. Technical Specification (TS) 23.501 defines Stage-2 System Architecture for the 5G System which includes Network Slicing.  Technical Specification (TS) 23.502 defines procedures for the 5G System.  Technical Specification (TS) 23.503 defines Policy and Charging Control Framework for the 5G System.  The work on these Technical Specifications is ongoing with target completion date being December 2017. Figure 1 depicts the non-roaming reference architecture.  Figure 2 depicts an example of Network Slicing.

Figure 1

Figure 1: 5G network architecture (non-roaming)

 

Figure 2

Figure 2: Example of Network Slices

1.1  3GPP Network Slice Definition

A network slice is viewed as a logical end-to-end network that can be dynamically created. A given User Equipment (UE) may access to multiple slices over the same Access Network (e.g. over the same radio interface). Each slice may serve a particular service type with agreed upon Service-level Agreement (SLA). In this article we provide highlights of 3GPP Network Slicing as being defined in TS 23.501 in SA2.  A Network Slice is defined within a Public Land Mobile Network (PLMN) and includes the Core Network Control Plane and User Plane Network Functions as well as the 5G Access Network (AN). The 5G Access Network may be:

  • A Next Generation (NG) Radio Access Network described in 3GPP TS 38.300, or
  • A non-3GPP Access Network where the terminal may use any non-3GPP access to reach the 5G core network via a secured IPSec/IKE tunnel terminated on a Non-3GPP InterWorking Function (N3IWF).

TS 23.501 defines Network Function, Slice, and Slice Instance as follows:

Network Function: A 3GPP adopted or 3GPP defined processing function in a network, which has defined functional behavior and 3GPP defined interfaces. (Note: A network function can be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g. on a cloud infrastructure.)

Network Slice: A logical network that provides specific network capabilities and network characteristics.

Network Slice instance: A set of Network Function instances and the required resources (e.g. compute, storage and networking resources) which form a deployed Network Slice.

1.2  Identification and selection of a Network Slice

Identification of a Network Slice is done via the Single Network Slice Selection Assistance Information (S-NSSAI). The NSSAI (Network Slice Selection Assistance Information) is a collection of S-NSSAIs.  Currently 3GPP allows up to eight (8) S-NSSAIs in the NSSAI sent in signaling messages between the UE and the Network. This means a single UE may be served by at most eight Network Slices at a time. The S-NSSAI signaled by the UE to the network, assists the network in selecting a particular Network Slice instance. An S-NSSAI is comprised of:

- A Slice/Service type (SST), which refers to the expected Network Slice behaviour in terms of features and services;

- A Slice Differentiator (SD), which is an optional information that complements the Slice/Service type(s) to differentiate amongst multiple Network Slices of the same Slice/Service type.

The S-NSSAI may be associated with a PLMN (e.g., PLMN ID) and have network-specific values or have standard values.  An S-NSSAI is used by the UE in access network in the PLMN that the S-NSSAI is associated with.

1.2.1  Standardized Slice/Service type (SST) values

SA2 has defined some standardized SST values in TS 23.501. These SST values are to reflect the most commonly used Slice/Service Types and will assist with global interoperability for slicing. Currently, SA2 has defined a short characteristic for eMBB SST, however, this may change while 3GPP Rel15 is being finalized.   Other SSTs are still work in progress.

Standardized SST values

Slice/Service type

SST value

Characteristics

eMBB (enhanced Mobile Broadband)

 

1

Slice suitable for the handling of 5G enhanced Mobile broadband, useful, but not limited to the general consumer space mobile broadband applications including streaming of High Quality Video, Fast large file transfers etc.

URLLC (ultra- Reliable Low Latency Communications)

2

 TBD

MIoT (Massive IoT)

3

 TBD

 

1.3 General aspects of network slicing in TS 23.501

The Access and Mobility Management Function (AMF) instance that is serving the UE is common (or logically belongs) to all the Network Slice instances that are serving the UE. Other network functions, such as the Session Management Function (SMF) or the User Plan Function (UPF), may be specific to each Network Slice.

The Network Slice instance selection for a UE is normally triggered as part of the registration procedure by the first AMF that receives the registration request from the UE. The AMF retrieves the slices that are allowed by the user subscription and interacts with the Network Slice Selection Function (NSSF) to select the appropriate Network Slice instance (e.g., based on Allowed S-NSSAIs, PLMN ID, etc.). This could result in a change of AMF if needed. 

A Protocol Data Unit (PDU) Session is associated to one S-NSSAI and one DNN (Data Network Name). The establishment of a PDU session within the selected instances-NSSAI is triggered when the AMF receives a Session Management message from UE. The AMF discovers candidate Session Management Functions (SMF) using multiple parameters including the S-NSSAI provided in the UE request and selects the appropriate SMF. The selection of the User Plane Function (UPF) is performed by the SMF and uses the S-NSSAI.  The Network Repository Function (NRF) is used for the discovery of the required Network Functions using the selected Network Slice instance – the detailed procedures are specified in 3GPP TS 23.502. The data transmission can take place after a PDU session to a Data Network is established in a Network Slice. The S-NSSAI associated with a PDU Session is provided to the AN, and to the policy and charging entities, to apply slice specific policies.

For roaming scenarios, S-NSSAI values applicable in the Visited PLMN (VPLMN) are used to discover a SMF instance in the VPLMN and in Home–Routed deployments S-NSSAI values applicable in the Home PLMN (HPLMN) are also used to discover a SMF instance in the HPLMN.

2. Network Slicing Management and Orchestration

3GPP SA5 is the 3GPP telecom management working group. By the time this article is written, SA5 has completed the study on management and orchestration on network slicing (TR28.801) and just started the normative specification work for release 15 based on this study. It is expected to be completed by the second quarter of 2018, including:

  • Network slice concepts, use cases and requirements (TS 28.530)
  • Provisioning of network slicing for 5G networks and services TS (TS 28.531)
  • Assurance data and Performance Management for 5G networks and network slicing
  • Fault Supervision for 5G network and network slicing

The following description highlights management and orchestration aspects of network slicing in 3GPP SA5 TR 28.801. However, these may be updated in the SA5 Normative Specifications based on the ongoing development of the SA2 technical specifications (as described above).

2.1 General management and orchestration aspects of network slicing defined in TR28.801:

Based on 3GPP SA2 TS23.501, SA5 has defined different management aspects for network slices in TR28.801 as listed below:

  • Managing a complete Network Slice Instance (NSI) is not only managing all the functionalities but also the resource necessary to support certain set of communications service.
  • An NSI not only contains Network Functions (NFs), e.g belonging to Acces Network (AN) and Core Network (CN), but also the connectivity between the NFs.
    If the NFs are interconnected, the 3GPP management system contains the information relevant to connections between these NFs such as topology of connections, individual link requirements (e.g. QoS attributes), etc. For the part of the Transport Network (TN) supporting connectivity between the NFs, the 3GPP management system provides link requirements to the management system that handles the part of the TN supporting connectivity between the NFs.
  • NSI can be composed of network slice subnets of Physical Network Functions and/or Virtualized Network Functions.

2.2 Network Slice Instance lifecycle management

3GPP TR28.801 has introduced the network slice instance lifecycle management as depicted below in Figure 2, considering it independent of the network service instance which is using the network slice instance.  Typically a network slice instance is designed (preparation phase), then it is instantiated (Instantiation, Configuration and Activation phase), then it is operated (Run Time phase) and finally it may be decommissioned when the slice is no longer needed (Decommissioning phase). These different phases would be part of the “Network Slice Management Function” mentioned below in Fig 3.

Figure 3

Figure 2: Network slice instance lifecycle

TR28.801 introduces 3 management logical functions as illustrated below in Figure 3:

Figure 4

Figure 3: Network slice management functions

- Communication Service Management Function (CSMF):

  - Responsible for translating the communication service related requirement to network slice related requirements.

- Network Slice Management Function (NSMF):

  - Responsible for management and orchestration of NSI.
  - Derive network slice subnet related requirements from network slice related requirements.

- Network Slice Subnet Management Function (NSSMF):

  - Responsible for management and orchestration of NSSI.

Conclusion

3GPP is conducting standardization effort holistically on network slicing. This article only gives the introduction of the standard progress from system architecture prospective.  Beyond 3GPP SA, 3GPP RAN (Radio Access Network) WGs are also working on how RAN handles network slices. Because Virtualization is one of the enabling technology for network slicing, 3GPP is also closely collaborating with relevant network virtualization standard organizations, such as ETSI NFV ISG, to make sure the network slice can run in the virtualized environment and operators can have a seamless E2E network slice resource management capability including the virtualized resource for the network slices.

 

References

[1]   3GPP TS 23.501:  “System Architecture for the 5G System”

[2]   3GPP TR 28.801:  “Study on management and orchestration of network slicing for next generation network”

 


 

Tony SaboorianTony Saboorian is a Director in Wireless Research and Standards in Huawei Technologies and leads the Huawei Wireless Network delegations in 3GPP TSG-SA. Before joining Huawei, he was the leader of the wireless core network standards group in Nortel Networks. He has extensive experience in telecommunication research and standardization with emphasis on Wireless Network, SDN and NFV. Mr. Saboorian has worked on various design, planning, architecture and standards projects in Siemens, Nortel Networks, and Huawei. He has contributed to number of telecom standards, held leadership positions in Standards organizations, and is recognized for his contributions to the industry. He received his master’s degree in Electrical and Computer Engineering from Florida Atlantic University.

 

Amanda XiangAmanda Xiang received Master degree of Electrical Engineering from Clemson University. She has been working in mobile communication industry for almost 20 years and worked for various companies such as Ericsson, Motorola, ZTE and Huawei with different technical and leadership roles. She has been participating and contributing industry standard effort for mobile network since 2005, including contribution in WiMAX forum, IEEE802.16, IEEE802.20, 3GPP (SA2, SA1, SA5, RAN2), 3GPP2, WFA, ETSI NFV ISG.  Currently she is the senior standard manager of Huawei, and responsible for NFV, network slicing, IoT.

 

Editor:

Laurent ThiebautLaurent Thiébaut is an End to End Senior Architect at Nokia Networks, Paris, France. His specialties are End to end network architecture, from the interface with the Radio Access Network to the applications, with a focus on IMS/sip based apllications.

 

 

Radio Slicing

Qian (Clara) Li (clara.q.li@intel.com), Geng Wu (geng.wu@intel.com), Apostolos (Tolis) Papathanassiou (apostolos.papathanassiou@intel.com), and Udayan Mukherjee (udayan.mukherjee@intel.com), Intel Corporation, USA

IEEE Softwarization, December 2017

 

Generally speaking, slicing techniques create self-contained logical systems from a common pool of physical resources (including computing, communication, storage, etc.). It is enabled by virtualization techniques and advances in computation and communication capabilities. Examples of slicing include vertical network slicing for different services/applications or groups of users, and horizontal edge computing slicing for computing offloading to augment device capability [1]-[3].

Motivated by the need to support diverse services and applications with flexibility, scalability and low cost, network slicing is considered as one of the key features of 5G and is developed from Core Network (CN) to Radio Access Network (RAN) to radio link. From CN and RAN perspective, slicing segregates traffic of each of the services/applications/user groups, practically avoiding or dramatically simplifying a traditional QoS engineering problem. From the radio perspective, new radio slices are created to fulfil communication requirements that cannot be achieved by scaling of the existing radio slices. An end-to-end network slice could include one CN slice, one or a few RAN slices and one or a few radio slices. For example, a CN slice that provide internet of things (IoT) services could have multiple RAN slices each to provide certain RAN capabilities, such as low power wide range access, low latency high reliability access, etc. A user equipment (UE) could connect to one or more network slices at the same time, as illustrated in Figure 1.

Figure 1

Figure 1 Illustration on E2E vertical network slicing

The normative specification work on network slicing is currently on-going (as of the time the article is written) in 3GPP [4]-[14]. From CN and RAN perspective, the focus has been on defining the slice identifiers, the slice selection and admission procedures, network function decoupling to enable flexible deployment of network slices, and network slice management and security. From radio link perspective, the focus is on the air interface design for each of the radio slices to meet the corresponding requirements, i.e., for the requirements that cannot be achieved by scaling of the existing radio slice air interfaces, new radio slice air interface are designed.

In fact, LTE already has radio slicing development to enable some non-mobile broadband (MBB) services. Examples include radio slices for Machine Type Communication (MTC), narrow band internet of things communication (NB-IOT) and vehicular communication (V2X). However, as LTE air interface was primarily developed for MBB service, the new radio slices often have to compromise performance to comply with LTE framework.

In 5G, the new radio (5G NR) is designed to be forward compatible, i.e., the air interface is provisioned for future addition of new radio slices. Mechanisms to ensure forward compatibility include:

  • Flexible resource allocation, scheduling and HARQ framework,
  • Flexible duplexing modes,
  • Flexible numerologies,
  • Bandwidth part contained operation.

The resource allocation and transmission scheduling framework in 5G NR as defined in [13]-[14] enables flexible multiplexing of radio slices. UEs in one radio slice are informed of the radio resources used by the radio slice, while regard radio resources used by other radio slices as unknown or reserved. Transmission can be scheduled in the unit of slot or in the unit of a few symbols in a slot, therefore allowing high transmission flexibility. Asynchronous hybrid automatic repeat request (HARQ) is supported, where depending on the UE processing capability, flexible HARQ-ACK timing can be configured.

5G NR supports flexible duplexing, where the transmission direction (i.e., downlink or uplink) of a slot in a paired spectrum can be dynamically indicated in the downlink control information of the slot. Flexible duplexing eliminates scheduling restrictions and design complexity caused by static duplexing operation, making it easier to flexibly multiplex radio slices.

5G NR supports multiple numerologies with subcarrier spacing scaling according to kHz. The symbol duration is thus scaled accordingly. From base station perspective, different numerologies can be multiplexed in time and frequency, which enables flexible multiplexing of radio slices of different numerologies. Bandwidth part contained operation allows UEs to operate within a part of the system bandwidth. The control and data transmission will be contained within the bandwidth part the UEs are configured with. This mechanism helps in reducing UE processing complexity and power consumption. It also facilitates radio slice based operation – a slice can only operate within the bandwidth part configured for the radio slice and thus can be self-contained.

Figure 2

Figure 2

3GPP is working on developing the first release of 5G NR specification with Release 15 planned for non-standalone operation (e.g., NR tight interworking with LTE). The primary focus is on enhanced MBB (eMBB). New radio slices are expected to be added in 3GPP future releases to enable new use cases and fulfil other 5G requirements, such as ultra-Reliable-Low-Latency Communication (URLLC), massive MTC (mMTC), V2X, device to device (D2D) communication, etc. The forward compatible design enables flexible addition of new radio slices under a unified 5G NR framework.

 

References

[1] NGMN Alliance: "Description of Network Slicing Concept", 2015. http://www.ngmn.org/publications/technical.html
[2] 5G Americas, “Network slicing for 5G networks and services”, Nov. 2016
[3] Q. Li, G. Wu, A. Papathanassiou, U. Mukherjee “An end to end network slicing framework for 5G wireless communication systems”, arXiv: 1608.00572, https://arxiv.org/abs/1608.00572
[4] 3GPP TS 23.501, “System architecture for the 5G system”, ver. 1.4.0, Sep. 2017
[5] 3GPP TS 22.261, “Service requirements for next generation new services and markets”, ver. 16.1.0, Sep. 2017
[6] 3GPP TR 33.811, “Study on security aspect of 5G network management slicing”, Sep. 2017
[7] 3GPP TS 28.530, “Management of network slicing in mobile network; Concepts, use cases and requirements”, ver. 0.1.0, Sep. 2017
[8] 3GPP TR 28.801, “Telecommunication management; Study on management and orchestration of network slicing for next generation network”, ver. 15.0.0, Sep. 2017
[9] 3GPP TS 38.300, “NR; Overall description; Stage-2”, ver. 1.1.1, Oct. 2017
[10] 3GPP TS 38.413, “NG-RAN; NG application protocol”, ver. 0.3.0, Sep. 2017
[11] 3GPP TS 38.423, “NG-RAN; Xn application protocol”, ver. 0.3.0, Sep. 2017
[12] 3GPP TS 38.300, “NR; NR and NG-RAN overall description”, ver. 2.0.0, Dec. 2017
[13] 3GPP TS 38.213, “NR; Physical layer procedures for control”, ver. 2.0.0, Dec. 2017
[14] 3GPP TS 38.214, “NR; Physical layer procedures for data”, ver. 2.0.0, Dec. 2017

 


 

Dr. Qian (Clara) LiDr. Qian (Clara) Li is a principle engineer with the next generation and standards division of Intel. Her research interests include radio access network, information theory, and communication theory. Since joining Intel in Sep. 2012, she has been working on 5G communications system design and standardization in sub-6 GHz and mmWave bands. Dr. Li has published more than 40 papers in international journals and conferences and 2 book chapters. She served as symposium co-chair, technical committee member and reviewer for several IEEE conferences and journals.

 

Dr. Geng WuDr. Geng Wu is an Intel Fellow and the chief technologist for Intel wireless standards and technologies. He leads Intel's fifth-generation (5G) wireless standards and technology development, works extensively with global research community and ecosystem partners. Dr. Wu’s current research interests include 5G mobile computing and communication platforms, future generation network architectures and devices, mmWave channel modeling, new air interface design and performance evaluation, and cross-layer optimization for future mobile services and applications.

 

Apostolos (Tolis) PapathanassiouApostolos (Tolis) Papathanassiou is a Senior Principal Engineer with the Next Generation and Standards (NGS) organization of the Intel Client and Internet of Things Businesses and Systems Architecture Group (CISA). He is responsible for LTE PHY and MAC standardization and has been leading different 5G technology development and standardization activities. He is the 5GAA Working Group 4 (Standards and Spectrum) Chairman and member of the WWRF (Wireless World Research Forum) Steering Board. He has more than 50 scientific contributions to international journals, conferences, and books since 1994, more than 20 awarded patents/patent applications in 3G (TDSCDMA and WCDMA), 4G (WiMAX, LTE), 5G and Wi-Fi (IEEE 802.11a/g/n) wireless communications systems since 1996, and more than 100 contributions to wireless standardization bodies such as 3GPP, IEEE 802.11, IEEE 802.16, and WiMAX Forum since 1999. Previously at Intel, he led multiple standardization efforts in ITU-R and IEEE 802.16/WiMAX Forum. Before joining Intel, Apostolos worked on multiple-antenna PHY techniques and algorithms for 3G, satellite, and Wi-Fi wireless systems.

 

Udayan MukherjeeUdayan Mukherjee is an Intel Fellow in the Data Center Group and chief technologist for network infrastructure at Intel Corporation. He leads technology and platform development related to wireless radio access and core networks, including Cloud-RAN, virtual RAN, base stations, mobile edge platforms, as well as gateways and packet core solutions. Mukherjee is also responsible for establishing new growth areas for Intel in the telecommunications market segment, a role that includes developing technologies and optimizations for telecom platforms designed for software-based networking and network function virtualization, developing wireless-specific intellectual property, and leading Intel’s 5G wireless network technology and platform development.

 

Editor:

Chris HrivnakChris Hrivnak is a Sr. Member of the IEEE and The Photonics Society.  He is also a member of the IEEE Life Sciences Community, the IEEE Software Defined Networks (SDN) Community and the IEEE Internet Technology Policy Community and has participated in the IEEE Experts in Technology and Policy (ETAP) Forum..  He graduated from Baldwin Wallace University and completed varied coursework at Cleveland State, Case Western Reserve, Gould Management Education Center, McKinsey, Hughes R&D Productivity, UT-Dallas, Tulane Law and Pepperdine Graziadio.  Broad range of interests including but not limited to augmented intelligence, autonomous systems, additive manufacturing, information & communications technologies (ICT), life sciences, dark physics, etc.

 

Slicing and Orchestration in Service-Oriented RAN Architecture

Navid Nikaein (navid.nikaein@eurecom.fr) and Chia-Yu Chang (Chia-Yu.Chang@eurecom.fr), Communication Systems Department, EURECOM, France

IEEE Softwarization, December 2017

 

I. INTRODUCTION

Radio access network (RAN) slicing is one of the key enablers to realize the service-oriented 5G vision and deliver RAN-as-a-service. To dynamically manage and orchestrate diverse slices [1], a multi-service execution environment is required to enable on-the-fly virtualization of RANs on the top of the same physical RAN infrastructure, each customized and programmed as per slice requirements. The underlying RAN infrastructure can be either monolithic or disaggregated, where RAN is decomposed into radio unit (RU), distributed unit (DU) and centralized unit (CU) with flexible functional split among them [2]. Such disaggregation provides the capability to abstract resources, states and function modules in order to be reusable and composable across slices, while retaining the centralization benefits for coordinated and cooperative processing. With abstraction, different levels of isolation and sharing among resource and state can be provided. Additionally, slice functions can be customized in terms of user-plane (UP) and control-plane (CP) processing to reflect slice-specific requirements with the access to a portion of resources and states in a virtualized form.

Several 3GPP studies are conducted to address the challenges of end-to-end (E2E) network slice management and orchestration [3], and RAN slicing [4]. Additionally, various ETSI NFV-MANO architectural framework implementations like open source MANO1, OPNFV2, and ONAP3 are addressing the management and orchestration of network slices for next generation network. Nevertheless, RAN slicing remains challenging in providing different levels of resource and state isolation and sharing while enabling slice orchestration for multi-service RAN infrastructures. This calls for a unified and flexible execution environment to run multiple virtualized RAN instances with the required level of customization over the monolithic or disaggregated RAN. To this end, we propose a RAN slicing runtime system to facilitate slicing and orchestration of RAN [5].

II. RAN SLICING RUNTIME SYSTEM

The RAN slicing architecture is shown in Figure 1 with the RAN runtime being the core component by which each slice interacts with underlying RAN module to access resources and states, and control the behaviors.

A. RAN runtime

Within the RAN runtime, three services are provided: (a) slice manager, (b) virtualization manager, and (c) context manager are operating over a shared slice data. Slice data includes both slice context (e.g., basic information to instantiate a slice service like its identity, user context and their slice association) and module context (e.g., CP and UP state information, module primitives) that are used to customize and manage a slice in terms of the required resources, states, processing, and users. Slice data can be transferred or shared among different runtime instances based on user and network dynamics such as user handover and/or RAN service template change when updating functional splits [2].

Based on the slice service template and slice context, the slice manager determines the CP/UP processing chain for each slice and each traffic flow, and programs the forwarding plane allowing to direct the input and output streams across multiplexed processing operated by the underlying RAN module and customized processing performed by each slice. An E2E RAN service is operated by the slice manager in support of service continuity when slice service template is updated. Further, slice manager is responsible for taking actions based on a set of policy rules when detecting any conflicts among multiple slices. The virtualization manager provides the required level of isolation and sharing among slices. Specifically, it partitions resources and states, abstracts physical resources and states to/from the virtual ones, and reveals virtual resources and states to a slice, which are decoupled from the physical ones. Regarding resource aspect, it can rely on the two-level scheduler framework that abstracts Physical Resource Blocks (PRBs) into independent virtual Resource Blocks (vRBs) scheduled by slice customized scheduler [6]. Once vRBs are allocated, the virtualization manager maps the vRB/users allocation to PRB/users allocation by considering the slice priority and service level agreement (SLA).

The context manager performs CRUD operations (i.e., create, read, update, and delete) on both slice and module context. To create a slice context, it firstly performs slice admission control based on the service template that defines the required processing, resources, and states. Upon admission control, module context is used to register (a) slice-specific life-cycle primitives to the slice manager, and (b) requested resources and/or performance to the virtualization manager. At this stage, a slice starts to consume the runtime services.

B. Slice Orchestration

The RAN runtime provides a multi-service environment with four interfaces (I1 to I4 in Figure 1) facilitating slice orchestration and management and complying with communication service management function (CSMF), network slice management function (NSMF) and network slice subnet management function (NSSMF) defined by 3GPP [3].

I1 interface serves several purposes. Firstly, information about the activated services and capabilities of runtime are exposed through such interface. Secondly, it serves the service registration to runtime during slice creation based on the service template. Thirdly, monitoring and feedback messages are retrieved to facilitate slice coordination and service template update.

Figure 1

Figure 1: RAN slicing runtime system architecture.

 

Figure 2

Figure 2: An example of multi-service chaining in disaggregated RAN.

I2 interface is between the NSMF and NSSMF. Here, a need for dedicated service orchestration and management is highlighted to facilitate the slice owner to fully control its service over deployed RAN nodes with several merits. It enables applying slice-specific life-cycle primitives, self-maintaining service continuity and isolation, and allowing for control logics being applied for slice-specific applications, e.g., slice-dependent load balancing.

I3 interface is between the dedicated service management and corresponding slice at RAN node through which a slice owner can customize service monitoring and management as per slice needs. Further, it is used by the slice manager of runtime to indicate any changes in the underlying RAN infrastructure and/or RAN module allowing the dedicated service manager to adapt its service accordingly.

I4 interface provides communication channels between slices and runtime allowing each slice as a separate process, whether being local or remote. Hence, each slice is executed isolatedly, either at host or guest level, leveraging OS and virtualization technologies like container or virtual machine.

C. Multi-service chaining

A slice service chain can be split between disaggregated RAN entities according to the functional split options defined by 3GPP [4]. Such chain can be composed horizontally based on the multiplexed functions provided by the underlying RAN modules, and/or vertically when customized CP/UP processing is required tailoring to service requirements. The overall service chain of each slice is composed by the forwarding plane in runtime, which can leverage SDN-based match-action abstractions to build slice forwarding input and output paths across multiplexed and customized functions. An example of a disaggregated RAN with different levels of customization in a downlink path is shown in Figure 2.

Note that slice-specific function customization is described in the service template, and the customized forwarding path of each slice are managed by the slice manager of runtime in coordination with slice orchestrator. As the runtime maintains the states for both customized and multiplexed network functions within the slice data, it facilitates dynamic service template update by handling state synchronization among involved RAN entities.

D. Examples of RAN slicing

We present three different slices shown in Figure 1, and each slice maintains its service information base (SIB) and service template. Several information can be retrieved through SIB: SLA, user information, user to slice association, and service inventory. The service template contains tangible per-slice requirement through CSMF functionality. Using such template, the NSMF prepares network service instances, in which each slice is orchestrated and managed in shared or dedicated NSSMF at RAN-domain.

Take slice 1 as an example, it relies on a dedicated service orchestrator and manager such that the resulted slice are fully controlled by the slice owner with customized CP/UP processing and virtual resources. While slice 2 and 3 do not request such customization, thus their services are managed through a shared RAN-domain service orchestrator based on the information stored in a shared SIB.

E. Summary

A 3GPP-compatible RAN slicing and service orchestration architecture is provided exploiting RAN runtime to enable a multi-service execution environment in disaggregated RAN. Under 5G-PPP research program, both 5G-PICTURE and SLICENET projects are exploring further challenges. For more information, please visit www.5g-picture-project.eu and slicenet.eu, respectively.

 

1 osm.etsi.org
2 www.opnfv.org
3 www.onap.org

 

REFERENCES

[1] IMT-2020 Deliverables, ITU-T Focus Group, 2017.
[2] C.-Y. Chang, N. Nikaein, R. Knopp, T. Spyropoulos, and S. Kumar, “FlexCRAN: A Flexible Functional Split Framework over Ethernet Fronthaul in Cloud-RAN,” in Proceedings of IEEE International Conference on Communications (ICC), 2017, pp. 1–7.
[3] TR 28.801 Study on management and orchestration of network slicing for next generation network (Release 15), 3GPP, Sep. 2017.
[4] TR 38.801 Study on new radio access technology: Radio access architecture and interfaces (Release 14), 3GPP, Mar. 2017.
[5] C.-Y. Chang and N. Nikaein, “RAN slicing runtime system for flexible and dynamic service execution environment,” Tech. Rep., 10 2017.
[6] A. Ksentini and N. Nikaein, “Toward Enforcing Network Slicing on RAN: Flexibility and Resources Abstraction,” IEEE Communications Magazine, vol. 55, no. 6, pp. 102–108, 2017.

 


 

Navid NikaeinNavid Nikaein is an assistant professor in Communication System Department at EURECOM. He received his Ph.D. degree in communication systems from the Swiss Federal Institute of Technology EPFL in 2003. He is leading a group focusing on experimental system research related to radio access and core networks with a blend of communication, cloud computing, and data analysis. He has led the development of the radio access layer of OpenAirInterface and coordinating a new ecosystem of open-source projects, under Mosaic5G.io framework, to deliver 5G as software-based service platforms.

 

Chia-Yu ChangChia-Yu Chang is currently a PhD candidate in Communication System Department at EURECOM since 2015. He participates in collaborative research projects related to future communication system architecture and protocol design in several H2020 framework programs. He received the B.S.E.E. and M.Sc. degrees from National Taiwan University, Taiwan, in 2008 and 2010, respectively. Prior to joining EURECOM, he had served as a senior engineer in MediaTek Inc. in the 3G/4G baseband communication system architecture and algorithm design.

 

Editor:

Mubashir Husain RehmaniMubashir Husain Rehmani (M’14-SM’15) received the B.Eng. degree in computer systems engineering from Mehran University of Engineering and Technology, Jamshoro, Pakistan, in 2004, the M.S. degree from the University of Paris XI, Paris, France, in 2008, and the Ph.D. degree from the University Pierre and Marie Curie, Paris, in 2011. He is currently an Assistant Professor at COMSATS Institute of Information Technology, Wah Cantt., Pakistan. He was a Postdoctoral Fellow at the University of Paris Est, France, in 2012. His current research interests include cognitive radio ad hoc networks, smart grid, wireless sensor networks, and mobile ad hoc networks. Dr. Rehmani served in the TPC for IEEE ICC 2016, IEEE GlobeCom 2016, CROWNCOM 2016, IEEE VTC Spring 2016, IEEE ICC 2015, IEEE WoWMoM 2014, IEEE ICC 2014, ACM CoNEXT Student Workshop 2013, IEEE ICC 2013, and IEEE IWCMC 2013 conferences. He is currently an Editor of the IEEE Communications Surveys and Tutorials and an Associate Editor of the IEEE Communications Magazine, IEEE Access journal, Elsevier Computers and Electrical Engineering (CAEE) journal, Elsevier Journal of Network and Computer Applications (JNCA), Ad Hoc Sensor Wireless Networks (AHSWN) journal, Springer Wireless Networks Journal, KSII Transactions on Internet and Information Systems, and the Journal of Communications and Networks (JCN). He is also serving as a Guest Editor of Elsevier Ad Hoc Networks journal, Elsevier Future Generation Computer Systems journal, IEEE Access journal, the IEEE Transactions on Industrial Informatics, Elsevier Pervasive and Mobile Computing journal and Elsevier Computers and Electrical Engineering journal. He has authored/ edited two books published by IGI Global, USA, one book published by CRC Press, USA, and one book is in progress with Wiley, U.K. He is the founding member of IEEE Special Interest Group (SIG) on Green and Sustainable Networking and Computing with Cognition and Cooperation. He received “Best Researcher of the Year 2015 of COMSATS Wah” award in 2015. He received the certificate of appreciation, “Exemplary Editor of the IEEE Communications Surveys and Tutorials for the year 2015” from the IEEE Communications Society. He received Best Paper Award from IEEE ComSoc Technical Committee on Communications Systems Integration and Modeling (CSIM), 2017.

 

NTT DOCOMO’s 5G Experimentations and Trials on Network Slicing

Ashiq Khan (khan@nttdocomo.com), Takuya Shimojo (takuya.shimojou.gt@nttdocomo.com), Anass Benjebbour (benjebbour@nttdocomo.com), and Shigeru Iwashina (iwashina@nttdocomo.com), Research Laboratories, NTT DOCOMO, INC.

IEEE Softwarization, December 2017

 

1. Introduction

With the availability of component technologies and the progress made in standardization, DOCOMO is progressing well towards its target of 5G commercial roll out in 2020, coinciding with the Tokyo Olympics. DOCOMO itself has enormously contributed to the development of the component technologies and standards for 5G. Many such innovations and consequent specifications come from the extensive experimentation and trials carried out by DOCOMO R&D. Where the Radio Access Network (RAN) trials [1]-[4] are focusing on meeting stringent 5G requirements, the core network and its operation is focusing on network slicing. This article presents an overview of DOCOMO’s 5G-related experiments and trials, focusing on 5G mobile core network, and the automation of network operation in the 5G era and beyond.

2. 5G Mobile Core Network Experiments

DOCOMO is continuing experimentation on a slice-based network infrastructure suitable for the mobile core network in the 5G era. Such experimentation, in collaboration with Ericsson, is focusing on suitable physical implementation of slices in the context of a mobile core network, control plane (C-plane) design, simultaneous multi-slice connection from a single UE, and a variety of other technical improvements. Our immediate future objective is to validate and optimize the 3GPP Release 15 mobile core (Figure 1) [5]. However, as this is still in the standardization process, our approach is to emulate the Release 15 core by using similar concepts and solutions from the already completed Release 14 specifications.

Figure 1

Figure 1: Applying non-roaming 5G System architecture for multiple PDU session in reference point representation (dotted lines with colour are not part of the original figure).

In our Release 15 based experimental mobile core network system for 5G, multiple user planes (U-planes) can be set up as different slices. This has been shown in Figure 2 as User Plane Functions (UPFs). U-plane is the user/session data transfer plane in mobile cellular networks. In order to utilize existing implementation as much as possible, a Control and User Plane Separation (CUPS) [6] principle was used from the Evolved Packet Core (EPC) functions. The UPFs in our experimental system thus have been implemented by using the U-plane functions of the Serving Gateway (S-GW) and Packet Data Network Gateway (P-GW) from the EPC [7].

Figure 2

Figure 2: 5G Core (5GC) network experimental system in DOCOMO.

Each of the UPFs has a dedicated Session Management Function (SMF) (see Figure 1), responsible for session management in that U-plane. In our experimental system, the SMFs are implemented by combining the legacy session management functions from the Mobility Management Entity (MME), S-GW and P-GW [7].

The Access and Mobility Management Function (AMF), responsible for admission control and mobility management has been implemented by using the respective functionalities from a legacy MME. The AMF remains common for all UPFs. At present, in our experimental system, the common control plane (Figure 1) in Release 15 is emulated only by the AMF we have developed (Figure 2) for simplicity.

Similar to present Release 15 specification, one User Equipment (UE), that is a mobile terminal, can connect to a single AMF in our prototype. The AMF manages multiple SMFs, thus multiple UPFs. One UE can connect to multiple UPFs, which enables it to connect to multiple slices simultaneously. Slice-specific resources are allocated to the pairs of SMFs-UPFs. By comparing the green and blue dotted rectangles in Figure 1 with the elements of the same color in Figure 2, the relevance of our prototype with the Release 15 mobile core can be understood clearly. Functions highlighted by red dotted rectangles in Figure 1 remain common over slices.

Using the prototype explained above, we have already performed successful trials on simultaneous multi-slice connections from a single UE. In one such trial, as shown in Figure 2, a robot is programmed to be an UE. The robot has a head-mounted camera for a security application. Real-time video is sent from the camera to a remote surveillance center e.g. to a security company.

The robot itself stands and balances on two wheels, where the wheels are controlled from a remote server. Sensor data on the robot’s physical position is transmitted to a remote robot control server. The server, after analyzing the status of the robot’s position, sends instruction back to the robot’s wheels. The wheels, moving accordingly, ensure that the robot continues to stand.

The robot’s balance-related session emulates an Ultra-Reliable Low Latency Communication (URLLC) service, where the Round Trip Time (RTT) needs to be kept below 40 ms. If the RTT raises beyond that, the robot tumbles to the floor.

The video transmission from the robot’s camera emulates an enhanced Mobile BroadBand (eMBB) session. Here, transmission latency is not of high concern and is above 50 ms. For this, high bandwidth and necessary resources are allocated.

Using the above scenario, we create two different slices, one for the URLLC session, and the other for the eMBB session. When the URLLC session is transported through the eMBB slice, the robot falls. We then create a URLLC slice which has an RTT below 40 ms and dedicate it to the URLLC session. This keeps the robot standing and the surveillance application running. However, the RAN part is not sliced and is emulated by WiFi for simplicity. In future, we would integrate this sliceable Release 15-based 5G Core (5GC) system with 5G New RAT (NR) in order to create end-to-end slices. The objective of this experimentation is to closely follow the Release 15 progress, and give feedback into standardization based on implementation and experiment results.

3. Automation of Network Operation in the 5G Era

Virtualization, networking slicing, softwarization etc. bring added complexity to a network. In legacy non-virtualized networks, as an example, an Element Manager (EM) performed all Fault, Configuration, Accounting, Performance, and Security (FCAPS) management of a network function and its hardware in an integrated manner. Virtualization, which decouples the software of a network function from the hardware, necessitates root-cause analysis and distributed event-handling mechanisms. Added dynamicity by Software Define Networks (SDNs) also requires an enhanced operation system to be sufficiently handled.

Network slicing in the 5G era, which encompasses Network Functions Virtualization (NFV) and SDNs to realize multiple end-to-end network slices, will come with different layers of network management and operation, such as:

- Operation of physical network infrastructure
- Operation of Infrastructure/Network/Platform/Software-as-a-Service (XaaS) domains
- Operation of network slices
- Operation of services in network slices
- Management of customers of services in network slices

Network slices, services and customers can also span over multiple operators networks. Conventional operation techniques where manual intervention is the norm will not be able to handle such complexity and scale. It is an absolute necessity now to automate the operations at all these layers to ensure the economical as well as technical viability of network slicing.

DOCOMO is continuing R&D on automation of operation with our partner Ericsson. Assuming network slicing over distributed cloud infrastructure over Wide Area Network (WAN) protocols, we are focusing first on automating all Life-Cycle Management (LCM) operations of a slice. Slice LCM includes but is not limited to instantiation, topological re-configuration, scaling, failure recovery, and termination of a network slice. Different levels of isolation between slices are also being investigated.

Figure 3

Figure 3: Network slice operation system on distributed cloud infrastructure

We have already successfully automated instantiation, topology reconfiguration and scaling of end-to-end slices in a setup as shown in Figure 3. The inter-cloud WAN is emulated on Multiprotocol label switching (MPLS) [8]. The WAN is managed by a WAN Orchestrator (WAN-O) which sets up per-tenant VPNs with bandwidth guarantees over MPLS. WAN-O, based on the instruction from the Automated Slice Operation (ASO) System, executes this task automatically by coordinating with the OpenDaylight (ODL) SDN controllers [9] and datacenter gateways (IP Edges). Border Gateway Protocol (BGP) and Path Computation Element (PCE) Communication Protocol (PCEP) are used for this purpose (Figure 3).

Per-tenant network functions are instantiated in cloud datacenters in the form of Virtual Machines (VMs). In our experiments, we are using OpenStack [10] as the cloud management system. Kernel-based Virtual Machine (KVM) is used as the hypervisor. Neutron, the network controller in OpenStack, does not currently support per-tenant bandwidth isolation. In our experiments, this function is carried out at the ASO layer.

Cloud resources are also isolated on a per-tenant basis. Resources of one tenant can only host the VMs from that tenant. VMs of one tenant are also interconnected by tenant-specific bandwidth-guaranteed transport plane Virtual Private Networks (VPNs), connecting other VMs of the same tenant in different clouds.

An IP packet destined to a remote VM but connected to the same logical neutron network is labelled by the Open vSwitch [11] in a cloud with a MPLS label and encapsulated in a Generic Routing Encapsulation  (GRE) [12] packet. The MPLS label associates the packet with the respective Virtual Routing and Forwarding (VRF) instance on the datacenter gateway. The datacenter ODL instance is responsible for programming the soft-switch accordingly and exchanging the label with the datacenter gateway by means of BGP [13]. In the remote datacenter, the reverse process takes place, resulting in packet delivery at the correct soft-switch and hence attached VM.

Such interconnected per-tenant VMs create an end-to-end slice, dedicated to a tenant. A tenant could be an enterprise customer, a customer-facing service, or some other similar entity.

Policy rules: In a multi-tenant, multi-slice end-to-end hosting and networking scenario, closed-loop automation requires both per-tenant policies, as well as the network operator’s own. In our experimental system, per-tenant policies can be set to limit compute, storage and network resource usage, block the execution of unauthorized operations, trigger actions including scaling, healing, and topology reconfiguration to meet the Service-Level Agreement (SLA) with a tenant. We use Topology and Orchestration Specification for Cloud Applications (TOSCA) [14] for modeling and setting policy rules.

Automated operation: At present, we have successfully automated the instantiation, scaling and topology reconfiguration of slices in distributed cloud scenarios. The operation system is fed with operation models and policy required for each model. Based on these models, multiple VMs are instantiated in different clouds, and then connected over the WAN with bandwidth guarantees, in a fully automated way without any manual intervention. Scaling and topology reconfiguration (e.g. inter-cloud VM migration) can also be performed in a model-driven automated way, governed by policy.

We are also experimenting with cases where a tenant can perform some of the operation by itself (Customers in Figure 3). This requires strict inter-slice isolation, and a robust policy definition to avoid any effects on other tenants. We’ll address this in future.

4. Conclusions

DOCOMO plans to commercially roll-out 5G in 2020. As 5G wireless technologies are more advanced, the first commercial 5G deployment is expected to start from the RAN. In consequent years, the 5G Core, network slicing and automated operation systems will see commercial roll out as the 5G services provided by DOCOMO grow larger. Therefore, a migration strategy will become vital for not only DOCOMO, but for all operators. In the future, we will continue to contribute to the development, experimentation and standardization of cutting edge technologies for 5G and beyond in cooperation with our partners and the global community.

 

References

[1] A. Harada, Y. Inoue, D. Kurita, T. Obara, “5G Trials with Major Global Vendors,” NTT DOCOMO Technical Journal, Vol. 17, No. 4, pp. 60-69, Apr. 2016.
[2] Y. Kishiyama, A. Benjebbour, S. Nagata, Y. Okumura, T. Nakamura, “NTT DOCOMO 5G Activities –Towards 2020 Launch of 5G Services,” NTT DOCOMO Technical Journal, Vol. 17, No. 4, pp. 4-15, Apr. 2016.
[3] T. Nakamura, A. Benjebbour, Y. Kishiyama, S. Suyama, T. Imai, “5G Radio Access: Requirements, Concept and Experimental Trials,” IEICE Transactions on Communication, Vol. E98-B, No. 8, pp. 1397-1406, Aug. 2015.
[4] 5G Trial Sites, NTT DOCOMO, INC., https://www.nttdocomo.co.jp/english/corporate/technology/rd/docomo5g/trial_site/index.html
[5] 3GPP TS 23.501 V1.3.0, System Architecture for the 5G System; Stage 2, Release 15, 2017.
[6] 3GPP TS 23.214, Architecture enhancements for control and user plane separation of EPC nodes, Release 14, 2016.
[7] 3GPP TS 23.401, General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access, Release 8, 2015.
[8] E. Rosen, A. Viswanathan, R. Callon, Multiprotocol Label Switching Architecture, RFC 3031, IETF, 2001.
[9] OpenDaylight, The Linux Foundation, https://www.opendaylight.org/
[10] OpenStack, The OpenStack Foundation, https://www.openstack.org/
[11] Open vSwitch, The Linux Foundation, http://openvswitch.org/
[12] D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina, Generic Routing Encapsulation (GRE), RFC 2784, IETF, 2000.
[13] Y. Rekhter, T. Li, S. Hares, A Border Gateway Protocol 4 (BGP-4), RFC 4271, IETF, 2006.
[14] TOSCA Simple Profile for Network Functions Virtualization (NFV) Version 1.0, OASIS, 2017.

 


 

Ashiq KhanAshiq Khan is an Assistant Manager at NTT DOCOMO, INC. where his present work focus is on the research and development of the 5G mobile network for 2020. He has 10 years of work experience in network virtualization, and was involved in ETSI NFV standardization, NFV-based mobile network development, and the consequent commercial roll-out of the world’s first multi-vendor virtualized Evolved Packet Core (vEPC) mobile system by DOCOMO in March 2016. He served in the OPNFV TSC as a founding member, and initiated the Doctor and Promise projects, leading to their success implementation in OpenStack.

Dr. Khan is now the chair of the OPNFV Tokyo User Group, and an OPNFV Ambassador. He holds a PhD in computer science from the University of Tsukuba.

 

Takuya ShimojoTakuya Shimojo is Researcher at NTT DOCOMO, INC. His current research interests include Network Slicing, 5G Core System, and Software Defined Network. He is also responsible for initiating and leading collaboration projects with external parties to realize the world’s first 5G mobile network, including a 1000-times-higher data rate and 1 millisecond ultra-low latency.

He holds a master's degree in electrical engineering from the University of Tokyo.

 

Anass BenjebbourAnass Benjebbour obtained his Ph.D. and M.Sc. degrees in Telecommunications in 2004 and 2001, respectively, and his B.Sc. diploma degree in Electrical Engineering in 1999, all from Kyoto University, Japan. In 2004, he joined NTT DOCOMO, INC.

Since 2010, he has been a leading member of its 5G team. Dr. Benjebbour served as 3GPP standardization delegation from DOCOMO, Japan delegation to ITU-R WP5D, secretary of the IEICE RCS conference from 2012 to 2014, associate editor for the IEICE Communications Magazine from 2010 to 2014, and associate editor for the IEICE Transactions on Communications from 2014 to 2018. He is an author or a coauthor of 100+ technical publications, 4 book chapters and is an inventor of 50+ patent applications. He is a senior member of IEEE and IEICE.

 

Shigeru IwashinaShigeru Iwashina is an Executive Research Engineer of the Smart ICT Platform Research Group in NTT DOCOMO, INC.

He received his B.E. and M.E. degrees from Tokyo Institute of Technology in 1993 and 1995, respectively. Since joining DOCOMO in 1995, he has been engaged in various research and development activities, including the PDC cellular systems, the core network of the IMT2000, and the core network of the LTE system. His current research interests are NFV-based mobile core network virtualization and 5G network architecture.

 

Editor:

Chris HrivnakChris Hrivnak is a Sr. Member of the IEEE and The Photonics Society.  He is also a member of the IEEE Life Sciences Community, the IEEE Software Defined Networks (SDN) Community and the IEEE Internet Technology Policy Community and has participated in the IEEE Experts in Technology and Policy (ETAP) Forum..  He graduated from Baldwin Wallace University and completed varied coursework at Cleveland State, Case Western Reserve, Gould Management Education Center, McKinsey, Hughes R&D Productivity, UT-Dallas, Tulane Law and Pepperdine Graziadio.  Broad range of interests including but not limited to augmented intelligence, autonomous systems, additive manufacturing, information & communications technologies (ICT), life sciences, dark physics, etc.