工研院資通所 賴家齡, Samer Talat, Shahzoob Bilal Chundrigar

5G-Crosshaul aims at developing an adaptive, sharable, cost-efficient 5G transport network solution integrating the fronthaul and backhaul segments of the network. This transport network will flexibly interconnect distributed 5G radio access and core network functions, hosted on in-network cloud nodes, through the implementation of two novel building blocks: 1) a control infrastructure using a unified, abstract network model for control plane integration (5G-Crosshaul Control Infrastructure, XCI); 2) a unified data plane encompassing innovative high-capacity transmission technologies and novel deterministic-latency switch architectures (5G-Crosshaul Packet Forwarding Element, XFE). 5G-Crosshaul will greatly simplify network operations despite growing technological diversity. It will hence enable system-wide optimization of Quality of Service (QoS) and energy usage as well as network-aware application development.

Motivations and Challenges in 5G-Crosshaul Project

Traditionally, traffic between base stations and the mobile core network of mobile operators is transported via the so-called backhaul network. Backhaul networks have very specific characteristics: 1) they typically consist of fibre rings in metro and regional aggregation parts and wireless trees or chains towards the network edge. 2) they employ a wide array of transport protocols such as SDH, OTN, Plain Ethernet, Carrier Ethernet, MPLS-TP or IP/MPLS. Furthermore, since it is close to the network edge, the backhaul network has to cope with lots of dynamics: user mobility, vastly changing load, mixed Quality of Service (QoS) requirements, etc. These characteristics are highly challenging for mobile operators and are far from being efficiently addressed in real-world networks. There is an abundance of Element and Network Management Systems (ENMS) for the different technology and vendor domains, switches are only partially compatible even though presumably supporting common standards, equipment management interfaces are non-standardized, bulk configurations are poorly supported, tunnels can hardly be changed after being set up, and so on. Due to this inflexibility and heterogeneity mentioned above, user plane interoperability and system-wide management let alone dynamic optimization are nearly impossible.

In addition to the above complexity, there is an ever-increasing stress on radio access performance which is one of the main reasons why 5G comes with some extremely challenging service-level Key Performance Indicators (KPIs) in terms of capacity and latency. Meeting these KPIs requires the evolution of current transport technologies along with the introduction of new ones. Further, these KPIs have led to the development of new base station cooperation features that can be best supported by centralizing base station functionalities, i.e., Centralized Radio Access Network (C-RAN). However, the resulting communication needs between remote and central base station functionalities (i.e., to transport digitized radio signals) only aggravates the service-level performance KPI requirements mentioned before. Thus, to support C-RAN, specialized transport standards and interfaces were developed in the past, resulting in logical point-to-point links between remote and central base station functions called fronthaul. As of today, fronthaul is a separate network segment, completely incompatible to the backhaul in terms of physical interfaces, user, control and management plane.

Given the above challenges, the telecom industry is actively looking into less extreme ways of Radio Access Network (RAN) centralization by analysing different split options between centralized and remote RAN functionality. Depending on how RAN functionality is split, there are highly varying performance requirements on the transport network. The 5G mobile transport network will have to support different functional splits of the 5G RAN, including C-RAN, in a unified way. Therefore it refers to this integrated backhaul and fronthaul network as 5G-Crosshaul.

Since 5G will include a flexible split of base station functions between central and edge locations, the C-RAN static split model (with purpose-built Remote Radio Heads, RRHs, and Base Band Units, BBUs, nodes) will not work as a general paradigm. Rather, both edge and central networking hardware need to include generic processing engines capable of coping with any set of base station functions. Practically speaking, this means that 5G-Crosshaul will not only comprise communication links and forwarding elements, but also encompass processing nodes which host the various RAN functions, as well as transport functions (e.g., virtual BGP, Virtual Resource Functions), caches, mobility anchors, and others. Clearly, the processing node where a function is placed has a direct impact on the end-to-end performance of the transport network. Vice versa, the transport network might dictate where to place a function in order to satisfy the QoS requirements. As opposed to traditional backhaul, resource management in 5G-Crosshaul must thus go beyond routing or traffic engineering to also jointly optimize RAN policies (e.g., schedulers, shapers, queue management) and function placement.

