WO2017147076A1

WO2017147076A1 - Methods, apparatuses and systems directed to common transport of backhaul and fronthaul traffic

Info

Publication number: WO2017147076A1
Application number: PCT/US2017/018730
Authority: WO
Inventors: Luca COMINARDI; Alain Mourad; Ravikumar V. Pragada; Douglas R. Castor
Original assignee: Idac Holdings, Inc.
Priority date: 2016-02-22
Filing date: 2017-02-21
Publication date: 2017-08-31
Also published as: TW201739215A

Abstract

Methods, apparatuses, systems, devices, and computer program products directed to common transport of backhaul and fronthaul traffic (collectively "crosshaul traffic") are provided. Among new methodologies and/or technologies provided herein is a crosshaul common frame (XCF) adapted to carry, among other information, new control information for enabling optimized forwarding and/or management of any packet-based crosshaul traffic. The optimized forwarding and/or management may be enhanced with segment routing adaptation of the XCF. And pursuant to the XCF being MAC-in-MAC protocol compatible, not only can the forwarding of the XCF be carried out by packet switching elements supporting common XCF-domain forwarding and management controls (and hence, capable of utilizing the new control information), but also by legacy MAC-in-MAC protocol (Ethernet) switches not under the XCF-domain common forwarding control.

Description

METHODS, APPARATUSES AND SYSTEMS DIRECTED TO COMMON TRANSPORT OF BACKHAUL AND FRONTHAUL TRAFFIC

CROSS REFERENCE TO RELATED APPLICATION(S)

[0001] This application claims the benefit of U.S. Provisional Patent Application Serial No. 62/298,428, filed 22-Feb-2016; and U.S. Provisional Patent Application Serial No. 62/298,449, filed 22-Feb-2016; each of which is incorporated herein by reference in its entirety.

BACKGROUND

[0002] Field

[0003] This application is related to wired and/or wireless communications.

[0004] Related Art

[0005] An ambitious set of key performance indicators (KPis), e.g., capacity, latency, and/or efficiency, is targeted for the design of the next generation, e.g., the fifth generation (5G), communication system at a time network operators are facing the challenge of reducing their costs, e.g., total cost of ownership (TCO), and expanding their service offerings. Current radio access network (RAN) architectures (including cloud-RAN (C-RAN)) are cost-prohibitive and may not be suitable to meet 5G requirements effectively. The unmodified fronthaul domain (from C-RAN) may be composed of deterministic bandwidth-hungry point-to-point links, e.g., common public radio interface (CPRI) over fiber, which may be cost-prohibitive and not scalable for the high densification, e.g., small cells, and multiple-input-multiple-output (MTMO) technologies, which may be massive, foreseen in 5G.

[0006] On the other hand, the backhaul domain is growing in complexity and hence cost, with increasingly heterogeneous and independently managed technologies, which also poses a challenge to meet stringent End-to-End (E2E) latency 5G requirements. Current approaches to evolve the fronthaul and backhaul exist, such as CPRI over Ethernet for the fronthaul, e.g., the recently published standard IEEE 1904.3, and software-defined networking (SDN) and/or network functions virtualization (NFV) enablement in the backhaul.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] A more detailed understanding may be had from the detailed description below, given by way of example in conjunction with drawings appended hereto. Figures in such drawings, like the detailed description, are examples. As such, the Figures and the detailed description are not to be considered limiting, and other equally effective examples are possible and likely. Furthermore, like reference numerals ("refi") in the Figures indicate like elements, and wherein:

[0008] FIG. 1 A is a system diagram of an example communications system in which one or more disclosed embodiments may be implemented; [0009] FIG. IB is a system diagram of an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1 A;

[0010] FIGs. 1C, ID and IE are system diagrams of example radio access networks and example core networks that may be used within the communications system illustrated in FIG.

1A;

[0011] FIG. 2 illustrates an example environment in which embodiments may be practiced or implemented;

[0012] FIG. 3 is a block diagram illustrating an example communications environment having a crosshaul common frame (XCF) domain;

[0013] FIG. 4 is a block diagram illustrating an example template of a MAC-in-MAC frame;

[0014] FIG. 5 is a block diagram illustrating an example crosshaul common frame (XCF);

[0015] FIG. 6 is a block diagram illustrating an example network entity in which embodiments may be practiced or implemented;

[0016] FIG. 7 is a block diagram illustrating an example XCF with segment routing controls;

[0017] FIG. 8 is a block diagram illustrating an example XCF configured to support segment routing;

[0018] FIG. 9 is a block diagram illustrating an example fast reroute mechanism of an XCF with segment routing controls;

[0019] FIG. 10 is a block diagram illustrating an example network entity in which embodiments may be practiced or implemented;

[0020] FIG. 11 shows an XCF encapsulation and forwarding example based on segment routing with fast reroute support in an Ethernet-compatible multi data-link scenario.

[0021] FIGs. 12 and 13 are block diagrams illustrating an example of legacy Ethernet switches MAC table population;

[0022] FIG. 14 is a block diagram illustrating an example of a high level XCF forwarding process carried out at a crosshaul forwarding entity (XFE);

[0023] FIG. 15 is a block diagram illustrating example internal forwarding procedures of an XFE;

[0024] FIG. 16 is a block diagram illustrating an example the high level XCF adaptation/translation process at a crosshaul adaptation unit (XAU);

[0025] FIG. 17 is a block diagram illustrating example internal forwarding procedures of an XAU;

[0026] FIG. 18 is a flow diagram illustrating a representative procedure directed to common transport of crosshaul traffic; and [0027] FIG. 19 is a flow diagram illustrating a representative procedure directed to common transport of crosshaul traffic.

DETAILED DESCRIPTION

[0028] In the following detailed description, numerous specific details are set forth to provide a thorough understanding of embodiments and/or examples disclosed herein. However, it will be understood that such embodiments and examples may be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, procedures, components and circuits have not been described in detail, so as not to obscure the following description. Further, embodiments and examples not specifically described herein may be practiced in lieu of, or in combination with, the embodiments and other examples described, disclosed or otherwise provided explicitly, implicitly and/or inherently (collectively "provided") herein.

[0029] Example Communications System

[0030] The methods, apparatuses and systems provided herein are well-suited for communications involving both wired and wireless networks. Wired networks are well-known. An overview of various types of wireless devices and infrastructure is provided with respect to FIGs. 1A-1E, where various elements of the network may utilize, perform, be arranged in accordance with and/or be adapted and/or configured for the methods, apparatuses and systems provided herein.

[0031] FIG. 1 A is a diagram of an example communications system 100 in which one or more disclosed embodiments may be implemented. Example communications system 100 is provided for the purpose of illustration only and is not limiting of the disclosed embodiments. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and the like.

[0032] As shown in FIG. 1A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like.

[0033] The communications systems 100 may also include a base station 114a and a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network 106, the Internet 110, and/or the networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

[0034] The base station 114a may be part of the RAN 104, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In another embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

[0035] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0036] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High- Speed Uplink Packet Access (HSUPA).

[0037] In another embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and/or LTE- Advanced (LTE-A).

[0038] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0039] The base station 114b in FIG. 1A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the core network 106.

[0040] The RAN 104 may be in communication with the core network 106, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 and/or the core network 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may be utilizing an E-UTRA radio technology, the core network 106 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0041] The core network 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

[0042] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, i.e., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0043] FIG. IB is a system diagram of an example WTRU 102. Example WTRU 102 is provided for the purpose of illustration only and is not limiting of the disclosed embodiments. As shown in FIG. IB, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 106, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0044] The processor 1 18 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. IB depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0045] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[0046] In addition, although the transmit/receive element 122 is depicted in FIG. IB as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MTMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0047] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.

[0048] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 106 and/or the removable memory 132. The non-removable memory 106 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SFM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0049] The processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0050] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0051] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0052] FIG. 1C is a system diagram of the RAN 104 and the core network 106 according to an embodiment. As noted above, the RAN 104 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 may also be in communication with the core network 106. As shown in FIG. 1C, the RAN 104 may include Node-Bs 140a, 140b, 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. The Node-Bs 140a, 140b, 140c may each be associated with a particular cell (not shown) within the RAN 104. The RAN 104 may also include RNCs 142a, 142b. It will be appreciated that the RAN 104 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment. [0053] As shown in FIG. 1C, the Node-B s 140a, 140b may be in communication with the RNC 142a. Additionally, the Node-B 140c may be in communication with the RNC 142b. The Node-Bs 140a, 140b, 140c may communicate with the respective RNCs 142a, 142b via an Iub interface. The RNCs 142a, 142b may be in communication with one another via an Iur interface. Each of the RNCs 142a, 142b may be configured to control the respective Node-Bs 140a, 140b, 140c to which it is connected. In addition, each of the RNCs 142a, 142b may be configured to carry out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macrodiversity, security functions, data encryption, and the like.

[0054] The core network 106 shown in FIG. 1C may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and/or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0055] The RNC 142a in the RAN 104 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.

[0056] The RNC 142a in the RAN 104 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 110, to facilitate communications between and the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0057] As noted above, the core network 106 may also be connected to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0058] FIG. ID is a system diagram of the RAN 104 and the core network 106 according to another embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 may also be in communication with the core network 106.

[0059] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MTMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0060] Each of the eNode-Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in FIG. ID, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0061] The core network 106 shown in FIG. ID may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0062] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an SI interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0063] The serving gateway 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the SI interface. The serving gateway 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The serving gateway 164 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0064] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP- enabled devices.

[0065] The core network 106 may facilitate communications with other networks. For example, the core network 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the core network 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 106 and the PSTN 108. In addition, the core network 106 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0066] FIG. IE is a system diagram of the RAN 104 and the core network 106 according to another embodiment. The RAN 104 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. As will be further discussed below, the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 104, and the core network 106 may be defined as reference points.

[0067] As shown in FIG. IE, the RAN 104 may include base stations 170a, 170b, 170c, and an ASN gateway 172, though it will be appreciated that the RAN 104 may include any number of base stations and ASN gateways while remaining consistent with an embodiment. The base stations 170a, 170b, 170c may each be associated with a particular cell (not shown) in the RAN 104 and may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the base stations 170a, 170b, 170c may implement MTMO technology. Thus, the base station 170a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. The base stations 170a, 170b, 170c may also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 172 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 106, and the like.

[0068] The air interface 116 between the WTRUs 102a, 102b, 102c and the RAN 104 may be defined as an Rl reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, and 102c may establish a logical interface (not shown) with the core network 106. The logical interface between the WTRUs 102a, 102b, 102c and the core network 106 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and/or mobility management.

[0069] The communication link between each of the base stations 170a, 170b, and 170c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations. The communication link between the base stations 170a, 170b, 170c and the ASN gateway 172 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

[0070] As shown in FIG. IE, the RAN 104 may be connected to the core network 106. The communication link between the RAN 104 and the core network 106 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example. The core network 106 may include a mobile IP home agent (MTP- HA) 174, an authentication, authorization, accounting (AAA) server 176, and a gateway 178. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0071] The MTP-HA 174 may be responsible for IP address management, and may enable the WTRUs 102a, 102b, and 102c to roam between different ASNs and/or different core networks. The MIP-HA 174 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The AAA server 176 may be responsible for user authentication and for supporting user services. The gateway 178 may facilitate interworking with other networks. For example, the gateway 178 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. In addition, the gateway 178 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0072] Although not shown in FIG. IE, it will be appreciated that the RAN 104 may be connected to other ASNs and the core network 106 may be connected to other core networks. The communication link between the RAN 104 the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 104 and the other ASNs. The communication link between the core network 106 and the other core networks may be defined as an R5 reference, which may include protocols for facilitating interworking between home core networks and visited core networks.

[0073] FIG. 2 illustrates an example communications system 200 in which embodiments may be practiced or implemented. The communications system 200 is provided for the purpose of illustration only and is not limiting of disclosed embodiments. As shown in FIG. 2, the communications system 200 includes a base station 214 and WTRUs 202a, 202b. As would be understood by a person of skill in the art, the communications system 200 may include additional elements not shown in FIG. 2.

[0074] The base station 214 may be any of the base stations 114 (FIG. 1A), Node-Bs 140 (FIG. 1C), eNode-Bs 160 (FIG. ID) and base stations 170 (FIG. IE), for example. The base station 214 may include functionality similar to, and/or different from, the base stations 114, Node-Bs 140, eNode-Bs 160 and base stations 170, as well. For example, the base station 214 may include functionality to support features of 5G and to implement the procedures, techniques, etc. included herein.

[0075] The base station 214 may be configured for small cell operation and/or deployment. The base station 214 may be configured to support any of centimeter wave (cmW) and millimeter wave (mmW) operation. For simplicity of exposition, the term "xmW" may be used herein to refer to any of cmW and mmW. The base station 214 may be additionally and/or alternatively configured to support various (e.g., all or some) functionality and/or features for small cell operation and/or deployment as specified in 3GPP Release 12. In this regard, the base station 214 may be capable of operating an xmW air interface in parallel, simultaneously and/or otherwise in connection with an LTE, LTE-A or like-type (collectively "LTE") air interface. The base station 214 may be equipped with at least one of various advanced antenna configurations and beamforming techniques, such as those that may allow the base station 214 to simultaneously transmit LTE downlink channels in a wide beam pattern and xmW channels in one or more narrow beam patterns. The base station 214 may also be configured to utilize an LTE uplink configuration adapted with features and procedures (e.g., those detailed herein) to support WTRUs that lack, or do not use their, xmW uplink transmission capabilities.

