Integrated Mobile Fronthaul and Backhaul
draft-huang-detnet-xhaul-00

Abstract

Ethernet can be a very promising technology for mobile Fronthaul and Backhaul traffic transportation, even an integrated Fronthaul / Backhaul (XHaul), although there are still some challenges. This memo tries to analyze some of the challenges and issues, such as L2 or L3 (MPLS/IP) forwarding, packet loss, etc., and to find out some requirements.

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 September 22, 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
• 1.1. Background
• 1.2. Requirements Language
• 1.3. Terminology
• 2. Ethernet or MPLS or IP
• 2.1. Scope
• 2.2. Pinned Path
• 2.3. QoS
• 2.4. Protection
• 2.5. Summary
• 3. Encapsulation
• 3.1. CPRI Aware or Unaware
• 3.2. One Encapsulation over Multiple Technologies
• 4. Packet Loss Due to BER
• 5. Time Synchronization for Re-timing
• 6. IANA Considerations
• 7. Security Considerations
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Author's Address

1. Introduction

1.1. Background

5G network will be a heterogeneous network supporting " multiple types of access technologies" [NGMN-5G-WHITE-PAPER] . A network with very low latency and jitter to support these various access technologies can significantly increase network flexibility; and network slicing should be considered to separate technologies with different QoS requirements, and separate difference operators, users or use cases. Ethernet is a good candidate for this purpose.

Fronthaul network has very critical delay, jitter and synchronization requirements, which is different from the existing Backhaul network. But in the future, there will be some new applications which require very low E2E latency, such as 5ms or even 1ms, as defined in [NGMN-5G-WHITE-PAPER] and [METIS-D1.1] . This will give some common requirements to both Fronthaul and Backhaul network.

There have been quite some work in the industry, trying to use Ethernet for Fronthaul, such as the IEEE 802.1CM and IEEE 1904.3.

Now the existing Backhaul network is Ethernet based (IP RAN, PTN, etc.), if the Fronthaul network can be Ethernet based too, it is possible to build an integrated Fronthaul and Backhaul

[XHaul] and [Crosshaul] are trying to develop and integrated Fronthaul and Backhaul, and packet network device ("Xhaul Packet Forwarding Element") will be considered. At the [IWPC-Evolving-Transport-Networks] meeting, some operators and vendors express the idea of "unified Fronthaul & Backhaul over Ethernet".

1.2. 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] .

1.3. Terminology

BBU: Baseband Unit

BER: Bit Error Rate

CPRI: Common Public Radio Interface

CRAN: Cloud / Centralized RAN

E2E: End to End

FEC: Forward Error Correction

FCS: Frame Check Sequence

FRR: Fast ReRoute

HARQ: Hybrid Automatic Repeat Request

IPWC: International Wireless Industry Consortium

RRU: Remote Radio Unit

TSN: Time Sensitive Network

2. Ethernet or MPLS or IP

2.1. Scope

The following analysis is on the Fronthaul / Backhaul use case.

MPLS includes L2VPN, L3VPN, PWE3, etc.

2.2. Pinned Path

If there are stringent QoS requirements, such as bandwidth reservation to avoid congestion, limited number of hops and distance to reduce delay, or even going through links with low BER, the path should be fixed. Traditional L2 MAC forwarding and L3 IP routing can not provided this capability. SDN or flow-based solution may be able to meet this requirement, either over L2 MAC forwarding or over L3 IP routing, in which forwarding decision will be made via MAC forwarding table, IP routing table or flow table which is installed by a controller, rather than being generated in an autonomous way, such as using OSPF protocol. But this type of solution is not yet widely used in the industrial. MPLS is a better solution for this purpose. A management system or PCE / RSVP / LDP can perform MPLS label planning and distribution, this is a mature solution in the industry.

2.3. QoS

In the Fronthaul / Backhaul use case, there will be Fronthaul traffic and Backhaul traffic in a same network, and also some other traffic types, such as WIFI, IoT traffic, etc. These various types of traffic have different QoS requirements. Priority based QoS mechanism is not sufficient. Pre-emption is developed by IEEE TSN to resolve the interference from the low priority traffic. Besides, re-timing should also be considered to achieve very low jitter.

E2E resource reservation is necessary to avoid congestion. In a congestion case, the delay, jitter and packet loss will be a problem. Usually MPLS is used for E2E resource reservation.

If network slicing is considered to support various type of traffic in a network, and support multiple operator or tenants, traffic separation in the network is necessary. VLAN can serve this purpose in some common cases where bandwidth guarantee is not required. If the network will cover an area of a city, or a broader area, MPLS should be considered for E2E resource reservation and traffic separation. Multiple routing instances (such as OSPF) can be configured to serve this purpose, which usually work on port or port + VLAN.

2.4. Protection

Protection is a common feature in operator's network.

Ethernet supports linear protection [ITU-G.8031] and ring protection [ITU-G.8032] , and a lot of other standard and proprietary solutions.

MPLS-TP can support multiple levels protection: LSP, PW and sector, linear protection [ITU-G.8131] . E2E resource reservation is retained after the protection switch.

Fast reroute is a MPLS (IP MPLS) [RFC4090] and IP [RFC5714] protection solution if there is link failure or router failure, which can provide network recovery within 50ms. The issue with IP fast reroute is, resource reservation can not be done via signaling, but has to depend on static network planning.