Besides, in times of decreasing Average Revenue per User (ARPU), the 5G-Crosshaul network must be highly cost-efficient, despite having to support increasing performance requirements and extreme densification of RAN, hence of transport links. This can only be achieved through a concerted effort across all 5G-Crosshaul components: Forwarding element architectures need to be streamlined. Cost-effective link technologies must be developed. Assets and technologies need to be sharable across fixed and mobile access as well as across multiple operators. 5G-Crosshaul control and management must be fully unified and automated, and self-optimization must ensure maximum asset utilization and drastic energy savings.

In summary, the 5G-Crosshaul mobile transport network has to address serious challenges listed in the below:

• How to homogeneously operate and optimize a 5G network with high technological heterogeneity?
  
  
• How to best support (and even strictly enforce) vastly different QoS requirements stemming from highly diverse user and network services?
  
  
• How to best exploit the flexibility offered by dynamically reconfiguring physical parameters, routing and function placement in order to maximize asset utilization and reduce energy consumption?
  
  
• How to find the best way to dynamically distribute base station functions depending on network layout and traffic conditions?
  
  
• How to support backhaul and fronthaul convergence in terms of switch evolutions, frame structures, synchronization mechanisms and physical technology evolution?
  
  
• How to reduce cost by appropriately including low-cost last mile technologies, supporting multi-tenancy and system-wide optimization, and performing algorithm-based infrastructure design?
  
  

5G-Crosshaul Architecture

This section presents the consolidated design of the 5G-Crosshaul architecture [1][2] depicted in Figure 1.

In the control plane defined in 5G-Crosshaul, it includes a group of key functional elements (e.g., topology discovery, network monitoring, technology abstraction, provisioning of virtual infrastructure, etc.) and their main interfaces towards the applications (northbound interface) and towards underlying technologies (southbound interface). For the design of the control plane we leverage on the SDN principles to have a unified control, management and configuration of the 5G multi-technology transport network, and apply Network Function Virtualization (NFV) to the 5G-Crosshaul infrastructure enabling flexible function placement and cost-effective usage of the 5G-Crosshaul infrastructure resources. The SDN principle allows the separation of the data and control planes, fostering network and device programmability. NFV allows infrastructure and function virtualization, where the underlying physical infrastructure and network functions can be virtualized in such a way that they will be appropriately instantiated, connected and combined with the 5G-Crosshaul substrate.

The data plane defined in 5G-Crosshaul, in turn, integrates heterogeneous technologies for the fronthaul and backhaul links into a single SDN-based controlled network. The main challenge of the data plane is the need for extended flexibility, to adapt to the new fronthaul and backhaul technologies arising with 5G as well as to incorporate legacy technologies through abstraction interfaces.

To achieve such a design, our approach is to leverage the state-of-the-art SDN and NFV architectures to maximize the compatibility and integration of 5G-Crosshaul system design with the existing standard frameworks and reference specifications. So far, the most well-developed open source SDN controllers which provide carrier-grade features and can be used for 5G networks are: Open Daylight (ODL) [3] and Open Network Operating System (ONOS) [4]. In the NFV case, ETSI NFV ISG is currently studying the ability to deploy instances of network functions running on VMs, providing network operators with the ability to dynamically instantiate, activate, and re-allocate resources and functions [5]. Based on these open source initiatives and standards, our 5G-Crosshaul architecture keeps the architecture compatibility with the existing ODL/ONOS and ETSI NFV architecture frameworks.

Component in 5G-Crosshaul Control Plane

The Crosshaul Control Infrastructure (XCI) is the brain controlling the overall operation of the 5G-Crosshaul architecture. The XCI part dealing with NFV comprises three main functional blocks: NFV Orchestrator (NFVO), VNF Manager (VNFM), and Virtual Infrastructure Manager (VIM) (following the ETSI NFV architecture [5]). In addition to these modules, which are in charge of managing the different Virtual Network Functions (VNFs) running on top of the 5G-Crosshaul, the XCI includes a set of specialized controllers to deal with the control of the underlying network, storage, and computation resources.