[0076] Each of the WTRUs 202a, 202b may be any of the WTRUs 102 (FIGs. 1A-1E), for example. Each of the WTRUs 202a, 202b may include functionality similar to, and/or different from, the WTRUs 102, as well. The WTRUs 202a, 202b may include functionality to support features of 5G and to implement the procedures, techniques, etc. included herein. For simplicity of exposition, when "WTRU 204" is used herein, it may refer to any of the WTRUs 202a, 202b.

[0077] Each of the WTRUs 202a, 202b may be configured to support xmW operation. The WTRUs 202a, 202b may be further configured to support various (e.g., all or some) functionality and/or features for user equipment operation and/or deployment as specified in 3 GPP Release 12. Each of the WTRUs 202a, 202b may be capable of operating LTE and xmW air interfaces in parallel, simultaneously and/or otherwise in connection with each other. Each of the WTRUs 202a, 202b may have two sets of antennas and accompanying RF chains; one configured for operating in a LTE band and the other configured for operating in a xmW frequency band. However, the present disclosure is not limited thereto, and a WTRU may have any number of sets of antennas and accompanying RF chains. Each of the WTRUs 202a, 202b may include one or more baseband processors, and the baseband processors may include separate, or at least partially combined, functionality for baseband processing of the LTE frequency band and the xmW frequency band. The baseband processing functions may share hardware blocks for the xmW and LTE air interfaces, for example.

[0078] Overview

[0079] This disclosure is drawn, inter alia, to methods, apparatuses, systems, devices, and computer program products directed to common transport of backhaul and fronthaul traffic (collectively "crosshaul traffic"). Among new methodologies and/or technologies provided herein is a crosshaul common frame (XCF) adapted to carry, among other information, new control information for enabling optimized forwarding and/or management of any packet-based crosshaul traffic. And pursuant to the XCF being MAC-in-MAC protocol compatible, not only can the forwarding of the XCF be carried out by packet switching elements supporting common XCF-domain forwarding and management controls (and hence, capable of utilizing the new control information), but also by legacy MAC-in-MAC protocol (e.g., Ethernet) switches not under the XCF-domain common forwarding control.

[0080] The new control information carried by the XCF allows for multiplexing of different types of crosshaul traffic and for forwarding and network management optimization. Such information may be carried in a payload and/or header of a MAC-in-MAC protocol frame. If carried in the payload, additional delay may be introduced since the switches need to read part of the frame payload before taking any forwarding decision. Moreover, if 802.1 AE is employed, the payload must be decrypted and re-encrypted at each hop, thus further increasing switching delay. In addition, adding new information in the payload may require introduction of a new XCF layer and a new switch hardware design.

[0081] Alternatively, the additional information may be carried in the MAC-in-MAC header. This may ensure compatibility with legacy switches if, for example, the additional information is carried within already defined fields of a MAC-in-MAC header template. An implication of this is that MAC-in-MAC legacy switches may be able to interpret such fields in accordance with the MAC-in-MAC protocol and that XCF-capable switches may interpret them in a different way and hence take advantage of them for forwarding optimization of the crosshaul traffic. This second alternative (e.g., using the MAC-in-MAC header as baseline template for the XCF) is favored over the first alternative. Compatibility with existing hardware may be maintained thanks to data and control plane separation, so there is no need to modify existing legacy Ethernet hardware to support XCFs (as they will appear as MAC-in-MAC protocol parameters at hardware level). Compatibility with MAC service may be maintained if, for example, the additional (new) control information is carried within those fields that are in common to Ethernet (802.2) sublayers. Under such conditions, MAC service compatibility avoids field translation by placing the same fields to different positions in the sublayer header (e.g., MAC-in-MAC mapped over IEEE 802.11 via IEEE 802.1 lak mechanisms). As described in detail herein below, the XCF may instantiate a MAC-in-MAC template (an example of which shown in FIG. 4) to carry the new control information and/or fields.

[0082] In an embodiment, a method implemented in a network entity may include any of generating, and transmitting crosshaul traffic using, an XCF encoded for MAC-in-MAC protocol compatibility and for supporting the common XCF-domain forwarding and/or management of the crosshaul traffic. In an embodiment, the XCF may include one or more MAC-in-MAC protocol fields/parameters encoded to support any of forwarding and management of the crosshaul traffic.

[0083] In an embodiment, a method implemented in a network entity may include any of generating, and transmitting crosshaul traffic, using a XCF that is MAC-in-MAC protocol compatible and that encodes one or more MAC-in-MAC protocol fields/parameters to support the common XCF-domain forwarding and/or management controls (collectively "common XCF-domain controls").

[0084] In an embodiment, the XCF may have a structure and features based on an instantiation of a template of a MAC-in-MAC protocol frame ("MAC-in-MAC template"). Legacy MAC- in-MAC switches that are non-XCF capable may be supported through the MAC-in-MAC backwards compatibility of the XCF. These legacy switches do not fall under the common XCF-domain controls, and hence, cannot take full advantage of the options set in the XCF to optimize for the crosshaul traffic forwarding. XCF-capable switches may take full advantage of the common XCF-domain controls.

[0085] Among new methodologies and/or technologies provided herein is an enhancement to mitigate the problem of MAC table size on legacy Ethernet switches due to the multiple Ethernet addresses associated with of one packet switching element supporting the XCF- domain controls, such as a crosshaul forwarding entity (XFE) node, (e.g., as a result of limiting the XCF address space) whilst enforcing a subset of XCF features on legacy MAC-in-MAC protocol (Ethernet) switches.

[0086] Among new methodologies and/or technologies provided herein is an optimized forwarding and management of the crosshaul traffic based on the XCF structure by applying segment routing. This may translate into (1) adding to the baseline MAC-in-MAC part a new XCF header part for defining a list of ordered segments; and (2) defining new control information (e.g. last segment, new EtherType) to enable proper functioning of the segment routing.

[0087] Also among new methodologies and/or technologies provided herein is a new structure including a fixed-length ordered list of information on fallback paths for fast reroute (no need to wait for the centralized controller reaction (e.g., to an event such as network element failures)) and reduced traffic loss in the event of network element failures (such as transmission link failure).

[0088] Pursuant to the new methodologies and technologies provided herein the structure and features of XCF may be based on (i) an instantiation of the MAC-in-MAC template to cater for the transport of crosshaul traffic, and on (ii) an application of segment routing.

[0089] FIG. 3 is a block diagram illustrating an example communications environment 300. The communications environment 300 may include a transport network 301. The transport network 301 may include a legacy domain 303 and a XCF domain 304. The XCF domain 304 may include first and second sub-domains 306, 308 interconnected via segment 310. Within each of the first and second sub-domains 306, 308 and segment 310 one or more different transmission or data-link technologies may be employed. The transmission or data-link technologies employed by interfaces between the first and second sub-domains 306, 308 and the segment 310 may be different from one another. Although different transmission or data- link technologies may be employed, the first and second sub-domains 306, 308, the segment 310 and other elements defining the XCF domain 304, if any, may support common transport of crosshaul traffic using XCFs. Although not shown, the XCF domain 304 may include more segments interconnecting the first and second sub-domains 306,308; and/or one or more additional sub-domains; and, for each additional sub-domain, one or more additional segments interconnecting such additional sub-domain with the first sub-domain 306, the second sub- domain 308 and/or other additional sub-domains, if any. Alternatively, the XCF domain 304 may include only a single sub-domain.

[0090] The first sub-domain 306 may include an XFE 312 interconnected, via local segments, to crosshaul adaptation units (XAUs) 316, 318, 319 and 320 and an Ethernet switch 322. The first sub-domain 306 may also include an XFE 314 that is interconnected, via a local segment, to the Ethernet switch 322 and that interfaces with the segment 310. The second sub-domain 308 may include a first XFE 324 that interfaces with the segment 310 and that is interconnected, via a local segment, to an Ethernet switch 334. The second sub-domain 308 may also include a second XFE 326 interconnected, via local segments, to the XFE 324, the Ethernet switch 334, XAUs 330, 332, and a third XFE 328. The XFEs 312, 314, 324, 326 and 328 along with the Ethernet switches 322, 334 may carry out packet switching of XCFs.

[0091] As described in more detail herein, an XCF handled in the XCF domain may be encoded for MAC-in-MAC protocol compatibility and for supporting common forwarding and/or management of crosshaul traffic in the XCF domain. The XFEs 312, 314, 324, 326 and 328, for example, may use the common forwarding control of the XCF domain, and may take full advantage of the options set in the XCF to optimize for the crosshaul traffic forwarding. The Ethernet switches 322, 334 may be legacy MAC-in-MAC (non-XCF capable) switches that do not support the common forwarding control of the XCF domain. Because an XCF handled by the Ethernet switches 322, 334 is encoded for MAC-in-MAC protocol (backwards) compatibility, MAC-in-MAC protocol forwarding control may be used. Legacy MAC-in-MAC switches cannot take full advantage of the options set in the XCF to optimize for the crosshaul traffic forwarding.

[0092] The XAUs 316, 318, 319, 320, 330 and 332 may adapt XCFs for exhange of crosshaul traffic with outside (e.g., non-XCF) interconnected domains. The outside interconnected domains may include (or include domains associated with) access networks 336, 338; the legacy domain 303; core network 340; cloud/data center, e.g., baseband unit (BBU) servers 342; access network 344; firewall 346, etc. As an example, the XAUs 316, 318 may adapt XCFs for exhange of crosshaul traffic with the access networks 336, 338, respectively; the XAUs 320, 330 may adapt XCFs for exhange of crosshaul traffic with the legacy domain 303 and/or access network 344; and the XAU 332 may adapt XCFs for exhange of crosshaul traffic with the core network 340.

[0093] The communications enviroment 300 may include a network controller 350. The network controller 350 may exchange various information with the entities of the XCF domain 304, e.g., the XFEs 312, 314, 324, 326 and 328 and the XAUs 316, 318, 319, 320, 330 and 332. The information may include rules, parameters, etc. for provisioning the entities of the XCF domain 304 for forwarding and queue management.

[0094] Work on a design of common packet switching format for crosshaul traffic for the EU H2020 5G-Crosshaul project recently started. An XCF in accordance with the description and claims herein may be an adoptable solution for the common packet switching format. The XCF is meant to be capable of transporting and multiplexing various (existing and new) fronthaul and backhaul traffic, with guaranteed QoS for the different traffic profiles. The XCF, as noted above, may be encoded for MAC-in-MAC protocol compatibility and for supporting common forwarding and/or management of crosshaul traffic in the XCF domain.

[0095] Provider Backbone Bridges (IEEE 802. lah-2008, known as "MAC-in-MAC") is a set of architecture and protocols for routing over a provider's network allowing interconnection of multiple Provider Bridge Networks without losing each customer's individually defined virtual local area networks (VLANs). Provider Backbone Bridge-Traffic Engineering (IEEE 802.1Qay-2009, known as "PBB-TE") extends MAC-in-MAC behavior by eliminating flooding, dynamically created forwarding tables, spanning tree protocols, and separating the data and control planes. PBB-TE adapts Ethernet technology to carrier backhaul class transport networks and leverages economies of scale inherent in Ethernet.

[0096] IEEE Std. 802.11 was originally designed as an access network with an assumption that connected devices would be leaf nodes of the network. Recently, interest has arisen for using 802.1 1 links not only in the access but also in the transport network. For example, IEEE 802.1 lad operates in the band of 60 gigahertz (GHz) and is able to provide high bandwidth links, which are also suitable for backhaul transport. IEEE 802.1 lak amendment optionally extends the 802.11 standard so that communication links may be established between devices that are usable as a transit links inside a network conformant to IEEE Std 802.1Q. IEEE 802.1Qbz and IEEE 802.1 AC amendments, along with IEEE 802.1 lak, define enhancements to bridging of 802.11 media. As a consequence, MAC-in-MAC frames may be natively carried over IEEE 802.11 links without requiring translation or encapsulation.

[0097] The MAC-in-MAC protocol enables the support of legacy Ethernet (MAC-in-MAC) switches, as well as a transparent (to the user) interconnection between the different domains and across different link technologies (e.g. optical, wireless, etc.). The MAC-in-MAC protocol however was initially designed and used for backhaul carrier grade transport, and hence it is deemed not sufficient to optimize for the forwarding of a new class of traffic, i.e. the fronthaul traffic or a mixture of fronthaul and backhaul, which comes with strict latency and jitter requirements.

[0098] FIG. 4 is a block diagram illustrating an example template of a MAC-in-MAC frame ("MAC-in-MAC template") 400. The MAC-in-MAC template 400 may include a MAC-in- MAC header 402. The MAC-in-MAC header 402 may include multiple fields for specifying various parameters of the MAC-in-MAC protocol. Such fields include, for example, a B-Dest address field 404 for specifying a (48-bit) Ethernet destination address and a B-Src address field 406 for specifying a (48-bit) Ethernet source address. As described in more detail herein, the MAC-in-MAC template 400 may provide a basis for the XCF to carry the XCF-domain controls and provide backwards compatibility with legacy Ethernet switches.

