DETNET WG CJ. Bernardos Internet-Draft A. de la Oliva Intended status: Informational UC3M Expires: May 4, 2017 L. Cominardi InterDigital LM. Contreras TID October 31, 2016 DETNET crosshauling requirements draft-bernardos-detnet-crosshaul-requirements-00 Abstract Future 5G networks will not make a clear distinction between fronthaul and backhaul transport networks, because varying portions of radio access network functionality might be moved toward the network as required for cost reduction and performance increase. This will pose additional challenges on the transport network, driving for a new design of integrated fronthaul and backhaul, usually referred to as crosshaul. This document present the crosshaul architecture framework being developed by the EU 5G-Crosshaul project, as well as identifies several key requirements for the transport network, with the goal of fostering discussion at the DETNET WG. 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 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 May 4, 2017. Bernardos, et al. Expires May 4, 2017 [Page 1] Internet-Draft DETNET crosshauling requirements October 2016 Copyright Notice Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. 5G-Crosshaul architecture . . . . . . . . . . . . . . . . . . 4 3.1. Data plane architecture . . . . . . . . . . . . . . . . . 6 4. Crosshaul requirements . . . . . . . . . . . . . . . . . . . 6 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction According to recent predictions, mobile data traffic will increase 11-fold between 2013 and 2018. Fifth generation (5G) radio access network (RAN) technologies serving this mobile data tsunami will require fronthaul and backhaul solutions between the RAN and packet core to deal with this increased traffic load. Furthermore, there will be a sizeable growth in the capillarity of the network since traffic load increase in the 5G RAN is expected to stem from an increased number of base stations with reduced coverage (i.e., mobile network densification). To support the increased density of the mobile network (e.g., in terms of interference coordination) and achieve the required 5G capacity, extensive support for novel air interface technologies such as cooperative multipoint (CoMP), carrier aggregation (CA), and massive multiple-input multiple-output (MIMO) will be needed. Such technologies require processing of information from multiple base stations simultaneously at a common centralized Bernardos, et al. Expires May 4, 2017 [Page 2] Internet-Draft DETNET crosshauling requirements October 2016 entity and also tight synchronization of different radio sites. Hence, backhaul and fronthaul will have to meet more stringent requirements not only in terms of data rate but also in terms of latency, jitter, and bit error rate. In this upcoming 5G network environment, the distinction between fronthaul and backhaul transport networks will blur as varying portions of functionality of 5G points of attachment might be moved toward the network as required for cost efficiency reasons. The traditional capacity over provisioning approach on the transport infrastructure will no longer be possible with 5G. Hence, a new generation of integrated fronthaul and backhaul technologies will be needed to bring capital expenditure (CAPEX) and operational expenditure (OPEX) to a reasonable return on investment (ROI) range. Current transport networks cannot cope with the amount of bandwidth required for 5G. Next generation radio interfaces, using 100 MHz channels and squeezing the bit-per-megahertz ratio through massive MIMO or even fullduplex radios, requires a 10-fold increase in capacity on the integrated fronthaul and backhaul (crosshaul) segment, which cannot be achieved just through the evolution of current technologies [crosshaul_magazine]. Current trend is moving towards defining an integrated fronthaul and backhaul into a common packet-based network, as supported by the works working towards the definition of a Next Generation Fronthaul Interface (NGFI, IEEE 1914), the packetization and encapsulation on Ethernet frames of this newly interface (IEEE 1914.1) or the extensions to bridging for Time Sensitive Networking (IEEE 802.1TSN) and their profiling for frontal traffic (IEEE 802.1CM). The design of the crosshaul poses new challenges that need to be tackled. Different project and initiatives are looking at the design of the crosshaul, among which we present here the one by the 5G-Crosshaul EU project (summarized in Section 3). [I-D.ietf-detnet-use-cases] introduces and describes several use cases for DETNET. While there are some documents analyzing DETNET requirements for backhaul and fronthaul, such as [I-D.huang-detnet-xhaul], in this document (Section 4) we derive identify some requirements relevant for the DETNET WG posed by the 5G-Crosshaul design. 2. Terminology 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 [RFC2119]. While [RFC2119] describes interpretations of these key words in terms of protocol specifications and implementations, they are used in this Bernardos, et al. Expires May 4, 2017 [Page 3] Internet-Draft DETNET crosshauling requirements October 2016 document to describe requirements for DETNET mechanisms regarding support for integrated backhaul and crosshaul. The following terms are used in this document: Backhaul: the network or links between radio base station sites (or digital units) and network controller/gateway sites. Common Public Radio Interface (CPRI): industry cooperation aimed at defining a publicly available specification for the key internal interface of radio base stations between the Radio Equipment Control (REC) and the Radio Equipment (RE), which are the two basic building blocks into which a radio base station can be decomposed in order to provide flexible radio base station system architectures for mobile networks. Fronthaul: the connection from a radio base station site (or digital unit) to a remote radio unit. The fronthaul is therefore the transport connection between the functional building blocks of a cellular radio base station. The fronthaul has traditionally been implemented with point-to-point connections based on the Common Public Radio Interface (CPRI) standard. In-Phase and Quadrature (IQ): User plane data between the REC and RE is transported in the form of one or many In-Phase and Quadrature (IQ) data flows. Each IQ data flow reflects the radio signal, sampled and digitised of one carrier at one independent antenna element, the so- called Antenna Carrier (AxC). 3. 5G-Crosshaul architecture The 5G-Crosshaul project is developing an architecture for the next generation of 5G integrated backhaul and fronthaul networks enabling a flexible and software-defined reconfiguration of all networking elements in a multi-tenant and service-oriented unified management environment. The envisioned crosshaul transport network will consist of high-capacity switches and heterogeneous transmission links (e.g., fiber or wireless optics, high-capacity copper, or millimeter-wave) interconnecting remote radio heads, 5G wireless points of attachment (e.g., macro and small cells), pooled-processing units (mini data centers), and points of presence (PoPs) of the core networks of one or multiple service providers. The 5G-Crosshaul architecture is based on a novel unified data plane protocol able to transport both backhaul and fronthaul traffic, regardless of the functional RAN split. Major challenges for such a protocol are the big amount of data to handle, the synchronization of user data, and reflection of the channel structure of RAN protocols. Bernardos, et al. Expires May 4, 2017 [Page 4] Internet-Draft DETNET crosshauling requirements October 2016 A unified data plane is adopted, supporting future RAN evolutions (as they may happen on shorter timescales than transport network upgrades). This new data plane allows CPRI data to be transported in a packetized form over the unified crosshaul data plane. 5G-Crosshaul is also developing a unified control and management plane (network model and interface primitives) to simplify network operations across heterogeneous technologies. Co-existance with legacy infrastructure and support for smooth migration are considered as key requirements for operators. Three main novel building blocks are considered in 5G-Crosshaul o A control infrastructure using a unified, abstract network model for control plane integration (Crosshaul Control Infrastructure, XCI). The XCI is based on existing software defined network (SDN) controllers, to provide the services for novel northbound and southbound interfaces (NBI and SBI), and enable multi-tenancy support in trusted environments. A key aspect of the XCI is the development of new mechanisms to abstract the mobile transport network and aggregate measured contextual information. o A unified data plane encompassing innovative high-capacity transmission technologies and novel latency-deterministic switch architectures (Crosshaul Forwarding Element, XFE). This element is the central part of the Xhaul infrastructure, integrating the different physical technologies used for fronthaul and backhaul through a common data frame and forwarding behavior. Developing a flexible frame format is a key aspect of fronthaul/backhaul integration, allowing the transport of fronthaul/backhaul traffic on the same physical link, replacing different technologies by a uniform transport technology for both network segments. o A set of computing capabilities distributed across the network (Crosshaul Processing Units, XPUs). 5G-Crosshaul follows a unique approach towards the integration of the different network segments (fronthaul and backhaul) into a common transport stratum. In order to integrate the different nature of the fronthaul and backhaul traffic (with their very disparate requirements) and the different technologies that can be used to transport them, a new common transport framing format is defined (the XCF, Crosshaul Common Frame) which is used to perform the forwarding within the Crosshaul. This XCF is based on MAC-in-MAC Ethernet, and all traffic going into a Crosshaul area is adapted to this frame format. In this way, 5G-Crosshaul can leverage all the work performed in IEEE 802.1 (IEEE 802.1TSN and IEEE802.1CM) to transport flows with stringent delay requirements in Ethernet-based networks. Bernardos, et al. Expires May 4, 2017 [Page 5] Internet-Draft DETNET crosshauling requirements October 2016 3.1. Data plane architecture Essentially, the XFE is modeled as a modular multi-layer switch, that can support single or multiple link technologies (mmWave, microwave, Ethernet, copper, fiber, etc.). The XFE is mainly made up of a packet switch (5GCrosshaul Packet Forwarding Element, XPFE) and a circuit switch (5G-Crosshaul Circuit Switching Element, XCSE). The packet switching path is the primary path for the transport of most delay-tolerant fronthaul and backhaul traffic, whereas the circuit switching path is there to complement the packet switching path for those particular traffic profiles that are not suited for packet- based transporting (e.g., legacy CPRI or traffic with extremely low delay tolerance) or just for capacity offloading. The packet switch is controlled by a unified Common Frame (XCF). The circuit switch can have an optical cross-connection component (based on wavelength selective switches) and a TDM part, based on OTN, a new cost effective approach for deterministic delay switching. Note that in this draft we focus on the packet switch only. MAC-in-MAC has been chosen as the frame format for transporting backhaul and fronthaul traffic within 5G-Crosshaul. Provider Backbone Bridges belongs to IEEE Std 802.1Q and is a set of architecture and protocols for switching over a provider's network, allowing interconnection of multiple Provider Bridge Networks without losing each customer's individually defined VLANs. 4. Crosshaul requirements In this section we enumerate the main requirements for the XCF packet technology (i.e., transport data plane architecture). Aditional details will be provided in subsequent revisions of this document. We start listing below the main functional (qualitative) requirements: o Support multiple functional splits simultaneously, * Including Backhaul and CPRI-like Fronthaul. o Multi-tenancy. * Isolate traffic (guaranteed QoS). * Separate traffic (tenant privacy). * Differentiation of forwarding behavior. * Multiplexing gain. Bernardos, et al. Expires May 4, 2017 [Page 6] Internet-Draft DETNET crosshauling requirements October 2016 * Tenant ID (identification of tenants' traffic). o Coexistence, Compatibility. * Ethernet (same switching equipment, for example different ports, etc.). * Security support. * Synchronization: IEEE1588, IEEE802.1AS. o Transport efficiency. * Short overhead. * Multi-path support. * Flow differentiation. * Class of Service Differentiation. o Management. * In band control traffic (OAM info, ...). o Energy efficiency. * Energy usage proportional to handled traffic (e.g., sleep mode, reduced rate). o Support of multiple data link technologies. * IEEE 802.3, 802.11 (including mmWave), etc. o No vendor lock-in. In addition to the qualitative requirements, there are performance/ quantitative requirements: o Latency: the maximum end-to-end latency for IQ data between REC and RE MUST be 100 us, including the propagation delay of the links between the devices, internal delays of the devices such as Bridges. For Control and Management (C&M) there is no latency requirement. o Frame loss ratio (FLR): can be caused by bit error, network congestion, failures, etc. Late delivery can also imply frame Bernardos, et al. Expires May 4, 2017 [Page 7] Internet-Draft DETNET crosshauling requirements October 2016 loss for CPRI data. It MUST be less than 10E-7. For C&M the FLR MUST be less than 10E-6. o Synchronization. Depending on the type of radio access technology the requirements are different: * The maximum absolute time error SHOULD be less than 10ns for intra-band contiguous carrier aggregation radio access technologies. * The maximum absolute time error MUST be less than 45ns for Multiple-Input and Multiple-Output (MIMO) and transmit diversity radio access technologies. * The maximum absolute time error MUST be less than 110ns for intra-band non-contiguous and inter-band carrier aggregation radio access technologies. * The maximum absolute time error MUST be less than 110ns for time division duplex radio access technologies. 5. Summary This document presents a specific solution for the integration of fronthaul and backhaul (being carried out within the framework of the 5G-Crosshaul project), to then derive some key requirements for the discussion and consideration of the DETNET WG. 6. IANA Considerations N/A. 7. Security Considerations TBD. 8. Acknowledgments The authors would like to thank Akbar Rahman for his review of the document. This work is partially supported by the EU H2020 5G-Crosshaul Project (grant no. 671598). Bernardos, et al. Expires May 4, 2017 [Page 8] Internet-Draft DETNET crosshauling requirements October 2016 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 9.2. Informative References [crosshaul_magazine] "Xhaul: Towards an Integrated Fronthaul/Backhaul Architecture in 5G Networks, IEEE Wireless Communications Magazine", October 2015. [I-D.huang-detnet-xhaul] Huang, J., "Integrated Mobile Fronthaul and Backhaul", draft-huang-detnet-xhaul-00 (work in progress), March 2016. [I-D.ietf-detnet-use-cases] Grossman, E., Gunther, C., Thubert, P., Wetterwald, P., Raymond, J., Korhonen, J., Kaneko, Y., Das, S., Zha, Y., Varga, B., Farkas, J., Goetz, F., Schmitt, J., Vilajosana, X., Mahmoodi, T., Spirou, S., and P. Vizarreta, "Deterministic Networking Use Cases", draft-ietf-detnet- use-cases-11 (work in progress), October 2016. Authors' Addresses Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Phone: +34 91624 6236 Email: cjbc@it.uc3m.es URI: http://www.it.uc3m.es/cjbc/ Bernardos, et al. Expires May 4, 2017 [Page 9] Internet-Draft DETNET crosshauling requirements October 2016 Antonio de la Oliva Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Phone: +34 91624 8803 Email: aoliva@it.uc3m.es URI: http://www.it.uc3m.es/aoliva/ Luca Cominardi InterDigital Europe Email: Luca.Cominardi@InterDigital.com URI: http://www.InterDigital.com/ Luis M. Contreras Telefonica I+D Ronda de la Comunicacion, S/N Madrid 28050 Spain Email: luismiguel.contrerasmurillo@telefonica.com Bernardos, et al. Expires May 4, 2017 [Page 10]