<strong>NFV Orchestrator (NFVO)</strong>is a functional block that manages a Network Service (NS) lifecycle. It coordinates the VNF lifecycle (supported by the VNFM) and the resources available at the NFV Infrastructure (NFVI) to ensure an optimized allocation of the necessary resources and connectivity to provide the requested virtual network functionality.

<strong>VNF Managers (VNFMs)</strong> are functional blocks responsible for the lifecycle management of VNF instances (e.g. instance instantiation, modification and termination);

<strong>Virtualized Infrastructure Manager (VIM)</strong> functional block is responsible for controlling and managing the NFVI computing (via Computing ctrl), storage (via Storage ctrl), and network resources (via SDN ctrl).

<strong>SDN Controller</strong> module is in charge of controlling the underlying network elements following the conventional SDN paradigm. 5G-Crosshaul aims at extending current SDN support of multiple technologies used in transport networks (e.g., microwave links) in order to have a common SDN controlled network substrate that can be reconfigured based on the needs of the network tenants.

<strong>Computing/Storage Controllers</strong> are included in what we call a cloud controller. A prominent example of this kind of software framework is OpenStack. Note that the SDN/computing/storage controllers are functional blocks with one or multiple actual controllers (hierarchical or peer-to-peer structure) that centralize some or all of the control functionality of one or multiple network domains. We consider the utilization of legacy network controllers (e.g., MPLS/GMPLS) to ensure backward compatibility for legacy equipment.

Component in 5G-Crosshaul Data Plane

5G-Crosshaul integrates all communication links between Remote Radio Heads/Small Cells and core network entities in a unified transport network by designing a common data plane that enables the integration of heterogeneous technologies for the fronthaul and backhaul links into a single programmable, multi-tenant enabled packet-based network. To this aim, in 5G-Crosshaul, several components are developed for data plane usage.

5G-Crosshaul Forwarding Element (XFE) XFEs are switching units that support single or multiple link technologies (mmWave, Ethernet, fiber, microwave, copper, etc.). A key part of the envisioned solution is a common switching layer in the XFEs for enabling unified and harmonized transport traffic management. This common switching layer supports the 5G-Crosshaul common frame (XCF) format across the various traffic flows (of fronthaul and backhaul) and the various link technologies in the forwarding network. The common switching layer in the XFEs is controlled by the XCI, which is foreseen to have a detailed (as per the abstraction level defined) view of the fronthaul and backhaul traffic and resources, and to expose this detailed view through a further abstraction to the orchestration layer to enable intelligent resource, network function, and topology management across the two domains. As depicted in Fig. 2, XFEs include packet switching elements (XPFEs) and circuit switching elements (XCSEs). Two paths are defined in this framework: a packet switching path (upper part) and an all-optical circuit switching path (lower part). 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 transport (e.g., legacy common public radio interface [CPRI] or traffic with extremely low delay tolerance). This two-path switching architecture is able to combine bandwidth efficiency through statistical multiplexing in the packet switch, with deterministic latency ensured by the circuit switch. The modular structure of the 5G-Crosshaul switch, where layers may be added and removed, enables various deployment scenarios with traffic segregation at multiple levels, from dedicated wavelengths to virtual private networks (VPNs), which is particularly desirable for multi-tenancy support.

5G-Crosshaul Common Frame (XCF) is the frame format used by the XPFE. Ideally, the XCF is supported by all physical interfaces where packets are transported. The XCF is based on Ethernet, utilizing MACinMAC (or Provider Backbone Bridged Network) [6]. MACinMAC, or alternatively QinQ (or Provider Bridged Network), provides a more flexible separation of tenants compared to VLANs. Networks of different tenants can be separated via the outer MAC header, nevertheless, within one tenant, there can be several virtual customer networks. The priority bits of the Ethernet header is used to indicate the priorities of the different traffic flows.