[0099] FIG. 5 is a block diagram illustrating an intermediate form of the example crosshaul common frame (XCF) 500 (hereinafter "XCF 500i"). The XCF 500 may be based on a full or partial instantiation of the MAC-in-MAC template 400 (as shown) or one or more MAC-in- MAC templates other than the MAC-in-MAC template 400. For simplicity of exposition in the description that follows, various elements of the example communications environment illustrated in FIG. 3 (e.g., elements of the transport network 301) may be referred to in connection with the XCF 500 (and its intermediate forms). The XCF 500 and its intermediate forms may be used, deployed, etc. in other communications environments and by elements of the example communications environment illustrated in FIG. 3 not specifically referred to, as well.

[0100] The XCF 500 may include an XCF header 502. The XCF header 502 may be based on an instantiation of the MAC-in-MAC header 402 with control information that is encoded to permit appropriate (proper/correct) forwarding of the XCF 500 using the MAC-in-MAC protocol as well as the common forwarding and/or management controls of the XCF domain ("XCF-domain forwarding controls"). The coding used to encode the control information may be any type of coding that permits the XCF 500 to be interpreted using both the MAC-in-MAC protocol and the XCF-domain forwarding controls. The coding, for example, may encode the control information such that the XCF header 502 (and/or XCF 500) can be interpreted using the MAC-in-MAC protocol and interpreted using the XCF-domain forwarding controls after applying a hash function to some or all of the XCF header 502.

[0101] Alternatively, the coding may encode the control information to dispose XCF-domain control information among one or more portions (e.g., fields, bits, etc.) of the XCF header 502 that do not affect the appropriate forwarding of the XCF using the MAC-in-MAC protocol. As an example, the XCF header 502 may include an XCF header subpart 503. The XCF subpart 503 may be based on an instantiation of the B-Dest address field 404 and the B-Src address field 406 with (i) destination and source addressing information disposed among portions of the XCF subpart 503 to permit appropriate forwarding of the XCF using the MAC-in-MAC protocol, and (ii) with the XCF-domain control information (e.g., control information regarding an active segment) disposed among one or more portions of the XCF subpart 502 that do not affect the appropriate forwarding of the XCF using the MAC-in-MAC protocol. In an embodiment in accordance with such example, the coding of the control information may be akin to re-purposing one or more bits of B-Dest and/or B-Src addresses for the XCF-domain control information. The result of the coding may be that the XCF header subpart 503 has less bits than conventional B-Dest and/or B-Src addresses for destination and/or source addressing. Alternatively, the repurposed bits may have dual meanings. The repurposed bits, for example, may represent both the MAC-in-MAC protocol destination and/or source addressing and the XCF-domain control information.

[0102] In an embodiment, the XCF header subpart 503 may include an XCF segment part 504 and an XCF source part 506. The XCF segment part 504 and the XCF source part 506 may be based on instantiation of the B-Dest address field 404 and the B-Src address field 406, respectively. Legacy MAC-in-MAC switches may interpret the XCF segment part 504 as a legacy (e.g., 48-bit) Ethernet destination address, and may interpret the XCF source part 506 as a legacy (e.g., 48-bit) Ethernet source address. Forwarding decision and control carried out by XCF-capable switches may be based on lookups associated with the XCF segment part 504 and/or the XCF source part 506.

[0103] The XCF segment part 504 may carry the XCF-domain control information associated with an active segment of the XCF domain 304 (FIG. 3), such as, for example, any of the segment 310 and the local segments of sub-domains 306, 308. The XCF segment part 504 may include an XCF destination address part 508 and an XCF destination control part 510. The XCF destination address part 508 may indicate or be indicative of a XCF-domain forwarding address for the XCF 500. The XCF destination address part 508, for example, may be a (e.g., 24-bit) unique identifier of an XCF-capable switch (e.g., any of the XFEs 312, 314, 324, 326 and 328 and XAUs 316, 318, 319, 320, 330 and 332). The XCF destination control part 510 may include the XCF-domain control information for forwarding optimization within the active segment. Such XCF-domain forwarding optimization information may include various parameters, which may be carried in various frame control fields of the XCF destination control part 510. Examples of the frame control fields may include, as shown in FIG. 5, an urgency field 516, an order field 518, a multiple destination field 520, a power management field 522, a pre-emption field 524, a protected frame field 526, a more data field 528 and a reserved field 520.

[0104] The urgency field 516 may carry an urgency indicator. The urgency indicator may be as small as a single bit, and may be set to a particular value to indicate that immediate processing of the XCF 500 is required. The urgency indicator may be set to such value for various reasons and/or conditions, including, for example, when explicit congestion notification (or any other OAM) information is carried in the XCF 500. The urgency field 516 may be considered by any destination XFE or XAU, e.g., any XFE or XAU having an address that matches or is consistent with the XCF destination address part 508. XFEs and/or XAUs other than the destination XFEs or XAUs need not consider the urgency field 516.

[0105] The order field 518 may carry an ordered-delivery-service indicator. The ordered- delivery-service indicator may be as small as a single bit, and may be set to a particular value to indicate that the XCF 500 needs (e.g., requires) an in-order delivery service. In general, the ordered-delivery-service indicator may be set to such value in any XCF requiring an in-order delivery service. The ordered-delivery-service indicator may be set to indicate that in-order delivery service is needed (e.g., required) in connection-oriented operational mode, e.g., 802.2 LLC Type 2.

[0106] The multiple destination field 520 may carry a multiple-destination indicator. The multiple-destination indicator may be as small as a single bit, and may be set to a particular value to indicate that the XCF 500 has multiple destinations (e.g., via Multicast, Anycast, Broadcast). When set to such value, the XCF destination address 508 may specify a distribution tree to be used to forward the XCF 500.

[0107] The power management field 522 may carry a power management indicator. The power management indicator may be as small as a single bit, and may be set to a particular value to indicate support of a power management mode on an XFE and/or XAU transmitting the XCF 500.

[0108] The pre-emption field 524 may carry a pre-emption indicator. The pre-emption indicator may be as small as a single bit, and may be set to a particular value to indicate whether the XCF can be preempted. In general, the pre-emption indicator may be set to such value for non-critical traffic.

[0109] The protected frame field 526 may carry a protected-frame indicator. The protected- frame may be as small as a single bit, and may be set to a particular value to indicate that the payload contains information that has been processed by a cryptographic encapsulation algorithm (e.g., a default cipher suite, such as GCM-AES-128).

[0110] The more data field 528 may carry a more-data indicator. The more-data indicator may be as small as a single bit, and may be set to a particular value to indicate more data belonging to the same I-SID are expected to be sent. In general, the more-data indicator is set to such value in any XCF data frame where more data belonging to the same I-SID are expected to be sent.

[0111] The reserved field 530 may carry bits reserved for future use.

[0112] In the example shown, the frame control fields collectively occupy 24 bits and the XCF destination address part 508 occupies 24 bits of the XCF segment part 504 (based on an instantiation of a B-Dest address field 404 that corresponds to a legacy (e.g., 48-bit) Ethernet destination address). The XCF segment part 504 may apportion more bits to XCF destination address part 508 and less bits to the XCF destination control part 510 and vice-versa. Alternatively, all of the bits of the XCF segment part 504 might not be allocated to the XCF destination address part 508 and the XCF destination control part 510, and the XCF segment part 504 may apportion the bits accordingly.

[0113] The XCF source part 506 may carry the XCF-domain control information associated with the payload ("XCF payload") of XCF 500. The XCF source part 506 may include an XCF source address part 512 and an XCF source control part 514. The XCF source address part 512 may indicate or be indicative of a XCF-domain source address for the XCF 500. The XCF source address part 512, for example, may be a (e.g., 24-bit) unique identifier of an XCF- capable switch (e.g., any of the XFEs 312, 314, 324, 326 and 328 and XAUs 316, 318, 319, 320, 330 and 332) that originated the XCF 500. The XCF source control part 514 may include the XCF-domain control information for forwarding optimization within the XCF domain 304. Such XCF-domain forwarding optimization information may include various parameters, which may be carried in various frame control fields of the XCF source control part 510. Examples of these frame control fields may include, as shown in FIG. 5, a quality of service (QoS) profile/Traffic field 532, an SN/TS field 534 and a sequence number/timestamp field 536.

[0114] The QoS profile/Traffic class field 532 may carry a QoS profile/Traffic class indicator. The QoS profile/Traffic class indicator may be, for example, 8-bits; and may specify a QoS profile (also called a traffic class) associated with the XCF 500. Examples of possible values and their meanings are: 0x1 : fronthaul.cpri, 0x2: fronthaul.ngfi, 0x10: backhaul. best. effort, 0x11 : backhaul. video. livestream, 0x12: backhaul. voip, etc. Different latency, jitter, and bandwidth requirements are typically associated with each QoS profile/traffic class. The extensions cpri and ngfi may refer to common public radio interface (CPRI) and next generation fronthaul interface (NGFI), respectively.

[0115] The SN/TS field 534 may carry a SN/TS indicator. The SN/TS indicator may be as small as a single bit, and may be set to different values to indicate whether to interpret the sequence number/timestamp field 536 as a sequence number or a timestamp.

[0116] The sequence number/timestamp field 536 may be, for example, 15 bits, and carry either a sequence number or a timestamp. If SN/TS field 534 is set to 1, for example, the sequence number/timestamp field 536 may include a sequence number associated with the SDU (Service Data Unit) e.g. IP, Ethernet, NGFI, CPRI, etc. Otherwise, the sequence number/timestamp field 536 may include a timestamp. [0117] In the example shown, the frame control fields of the XCF source control part 514 collectively occupy 24 bits and the XCF source address part 512 occupies 24 bits of the XCF source part 506 (based on an instantiation of a B-Src address field 406 that corresponds to a legacy (e.g., 48-bit) Ethernet source address). The XCF source part 504 may apportion more bits to XCF source address part 512 and less bits to the XCF source control part 514 and vice- versa. Alternatively, all of the bits of the XCF source part 506 might not be allocated to the XCF source address part 512 and the XCF source control part 514, and the XCF source part 504 may apportion the bits accordingly.

[0118] In the example shown in FIG. 5, instantiation of the MAC-in-MAC template 400 results in each of the XCF segment part 504 and the XCF source part 506 (corresponding to the B-Dest address field 404 and the B-Src address field 406, respectively) being split into multiple subfields; some of which may carry the XCF-domain control information. The splits may be based on one or more of the following:

[0119] 1. Ethernet addresses are 48-bits long because the addresses are meant to be globally unique. In the XCF domain, addressing need not be globally unique (e.g., because of relating to a provider domain); allowing for reuse/re-purposing part of the address space to carry the XCF-domain control information.

[0120] 2. Legacy switches may consider the XCF-domain control information as part of B-Dest and B-Src addresses. Indeed, legacy compatibility may be enabled by the use of the MAC-in-MAC template 400 or other standard compliant MAC-in-MAC template to instantiate the XCF.

[0121] 3. Because the XCF-domain control information is used to optimize XCF forwarding, it should be made available as soon as practicable after frame reception starts. Having the XCF-domain control information disposed in the portion of the XCF received first may allow effective cut-through forwarding to be implemented for latency-sensitive frames.

[0122] 4. The destination and source addresses are fields that are always present in Ethernet, 802. ID, and 802.1Q networks. Therefore, there is no need to modify the standard MAC service interface to communicate the XCF-domain control information from one network layer to another. For instance, the mapping of those fields between Ethernet and 802.11 frames is defined by the standard MAC interface.

[0123] 5. Ethernet destination and source addresses are always encoded at the beginning of a frame and are never encrypted. Moreover, 802. lAE encrypts the 802.1Q tags (e.g., C- tag, S-tag) while adopting MacSec/LinkSec operation. [0124] The forwarding on legacy Ethernet switches is based on the look up of Ethernet destination address, which, for the XCF 500, may be represented by the XCF destination address part 508 and the XCF destination control part 510. A different combination of XCF- domain control bits may be interpreted as a different Ethernet destination address on Legacy Ethernet switches. In this way, an appropriate configuration of the XCF-domain control bits may cause the legacy Ethernet switches to steer the crosshaul traffic on a different port even if the legacy switches do not directly support it.

[0125] The XCF 500 may support legacy Ethernet switches as follows. Legacy Ethernet switches may interpret the XCF as a standard MAC-in-MAC frame. The combination of the XCF destination address part 508 and the XCF destination control part 510 may be interpreted as an Ethernet destination address based on the XCF instantiation of the MAC-in-MAC template. The combination of the XCF source address part 512 and XCF source control part 514 may be interpreted as an Ethernet source address based on the XCF instantiation of the MAC-in-MAC template. B-VID, I-SID, S-Tag, and C-Tag may be interpreted according to the 802.1Q standard based on the XCF instantiation of the MAC-in-MAC template.

[0126] Legacy Ethernet switches may forward the crosshaul traffic based on the combination of the XCF destination address part 508 and the XCF destination control part 510 (forming the equivalent of an Ethernet destination address) along with B-VID and I-SID: according to the 802.1Q standard.

