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,
<http://www.rfc-editor.org/info/rfc2119>.
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]