5G-Crosshaul Processing Unit (XPU) Cloud and Storage control platform of the XCI handles the 5G-Crosshaul IT components (computing and storage resources) in the XPUs. Virtual infrastructure is instantiated, configured and operated by XCI in XPUs, where VNFs can be deployed to run the 5G-Crosshaul services in a proper and efficient manner.

Network Applications in 5G-Crosshaul Network

In D4.1 [7][8], ITRI developed three novel applications in terms of Multi-tenancy Application (MTA), Mobility and Management Application (MMA) and Energy Management and Monitor Application (EMMA). The below description is to briefly summary those three applications. For further detailed content for those developed applications can be referred to the literatures in [12][13][14].

A.MMA

For high-speed train scenario adopting two-hop architecture, i.e. passengers use on-board point-of-access points which are then backhauled by ground-to-train communications, the outbound gateway(s) providing ground-to-train moving backhaul perform handover frequently to maintain the availability and quality of moving backhaul. Current LTE systems adopt break-and-make handover, which inevitably causes interruption and throughput degradation during handover.

In conventional handover, it is composed of the four stages: 1) HO Measurement: in addition to current serving eNB, UE also measures the signal quality of neighbor eNBs and reports to its serving eNB. 2) HO Preparation: once the signal quality of some neighbor eNB reaches some criteria compared to serving eNB, serving eNB starts negotiation with the neighbor eNB (called target eNB) to reserve/allocate resource for upcoming handover. 3) HO Execution: serving eNB commands UE to disconnet and which target eNB to connect immediately. 4) HO Completion: after the UE completes attachment, the target eNB notifies MME to switch the path it sends packet through.

In the conventional LTE handover procedure is related to packet redirection during handover. Before path switch command is issued in handover completion stage, MME has no idea about the handover at all. Therefore, each and every packet for UE is sent to original serving eNB first, who then re-routes the packets to the target eNB, and it prolongs the round-trip-time of packets with negative effect on the throughput. Since the handover procedure is strictly controlled by LTE handover control signals, this issue is seldom addressed because it involves the orchestration among eNBs (serving and target) as well as MME and the serving GW. 

With 5G-Crosshaul, MMA for High-Speed Train (HST) is proposed to address the aforementioned issue in a transparent manner as shown in Figure 3. The main idea behind MMA for HST is to act as a proxy between eNBs and MME and send the handover control signal on behalf of them. By doing so, the handover completion stage can be performed in parallel with handover execution stage, and the path switch doesn’t need to wait until handover execution is done.

B.MTA

Multi-Tenancy is a desired feature by 5G-Crosshaul to enable a generalized, flexible sharing of 5G-Crosshaul infrastructures among multiple network operators or service providers (i.e., multiple tenants). The target is to significantly reduce the CAPEX and OPEX by sharing the infrastructure resources and maximize their utilization in a cost-efficient manner. The 5G-Crosshaul XCI relies on the integration and alignment with existing initiatives and projects (e.g., SDN controllers such as OpenDaylight) supporting multi-tenancy to some degree. However, a coherent management of multi-tenancy is required horizontally, unifying the concepts of infrastructure virtualization and multi-tenancy in all involved segments and resources. For this purpose, the Multi-Tenancy Application (MTA) is needed to provide such management.

The MTA is in charge of assembling these physical resources into a virtual network infrastructure and then allocate the virtual resources to the tenants as shown in Figure 4. Each tenant is composed of a network subset with virtual nodes and links, referred to as a slice, owning a subset of the physical resources (including computing, storage and networking resources). The tenant is created making use of virtualization techniques. The MTA allows on-demand, dynamic allocation of virtual resources to the tenants, providing per-tenant monitoring of network QoS and resource usage. Moreover, the MTA also allows the tenants to control and manage their own virtual resources. The main challenge is to ensure a clean isolation across tenants.

C. EMMA

To provide high-speed train communications, we can deploy either general purpose or dedicated systems. In dedicated systems, the transceiving equipment deployed along railway track spend most of the time waiting for passing-by high-speed train to serve, which implies a great deal of waste in energy consumption and operation cost. If all or part of them can be turned on only when needed, system energy efficiency and OPEX can be improved.