[0127] The XCF destination address part 508, which is unique for each XAU/XFE within the XCF domain, may be combined with any possible combination of the XCF destination control part 510 (bits); hence, multiple Ethernet addresses may be associated to each XAU/XFE (e.g., an XFE with the XCF address 0x00: 11 :22 may be associated to the Ethernet addresses 0x00: 1 l :22:uv:wx:yz, where u, v, w, x, y, z are any possible hexadecimal values). By appropriately configuring the control information to create different combinations of Ethernet destination address as seen by legacy switches, some of the XCF-domain controls may be also enforced on the legacy Ethernet switches. This may be facilitated by making the new address fields and control bits compatible with MAC-in-MAC template and legacy Ethernet switches.

[0128] FIG. 6 is a block diagram illustrating an example network entity 600 in which embodiments may be practiced or implemented. For simplicity of exposition in the description that follows, various elements of the example communications environment illustrated in FIG. 3 and/or the XCF 500 may be referred to in connection with the network entity 500.

[0129] The network entity 600 may include, or be configured, as an XFE or an XAU, such as one of the XFEs 312, 314, 324, 326 and 328 or XAUs 316, 318, 319, 320, 330 and 332. The network entity 600 may include one or more ingress ports 601, a common switching layer 603 and one or more egress ports 605. The ingress ports 601 may receive one or more MAC-in- MAC compatible frames. The MAC-in-MAC compatible frames may include XCFs and other MAC-in-MAC compatible ("non-common-crosshaul") frames. The ingress ports 601 may send the MAC-in-MAC compatible frames to the common switching layer 603.

[0130] The common switching layer 603 may include a frame discriminator 611, first and second forwarding decision entities 613, 615, and first and second queue management entities 617, 619. The frame discriminator entity 611 may receive the MAC-in-MAC compatible frames from the ingress ports 601. The frame discriminator entity 611 may discriminate the XCF frames from the non-common-crosshaul frames based on matching fields (e.g., Src/Dst fields) of the received frames and controller-provisioned matching rules. The controller-provisioned matching rules may include wild-card matching rules, for example. The frame discriminator entity 611 may send the non-common-crosshaul frames to the first forwarding decision entity 613 (e.g., for legacy forwarding decision). The frame discriminator entity 611 may send the XCFs to the second forwarding decision entity 615 (e.g., for XCF forwarding decision).

[0131] The first forwarding decision entity 613 may receive the non-common-crosshaul frames from the frame discriminator entity 611. The first forwarding decision entity 613 may process the non-common-crosshaul frames using legacy/corresponding forwarding procedures. The first forwarding decision entity 613 may send the processed non-common-crosshaul frames to the first queue management entity 617 (e.g., for legacy queue management). The first queue management entity 617 may receive the non-common-crosshaul frames from first forwarding decision entity 613. The first queue management entity 617 may processes the non-common- crosshaul frames using legacy/corresponding queue management procedure. The first queue management entity 617 may send the non-common-crosshaul frames to an appropriate egress port of the egress ports 605 in accordance with the forwarding decision made by the first forwarding decision entity 613 and with the queue management carried out by the first queue management entity 617.

[0132] The second forwarding decision entity 615 may receive the XCFs from the frame discriminator entity 611. The second forwarding decision entity 615 may process the XCFs using XCF common forwarding procedures. The second forwarding decision entity 615, for example, may decode XCF information present in an XCF. The second forwarding decision entity 615 may process the XCF information, and may perform forwarding based on the processed XCF information. The second forwarding decision entity 615 may send the XCFs to the second queue management entity 619 (e.g., for XCF queue management). [0133] The second queue management entity 619 may receive the XCFs from second forwarding decision entity 615. The second queue management entity 619 may perform queue management procedures based on XCF management rules. The second queue management entity 619 may send the XCFs to an appropriate egress port of the egress ports 605 in accordance with the forwarding decision made by the second forwarding decision entity 615 and with the queue management carried out by the second queue management entity 619.

[0134] FIG. 7 is a block diagram illustrating an example crosshaul common frame (XCF) 700. The XCF 700 may be based on a full or partial instantiation of the MAC-in-MAC template 400 (or one or more MAC-in-MAC templates other than the MAC-in-MAC template 400) and an application of segment routing. The XCF 700 may facilitate application of segment routing through addition of new fields for carrying segment-routing controls. The XCF 700 may include an XCF header MAC-in-MAC part 705 and a XCF header segment routing part 707. One of both of the XCF header MAC-in-MAC part 705 and the XCF header segment routing part 707 may include the fields for carrying segment-routing controls; examples of which are shown in fields 750-760. Further details of the XCF 700 and the particular fields 750-760 thereof, are described below with respect to Figures 8-9.

[0135] FIG. 8 is a block diagram illustrating an example crosshaul common frame (XCF) 800 configured to support segment routing. The XCF 800 may be an independent form of an XCF. Alternatively, the XCF 800 may be an intermediate form of the XCF 700. The XCF 800 may build on the XCF 500 of FIG. 5 (which may be an intermediate form of the XCF 700, as well). Although the XCF 800 may be based on an instantiation of a MAC-in-MAC template different from the XCF 500, for the sake of simplicity in the description that follows, the XCF 800 includes and builds on the XCF 500.

[0136] The XCF 800 may facilitate application of segment routing through addition of new fields to the XCF header 502 for carrying segment-routing controls, such as the fields 850-860. The segment routing controls may include an ordered list of segments ("ordered-segment list") that the XCF may traverse. The ordered-segment list may include an active segment 804 and one or more inactive segments 809. Only one of the segments may be active at a given time, and the rest of the segments may remain inactive until processing of an active segment is completed. After completion of its processing, the active segment 804 becomes inactive, and may be removed from the ordered-segment list or added to the inactive segments 809. The segment next in the ordered-segment list may be activated (i.e., becoming the new active segment, e.g., XCF-segment 0) and may remain activated until processing of it is completed, whereupon the cycle may be repeated for some or all of the inactive segments. [0137] Building on the XCF 500 (FIG. 5), the XCF header 502 of the XCF 800 may include an XCF header MAC-in-MAC part 805 and a XCF header segment routing part 807. The XCF header MAC-in-MAC part 805 may instantiate the MAC-in-MAC protocol frame similarly to example XCF 500 (FIG. 5). The XCF header segment routing part 807 may be carried within the MAC-in-MAC payload (FIG. 4), and may define segment-routing controls fields. The segment-routing controls fields may carry the inactive segments 809 of the ordered-segment list. Each segment in the ordered-segment list may be identified by a combination of XCF-Dst address and XCF-Dst control fields. XCF-segment 0 (XCF subpart 503) may identify the active segment 804. XCF-segment 1 ... k ... XCF-segment k+l may identify the inactive segments 809 of the ordered-segment list.

[0138] New control information may be included in the XCF header MAC-in-MAC part 805 and/or the XCF header segment routing part 807 to permit full operation of the XCF 800 with segment routing support. The new control information may be expressed using various control fields, including an "other segments" field 850 and a new EtherType field 852.

[0139] The other segments field 850 may be as small as one a single bit, and may be included in the XCF-Dst control bits 510. The other segments field 850 may be set to one value (e.g., to 0) for the last entry in the ordered list (i.e., for the last segment in the list), and to another value (e.g., to 1) for all other segment stack entries signaling that other segments are still present and to be processed.

[0140] The new EtherType field 852 may be disposed in the in the XCF header MAC-in- MAC part 805. The new EtherType field 852 may signal a new value for an EtherType in the XCF header MAC-in-MAC part 805 to identify presence of the XCF header segment routing part 807.

[0141] FIG. 9 is a block diagram illustrating an example crosshaul common frame (XCF) 900 configured to support segment routing. The XCF 900 may be an independent form of an XCF. Alternatively, the XCF 900 may be an example of the XCF 700. Although the XCF 900 may be based on an instantiation of a MAC-in-MAC template different from the XCF 500 and XCF 800, for the sake of simplicity in the description that follows, the XCF 900 includes and builds on the XCFs 500 and 800.

[0142] The XCF 900 may extend XCF 800 to provide a fast reroute mechanism. The fast reroute mechanism may be provided through addition of new fields to the XCF header 502 (e.g., fields 954-960 in the XCF subpart 503). In the event of a network element failure, for instance, the fast reroute mechanism may be employed to re-route traffic as quickly as possible. This behavior may be enabled by insertion into the XCF header 502 a fixed-length ordered list of paths ("ordered-path list"). The ordered-path list may be configured (e.g., beforehand) by a network controller for each segment. The ordered-path list may be used by XFEs to proactively know the fallback path in case of a link failure. Among the additional new fields are a first path ("Path 1 ") field 954, a second path ("Path 2") field 956, a third path ("Path 3") field 958 and a fourth path ("Path 4") field 960. Each of the Path 1 field 954, Path 2 field 956, Path 3 field 958 and Path 4 field 960 are shown as having a length of two bits. However, the length of each of the fields 954-960 may be longer or shorter than two bits.

[0143] The Path 1 field 954 may identify a preferred path for forwarding XCFs directed to the XFE (or XAU) identified by the XCF-Dst address 508. The Path 2 field 956 may identify a first fallback path in case of link failure(s) along the preferred path identified by the Path 1 field 954. The Path 3 field 958 may identify a second fallback path in case of link failure(s) along the first fallback path identified by the Path 2 field 956. The Path 4 field 960 may identify a third fallback path in case of link failure(s) along the second fallback path identified by the Path 3 field 958.

[0144] For each segment, hence XCF destination address, the network controller may define, and/or configure the XFEs with, four, more than four, or less than four different paths for reaching the same XFE. Each path may be identified by a two bit, more than two bit, or less than two bit value. Using the configured paths along with the fields 954-960, the XFEs may start rerouting traffic upon link failure detection (e.g., when there is no carrier on the link) without awaiting the network controller to react to such event. As a consequence, the XFEs may be able to minimize traffic loss and/or retransmissions.

[0145] FIG. 10 is a block diagram illustrating an example network entity 1000 in which embodiments may be practiced or implemented. For simplicity of exposition in the description that follows, various elements of the example communications environment illustrated in FIG. 3 and/or the XCFs 500-900 may be referred to in connection with the network entity 1000.

[0146] The network entity 1000 may include, or be configured, as an XFE or an XAU, such as one of the XFEs 312, 314, 324, 326 and 328 or XAUs 316, 318, 319, 320, 330 and 332. The network entity 1000 may include one or more ingress ports 1001, a common switching layer 1003 and one or more egress ports 1005. The ingress ports 1001 may receive one or more MAC- in-MAC compatible frames. The MAC-in-MAC compatible frames may include XCFs and non-common-crosshaul frames. The ingress ports 1001 may send the MAC-in-MAC compatible frames to the common switching layer 1003.

[0147] The common switching layer 1003 may include a frame discriminator 1011, first and second forwarding decision entities 1013, 1015, first and second queue management entities 1017, 1019 and a segment routing processing entity 1021. The frame discriminator entity 1011 may receive the MAC-in-MAC compatible frames from the ingress ports 1001. The frame discriminator entity 1011 may discriminate the XCF frames from the non-common-crosshaul frames based on matching fields (e.g., Src/Dst fields) of the received frames and controller- provisioned matching rules, such as wild-card matching rules. The frame discriminator entity 1011 may send the non-common-crosshaul frames to the first forwarding decision entity 1013. The frame discriminator entity 1011 may send the XCFs to the second forwarding decision entity 1015.

[0148] The first forwarding decision entity 1013 may receive the non-common-crosshaul frames from the frame discriminator entity 1011. The first forwarding decision entity 1013 may process the non-common-crosshaul frames using legacy/corresponding forwarding procedures. The first forwarding decision entity 1013 may send the processed non-common-crosshaul frames to the first queue management entity 1017. The first queue management entity 1017 may receive the non-common-crosshaul frames from first forwarding decision entity 1013. The first queue management entity 1017 may processes the non-common-crosshaul frames using legacy/corresponding queue management procedure. The first queue management entity 1017 may send the non-common-crosshaul frames to an appropriate egress port of the egress ports 1005 in accordance with the forwarding decision made by the first forwarding decision entity 1013 and with the queue management carried out by the first queue management entity 1017.

[0149] The second forwarding decision entity 1015 may receive the XCFs from the frame discriminator entity 1011. The second forwarding decision entity 1015 may process the XCFs using XCF common forwarding procedures. The second forwarding decision entity 1015 may decode XCF information present in an XCF. The second forwarding decision entity 1015 may process the XCF information, and may perform forwarding based on the processed XCF information. The second forwarding decision entity 1015 may send the XCFs without segment routing information to the second queue management entity 1019. The second forwarding decision entity 1015 may send the XCFs with segment routing information to the segment routing processing entity 1021.

[0150] The segment routing processing entity 1021 may receive and may process the XCFs with segment routing information based on the segment routing information. The segment routing processing entity 1021 may send the segment-routing processed XCFs to the second queue management entity 1019.

