Network Working Group J. Qin Internet-Draft K. Makhijani Intended status: Informational J. Dong Expires: September 14, 2017 L. Qiang S. Peng Huawei Technologies March 13, 2017 Network Slicing Use Cases: Network Customization for Different Services draft-qin-netslices-use-cases-00 Abstract Network Slicing (NS) is widely discussed and considered in 5G communities and standard organizations as a key mechanism to meet diverse service requirements concurrently with the same physical network infrastructure. NS enables the operator to provide isolated platform for service verticals, and deploy new services without causing or experiencing any disruption to other already deployed services in the same physical network infrastructure. This document describes the typical use cases that could benefit from network slicing, to support each case, the corresponding requirements on 5G transport network will be analyzed. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Additionally, the key words "MIGHT", "COULD", "MAY WISH TO", "WOULD PROBABLY", "SHOULD CONSIDER", and "MUST (BUT WE KNOW YOU WON'T)" in this document are to interpreted as described in RFC 6919 [RFC6919]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any Qin, et al. Expires September 14, 2017 [Page 1] Internet-Draft Use Case for Network Slicing March 2017 time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 14, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Network Customization Requirement for Diverse Services . . . 4 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Network Customization Concept . . . . . . . . . . . . . . 4 2.3. Service Requirements from Customized Networks . . . . . . 4 3. Use Cases Demanding NS . . . . . . . . . . . . . . . . . . . 5 3.1. eMBB Type NS Use Case . . . . . . . . . . . . . . . . . . 5 3.1.1. HD Video . . . . . . . . . . . . . . . . . . . . . . 5 3.1.2. Virtual Reality (VR)/Augmented Reality (AR) . . . . . 5 3.2. uRLLC Type NS Use Case . . . . . . . . . . . . . . . . . 6 3.2.1. Industrial Operation and Inspection . . . . . . . . . 6 3.2.2. Remote Surgery . . . . . . . . . . . . . . . . . . . 6 3.2.3. Vehicle-to-everything (V2X) . . . . . . . . . . . . . 6 3.3. mMTC Type NS use case . . . . . . . . . . . . . . . . . . 7 3.3.1. Smart City . . . . . . . . . . . . . . . . . . . . . 7 3.3.2. Health Monitoring . . . . . . . . . . . . . . . . . . 7 3.4. Other Type NS Use Case . . . . . . . . . . . . . . . . . 7 3.4.1. Use Cases Have Mixed Requirements . . . . . . . . . . 8 3.4.2. Use Cases Have no Special Requirements . . . . . . . 8 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 8. Informative References . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Qin, et al. Expires September 14, 2017 [Page 2] Internet-Draft Use Case for Network Slicing March 2017 1. Introduction Network Slicing (NS) has been widely discussed and considered in 5G communities and standard organizations to meet the diverse service requirements in different 5G service scenarios. NS refers to the managed partitions of physical and/or virtual network resources, network physical/virtual and service functions [RFC7665] that can act as an independent instance of a connectivity network and/or as a network cloud [I-D.gdmb-netslices-intro-and-ps]. As [TR23.799] of 3rd Generation Partnership Project (3GPP) identified, "Network slicing enables the operator to create networks customized to provide optimized solutions for different market scenarios which demands diverse requirements, e.g. in the areas of functionality, performance and isolation". Draft [I-D.gdmb-netslices-intro-and-ps] defines network slicing in a broad context and suggests related problems and work areas. Other standardization organizations like Next Generation Mobile Networks (NGMN) [Network-Slicing-Concept] and ITU-T FG IMT-2020 [FG-IMT2020-Gaps] also present their separate definitions of NS. To maximize resource utilization and minimize infrastructure cost, services will need to be deployed simultaneously, next to each other over a shared network as against the traditional monolithic model. Service operators can utilize or benefit from Network Slicing through multi-tenancy, enabling different customized infrastructures for different group of services across different network segments and operating them independently. Moreover, NS is also able to guarantee the isolation between different network slices. The operation of the data packets traversing one network slice do not adversely affect the service operation in other network slices sharing the same underlying packet network. Transport networks need to provide the functionality and capability required to support end-to-end network slicing. This draft presents various use cases from diverse industries. In each use case, the requirement for the transport network is analyzed. 1.1. Terminology o Over-the-top (OTT): A service, e.g., content delivery using a CDN, operated by a different operator than the NSP to which the users of that service are attached. o Industry Vertical: A collection of services or tools specific to an industry, trade or market sector. Qin, et al. Expires September 14, 2017 [Page 3] Internet-Draft Use Case for Network Slicing March 2017 2. Network Customization Requirement for Diverse Services 2.1. Overview It should be possible for the providers of above service categories to continuously evolve, adapt, and differentiate themselves through purpose-built infrastructures with minimal impact on network deployment and operations. The motivation behind 5G Network slicing paradigm is exactly that. By creating logically partitioned network infrastructures, isolated platforms for various industry verticals can be provided. NS is envisioned to enable new service deployments without having to build new network infrastructures or causing disruptions to other already deployed services in the network. 2.2. Network Customization Concept Network slicing is enabled through customization. Customization gives control to the operator (of a slice) to create, provision, change and consume network resources to suit their service demands. It requires ability to decompose resources from an underlying network infrastructure and logically aggregate them to form a customized network into a slice. These customizations are not only in the context of the network characteristics but include network functions. 2.3. Service Requirements from Customized Networks Services or Service Verticals (i.e. a service or group of services specific to an industry or trade) refer to combination of service segments in which services are offered to customers with customized requirements. The customization may be along the following constraints and features: o Reliability o Latency o Bandwidth o Redundancy o Burst o Security/Encryption o Mobility o Authentication Qin, et al. Expires September 14, 2017 [Page 4] Internet-Draft Use Case for Network Slicing March 2017 3. Use Cases Demanding NS The International Telecommunication Union (ITU) has classified 5G mobile network services into three categories: Enhanced Mobile Broadband (eMBB), Ultra-reliable and Low-latency Communications (uRLLC), and Massive Machine Type Communications (mMTC). Based on this, we give representative use cases that demanding NS in each type of the services. 3.1. eMBB Type NS Use Case 3.1.1. HD Video Person-to-person or person-to-group video communication with high resolution (4K/8K) and more advanced capabilities will have a much wider usage in 5g era. The gathering in large stadium or some open- air location, people can watch HD playback video, share live video or post HD photos to social networks. The connection density and date rate requirements will be high. Currently the 4K UHD video streaming service promoted in UK needs at least 40Mbps consistent data rates [BT-Ultra-HD-review], with 8K UHD and further evolutions these requirements are likely to increase many fold. In 5g era an environment will emerge in which video is available to everyone, regardless of the physical location, the device being used, and the network connection [NGMN-White-Paper].The number of concurrently active connections, combined with the bandwidth required will present a challenging situation for the transport network. For the network, when a bandwidth intensive trasmission bursts, it is necessaryt to avoid the performance of the other services being affected. 3.1.2. Virtual Reality (VR)/Augmented Reality (AR) Virtual Reality(VR)/Augmented Reality(AR) is another demanding use case of eMBB services. VR/AR video streaming will have far more stringent network resource requirements than on-demand video content. It may require it's own dedicated infrastructure with enhanced network protocols. A mass adoption of bandwidth-hungry VR/AR immersive services will have a significant impact on network capacity. The 360 degree video on which VR/AR applications based today are mostly low resolution, requiring a bandwidth of around 25 Mbit/s for streaming. But as display quality improves towards HD and eventually retina resolution (5073x5707 per eye and upwards), the bandwidth required will ramp up significantly. For retina experience VR/AR, estimates suggest that bandwidths ranging from hundreds of Mbit/s through to several gigabits per second will be needed for a fully immersive mobile experience. Qin, et al. Expires September 14, 2017 [Page 5] Internet-Draft Use Case for Network Slicing March 2017 3.2. uRLLC Type NS Use Case 3.2.1. Industrial Operation and Inspection In industry area, usually remote operations need the support of the mobile transport networks. Remote operation solutions allow people to operate machinery in a control center at another site that could avoid the on-site dangers of industrial sites like waterworks, large process plants, mines, harbors, chemical factory. On the other hand, deploying a remote or tele-operation for heavy machinery and other equipments in dangerous environment is one way to cut the size of the on-site workforce. Securing a high-quality communication link between the control site and the machines being operated is key to accurate and effective remote operation. Remote operation requires the communication with the characteristics of low latency and low jitter. To manipulate equipment efficiently on a remote site, the time interval between the instant an operator sends a control instruction to the moment the equipment's reaction is sensed by the operator must be as short as possible. A typical haptic control loop in a remote operation application requires latency to be below 10ms[Technology-Watch-Report]. 3.2.2. Remote Surgery Remote surgery which enables surgeons to perform critical specialized medical procedures remotely, allowing their vital expertise to be applied globally. Providing the correct control and feedback for the surgeon entails very strict requirements in terms of latency, reliability and security. 3.2.3. Vehicle-to-everything (V2X) Vehicle-to-everthing (V2X) refers to an intelligent transport system where all vehicles and infrastructure systems are interconnected with each other [5GAA White Paper]. This connectivity will provide more precise knowledge of the traffic situation across the entire road network which in turn will help: optimize traffic flows, reduce congestion, cut accident numbers. V2X scenarios have certain common network functions (dynamic topology, mobility, vehicle subscription) and then there are specialized operations per services a. V2I in short-range, adhoc routing, high reliability, higher layer security and authentication; b. traditional broadband for Infotainment; c. in network assistance for localized services. Vehicles on the road cooperate, coordinate and share information with other vehicles, the information could be collected from sensors on the road and other vehicles. During the drive a vehicle may subscribe to various location based services. A vehicle may become Qin, et al. Expires September 14, 2017 [Page 6] Internet-Draft Use Case for Network Slicing March 2017 part of of slices such that different customized slice serves low latency and zero-packet loss slice perhaps with a Vehicular Ad Hoc Network (VANET) type protocols for vehicle to vehicle and composed of an access medium (either intelligent transportation systesm (ITS) band or commercial-cellular) and a part transport and core. Vehicles also may join remote diagnose network, in which diagnostics, or software/firmware upgrades to vehicle maybe performed. Remote diagnose, location-based services are of somewhat less sensitive to response time. Vehicles will demand enhanced connectivity for in vehicle entertainment, accessing the Internet, enhanced navigation through instant and real-time information, autonomous driving, and safety, which are resource intensive. 3.3. mMTC Type NS use case 3.3.1. Smart City Smart city is about various kinds of public infrastructures connecting and harmonizing (relate to machine-to-machine (M2M) communications based on Internet of things (IoT)). Using various data sensors, smart city technologies will be able to respond in real-time to everyday events including metering (e.g., gas, energy, and water), environment (e.g., pollution, temperature, humidity, noise) monitoring, city or building lights management, vehicle traffic control, public safety like nature disaster alerting and forecasting, etc. The communication network enabling smart city need to ensure reliable communication over the entire footprint of the emergency services. 3.3.2. Health Monitoring Applications of remote health monitoring will continue growing, such applications will include several devices, like sensors, e.g., for heart rate, pulse, blood pressure, temperature. Constantly monitoring vital signs could prevent body conditions from becoming acute, and adapt medication to meet changing conditions. E-Health applications can be life critical and the system must be able to reserve/prioritise capacity for the related communications including out of coverage warnings. Identity, privacy, security and authentication management must be ensured for each device. 3.4. Other Type NS Use Case This type includes those use cases that do not have special requirements for network infrastructure and those use cases that may have mixed requirement (e.g. both eMBB and uRLL). Qin, et al. Expires September 14, 2017 [Page 7] Internet-Draft Use Case for Network Slicing March 2017 3.4.1. Use Cases Have Mixed Requirements Use cases that have mixed requirements for the network are pervasively existed. As described in section 2.1.2, AV/VR may have high requirements for bandwidth. On the other hand, as most of the applications for AR and VR are real-time, interactive VR/AR applications are extremely sensitive to delay and require very low end-to-end latency. Less than 20ms roundtrip is essential to avoid users experiencing disorientation and dizziness, which can occur if there is too much delay between the perception of an action and image display. In remote controlling, remote operation requires the communication with the characteristics of low latency and low jitter, in case of video or voice assisted communication maintenance, the bandwidth is also important. Actually, usually most of the services have mixed requirements for the network, especially for the mMTC type applications. 3.4.2. Use Cases Have no Special Requirements Over-The-Top(OTT) services are the typical scenario of this kind. OTT services are those associated with content, like video (with normal definition), audio, IM messages, web-digital content, and other media transmitted via the Internet, this kind of communications are expected to be pervasive and part of everyday life. Most commonly, a high degree of applications such as VOIP, CDNs are deployed as OTT services with low expectations from the underlying network as communication medium and subsequently by building their own application infrastructure. The trend toward IP (or HTTP) based content delivery may be perceived as an indicative of network as dumb pipe. However, QoE is important to content delivery and requires coordination with the ISPs. With a network slice which represents a partitioned network infrastructure allocated for content delivery can help create new opportunities for both network operators and content providers. 4. Conclusions Many vertical industries will migrate onto the 5G network, the goal of 5G is to support various service scenarios from these verticals that have very different network capability and performance demands. The above listed typical use cases show that each scenario requires a different network service and poses requirements that are different, each of which usually has a set of unique requirements in delay, jitter, bandwidth, security, availability et., al. These requirements indicate that the 5G networks need to be more flexible and scalable to support massive connections of diverse performance requirements into a single network. The current transport network Qin, et al. Expires September 14, 2017 [Page 8] Internet-Draft Use Case for Network Slicing March 2017 architecture is not flexible and scalable enough to support the various services scenarios and fulfill specific set of performance requirements of each use case at the same time. Network slicing aims to support services with diverse requirements to be provided on the same physical network with guaranteed independence/isolation levels. Each network slice appears to its users as an independent, dedicated private network which is impervious to anything that is happening on any of the other network slices. For the applications that do not have special requirements for network, the emergence of NS will help these applications work more economical and effective. 5. IANA Considerations This document makes no request of IANA. 6. Security Considerations The security considerations apply to each slice. In addition general security considerations of underlying infrastructure whether isolated communication with in a slice apply for links using wireless technologies. 7. Acknowledgements Thanks to Stewart Bryant for providing details for several use cases. 8. Informative References [BT-Ultra-HD-review] "BT", 2016, . [FG-IMT2020-Gaps] "FG IMT-2020: Report on Standards Gap Analysis", 2015, . [I-D.gdmb-netslices-intro-and-ps] Galis, A., Dong, J., kiran.makhijani@huawei.com, k., Bryant, S., Boucadair, M., and P. Martinez-Julia, "Network Slicing - Introductory Document and Revised Problem Statement", draft-gdmb-netslices-intro-and-ps-02 (work in progress), February 2017. [Network-Slicing-Concept] "Description of Network Slicing Concept", 2016, . Qin, et al. Expires September 14, 2017 [Page 9] Internet-Draft Use Case for Network Slicing March 2017 [NGMN-White-Paper] "NGMN", 2016, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words for Use in RFCs to Indicate Requirement Levels", RFC 6919, DOI 10.17487/RFC6919, April 2013, . [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, . [Technology-Watch-Report] , 2016, . [TR23.799] "Study on Architecture for Next Generation System", 2012, . Authors' Addresses Jun Qin Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: qinjun4@huawei.com Kiran Makhijani Huawei Technologies 2890 Central Expressway Santa Clara CA 95050 Email: kiran.makhijani@huawei.com Qin, et al. Expires September 14, 2017 [Page 10] Internet-Draft Use Case for Network Slicing March 2017 Jie Dong Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: jie.dong@huawei.com Li Qiang Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: qiangli3@huawei.com Shuping Peng Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: pengshuping@huawei.com Qin, et al. Expires September 14, 2017 [Page 11]