Among the transceiving nodes deployed along high-speed rail track, Radio-over-Fibre (RoF) technology is used to extend Radio Frequency (RF) signals from base stations (BS), mostly to tunnels, in a transparent manner. EMMA controls the power state of RoF according to the presence of a high-speed train in close proximity of the nodes reported by cloud database as shown in Figure 5. The application signals to the XCI that idle RoF nodes should be switched off when unused. The goal is to minimize the energy footprint of the deployed distributed RoF nodes in the Crosshaul network without degrading the QoS of ground-to-train communication.

Conclusion and 5G-Crosshaul Phase II Project

5G-Crosshaul is ended in December 2017. The validation and demonstration results can be found in [10]. However, 5G-Crosshaul is Phase I project to 5G network, which is focusing on investigation all possible solutions for 5G network. Following the advanced study and validated results in 5G-Crosshual, a 5G-Phase II project is going to implement a real 5G network based on the supported results from 5G-Crosshaul. 5G-Transformer project is started and dedicated to 5G network implementation in terms of network slicing and edge computing realization [11] based on the foundation of 5G-Crosshaul project. It is aiming to transform today’s mobile transport network by using an SDN/NFV-based Mobile Transport and Computing Platform (MTP). Also in 5G Transformer, it enables vertical industries to meet their service requirements within customized MTP slices and aggregate and federate transport networking and computing fabric, from the edge all the way to the core and cloud, to create and manage MTP slices throughout a federated virtualized infrastructure.

Reference

[1] 5G-Crosshaul initial system design, use cases and requirements [Online]. Available: http://5g-crosshaul.eu/wp-content/uploads/2018/01/5G-CROSSHAUL_D1.1.pdf

[2] X. Costa-Pérez, A. Garcia-Saavedra, X. Li, A. de la Oliva, P. Iovanna, T. Deiß, A, di Giglio, and A. Mourad, “Integrated Fronthaul/Backhaul Transport Network Architecture,” IEEE Wireless Communications Magazine, Vol. 24, No. 1, Feb. 2017.

[3] OpenDaylight [Online]. Available: http://www.opendaylight.org

[4] ONOS [Online]. Available: http://onosporject.org

[5] ETSI GS NFV 003, ETSI, V1.2.0, 2014-11

[6] Bridges and Bridged Networks, IEEE Std 802.1Q™-2014

[7] http://5g-crosshaul.eu/wp-content/uploads/2018/01/5G-CROSSHAUL_D4.1.pdf

[8] http://5g-crosshaul.eu/wp-content/uploads/2018/01/5G-CROSSHAUL_D4.2.pdf

[9] http://5g-crosshaul.eu/wp-content/uploads/2018/01/5G-CROSSHAUL_D1.1.pdf

[10] http://5g-crosshaul.eu/wp-content/uploads/2018/01/5G-CROSSHAUL_D5.2.pdf

[11] https://5g-ppp.eu/5g-transformer/

[12] Chia-Lin Lai, Shahzoob Bilal Chundrigar, Samer T. Talat, Hsien-Wen Chang, “Network Sharing based on Multi-Operator Traffic inside Moving Transportation,” IEEE Vehicular Technology Magazine, Vol. 13, Issue 1, January 2018.

[13] Shahzoob Bilal Chundrigar, Samer T. Talat, Hsien-Wen Chang, “Evaluation of Energy Efficient Radio-over-Fiber for High-speed Train Testbed,” to be published in IEEE AnNet 2018.

[14] Osamah Ibrahiem Abdullaziz; Marco Capitani; Claudio Ettore Casetti; Carla Fabiana Chiasserini; Shahzoob Bilal Chundrigar; Giada Landi; Xi Li; Francesca Moscatelli; Kei Sakaguchi; Samer T. Talat, “Energy monitoring and management in 5G integrated fronthaul and backhaul,” EuCNC, pp. 1 – 6, 2017.