[0151] The second queue management entity 1019 may receive the XCFs from any of the second forwarding decision entity 1015 and the segment routing processing entity 1021. The second queue management entity 1019 may perform queue management procedures based on XCF management rules. The second queue management entity 1019 may send the XCFs to an appropriate egress port of the egress ports 1005 in accordance with the forwarding decision made by the second forwarding decision entity 1015 and with the queue management carried out by the second queue management entity 1019.

[0152] Cross-Domain Multi-Traffic Encapsulation And Segment Routing Forwarding Example

[0153] FIG. 11 shows examples of XCF encapsulation and forwarding in an Ethernet- compatible multi data-link environment. The XCF encapsulation and forwarding may be based on segment routing with fast reroute support. For simplicity of exposition, the XCF encapsulation and forwarding examples are overlaid on the example communications environment 300 of FIG. 3. Internal encapsulation and forwarding mechanisms are provided herein below in connection with FIGs. 12-17.

[0154] In the examples shown, XCFs may be forwarded from left to right, and protocol headers added to the XCFs are shown on the right-hand side of the XCFs. In an embodiment, the access network 344 of the communications environment 300 may include a fixed access switch. The (data-link) sub-domain 306 may be an IEEE 802.1 lad wireless mesh-network. The (data-link) sub-domain 308 may be IEEE 802.3aq fiber optic network. The data-link legacy domain 303 may be a synchronous digital hierarchy (SDH) network.

[0155] The following traffic flows may show XCF encapsulation and segment routing forwarding based on the XCF 900. For illustration clarity, B-VID, I-SID, S-Tag, C-Tag, etc. carried in an XCF header are referred to collectively as "XCF fields".

[0156] Example Traffic Flows 1 and 2

[0157] For the following description, the term "[1]" and the term "[2]" refer to traffic of traffic flows 1 and 2 identified in FIG. 11 with like-type boxed numbers, and a number surrounded by parentheses refers to a forwarding stage for the traffic flows identified in FIG. 11 with a like- type encircled number.

[0158] Forwarding Stage (1) Example

[0159] A WTRU 302a may be connected to the access network 336. The access network 336 may be configured with a particular functional split. Traffic of the WTRU 302a (WTRU-1 data) might not be identified until fronthaul data [1] is decoded at the baseband unit (BBU) servers 342 (5). The fronthaul data [1] may be fronthaul data associated to access network 336 (e.g., CPRI traffic), and it might include a fronthaul-specific header depending on the employed interface. A latency and packet delay variation budget may be associated to fronthaul data [1]. To decode CPRI traffic, for example, the signal must be received within a certain delay by the BBU servers 342. Packet Delay Variation (PDV) may be as important as a latency requirement. Indeed, even if the latency requirement is fulfilled, a PDV too great (e.g., large) might affect correctness of the CPRI decoding. By transport network perspective, the fronthaul data [1] may be high priority traffic in terms of latency and PDV.

[0160] Forwarding Stage (2) Example

[0161] The network controller 350 may configure on the XAU 316 framing and encapsulation parameters regarding the fronthaul data [1] generated by access network 336. The XAU 316 may append an XCF header to the fronthaul data [1]. The XCF header may be instantiated with the one or more of the following field values:

[0162] a. - the XCF Src carries the XCF source address in the XCF domain of XAU

316 given that XAU 316 originates the XCF;

[0163] b. - XCF Dst carries the XCF destination address of the XAU 319 because the fronthaul data [1] is destined for decoding at BBU servers 342 and the XAU 319 is the XCF destination address for traffic directed to the BBU servers 342;

[0164] c. - Example XCF-Dst control values may include: Urgent: 0, Order: 1 (CPRI traffic cannot be received out-of-order: reordering at the end points would introduce additional latency that could not be tolerated by the fronthaul interface), Multi destination: 0, Preemption: 0, Protected frame: 0, Other segments: 0, Path 1 : 1, Path 2: 2, Path 3 : 3;

[0165] d. Example XCF-Src control values may include: QoS profile/Traffic class: Fronthaul. CPRI-over-E, SN/TS bit: TS, Timestamp value: current timestamp. Those values may be used by XFEs to enforce locally the latency and PDV subject to the rules configured by the network controller; and

[0166] e. - B-VID and I-SID may be configured at this stage, while S-Tag and C-Tag are configured at XAU only if the encapsulated frame does not contains those tags. This may be the case when the fronthaul data [1] does not contain S-Tag and C-Tag in the fronthaul - specific header.

[0167] SI may be the active segment (e.g., including any of XCF Dst, XCF Dst Ctrl, XCF Src, and XCF Src Ctrl) and there might not be other segments added in the XCF header segment routing part 507. This may be because the fronthaul traffic [1] may be decoded at BBU servers 342 (5) and it might not be possible to further differentiate the traffic until the signal is correctly decoded by the BBU. The XAU 316 may maintain a flow state associated to the traffic flow [1]. In the embodiment in which the sub-domain 306 is an IEEE 802.11 wireless mesh network, the XAU 316 may map the XCF onto an 802.11 frame and may transmit it over a wireless link towards the XAU 319. [0168] Forwarding Stage (3) Example

[0169] The XFE 312 may forward the fronthaul traffic based on the information contained in SI and XCF fields, based on one or more of the following:

[0170] a. the XCF Dst and XCF Dst control-Path 1 (assuming Path 1 is alive): determine the output port; and

[0171] b. the XCF Dst control and XCF Src control fields: determine the fronthaul traffic [1] QoS and internal queue management and switching based, for example, on QoS profile/Traffic class, Timestamp, pre-emption, Order, etc.

[0172] The network controller 350 may continue monitoring the transport network 301, and may know a time needed (e.g., required) to transmit a frame from the XAU 316 to the XAU 319. Rules configured on the XFE 312 may be related to the end-to-end path in order to enforce locally QoS requirements. For example, the fronthaul data [1] frames might not be running out of latency budget when forwarded by the XFE 312, but they may run out of latency budget if the XFE 312 excessively delays the forwarding of those frames. Indeed, QoS requirements refer to the end-to-end path (in this case the end of the path is the XAU 319).

[0173] Forwarding Stage (4) Example

[0174] The network controller 350 may configure on the XAU 319 deframing and de- encapsulation parameters regarding the fronthaul traffic [1] generated by access network 336. The XAU 319 may strip the XCF header because SI terminates at the XAU 319 and since the XCF Dst address is the address of the XAU 319 and the other segments bit is set to 0. Depending on the employed functional split, the XAU 319 may append an additional header to the frame, and forward it to the BBU servers 342 (5).

[0175] Forwarding Stage (5) Example

[0176] The BBU servers 342 may decode the fronthaul data [1] producing WTRU-1 data [2]. The WTRU-1 data [2] may thereafter be sent back to the XAU 319.

[0177] Forwarding Stage (6) Example

[0178] The network controller 350 may configure on the XAU 319 framing and encapsulation parameters regarding the WTRU-1 data [2] generated by BBU servers 342. Assuming that the WTRU-1 data [2] must be analyzed by the firewall 346, the network controller 350 may decide/determine the path(s) for the WTRU-1 data [2] as follows.

[0179] a. S2 (XAU 319 to XFE 314) may be set as the active segment: This segment completely belongs to the sub-domain 306 and XFE 314 is the switch that is traversed to go from the sub-domain 306 to the sub-domain 308. This segment may belong to XCF header MAC-in-MAC part. [0180] b. S3 (XFE 314 to XFE 328) may be set as the first segment coming in the ordered list. This segment completely belongs to sub-domain 308. This segment may belong to XCF header segment routing part.

[0181] a. S4 (XFE 328 to XAU 332 traversing firewall 346) may be set as the last segment. This segment belongs to sub-domain 308 and XAU 332 may be the adaptation function that is traversed to go from the XCF domain 304 to the core network 340. This segment may belong to XCF header segment routing part.

[0182] XAU 319 may append an XCF header to WTRU-1 data [2] with the following field values for S2:

[0183] a. XCF Src: may carry the XCF source address in the XCF domain of the XAU 319 (as source);

[0184] b. XCF Dst: may carry the XCF destination address for the first segments, namely, XFE 314;

[0185] c. Example XCF-Dst control values may include: Urgent: 0, Order: 0, Multi destination: 0, Pre-emption: 1, Protected frame: 0, Other segments: 1 (indicating other segments carried in the XCF header segment routing part), Path 1 : 1, Path 2: 2, Path 3 : 3;

[0186] d. Example XCF-Src control values may include: QoS profile/Traffic class: backhaul. video. stream, SN/TS bit: SN, Sequence Number value: current video frame number. Those values may be used by XFEs to enforce locally the latency and PDV subject to the rules configured by the network controller; and

[0187] e. B-VID, I-SID, S-Tag, and C-Tag may be configured at this stage for WTRU-1 data [2].

[0188] XAU 319 may be the only node in the network that maintains a state associated to the traffic flow [2]. Assuming that sub-domain 306 is an IEEE 802.11 wireless mesh-network, XAU 319 may map the XCF onto an 802.11 frame and may transmit it over the wireless link.

[0189] Forwarding Stage (7) Example

[0190] Similar to the forwarding stage (3) example, XFE 312 may forward the backhaul traffic [2] based on the information contained in S2 and XCF fields, based on one or more of the following:

[0191] a. XCF Dst and XCF Dst control-Path 1 (assuming Path 1 is alive): determine the output port; and

[0192] b. XCF Dst control and XCF Src control fields: determine [2]'s QoS and internal queue management and switching based, for example, on QoS profile/Traffic class, Pre-emption, Order, etc. [0193] Forwarding Stage (8) Example

[0194] The legacy Ethernet switch 322 may forward the WTRU-1 data [2] based on the information contained in the XCF header MAC-in-MAC part that includes the S2 and XCF fields. Legacy Ethernet switches may interpret the XCF format as plain MAC-in-MAC frame as follows:

[0195] a. the XCF Dst address and XCF Dst control may be interpreted as an Ethernet destination address thanks to the XCF instantiation of the MAC-in-MAC template; and

[0196] b. similarly, the XCF Src address and XCF Src control are interpreted as an Ethernet source address.

[0197] B-VID, I-SID, S-Tag, and C-Tag may be interpreted according to the standard.

[0198] The legacy Ethernet forwarding may be based on:

[0199] a. Ethernet destination address: XCF Dst address (i.e., 24-bit), which is unique for each XAU/XFE within the XCF domain, may be combined with any possible combination of XCF Dst control bits (i.e., 24-bit). Therefore, multiple Ethernet addresses may be associated to each XAU/XFE. The legacy Ethernet switch will forward any of those combinations to the same XAU/XFE; and

[0200] b. B-VID and I-SID: according to the 802.1Q standard.

[0201] Forwarding Stage (9) Example

[0202] The XFE 314 may be the destination for S2. The XFE 314 may detect that the frame needs to be forwarded by performing a look up on the following fields:

[0203] a. Urgent: if set to 0, the frame is not meant to be processed locally by the

XAU/XFE. This bit may be set to 0 in S2; and

[0204] b. Other segments: if set to 1, other segments are present in the XCF header segment routing part. This bit may be set to 1 in S2.

[0205] Next, the XFE 314 may replace S2 with S3, which may remove them from the XCF header segment routing part. Thereafter, the XFE 314 may forward the XCF, e.g., following the procedure described in the forwarding stage (7) example using the information contained in S3. Assuming that sub-domain 308 is an IEEE 802.3aq fiber optic network, the XFE 314 might not map the frame and may send the XCF directly on the fiber optic link.

[0206] Forwarding Stage (10) Example

[0207] After having pushed the XCF header (including all the segments) on WTRU-1 data [2] at the XAU 316, the link between XFE 324 and XFE 326 fails. The consequence of which is that Path 1 (initially configured by the controller on S3) is not available (as shown by dotted line marked with an X). The XFE 324 may detect the link failure, and according to the information contained in S3 on the fallback paths, the XFE 324 may decide to forward the XCF on Path 2, which traverses Ethernet switch 334 instead of XFE 326. The XFE 324, consequently, may forward the XCF based on the information contained in S3, which may be as follows:

[0208] a. XCF Dst and XCF Dst control-Path 2 (Path 1 is not available due link failure, Path 2 is alive): determine the output port; and

[0209] b. XCF Dst control and XCF Src control fields: determine WTRU-1 data [2] QoS and internal queue management and switching based, for example, on QoS profile/Traffic class, Timestamp, Pre-emption, Order, etc.

[0210] In case of Path 2 failing as well, the XFE 324 may forward the XCF based on Path 3.

The same procedure may occur when Path 3 also fails and the XFE 324 needs to forward the frame based on Path 4.

[0211] Forwarding Stage (11) Example

[0212] Ethernet switch 334 may forward the XCF in accordance with the procedure described in (8) using the information contained in S3.

[0213] Forwarding Stage (12) Example

[0214] The XFE 328 may terminate S3 and replace it with S4, e.g., as described in the forwarding stage (9) example. The XFE 328 may detect that the frame needs to be forwarded first to the firewall 346 (instead of forwarding it directly to the XAU 332) by performing a look up on the following fields:

[0215] a. XCF Dst alone might not be enough to determine the output port; and

[0216] b. Traffic class, B-VID, and I-D may be jointly used to determine that WTRU-1 data [2] needs to traverse the firewall 346 before reaching the core network 340.