2.5. Summary

Through the above analysis, MPLS (over Ethernet) is a good candidate for the XHaul case, mainly due to the E2E resource reservation and protection features. Support to MPLS should be considered.

But MPLS does not means it will work for all the case, e.g. in a pro-audio/video network, Ethernet may be a better choice because the network is small and simple, there are QoS requirements but not too stringent. It may be similar in the industry control network.

3. Encapsulation

3.1. CPRI Aware or Unaware

[CPRI] is an open protocol, but it is not complete, some details are missing, such as the sampling bit width. Some possible values of sampling width are provided in the specification, but not sure which one will be used for a specific wireless technology, and if compression is considered to reduce bandwidth requirement, a smaller sampling width value may be used. If such a value is not specified, then it is difficult to identify a CPRI frame.

A reasonable solution is to treat the CPRI traffic as a bit stream. A fixed block of CPRI traffic, such as 1500byte including the encapsulation, or the traffic over a fixed period of time, is encapsulate into a packet.

One of the advantages of CPRI aware encapsulation, is to perform compression, and some of the reserved bits in the control bit are removed, the IQ data is compressed using some compressing solution. But, maybe the RRU itself is a better place to do this kind of processing, rather than in the transport device.

3.2. One Encapsulation over Multiple Technologies

IEEE 1904.3 defines encapsulation for CPRI over Ethernet. Should that encapsulation format be used over MPLS or even IP too, or should there be any necessary changes?

4. Packet Loss Due to BER

The CPRI traffic carries the IQ data of baseband signal, in which FEC function is usually used, e.g. the turbo coding function in LTE. Some bit errors in the baseband signal or in the IQ data can be corrected by the FEC module, and the left can be fixed using HARQ retransmission mechanism. Due to this, when CPRI traffic is carried by direct fiber link or by non-packet based technology, such as OTN, even if there are bit errors, it is not a big problem, the BBU can still process the IQ data.

But if CPRI traffic is carried over an Ethernet or other packet-based link, when there is a bit error, usually the packet is discarded. The packet size will decide how much CPRI traffic be lost. Because CPRI requires a lot of bandwidth, the packet size should be large enough for efficiency. For Ethernet the payload size should be 1500byte or 9000byte (jumbo frame). If such a continuous segment of CPRI data is lost, it will significantly increases "equivalent" BER [packet-loss-consideration] . Issues caused by packet loss can not fixed by existing FEC function in LTE. HARQ retransmission will have to be considered as a final resort.

The packetization / framing will make the issue worse. The CPRI traffic over a packet may expand across multiple CPRI basic frame or even hyperframe, and further across multiple LTE code block and transport block, which may lead to multiple LTE HAQR retransmission. Further study on the impact to the wireless network performance caused by packet lost is necessary.

Cut-through forwarding is to start forwarding actions such as forwarding table lookup when the header of a packet is received, before receiving the complete packet. Cut-through forwarding can significantly reduce the delay in a network device. Receiving a packet of 1500bytes on a 10GE interface will take about 1.2us, if cut-through forwarding is used, more than 1us delay time can be reduced. Cut-through forwarding is widely used in FCoE and Infiniband, some Ethernet switches also provide this capability.

But cut-through forwarding has some issues, one of which is the FCS error of a Ethernet packet. If there is a bit error, the FCS validation will fail, and the packet should be discarded. But in cut-through forwarding mode, before the switch can validate the FCS, part of the packet is already on the wire and the packet can not discarded. The packet with bit error will finally be forwarded to a store-and-forward switch, or the final receiver. Even the receiver, such as the BBU in the CRAN architecture, finally receive the packet, it will has to discarded the packet, because it does not know the bit error occurs in which part of the packet, in the Ethernet or MPLS header, or the encapsulation, or in the CPRI data.

Cut-through forwarding itself does not help in the bit error case.

5. Time Synchronization for Re-timing

Due to the very critical jitter requirement, +/- 8.138ns for one way jitter and +/- 16.276ns for round trip jitter, it is very difficult to achieve this target simply via scheduling, neither priority based nor pre-emption, or other algorithms. According to [applicability-of-qbu-and-qbv], even if pre-emption is used, a maximum delay of 114.4ns over a 10GE interface still exist. To further reduce the jitter, re-timing should be used. That is, put a time stamp T1 in the packet at the ingress of the network; when the packet arrive at the egress node at T2, buffer the packet until T3, then send out the packet. T3 >= T2. (T3 - T1) is a fixed value, and it should be long enough to cover all the possible jitter, fibre propagation delay, processing delay, etc. On the other hand, the delay (T3-T1) should be as low as possible.

Re-timing mechanism should be bi-directional.

+------+  +-----------------+  +-----+
| RRU1 |--| Ingress Switch1 |--| ... |--- 
+------+  +-----------------+  +-----+   \
                                          \
                                           \
+------+  +-----------------+  +-----+  +---------------+  +-----+
| RRU2 |--| Ingress Switch2 |--| ... |--| Egress Switch |--| BBU |
+------+  +-----------------+  +-----+  +---------------+  +-----+
            add time stamp               arrive at T2 
                 T1                      send out at T3