[0217] The XFE 328 may forward the XCF, e.g., following the procedure described in the forwarding stage (7) example using the information contained in S4.

[0218] Forwarding Stage (13) Example

[0219] The firewall 346 does not make any switching decision. It may (e.g., eventually) block or drop traffic according to the network control plane decision. For example, the firewall 346 may block any communication directed to any specific IP address. In this example, WTRU-1 data [2] is not blocked by the firewall 346 and it may be transparently relayed to the XAU 328.

[0220] Forwarding Stage (14) Example

[0221] The network controller 350 may configure on the XAU 328 deframing and de- encapsulation parameters regarding the WTRU-1 data [2]. The XAU 328 may strip the XCF header because S4 terminates at the XAU 328 and since XCF Dst address is the address of the XAU 328 and other segments bit is set to 0. Thereafter, the XAU 328 may forward WTRU-1 data [2] to the core network 340. Depending on the protocol used in the core network 340, the XAU 328 may append an additional header to the WTRU-1 data [2] prior to forwarding it.

[0222] Example Traffic Flow A

[0223] For the following description, the term "[A]" refers to traffic of traffic flow A identified in FIG. 11 with a like-type boxed letter, and an uppercase letter surrounded by parentheses refers to a forwarding stage for the traffic flow A identified in FIG. 11 with like-type boxed letter.

[0224] Forwarding Stage (A) Example

[0225] A WTRU 302b may be connected to access network 338, which may be a radio access network without a functional split. The WTRU 302b may communicate with some server outside the operator' s network, and it may send backhaul traffic [A] directly to the core network 340. For the sake of simplicity legacy switch 348 may be considered as the transport network's point-of-presence in the core network 340. A packet loss ratio budget may be associated to the backhaul traffic [A] and no maximum latency or PDV may be required. For example, the WTRU 302b may be performing a backup of the mobile phone apps on a remote server. By transport network perspective, the backhaul traffic [A] is a low priority traffic in terms of latency and PDV, but high priority in terms of packet loss ratio.

[0226] Forwarding Stage(B) Example

[0227] The network controller 350 may configure on the XAU 318 framing and encapsulation parameters regarding the backhaul data [A] generated by WTRU 302b. The XAU 318 may append an XCF header to the backhaul traffic [A] with the following field values:

[0228] a. XAU 318 is XCF Src: is the XCF source address in the XCF domain;

[0229] b. XAU 320 is XCF Dst: backhaul data [A] will be forwarded via the legacy domain 303 in order to reach the core network 340. Hence, XAU 320 is the XCF destination address for the backhaul traffic [A];

[0230] c. Example XCF-Dst control values may include: Urgent: 0, Order: 0, Multi destination: 0, Pre-emption: 1, Protected frame: 1, Other segments: 0;

[0231] d. Example XCF-Src control values may include : QoS profile/Traffic class: backhaul. ftp-session, SN/TS bit: SN, Sequence number value: current sequence number. Those values may be used by XFEs to enforce locally the latency and PDV subject to the rules configured by the network controller; and [0232] e. B-VID, I-SID, S-Tag, and C-Tag may be configured at this stage for backhaul traffic [A].

[0233] SA is the active segment (e.g., any of XCF Dst, XCF Dst Ctrl, XCF Src, and XCF Src Ctrl) and there are no other segments added in the XCF header segment routing part. Assuming that sub-domain 306 is an IEEE 802.11 wireless mesh-network, the XAU 318 may map the XCF onto an 802.11 frame and may transmit it over the wireless link.

[0234] Forwarding Stage (C) Example

[0235] The XFE 312 may forward the backhaul traffic based on the information in the SA and the XCF fields, which may be as follows:

[0236] a. XCF Dst address and XCF Dst control: determines the output port; and

[0237] b. XCF Dst control and XCF Src control fields: determine the backhaul traffic [A] QoS and internal queue management and switching based, for example, on QoS profile/Traffic class, Timestamp, Pre-emption, Order, etc.

[0238] The network controller 350 may continuously monitor the transport network 310, and may know the time needed (e.g., required) to transmit a frame from the XAU 318 to XAU 320.

The rules configured on XFE 312 may be related to the end-to-end path in order to enforce locally QoS requirements.

[0239] Forwarding Stage (D) Example

[0240] The network controller 350 may configure on the XAU 320 deframing and de- encapsulation parameters regarding the backhaul traffic [A] associated to WTRU 302b. The XAU 320 may strip the XCF header because SA terminates at the XAU 320 and since the XCF Dst address is the address of the XAU 320 and other segments bit is set to 0. The XAU 320 may forward the backhaul traffic [A] to the point of presence, legacy switch 348. The XAU 320 may append an additional header to the backhaul traffic [A] depending on the protocol used in the legacy domain 303.

[0241] Forwarding Stage (E) Example

[0242] The legacy switch 348 is outside the XCF domain 304 and may operate as a legacy point of presence.

[0243] An example of multiple XCF traffic profiles traversing the same XFE is given by the forwarding stages (3), (7), and (C) examples. The fronthaul traffic [1] and backhaul traffic [2], [A] may be multiplexed on the same XFE, which may use the XCF control fields to enforce the QoS requirements. [0244] Legacy Ethernet Switch MAC Table Population Example

[0245] To mitigate the size of the MAC table on legacy Ethernet switches, so there is no need to store all the Ethernet addresses associated to each XFE, the MAC learning algorithm running on the legacy Ethernet switches to properly populate the MAC tables may be exploited. Population of a MAC table may be performed in such a way that the combination of control information carried by the XCF destination control part 510 to manipulate the forwarding decision performed by the legacy Ethernet switches to enforce a subset of the XCF features on the non-XCF capable nodes.

[0246] FIGs. 12 and 13 show an example of legacy Ethernet switch MAC table population triggered by a controller through one or more XFEs. For simplicity of exposition in the description that follows, various elements of the example communications environment illustrated in FIG. 3 may be referred to in connection with FIGs. 12 and 13.

[0247] In general, a legacy Ethernet switch may process a frame and forward it based on Ethernet destination addresses. A legacy Ethernet switch may learn the Ethernet addresses from the frames it receives and then store such information in an internal MAC table. Any time such switch receives a new frame, it stores the source Ethernet address of that frame along with the port from where it received that frame in its table. This means that next time the switch receives a frame with this Ethernet address as a destination, it will know (by looking in its address table) to which port to forward that frame. Since legacy Ethernet switches do not fall under the control of the network controller (meaning that the network controller cannot directly populate the MAC table), the population of the MAC table may be triggered externally by sending to the legacy Ethernet switch multiple Ethernet frames having specific source Ethernet address. These source addresses may correspond to different combination of the control information carried in the XCF source address part 512 and the XCF destination control part 510.

[0248] FIG. 12 shows how the MAC table may be populated on the legacy Ethernet switch 334 by XFEs 324, 326, 328. In the following examples, three possible routes may exist for each pair of nodes including XFEs and legacy Ethernet switch (e.g., legacy Ethernet switch 334 may reach XFE 328 on the following routes: directly to XFE 328; via XFE 326 (XFE 326 - XFE 328); and via XFEs 324, 326 (XFE 324 - XFE 326 - XFE 328). Each of the routes may be identified by a different combination of control bits. For example, the first route for reaching XFE 328 may be identified by the combination of the control information carried in the XCF source address part 512 and the XCF destination control part 510 forming the Ethernet address 328.1. Similarly, the second route may be identified by the Ethernet address 328.2, and the third route may be identified by the Ethernet address 328.3. Similar route identification based on variation of the combination of the control information carried in the XCF source address part 512 and the XCF destination control part 510 may be used for XFE 324, 326.

[0249] The MAC learning process, in general, is always active on a legacy Ethernet switch. This may mean that whenever the legacy switch receives a frame with an Ethernet source address that is not stored in the MAC table, the legacy Ethernet switch will add a new entry in the MAC table. Given that the XCF source address part 512 and XCF source control part 514 represent an Ethernet source address, the network controller might disable some features (e.g., the timestamp) in order to mitigate the MAC table size. For example, different routes can be identified by the QoS Profile/Traffic class field in the XCF source control part 514. Hence traffic directed to the same destination but with different QoS profiles can be forwarded on different ports.

[0250] To manipulate legacy Ethernet switch 334 into populating its MAC table 1301 (FIG.

13), the network controller may instruct each XFE to send to legacy Ethernet switch 334 multiple Ethernet frames with different combinations of the control information carried in the

XCF source address part 512 and XCF source control part 514 (as Ethernet source addresses).

Examples 1201, 1203 and 1205 of the Ethernet source and destination addresses values of such frames sent from the XFEs to Ethernet switch 334 are shown in FIG. 12.

[0251] After having received all the frames reported in FIG. 12, the legacy Ethernet switch

324 may populate the MAC table 1301 (FIG. 13) based on the Ethernet source addresses of such frames along with the port from where it received them. With the MAC table 1301 populated based on the sent frames, the network controller may steer crosshaul traffic on the legacy Ethernet switch 334 by selecting a specific combination of XCF-domain control information that form the Ethernet addresses stored in the MAC table.

[0252] Internal Encapsulation and Forwarding Examples

[0253] Examples of XFE and XAU internal procedures are provided herein below.

[0254] FIG. 14 is a block diagram illustrating an example of a high level XCF forwarding process 1400 carried out at an XFE. The XCF forwarding process 1400 may include any of the following.

[0255] As shown at 1402, the XFE may receive an XCF over link 1 (e.g., 802.11). The data- link frame (e.g. 802.11) may be processed by a reception engine (e.g. to detect collisions), and may be passed to an (ingress) mapping layer (1404).

[0256] As shown at 1406, the (ingress) mapping layer may carry out mapping of link 1 frame fields into a MAC-in-MAC XCF instantiation when needed (e.g., mapping of an 802.11 frame into a MAC-in-MAC template). The resulting XCF may be passed to a common switching layer (1408).

[0257] As shown at 1410, the common switching layer may process the incoming XCF based on some rules and/or parameters configured by the network controller, and may decide where and how to forward the frame (e.g., to meet latency budget, PDV budget, packet loss ratio, fallback paths, etc.). The processing pipeline may include 3 stages, namely, ingress processing (1412), egress processing (1414), and queue management (1416). After the processing, the XCF may be passed to an (egress) mapping layer for transmission over link 2 (1418).

[0258] As shown at 1420, the (egress) mapping layer may carry out mapping of XCF fields into the link 2 frame fields (e.g. Priority) where needed (e.g., mapping the XCF onto an 802.11 frame). The resulting link 2 frame may be passed to a transmission engine for transmission over link 2 (1422). As shown at 1424, the transmission engine may transmit the resulting link 2 frame over link 2.

[0259] FIG. 15 shows an example of internal forwarding procedures 1500 related to an XCF arriving at the XFE port 3 and relayed on port 2. Mapping and forwarding may be carried out using the following processing blocks.

[0260] At process block 1502, various procedures associated with reception of an XCF on port 3 may be carried out. As shown in process block 1504, procedures may be carried out for physical reception of the XCF (e.g. synchronization and frontend processing). MAC operations needed (e.g., required) by the data-link layer technology used on port 3 may be carried out, as well. As shown in process block 1506, the data-link frame may be mapped to the Ethernet- template XCF format. For instance, address 1 and 2 in 802.11 may be mapped into destination and source address in Ethernet. The XCF may be passed to the common switching layer (1508).

[0261] At process block 1510, XCF forwarding procedures may be carried out. As shown in process block 1512, ingress processing may specify matching rules and output port(s). The XFE may match the XCF based on addresses, tags, and control fields/bits, and any combination of them (e.g., a XCF can be matched over XCF Dst. address, XCF Src. address, Flow Hash, TTL, and QoS profile fields). After a rule successfully matches an XCF, the ingress processing may identify an output port for that frame. The matching rules may be configured by the network controller. As shown in process block 1514, egress processing may specify actions to be applied to the XCF before transmission. Such processing may include, for example, decrementing of TTL in case of C-Tag presence, and configuration of the most appropriated transmission queue based on QoS profile, Timestamp, and/or Priority fields. As shown in process block 1516, queue management may enforce the QoS at XCF level with a multiple queues transmission mechanism. The queues may implement a traffic shaper. The traffic shaper may be used to optimize or guarantee performance, improve latency, and/or increase usable bandwidth for some kinds of frames by delaying other kinds (e.g., QoS requirements may be enforced at this stage). After the queue management decides to transmit a frame, it may contact the underlying mapping layer.

[0262] At process block 1518, procedures for facilitating XCF transmission on port 2 may be carried out. As shown in process block 1520, the XCF may be mapped to a specific data-link layer frame format (e.g. IEEE 802.11). As shown in process block 1522, MAC operations needed (e.g., required) by the data-link layer technology used on port 2 may be carried out. Procedures for carrying out physical transmission of the XCF (e.g. synchronization and frontend processing) may also be carried out.

[0263] FIG. 16 is a block diagram illustrating an example high level XCF adaptation/translation process 1600 at a XAU. The adaptation/translation and forwarding process 1600 may include any of the following.

[0264] As shown at 1602, the XAU may receive a legacy frame (i.e. IEEE 1904.3) encapsulated in a data-link frame (i.e. Ethernet) over link 1. The data-link frame may be processed by a reception engine (e.g. to detect collisions) and may be passed to a (ingress) mapping layer (1604).

[0265] As shown at 1606, the (ingress) mapping layer may carry out mapping of link 1 frame fields into a legacy frame (e.g. Fragment ID). The resulting legacy frame may be passed to a legacy operations layer (1608).

[0266] As shown at 1610, the legacy operations layer may implement all operations (e.g., timestamping), related to the legacy protocol. The legacy operations layer may pass the legacy frame to a translation/adaptation layer (1612).

[0267] As shown at 1614, the translation/adaptation layer may frame (e.g., packetization of a CPRI stream) and translate the legacy frame into an XCF. The resulting XCF may be passed to a common switching layer (1616).

[0268] As shown at 1618, the common switching layer may implement the same XFE forwarding functions described earlier. After the processing, the XCF may be passed to a (egress) mapping layer for transmission (1620).

[0269] As shown at 1622, the (egress) mapping layer may carry out mapping XCF fields into link 2 frame fields (e.g. Priority) when needed. The resulting link 2 frame may passed to a transmission layer for transmission over link 2 (1624). As shown at 1626, the transmission engine may transmit the resulting link 2 frame over link 2. [0270] FIG. 17 shows an example of internal forwarding procedures 1700 related to an XCF arriving at the XAU port 3 and relayed on port 2. Mapping and forwarding may be carried out using the following processing blocks.

[0271] At process block 1702, procedures associated with signal reception (i.e. CPRI stream) on port 1 may be carried out. As shown in process block 1704, physical reception and MAC operations (if any), may be carried out (e.g., using the procedures as described in FIG. 15, process block 1.1). As shown in process block 1706, any eventual data-link field may be removed, and the incoming signal may be mapped in the legacy protocol. After process block 1706, the frame may be passed to a translation/adaptation layer. As shown in process block 1708, any non-packetized stream may be framed. The framing procedure may be configured by the network controller (e.g., size of each frame). The traffic may be mapped in the MAC-in- MAC XCF format (i.e. QoS Profile field and Timestamp are set at this stage). When XCF with segment routing support is used, the XCF header segment routing part may be added to the XCF header MAC-in-MAC part. The ordered list of segments may be added, as well. Thereafter, the XCF may be passed to a common switching layer.

[0272] At process block 1710, XCF forwarding procedures may be carried out. As shown in process block 1712, ingress processing may be carried out (e.g., using the, same procedures as described in FIG. 15, process block 1512). As shown in process block 1714, egress processing may be carried out (e.g., using the same procedures as described in FIG. 15, process block 1514). As shown in process block 1716, queue management may be carried out (e.g., using the same procedures as described in FIG. 15, process block 1516).

[0273] At process block 1718, procedures for facilitating XCF transmission on port 4 may be carried out. As shown in process block 1720, mapping and encapsulation procedures may be carried out (e.g., using the same procedures as described in FIG. 15, process block 1520). As shown in process block 1722, MAC operations and physical transmission procedures may be carried out (.e.g., using the same procedures as described in FIG. 15, process block 1522).

[0274] FIG. 18 is a flow diagram illustrating a representative procedure 1800 directed to common transport of crosshaul traffic. The representative procedure 1800 may be implemented in a network entity, such as an XFE, XAU or otherwise disclosed herein and/or illustrated in FIGs. 3 and 11-17.

[0275] Referring to FIG. 18, the network entity may receive a plurality of MAC-in-MAC compatible frames, including an XCF (1802). In an embodiment, the XCF may be encoded for MAC-in-MAC protocol compatibility and for supporting common forwarding and/or management of the crosshaul traffic. In an embodiment, the XCF may include one or more MAC-in-MAC protocol fields/parameters encoded to support any of the forwarding and management of the crosshaul traffic.

[0276] In an embodiment, the XCF may include an XCF header. The XCF header may be based on an instantiation of a MAC-in-MAC header with control information that is encoded to permit appropriate forwarding of the XCF using the MAC-in-MAC protocol XCF-domain forwarding controls. In an embodiment, the coding used to encode the control information may include any type of coding that permits the XCF to be interpreted using both the MAC-in-MAC protocol and the XCF-domain forwarding controls. In an embodiment, the coding may encode the control information such that the XCF header and/or the XCF may be interpreted using the MAC-in-MAC protocol and interpreted using the XCF-domain forwarding controls after applying a function to some or all of the XCF header. In an embodiment, the coding may encode the control information to dispose XCF-domain control information among one or more portions of the XCF header that do not affect the appropriate forwarding of the XCF using the MAC-in-MAC protocol.

[0277] In an embodiment, the XCF header may include an XCF header subpart. The XCF subpart may be based on an instantiation of a B-Dest address field and a B-Src address field with: (i) destination and source addressing information disposed among portions of the XCF subpart to permit appropriate forwarding of the XCF using the MAC-in-MAC protocol, and (ii) the XCF-domain control information disposed among one or more portions of the XCF subpart that do not affect the appropriate forwarding of the XCF using the MAC-in-MAC protocol. In an embodiment, the coding of the control information is akin to re-purposing one or more bits of B-Dest and/or B-Src addresses for the XCF-domain control information. In an embodiment, the result of the coding may be that the XCF header subpart has less bits than conventional B- Dest and/or B-Src addresses for destination and/or source addressing. In an embodiment, the repurposed bits may have dual meanings; the repurposed bits representing both the MAC-in- MAC protocol destination and/or source addressing and the XCF-domain control information.

[0278] In an embodiment, the XCF header may include an XCF header subpart, and the XCF header subpart may include an XCF segment part and an XCF source part. The XCF segment part and the XCF source part may be based on instantiation of a B-Dest address field and a B- Src address field, respectively.

[0279] The network entity may discriminate the XCF from other MAC-in-MAC compatible frames based on matching fields of the received MAC-in-MAC compatible frames and controller-provisioned matching rules (1804). The network entity may obtain XCF information disposed in the XCF (1806). The network entity may obtain the XCF information disposed in the XCF by decoding the XCF and processing the decoded XCF. The network entity may perform forwarding based on the obtained XCF information (1808). The network entity may perform queue management procedures based on XCF management rules (1810).

[0280] The network entity may optionally process the other MAC-in-MAC compatible frames (1812). The network entity may carry out the processing of the other MAC-in-MAC compatible frames, for example, using any of (i) legacy forwarding and queue management procedures and (ii) forwarding and queue management procedures in accordance with a MAC-in-MAC compatible protocol for the other MAC-in-MAC compatible frames. The network entity may transmit any of the XCF and other MAC-in-MAC compatible frames (1814).

[0281] FIG. 19 is a flow diagram illustrating a representative procedure 1900 directed to common transport of crosshaul traffic. The representative procedure 1900 may be implemented in a network entity, such as an XFE, XAU or otherwise disclosed herein and/or illustrated in FIGs. 3 and 11-17. The representative procedure 1900 is similar to the representative procedure 1800 (FIG. 18), and various embodiments common to both procedures are not repeated here for sake of simplicity.

[0282] Referring to FIG. 19, the network entity may receive a plurality of MAC-in-MAC compatible frames, including an XCF (1902). The XCF may be based on instantiation of a template of MAC-in-MAC protocol frame and an application of segment routing.

[0283] The network entity may discriminate the XCF from other MAC-in-MAC compatible frames based on matching fields of the received MAC-in-MAC compatible frames and controller-provisioned matching rules (1904). The network entity may obtain XCF information disposed in the XCF (1906). The network entity may obtain the XCF information disposed in the XCF by decoding the XCF and processing the decoded XCF. The network entity may determine from the XCF information that segment routing is employed (1908). The network entity may perform forwarding based on the obtained XCF information and on segment routing information extracted from the XCF (1910). In an embodiment, the segment routing information may include an ordered list of segments that the XCF may traverse. In an embodiment, the XCF may include an XCF header having first and second parts. The first part may carry the active segment, and the second part may carry the ordered list of segments. In an embodiment, the first part may correspond to XCF destination address and XCF destination control parts of the XCF header. In an embodiment, the second part may correspond to a payload of the XCF header.

[0284] In an embodiment, only one of the segments may be active at a given time. The rest of the segments may remain inactive until processing of the active segment is completed. The network entity may update the matching fields with segment routing information for a next segment (1912) based on whether the active segment is completed. In an embodiment, after completion of its processing, the active segment may become inactive and/or is may be removed from the list. In an embodiment, the segment next in the ordered list becomes the active segment and remains activated until processing of it is completed. The active segment may be removed from the first part of the XCF header responsive to deactivation and replaced with a newly activated segment from the ordered list in the second part of the XCF header. In an embodiment, the segment routing information may include a reroute mechanism for rerouting the XCF. The reroute mechanism may be facilitated by a fixed-length ordered list of paths carried in the XCF header.

[0285] In an embodiment, the forwarding decision and control may be based on lookups associated with an XCF segment part and/or the XCF source part. The XCF segment part may carry the XCF-domain control information associated with an active segment of an XCF domain. In an embodiment, the XCF segment part may include an XCF destination address part and an XCF destination control part. The XCF destination address part may indicate or may be indicative of a XCF-domain forwarding address for the XCF. In an embodiment, the XCF destination address part may include a unique identifier of an XCF-capable switch.

[0286] In an embodiment, the XCF destination control part may include the XCF-domain control information for forwarding optimization within the active segment. The XCF-domain forwarding optimization information may include one or more carried in one or more frame control fields of the XCF destination control part.

[0287] In an embodiment, the XCF source part may carry the XCF-domain control information associated with a payload of the XCF. The XCF source part may include an XCF source address part and an XCF source control part. The XCF source address part may indicate or may be indicative of a XCF-domain source address for the XCF. In an embodiment, the XCF source address part comprises a unique identifier of an XCF-capable switch that originated the XCF. In an embodiment, the XCF source control part may include the XCF-domain control information for forwarding optimization within an XCF domain.

[0288] The network entity may perform queue management procedures based on XCF management rules (1914). The network entity may optionally process the other MAC-in-MAC compatible frames (1916). The network entity may carry out the processing of the other MAC- in-MAC compatible frames, for example, using any of (i) legacy forwarding and queue management procedures and (ii) forwarding and queue management procedures in accordance with a MAC-in-MAC compatible protocol for the other MAC-in-MAC compatible frames. The network entity may transmit any of the XCF and other MAC-in-MAC compatible frames (1918).

[0289] Conclusion

[0290] The example XCFs (e.g., as shown in FIGs. 5, 7-9) and the representative operations and/or procedures carried out using such frames are provided herein for purposes of illustration, and other common crosshaul frames may be used. Details of other common crosshaul frames (referred to as common frame format (CFF) frames) and representative operations and/or procedures for using such frames may be found in and U.S. Provisional Patent Application Serial No. 62/452,741, filed 31-Jan-2017; which is incorporated herein by reference in its entirety.

[0291] Although features and elements are provided above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. The present disclosure is not to be limited in terms of the particular embodiments described in this application, which are intended as illustrations of various aspects. Many modifications and variations may be made without departing from its spirit and scope, as will be apparent to those skilled in the art. No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly provided as such. Functionally equivalent methods and apparatuses within the scope of the disclosure, in addition to those enumerated herein, will be apparent to those skilled in the art from the foregoing descriptions. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is to be limited only by the terms of the appended claims, along with the full scope of equivalents to which such claims are entitled. It is to be understood that this disclosure is not limited to particular methods or systems.

[0292] It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting. As used herein, the term "video" may mean any of a snapshot, single image and/or multiple images displayed over a time basis. As another example, when referred to herein, the terms "user equipment" and its abbreviation "UE" may mean (i) a wireless transmit and/or receive unit (WTRU), such as described supra; (ii) any of a number of embodiments of a WTRU, such as described supra; (iii) a wireless-capable and/or wired-capable (e.g., tetherable) device configured with, inter alia, some or all structures and functionality of a WTRU, such as described supra; (iii) a wireless-capable and/or wired-capable device configured with less than all structures and functionality of a WTRU, such as described supra; or (iv) the like. Details of an example WTRU, which may be representative of any WTRU recited herein, are provided herein with respect to FIGs. 1A-1E.

[0293] In addition, the methods provided herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer- readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

[0294] Variations of the method, apparatus and system provided above are possible without departing from the scope of the invention. In view of the wide variety of embodiments that can be applied, it should be understood that the illustrated embodiments are examples only, and should not be taken as limiting the scope of the following claims. For instance, the embodiments provided herein include handheld devices, which may include or be utilized with any appropriate voltage source, such as a battery and the like, providing any appropriate voltage.

[0295] Moreover, in the embodiments provided above, processing platforms, computing systems, controllers, and other devices containing processors are noted. These devices may contain at least one Central Processing Unit (CPU") and memory. In accordance with the practices of persons skilled in the art of computer programming, reference to acts and symbolic representations of operations or instructions may be performed by the various CPUs and memories. Such acts and operations or instructions may be referred to as being "executed," "computer executed" or "CPU executed."

[0296] One of ordinary skill in the art will appreciate that the acts and symbolically represented operations or instructions include the manipulation of electrical signals by the CPU. An electrical system represents data bits that can cause a resulting transformation or reduction of the electrical signals and the maintenance of data bits at memory locations in a memory system to thereby reconfigure or otherwise alter the CPU's operation, as well as other processing of signals. The memory locations where data bits are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties corresponding to or representative of the data bits. It should be understood that the embodiments are not limited to the above-mentioned platforms or CPUs and that other platforms and CPUs may support the provided methods.

[0297] The data bits may also be maintained on a computer readable medium including magnetic disks, optical disks, and any other volatile (e.g., Random Access Memory (RAM")) or non-volatile (e.g., Read-Only Memory (ROM")) mass storage system readable by the CPU. The computer readable medium may include cooperating or interconnected computer readable medium, which exist exclusively on the processing system or are distributed among multiple interconnected processing systems that may be local or remote to the processing system. It should be understood that the embodiments are not limited to the above-mentioned memories and that other platforms and memories may support the provided methods.

[0298] In an illustrative embodiment, any of the operations, processes, etc. described herein may be implemented as computer-readable instructions stored on a computer-readable medium. The computer-readable instructions may be executed by a processor of a mobile unit, a network element, and/or any other computing device.

[0299] There is little distinction left between hardware and software implementations of aspects of systems. The use of hardware or software is generally (but not always, in that in certain contexts the choice between hardware and software may become significant) a design choice representing cost vs. efficiency tradeoffs. There may be various vehicles by which processes and/or systems and/or other technologies described herein may be effected (e.g., hardware, software, and/or firmware), and the preferred vehicle may vary with the context in which the processes and/or systems and/or other technologies are deployed. For example, if an implementer determines that speed and accuracy are paramount, the implementer may opt for a mainly hardware and/or firmware vehicle. If flexibility is paramount, the implementer may opt for a mainly software implementation. Alternatively, the implementer may opt for some combination of hardware, software, and/or firmware.

[0300] The foregoing detailed description has set forth various embodiments of the devices and/or processes via the use of block diagrams, flowcharts, and/or examples. Insofar as such block diagrams, flowcharts, and/or examples contain one or more functions and/or operations, it will be understood by those within the art that each function and/or operation within such block diagrams, flowcharts, or examples may be implemented, individually and/or collectively, by a wide range of hardware, software, firmware, or virtually any combination thereof. In an embodiment, several portions of the subject matter described herein may be implemented via Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), digital signal processors (DSPs), and/or other integrated formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein, in whole or in part, may be equivalently implemented in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing the circuitry and/or writing the code for the software and or firmware would be well within the skill of one of skill in the art in light of this disclosure. In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described herein may be distributed as a program product in a variety of forms, and that an illustrative embodiment of the subject matter described herein applies regardless of the particular type of signal bearing medium used to actually carry out the distribution. Examples of a signal bearing medium include, but are not limited to, the following: a recordable type medium such as a floppy disk, a hard disk drive, a CD, a DVD, a digital tape, a computer memory, etc., and a transmission type medium such as a digital and/or an analog communication medium (e.g., a fiber optic cable, a waveguide, a wired communications link, a wireless communication link, etc.).

[0301] Those skilled in the art will recognize that it is common within the art to describe devices and/or processes in the fashion set forth herein, and thereafter use engineering practices to integrate such described devices and/or processes into data processing systems. That is, at least a portion of the devices and/or processes described herein may be integrated into a data processing system via a reasonable amount of experimentation. Those having skill in the art will recognize that a typical data processing system may generally include one or more of a system unit housing, a video display device, a memory such as volatile and non-volatile memory, processors such as microprocessors and digital signal processors, computational entities such as operating systems, drivers, graphical user interfaces, and applications programs, one or more interaction devices, such as a touch pad or screen, and/or control systems including feedback loops and control motors (e.g., feedback for sensing position and/or velocity, control motors for moving and/or adjusting components and/or quantities). A typical data processing system may be implemented utilizing any suitable commercially available components, such as those typically found in data computing/communication and/or network computing/communication systems.

[0302] The herein described subject matter sometimes illustrates different components contained within, or connected with, different other components. It is to be understood that such depicted architectures are merely examples, and that in fact many other architectures may be implemented which achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality may be achieved. Hence, any two components herein combined to achieve a particular functionality may be seen as "associated with" each other such that the desired functionality is achieved, irrespective of architectures or intermedial components. Likewise, any two components so associated may also be viewed as being "operably connected", or "operably coupled", to each other to achieve the desired functionality, and any two components capable of being so associated may also be viewed as being "operably couplable" to each other to achieve the desired functionality. Specific examples of operably couplable include but are not limited to physically mateable and/or physically interacting components and/or wirelessly interactable and/or wirelessly interacting components and/or logically interacting and/or logically interactable components.

[0303] With respect to the use of substantially any plural and/or singular terms herein, those having skill in the art can translate from the plural to the singular and/or from the singular to the plural as is appropriate to the context and/or application. The various singular/plural permutations may be expressly set forth herein for sake of clarity.

[0304] It will be understood by those within the art that, in general, terms used herein, and especially in the appended claims (e.g., bodies of the appended claims) are generally intended as "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "includes" should be interpreted as "includes but is not limited to," etc.). It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, where only one item is intended, the term "single" or similar language may be used. As an aid to understanding, the following appended claims and/or the descriptions herein may contain usage of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles "a" or "an" limits any particular claim containing such introduced claim recitation to embodiments containing only one such recitation, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., "a" and/or "an" should be interpreted to mean "at least one" or "one or more"). The same holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number (e.g., the bare recitation of "two recitations," without other modifiers, means at least two recitations, or two or more recitations). Furthermore, in those instances where a convention analogous to "at least one of A, B, and C, etc." is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., "a system having at least one of A, B, and C" would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B, and C together, etc.). In those instances where a convention analogous to "at least one of A, B, or C, etc." is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., "a system having at least one of A, B, or C" would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B, and C together, etc.). It will be further understood by those within the art that virtually any disjunctive word and/or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase "A or B" will be understood to include the possibilities of "A" or "B" or "A and B." Further, the terms "any of followed by a listing of a plurality of items and/or a plurality of categories of items, as used herein, are intended to include "any of," "any combination of," "any multiple of," and/or "any combination of multiples of the items and/or the categories of items, individually or in conjunction with other items and/or other categories of items. Moreover, as used herein, the term "set" is intended to include any number of items, including zero. Additionally, as used herein, the term "number" is intended to include any number, including zero.

[0305] In addition, where features or aspects of the disclosure are described in terms of Markush groups, those skilled in the art will recognize that the disclosure is also thereby described in terms of any individual member or subgroup of members of the Markush group.

[0306] As will be understood by one skilled in the art, for any and all purposes, such as in terms of providing a written description, all ranges disclosed herein also encompass any and all possible subranges and combinations of subranges thereof. Any listed range can be easily recognized as sufficiently describing and enabling the same range being broken down into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range discussed herein may be readily broken down into a lower third, middle third and upper third, etc. As will also be understood by one skilled in the art all language such as "up to," "at least," "greater than," "less than," and the like includes the number recited and refers to ranges which can be subsequently broken down into subranges as discussed above. Finally, as will be understood by one skilled in the art, a range includes each individual member. Thus, for example, a group having 1-3 cells refers to groups having 1, 2, or 3 cells. Similarly, a group having 1-5 cells refers to groups having 1, 2, 3, 4, or 5 cells, and so forth.

[0307] Moreover, the claims should not be read as limited to the provided order or elements unless stated to that effect. In addition, use of the terms "means for" in any claim is intended to invoke 35 U.S.C. §112, ]f 6 or means-plus-function claim format, and any claim without the terms "means for" is not so intended.

Claims

CLAIMS What is claimed is:

1. A method implemented in a network entity, the method comprising:

receiving a plurality of MAC-in-MAC compatible frames, including a crosshaul common frame (XCF);

discriminating the XCF from other MAC-in-MAC compatible frames based on matching fields of the received MAC-in-MAC compatible frames and controller-provisioned matching rules;

for the XCF,

obtaining XCF information disposed in the XCF;

performing forwarding based on the obtained XCF information; and

performing queue management procedures based on XCF management rules.

2. The method of claim 1, further comprising:

processing the other MAC-in-MAC compatible frames using any of (i) legacy forwarding and queue management procedures and (ii) forwarding and queue management procedures in accordance with a MAC-in-MAC compatible protocol for the other MAC- in-MAC compatible frames

3. The method of any of the preceding claims, further comprising:

for the XCF,

determining from the XCF information that segment routing is employed, wherein performing forwarding is further based on segment routing information extracted from the XCF; and

updating the matching fields with segment routing information for a next segment.

4. The method of claim 3, wherein the XCF is based on instantiation of a template of a MAC- in-MAC protocol frame and an application of segment routing.

5. The method of claim 3, wherein the XCF comprises an ordered list of information indicating fallback paths for fast rerouting, the method further comprising:

utilizing the ordered list of information indicating fallback paths for fast rerouting responsive to at least a portion of a current path being detected as unavailable.

6. The method of any of the preceding claims, wherein obtaining XCF information disposed in the XCF comprises:

decoding the XCF; and processing the decoded XCF.

7. The method of any of the preceding claims, further comprising: transmitting any of the XCF and other MAC-in-MAC compatible frames.

8. The method of any of the preceding claims, wherein the XCF is encoded for MAC-in-MAC protocol compatibility and for any of supporting common forwarding and management of the crosshaul traffic.

9. The method of claim 8, wherein the XCF comprises one or more MAC-in-MAC protocol fields/parameters encoded to support any of the common forwarding and management of the crosshaul traffic.

10. The method of any of the preceding claims, wherein the XCF comprises an XCF header.

11. The method of claim 10, wherein the XCF header is based on an instantiation of a MAC- in-MAC header with control information that is encoded to permit appropriate forwarding of the XCF using any of the MAC-in-MAC protocol and XCF-domain forwarding controls.

12. The method of claim 11, wherein coding used to encode the control information comprises any type of coding that permits the XCF to be interpreted using both the MAC-in-MAC protocol and the XCF-domain forwarding controls.

13. The method of claim 12, wherein the coding encodes the control information such that any of the XCF header and the XCF is interpretable using the MAC-in-MAC protocol and the XCF- domain forwarding controls after applying a function to some or all of the XCF header.

14. The method of claim 12, wherein the coding encodes the control information to dispose XCF-domain control information among one or more portions of the XCF header that do not affect the appropriate forwarding of the XCF using the MAC-in-MAC protocol.

15. A network entity comprising circuitry, including a processor and memory storing instructions executable by the processor, configured to:

receive a plurality of MAC-in-MAC compatible frames, including a crosshaul common frame (XCF);

discriminate the XCF from other MAC-in-MAC compatible frames based on matching fields of the received MAC-in-MAC compatible frames and controller-provisioned matching rules;

for the XCF,

obtain XCF information disposed in the XCF; perform forwarding based on the obtained XCF information; and

perform queue management procedures based on XCF management rules.

16. The network entity of claim 15, wherein the circuitry is configured to:

process the other MAC-in-MAC compatible frames using any of (i) legacy forwarding and queue management procedures and (ii) forwarding and queue management procedures in accordance with a MAC-in-MAC compatible protocol for the other MAC-in-MAC compatible frames

17. A network entity comprising circuitry, including a processor and memory storing instructions executable by the processor, configured to:

for the XCF,

obtain XCF information disposed in the XCF;

determining from the XCF information that segment routing is employed;

perform forwarding based on the obtained XCF information and on segment routing information extracted from the XCF; and

perform queue management procedures based on XCF management rules.

18. The network entity of claim 17, wherein the circuitry is configured to:

for the XCF,

update the matching fields with segment routing information for a next segment.

19. The network entity of any of the claims 15-18, wherein the circuitry being configured to obtain XCF information disposed in the XCF comprises the circuitry being configured to: decode the XCF; and

process the decoded XCF.

20. The network entity of any of the claims 15-19, wherein the circuitry is configured to transmit any of the XCF and other MAC-in-MAC compatible frames.

21. The network entity of any of the claims 15-20, wherein the XCF is encoded for MAC-in- MAC protocol compatibility and for supporting any of common forwarding and management of the crosshaul traffic.

22. The network entity of any of the claims 15-21, wherein the XCF comprises an XCF header.

23. The network entity of claim 22, wherein the XCF header is based on an instantiation of a MAC-in-MAC header with control information that is encoded to permit appropriate forwarding of the XCF using any of the MAC-in-MAC protocol and XCF-domain forwarding controls.

24. The network entity of claim 23, wherein coding used to encode the control information comprises any type of coding that permits the XCF to be interpreted using both the MAC-in- MAC protocol and the XCF-domain forwarding controls.

25. The network entity of claim 24, wherein the coding encodes the control information such that any of the XCF header and the XCF is interpretable using the MAC-in-MAC protocol and the XCF-domain forwarding controls after applying a function to some or all of the XCF header.

26. The network entity of claim 24, wherein the coding encodes the control information to dispose XCF-domain control information among one or more portions of the XCF header that do not affect the appropriate forwarding of the XCF using the MAC-in-MAC protocol.