CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority from U.S. Provisional Application No: 62/266,363, filed December 11, 2015, the contents of which is incorporated herein by reference.

FIELD

[0002] The present invention relates to the field of wireless communications and, more particularly, to methods, apparatus, systems, and procedures for common transport of backhaul and fronthaul traffic.

SUMMARY

[0003] Methods, apparatus and systems are disclosed herein for the common transport of backhaul traffic and fronthaul traffic. Methods, apparatus and systems are disclosed herein for a common-haul frame format, denoted as XCF, that is Ethernet compatible for the support of Ethernet legacy switches. Certain representative methods, apparatus and systems may include the encapsulation of the XCF as payload in an Ethernet frame, and the identification of the XCF within the Ethernet header, for XCF-capable nodes (XFEs) to process the XCF frames, and for non-XCF-capable nodes to ignore XCF options (treat the frame just as Ethernet frame).

[0004] Methods, apparatus and systems are disclosed herein for a common-haul frame format for the transport of crosshaul (various backhaul and fronthaul) traffic in a unified (e.g., single) packet switching domain, across multiple data-link transmission technologies. Certain representative methods, apparatus and systems may include options and features defined in the XCF header such as unique identification of the XCF routing information (e.g., addressing information), information on the payload traffic in the XCF frames for QoS-guaranteed forwarding, and/or in-band signaling information (e.g., congestion, buffer, etc.).

[0005] Methods, apparatus and systems are disclosed herein for a common-haul frame format that is adaptable to the outside and interconnected to domains through crosshaul adaptation units. Certain representative methods, apparatus and systems may include encapsulation procedures and/or de-encapsulation procedures of the traffic data coming into the XCF domain from other non-XCF formats and/or going out of the XCF domain to other non-XCF formats.

[0006] In certain representative embodiments, a crosshaul forwarding element (XFE) may be implemented that may receive data-link frame including an encapsulated crosshaul common frame (XCF). The XFE may process the data-link frame to detect collisions and map first link frame fields of the data-link frame onto XCF fields. The XFE may receive rules for processing the XCF. These rules may be transmitted by a network controller. The XFE may process the XCF based on the received rules. Further, the XFE may generate a second data-link frame using the XCF, including mapping the XCF fields onto second data-link frame fields. The XFE may add an XCF header to the XCF. The XFE may transmit the second data-link frame. A crosshaul adaptation unit (XAU) may translate a legacy frame into an XCF.

[0007] Methods, apparatus and systems are disclosed herein for a new transport format (XCF) that may define information enablers for adaptive forwarding of crosshaul traffic. The new transport format may include identification of the traffic class carried in the XCF payload, identification of the XCF payload format, control information for XCF frame-specific forwarding, QoS fields to prioritize different types of traffic, a counter specific to the avoidance of infinite loops within the XCF domain, and/or Ingress and Egress nicknames that are unique within the XCF domain across multi data-link segments (e.g., IEEE 802.1 lad, optical and the like). In certain representative embodiments, XCF encapsulation in Ethernet frames may include the identification of XCF format in Ethernet through Ethertype. XCF encapsulation in Ethernet frames may include forwarding in co-existing Ethernet switches which may follow conventional mechanisms.

[0008] In certain examples, procedures may use the information enablers described herein including: (1) forwarding of incoming traffic from one XFE to another based on unique Egress nickname; (2) preempting of an ongoing transmission based on traffic class and timestamp to meet latency budget; (3) dropping of packets for congestion avoidance based on traffic class and priority whilst fulfilling packet loss ratio; and/or (4) enforcing of Packet Delay Variation (PDV) based on a traffic class, a flow ID, and/or a timestamp. The adaptation of XCF format may be performed through XAUs at the edge of the XCF domain for encapsulation and/or de- encapsulation in/from other non-XCF protocols.

BRIEF DESCRIPTION OF THE DRAWINGS

[0009] 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 in the Figures indicate like elements, and wherein: FIG. 1A is a system diagram of an example communications system in which one or more disclosed embodiments may be implemented;

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. 1A;

FIG. 1C is a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in FIG. 1A;

FIG. 2 is a system diagram of an example communications system in which a mix of fronthaul and backhaul traffic may be implemented;

FIG. 3 is a diagram of an example of an Ethernet header and successive extensions;

FIG. 4 is an illustration of an example of transport network infrastructure including the crosshaul common frame (XCF) domain;

FIG. 5 is a diagram of an example of XCF encapsulation;

FIG. 6 is a diagram of an example of an XCF fixed header;

FIG. 7 is a diagram of an example of an XCF fixed header frame control field;

FIG. 8 is a diagram of an example of an XCF fixed header priority and Quality of Service (QoS) control field;

FIG. 9 is a diagram of XCF extension header exemplary identification tags;

FIG. 10 is a diagram of an example overview of XCF forwarding;

FIGS. 11A, 11B, 11C and 11D are diagrams of an example of crosshaul forwarding elements (XFE) forwarding internal procedures;

FIG. 12 is a diagram of an example overview of crosshaul adaptation units (XAU) adaptation, encapsulation and forwarding;

FIGS. 13 A, 13B, 13C and 13D are diagrams an example of XAU encapsulation and forwarding internal procedures;

FIG. 14 is a diagram of another example of a common switching layer procedure for a crosshaul entity (XE);

FIG. 15 is a flow chart of a further example of a common switching layer procedure for the crosshaul entity (XE);

FIGS. 16-22 are a diagram of examples of encapsulation and forwarding operations;

FIG. 23 is a flowchart illustrating a representative method in an XE;

FIG. 24 is a flowchart illustrating another representative method in the XE; and

FIG. 25 is a flowchart illustrating a further representative method in the XE. DETAILED DESCRIPTION

[0010] A detailed description of illustrative embodiments may now be described with reference to the figures. However, while the present invention may be described in connection with representative embodiments, it is not limited thereto and it is to be understood that other embodiments may be used or modifications and additions may be made to the described embodiments for performing the same function of the present invention without deviating therefrom.

[0011] Although the representative embodiments are generally shown hereafter using wireless network architectures, any number of different network architectures and/or network components may be used including networks with wired components and/or wireless components, for example.

[0012] FIG. 1A is a diagram of an example communications system 100 in which one or more disclosed embodiments may be implemented. 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.

[0013] 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.

[0014] 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 Intemet 110, and/or the other 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.

[0015] 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 may utilize multiple transceivers for each sector of the cell.

[0016] 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).

[0017] 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).

[0018] 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).

[0019] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), 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.

[0020] 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.

[0021] 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, UMTS, CDMA 2000, WiMAX, or WiFi radio technology. [0022] 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/or the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired and/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.

[0023] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., 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.

[0024] FIG. IB is a system diagram illustrating an example WTRU 102. 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 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and/or other peripherals 138, among others. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0025] The processor 118 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.

[0026] 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/or 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.

[0027] 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 MIMO 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.

[0028] 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.

[0029] 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 130 and/or the removable memory 132. The non-removable memory 130 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 (SIM) 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). [0030] 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.

[0031] 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.

[0032] 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.

[0033] 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 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.

[0034] The RAN 104 may include eNode-Bs 140a, 140b, 140c, 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 140a, 140b, 140c 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 140a, 140b, 140c may implement MIMO technology. Thus, the eNode-B 140a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. [0035] Although the eNode-Bs are illustrated, two or more devices may be used. For example, as illustrated in FIG. 2, one or more radio access units (RAUs) 210 (see FIG. 2) (e.g., sometimes referred to as Remote Radio Units (RRU) and/or RU (Radio Units)) and one or more central access units (CAUs) 230 (see FIG. 2) (sometimes referred to as Baseband Units (BBU) and/or Data Units (DUs)) may be used in lieu of or in addition to the e-Node-Bs 140. The RAUs 210 and the CAUs 230 may interface to the core network 106 directly and/or may interface to the core network 106 via a new core network (e.g., a 5G network (not shown).

[0036] Each of the eNode-Bs 140a, 140b, and 140c 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. 1C, the eNode-Bs 140a, 140b, 140c may communicate with one another over an X2 interface.

[0037] The core network 106 shown in FIG. 1C may include a mobility management entity gateway (MME) 142, a serving gateway (SGW) 144, and a packet datanetwork (PDN) gateway 146. 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.

[0038] The MME 142 may be connected to each of the eNode-Bs 140a, 140b, and 140c in the RAN 104 via an S I interface and may serve as a control node. For example, the MME 142 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 142 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.

[0039] The SGW 144 may be connected to each of the eNode-Bs 140a, 140b, and 140c in the RAN 104 via the S I interface. The SGW 144 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The SGW 144 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.

[0040] The SGW 144 may also be connected to the PDN gateway 146, 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. [0041] 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 other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.

[0042] Other network 112 may further be connected to an IEEE 802.11 based wireless local area network (WLAN) 160. The WLAN 160 may include an access router 165. The access router may contain gateway functionality. The access router 165 may be in communication with a plurality of access points (APs) 170a, 170b. The communication between access router 165 and APs 170a, 170b may be via wired Ethemet (IEEE 802.3 standards), or any type of wireless communication protocol. AP 170a is in wireless communication over an air interface with WTRU 102d.

[0043] 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 (MIMO) technologies, which may be massive, foreseen in 5G.

[0044] The backhaul domain is growing in complexity and cost, with increasingly heterogeneous and independently managed technologies, which also poses a challenge to meet stringent End-to-End (E2E) latency 5G requirements.

[0045] In certain representative embodiments, intelligence (e.g., processing and/or network functions/ among others) may be moved flexibly and/or dynamically through the network infrastructure (e.g., from one end to another and/or across a portion or all of the network infrastructure). [0046] In certain representative embodiments, apparatus, methods and procedures may implemented for interoperability with vendor equipment (e.g., small cell vendor equipment) and/or for cooperative radio functions (e.g., massive MIMO, coordinated multipoint (COMP) and the like). Modified technology (e.g., hardware and/or software) may be appropriate for use with such features.

[0047] A variable bit rate (VBR) packetized fronthaul may be used instead of, or along with, a constant bit rate (CBR) common public radio interface (CPRI). The VBR fronthaul may use a set of fronthaul traffic patterns which may depend on a functional split. The packetized fronthaul may not terminate at an edge of a forwarding (and/or switching) network. The packetized fronthaul may penetrate into (e.g., deep into) the transport network. Some segments of the transport network may receive, obtain and/or generate a multiplex of various fronthaul and/or backhaul traffic. The multiplex of the fronthaul traffic and/or the backhaul traffic may be referred to as crosshaul traffic. The fronthaul traffic and/or the backhaul traffic may be integrated under a common software-defined networking (SDN)-based crosshaul control and may be over a common-haul transport frame, such as a crosshaul common frame (XCF).

[0048] FIG. 2 is a diagram of an example communications system 200 with fronthaul and backhaul traffic. The communications system 200 may include one or more radio access units (RAUs) 210, one or more forwarding nodes (FWDs) 220, one or more central access units (CAUs) 230, an MME 142 and/or a SGW 144. The RAUs 210 may also be referred to as a remote access units. In certain examples, the communication system 200 may include two RAUs 210 with one of the RAUs 21 OA having a peer CAU 23 OA (e.g., its peer CAU 23 OA) toward a back of the forwarding network and another one of the RAUs 210B having a peer CAU 230B (e.g., its peer) at the edge (prior to the forwarding network). In some examples, some and/or all of the fronthaul traffic and backhaul traffic may mix together at some and/or all of the FWDs 220A and 220B.

[0049] For example, the RAU 210B may interface with the CAU 230B and may communicate fronthaul traffic (e.g., only fronthaul traffic) with the CAU 230B. The RAU 21 OA may interface with the FWD 220A and may communicate fronthaul traffic (e.g., only fronthaul traffic) with the FWD 220A. The CAU 23 OA may interface with the FWD 220 A and may communicate backhaul traffic (e.g., only backhaul traffic) with the FWD 220 A. The CAU 23 OA may interface with the FWD 220B and may communicate fronthaul and backhaul traffic (e.g., both fronthaul and backhaul traffic, for example multiplexed using a common control structure/procedure) with the FWD 220B. The MME 142 and/or the SGW 144 may interface with the FWD 220B and may communicate backhaul traffic (e.g., only backhaul traffic) with the FWD 220B and/or the CAU 23 OA. The FWD 220A may interface with the FWD 220B and may communicate (e.g., forward to the FWD 220B and/or receive from the FWD 220B forwarded fronthaul and/or backhaul traffic) with the FWD 220B.

[0050] In certain representative embodiments, a converged fronthaul and backhaul under common software defined network/network functions virtualization (SDN/NFV)-based control may be implemented. For example, this control may be capable of supporting new 5G RAN architectures and performance requirements. Such convergence may use a common-haul packet switching transport such that a mixture of various fronthaul and backhaul traffic (e.g., with different quality of service (QoS) requirements) may be carried in a common frame format, for example to enable: (1) a common control (e.g., common control operations/functions) in fronthaul and backhaul domains (e.g., across fronthaul and backhaul domains); (2) reduced complexity of the switching fabric; and/or (3) improved efficiency in the transport (e.g., through statistical multiplexing schemes).

[0051] In certain representative embodiments, methods, apparatus and systems may be implemented for a common-haul packet switching format and operations. For example, the common packet switching format may be capable of transporting and multiplexing various fronthaul and backhaul traffic profiles over the same and/or substantial the same physical mediums, with different QoS needs and/or requirements for the different traffic profiles (e.g., fronthaul and backhaul traffic profiles). The fronthaul traffic profile may vary with different parameters, such as (1) a level of the access protocol functional split between the remote unit (e.g., the RAU) 210 and the central unit (e.g., the CAU) 230, and/or (2) the access interface bandwidth used or needed and/or (e.g., together with) its tolerance to latency and/or jitter. The level of aggregation may impact the fronthaul and backhaul traffic profiles and their QoS needs and/or requirements. New traffic profiles may be used (e.g., as a result of new functional splits, between physical (PHY)/media access control (MAC) layers) and/or legacy traffic (e.g., CPRI fronthaul traffic).

[0052] FIG. 3 is a diagram of an example of Ethemet header/frames 300 associated with different extensions. Successive extensions of the Ethernet header/frames may include: (1) a 802.1 (1995) Ethemet header/frame 310; (2) a 802.1Q Ethernet header/frame 320; (3) a 802. IAD QINQ Ethernet header/frame 330; (4) a 802.1 AH MACINMAC Ethernet header/frame 340; (5) TRILL (2010) Ethemet header/frame 350; and/or VXLAN (2011) Ethernet header/frame 360, among others. [0053] For example, a first one of Ethernet header/frame extensions 310 (e.g., used for 802.1 (1995)) may include: (1) a destination address; (2) a source address; (3) an Ethertype; and/or (4) a payload. A second one of Ethernet header/frame extensions 320 (e.g., used for 802.1Q) may include (1) the destination address; (2) the source address; (3) a customer tag (C-TAG); (4) the Ethertype; and/or (5) the payload. A third one of the Ethernet header/frame extensions 330 (e.g., used for 802. IAD QINQ) may include (1) the destination address; (2) the source address; (3) a service tag (S-TAG); (4) the C-TAG; (5) the Ethertype; and/or (6) the payload. A fourth one of the Ethernet header/frame extensions 340 (e.g., used for 802.1 AH MACINMAC) may include (1) a backbone destination address (B-DA); (2) a backbone source address (B-SA); (3) a backbone VLAN tag (B-TAG); (4) a service identifier (I-SID); (5) a customer destination address (C-DA); (6) a customer source address (C-SA); the C-TAG; (7) the Ethertype; and/or (8) the payload. A fifth one of the Ethernet header/frame extensions 350 (e.g., used for TRILL (2010)) may include (1) the B-DA; (2) the B-SA; (3) the B-TAG; (4) certain flags; (5) the C-DA; (6) the C-SA; (7) the C-TAG; (8) the Ethertype; and/or (9) the payload. A sixth one of the ethernet header/frame extensions 360 (e.g., used for VXLAN (2011)) may include (1) the B-DA; (2) the B-SA; (3) the C-TAG; (4) an Ethertype (e.g., the Ethertype of the inner ethernet frame); (5) an outer IP source address; (5) UDP (VXLAN); (6) certain flags; (7) the C-DA; (6) the C-SA; (7) the C-TAG; (8) the Ethertype (e.g., the Ethertype of the outer ethernet frame) and/or (9) the payload.

[0054] In certain representative embodiments, methods, apparatus and systems are disclosed herein, for example, for a solution that can keep costs low and leverage and extend widely used Ethernet technology.

[0055] In certain representative embodiments, methods, apparatus and systems are disclosed herein, for example, for a solution that is Ethernet-compatible and that meets common-haul transport QoS requirements.

[0056] In certain representative embodiments, methods, apparatus and systems are disclosed herein, for example, for the design of a common packet switching format (e.g., an XCF) that may be capable of transporting and multiplexing various crosshaul traffic profiles over a same physical media. For example, the common packet switching format may be capable of leveraging Ethernet technology to keep costs low and/or provisioning actual context awareness for adaptive forwarding. None of the unmodified Ethernet protocols are able to provide actual context awareness information. Context awareness information may include, but is not necessarily limited to, the following: the end-to-end status of the network (control), the local status at the switching element (data), and the actual traffic forwarding state (data).

[0057] In certain representative embodiments, methods, apparatus and systems are disclosed herein, for example, to define a structure and/or features of the common frame format for the transport of backhaul and/or fronthaul traffic across the packet switching network infrastructure. The common frame format may be denoted as an XCF. The packet switching elements supporting an XCF format may be referred to as crosshaul forwarding elements (XFEs). Crosshaul Adaptation Units (XAUs) may be included in the Crosshaul switching network infrastructure to adapt the XCF format to outside (non-XCF) interconnected domains.

[0058] In certain representative embodiments, methods, apparatus and systems are disclosed herein, for example, for a common-haul frame format that may be Ethernet compatible and/or may support Ethernet legacy switches. For example, this may include encapsulation of the XCF as payload in an Ethernet frame, and the identification of the XCF within the Ethernet header, for XCF-capable nodes (XFEs) to process the XCF frames, and for non-XCF-capable nodes to ignore XCF options (e.g., treat the frame as Ethernet frame or just as Ethernet frame).

[0059] In certain representative embodiments, methods, apparatus and systems are disclosed herein, for example, for a common-haul frame format for the transport of crosshaul (various backhaul and/or fronthaul) traffic in a unified (single) packet switching domain, across multiple data-link transmission technologies. For example, this may include options and/or features defined in the XCF header such as a unique identification of the XCF routing information (e.g., addressing information), on the payload traffic in the XCF frames for QoS-guaranteed forwarding, and/or in-band signaling information (e.g., congestion information, and/or buffer information, among others).

[0060] In certain representative embodiments, methods, apparatus and systems are disclosed herein, for example, for a common-haul frame format that may be adaptable to the outside and interconnected to domains through XAUs. For example, this may include encapsulation procedures and/or de-encapsulation procedures of the traffic data coming in to the XFC domain from other non-XFC formats and/or coming out of the XCF domain to other non-XCF formats.

[0061] In certain representative embodiments, methods, apparatus and systems are disclosed herein, for example, for a new transport format XCF that may define information enablers for adaptive forwarding of crosshaul traffic. The new transport format may include, but is not necessarily limited to, one or more of the following: (1) identification of the traffic class carried in the XCF payload, (2) identification of the XCF payload format, (3) control information for XCF frame-specific forwarding, (4) QoS fields, for example, to prioritize different types of traffic, (5) a counter specific to the avoidance of infinite loops within the XCF domain, and/or (6) Ingress and Egress nicknames that may be unique within the XCF domain across multi data-link segments (e.g., 802.1 lad segments, and/or optical segments, among others). In certain examples, XCF encapsulation in Ethernet frames may include the identification of the XCF format in Ethernet through the Ethertype. The XCF encapsulation in the Ethernet frames may include forwarding in co-existing Ethernet switches, for example, which may follow conventional mechanisms.

[0062] In certain examples, the following procedures may use one or more of the information enablers described herein, for example: (1) forwarding of incoming traffic from one device (e.g., an XFE or other device) to another device (e.g., an XFE or other device) based on a unique Egress nickname; (2) preempting of an ongoing transmission based on a traffic class and/or a timestamp, for example, to meet a latency budget; (3) dropping of packets, for example, for congestion avoidance based on traffic class and/or priority whilst fulfilling a packet loss ratio (e.g., on condition that the packet loss ratio is above a threshold level); and/or (4) enforcing of a Packet Delay Variation (PDV) based on the traffic class, the flow ID, and/or the timestamp. In certain examples, the adaptation of the XCF format may be performed through the XAUs at the edge of the XCF domain for encapsulation into other non-XCF protocols and/or de-encapsulation from other non-XCF protocols.

[0063] FIG. 4 is a diagram illustrating an example of a transport network infrastructure including an XCF domain.

[0064] As shown in FIG. 4, a representative network 400 may include a transport network 402, one or more core networks 455 and/or one or more access networks 470, among others. The transport network 402 may include infrastructure such as an XCF domain 405 having different segments (e.g., segment 410 and 420) and/or a non-XCF domain 415, among others. The core networks 455 and/or the access networks 470 may connect to and/or communicate with the one or more of the XCF domain 405 and/or the non-XCF domain 415 of the transport network 402.

[0065] For example, a first segment 410 of the XCF domain 405 may include one or more Ethernet switches 430 (e.g., which may or may not be legacy switches 460), one or more XFEs 440 and/or one or more XAUs 450, among others. The Ethernet switches 430 and/or the XFEs 440 may be located inside the first segment 410 and may forward data within the first segment 410 and/or to other XFEs 440 of other segments 420 of the XCF domain 405. A second segment 420 of the XCF domain 405 may include one or more Ethernet switches 430 (e.g., and/or legacy switches 460), one or more XFEs 440 and/or one or more XAUs 450, among others. The Ethernet switches 430 and/or the XFEs 440 may be located inside the second segment 420 and may forward data within the second segment 420 and to other XFEs 440 of other segments 410 of the XCF domain 405.

[0066] The XAUs 450 (e.g., that may be located at an edge and/or a boundary of the first segment 410) may interconnect with: (1) the access networks 470 and/or (2) another segment (e.g., a non-XCF domain segment 415) of the transport network 402. For example, an XAU 450 inside (e.g., at the boundary of) the XCF domain 405 may interface with a legacy switch 460 outside of the XFC domain 405. The XAUs 450 (e.g., that may be located at the edge and/or a boundary of the second segment 420) may interconnect with: (1) one or more servers 480; (2) one or more core networks 455; and/or (3) the other segment (e.g., the non-XCF domain segment 415) of the transport network 402. For example, an XAU 450 inside (e.g., at the boundary of) the XCF domain 405 may interface with a legacy switch 460 outside of the XFC domain 405.

[0067] Examples of interconnections to outside domains (e.g., non-XCF domains), for example, in the access network, in the core network, and/or in the cloud/data centers) are shown. The XCF domain 405 may include any number of segments or sub-domains 410 and 420 with a data-link technology (e.g., each with one or more particular transmission or data- link technology (e.g., 802. Had for millimeter wave (mmW) technology). The traffic forwarding within the sub-domains 410 and 420 and across the sub-domains 410 and 420 may be unified under a single XCF domain 405. The XFEs 440 (e.g., some or all of the XFEs 440), independently of which technology domain the XFEs belong to or support, may fall under the unified XCF domain 405 (e.g., be included in the unified XCF domain 405). The unified XCF domain 405 may be translated into specific characteristics for the XCF structure and features, which are detailed herein.

[0068] Legacy Ethernet switches 460 which are non-XCF capable may be supported through a modified design constraint of an Ethernet compatible XCF format. The legacy switches 460 may not fall under the common forwarding control of the XCF domain and/or may not take advantage of the options set in the XCF to meet the QoS requirements for traffic forwarding. At the in-out gateways (e.g., ingress points and/or egress points) of the XCF domain 405, the XAUs 450 may be placed to perform adaptation and/or translation of the XCF format from a non-XCF domain and/or to the non-XCF domain. [0069] FIG. 5 is a diagram of an example of XCF encapsulation.

[0070] Referring to FIG. 5, the XCF adaptation procedure 500 may use a Backhaul/Fronthaul (B/F) module 510, a XCF module 520 and/or a data link protocol module 530. The B/F module 510 may output a packetized B/F media access protocol data unit (B/F MPDU) 512 to the XCF module 520. In certain representative embodiments, the B/F module 510 may output a B/F non-packetized stream 514 to the XCF module 520. For the B/F non-packetized stream 514, the XCF module may frame and/or translate the B/F non-packetized stream 514 to generate a B/F media access service data unit (B/F MSDU) 524. The XCF module 520 may generate a XCF Header 526 and may combine the XCF Header 526 and the B/F MSDU to generate the XCF MPDU 528. The XCF 520 may output the XCF MPDU 528 to the Data link protocol module 530. The Data link protocol module 530 may generate: (1) an XCF MSDU 532 from the XFC MPDU 528 and a data link Header 534. The Data link protocol module 530 may combine the XCF MSDU 532 and a data link Header 534 to generate the data link MPDU 536.

[0071] For example, a packetized B/F protocol (e.g., any packetized B/F protocol (e.g., the B/F MPDU 512) may be encapsulated into (e.g., directly into) an XCF frame. In certain representative embodiments, the B/F protocol may not be packetized and the incoming stream 514 may be translated by a XCF framing/translation layer 522 into a series of concatenated protocol data units (PDUs) before being encapsulated into XCF frames. In both cases, an XCF header 526 may be added to the B/F MSDU. The XCF header 526 may contain or include the information related to the carried traffic (for example, a type of traffic, a QoS, a source and/or a destination), and/or a label identifying the flow, among others. The information included in the XCF header 526, for example, may be used for forwarding at the XFEs 440, as disclosed herein. The XCF frame may be encapsulated in a data-link frame for transmission over the physical medium (e.g., the Ethernet, and/or IEEE 802.11, among others). For example, the XCF frame may be a data-link layer MSDU 536.

[0072] The XCF implementation/design may include an Ethernet container, for example, for the support of legacy Ethernet switching, As such, it may not be appropriate (e.g., there may be no need) to dive (e.g., decode during transport) into the XCF payload encapsulated with the Ethernet Header. In certain representative embodiments, the XCF implementation/design may include an identification of the XCF payload in an Ethernet container, for example to allow XFEs 440 (or XCF-capable nodes) to process the XCF frames. In certain representative embodiments, the XCF implementation/design may include unique identifiers in the XCF header 526 for source and destination addresses in the unified XCF domain 405. The identifiers may be unique across multiple technology-domains. In certain representative embodiments, the XCF implementation/design may include: (1) information on the traffic transported inside the XCF payload; (2) information on a QoS and/or a priority associated to the XCF payload, and/or (3) information in the XCF header 526, for example to avoid infinite loops in the network 400. In certain representative embodiments, the XCF implementation/design may include in-band signaling information in the XCF header 526 to be processed locally at the XFEs 440. This information may be related to operations that cannot be timely handled by the control plane (e.g., buffer notifications, port power management notifications, and/or explicit congestion notifications, among others). In certain representative embodiments, the XCF implementation/design may include extension headers. For example, the extension headers may include extended label space for packet tagging, authentication header, and/or encapsulation security header, among others.

[0073] FIG. 6 is a diagram of an example of an XCF fixed header 600.

[0074] Referring to FIG. 6, an example of an XCF header format 610 may include certain defined field including, but are not necessarily limited to any of the following:

(1) a version field that may specify the XCF frame format version;

(2) a type field that may specify the type of XCF frame (for example, the type field may specify: 0x1 : Control; 0x2: Management; 0x3: Data and the like);

(3) a subtype field that may specify the subtype of the XCF frame (e.g., the meaning of the subtype may depend on the type value. For example, in case of the Data Type: 0x1 : fronthaul.cpri; 0x2: fronthaul.ngfi; 0x10: backhaul. best.effort; 0x11 : backhaul. video. livestream; 0x12: backhaul. voip and the like;

(4) a frame control field that may specify control information related to the XCF frame (FIG. 7 provides an example of a detailed description of the frame control field);

(5) a retransmission control field that may specify the retransmission policy that may be enforced by the data-link layer;

(6) a priority field that may specify a priority of the XCF frame (for example, higher values may mean a higher priority);

(7) a QoS control field that may specify control information related to the QoS of the XCF frame (FIG. 8 provides an example of a detailed description of the QoS control field);

(8) a hop count field that may specify a limit on the number of hops a XCF frame is allowed before being discarded (for example, the Hop Count value may be decremented by 1 whenever the XCF frame traverses an XFE 440); (9) a payload length field that may specify a length, for example in octets, of the payload (for example, if a Jumbo Payload bit (see, e.g., the frame control field) is 1, the payload length field may specify the length of the payload (e.g., as multiple of 1024 octets);

(10) a fragment ID field that may specify the fragment ID when the XCF performs fragmentation on an SDU (e.g., an IP SDU, an Ethernet SDU, a NGFI SDU, and/or a CPRI SDU), among others;

(11) a sequence number field that may specify a sequence number associated with the IP SDU, the Ethernet SDU, the NGFI SDU and/or the CPRI SDU;

(12) an egress XFE nickname field that may specify a nickname of the XFE 440 which the XCF may be forwarded to, for example, if the Multi Destination (see, e.g., the frame control field) bit is 1, and the egress XFE nickname field may specify the distribution tree to be used to forward the frame;

(13) an ingress XFE nickname field that may specify a nickname of the XFE 440 originating the XCF frame;

(14) a flow ID field that may specify a flow ID that the XCF frame belongs to (e.g., the Flow IDs may be uniquely related to the Ingress/Egress XFE Nickname pair;

(15) a next header field that may specify a type of the next header (for example, the next header field may specify (e.g., usually specify) the payload's protocol and/or when extension headers are present in the packet, the next header field may indicate which extension header follows (for example, the next header field may indicate 0x1 : Identification Extension header (see e.g., FIG. 9), OxAO: CPRI-over-Ethernet, OxBO: Ethernet, OxBl: IPv4, and/or 0xB2: IPv6));

(16) a timestamp field that may provide a timestamp (e.g., a multi-bit and/or 32-bit timestamp), for example in nanoseconds modulo; and/or

(17) a frame check sequence field that may provide a field (e.g., a multi-bit and/or 32- bit field) containing or including a cyclic redundancy check (CRC) (e.g., a multi-bit and/or 32- bit CRC, among others.

[0075] FIG. 7 is a diagram of an example of an XCF fixed header frame control field 700. Referring to FIG. 7, a frame control field format 710 may include, but is not necessarily limited to, any of the following:

(1) an urgent bit that may indicate if the frame is to be processed and/or must be processed immediately by the destination XFE 440 (for example, the urgent bit may be relevant if (e.g., only if) the receiving XFE nickname matches the egress XFE nickname (for example, this bit may be set (e.g., usually set) to 1 when explicit congestion notification information is carried in the XCF frame;

(2) a power management bit that may specify a Power Management mode of an XFE

440;

(3) a protected frame bit that may specify if the payload contains or includes information that has been processed by a cryptographic encapsulation algorithm;

(4) a retry field the may be set to a logic level (e.g., the logic level of 1) in a XCF data or management type frame (e.g., any XCF data or management type frame) that is a retransmission of an earlier XCF frame;

(5) a jumbo payload bit the may be set to a logic level (e.g., the logic level of 1) in a XCF data frame (e.g., any XCF data frame) carrying a payload larger than a threshold (e.g., 65,535 octets);

(6) an order bit that may be set to a logic level (e.g., the logic level of 1) in the XCF data frame (e.g., any XCF data frame) using and/or requiring an in-order delivery service;

(7) a don't fragment bit that may be set to a logic level (e.g., the logic level of 1) in the XCF data frame (e.g., any XCF data frame) that is not to be or that should not be fragmented;

(8) a more fragment bit that may be set to a logic level (e.g., the logic level of 1) in the XCF data frame (e.g., any XCF data frame) carrying a fragmented IP SDU, a fragmented Ethernet SDU, a fragmented NGFI SDU, and/or a fragmented CPRI SDU, among others, for example when more fragments are expected;

(9) a more data bit that may be set to a logic level (e.g., the logic level of 1) in the XCF data frame (e.g., any XCF data frame) where more data belonging to the same Flow ID are expected to be sent; and/or

(10) an aggregated MSDU (A-MSDU) bit that may be set to a logic level (e.g., the logic level of 1) in the XCF data frame (e.g., any XCF data frame) carrying the A-MSDU as a payload, among others.

[0076] FIG. 8 is a diagram of an example of an XCF fixed header priority and QoS control field.

[0077] Referring to FIG. 8, the XCF fixed header priority and QoS control field 800 may have a QoS control field format 810 that may include certain fields including, but is not necessarily limited to, any of the following: (1) a priority; (2) a pre-emptible bit that may specify if the XCF frame can be preempted, for example the pre-emptible bit may be set (e.g., usually set) to a logical level (e.g., the logic level of 1) for non-critical traffic; (3) a Queue Size multiple bit that refers to a multiple of octets (e.g., of 1024 octets); and/or (4) a queue size bit, for example as a multiple of 1024 octets, may be set to a logical level (e.g., the logic level of 1) if or on condition that a Queue Size value refers to a multiple of octets (e.g., of 1024 octets) (for example, the queue size bit may indicate an amount of buffered traffic to be sent to the receiving XFE 440 by the previous hop XFE 440, among others.

[0078] FIG. 9 is a diagram of XCF extension header exemplary identification tags.

[0079] Referring to FIG. 9, the XCF extension header exemplary identification tags 900 shows an exemplary extension header 910. Additional fields may be added for tagging purposes. The extension header 910 may include any of the following: (1) the next header field that may have the meaning of Next Header field depicted in FIG. 6; (2) a tenant tag that may specify the tenant of the XCF frame in a multi-tenant scenario; (3) a service tag that may specify the service of the XCF frame (for example, 0x1 : bulk data transfer); (4) an instance tag that may specify the service instance of the XCF frame (for example, multiple instances of the same service may be active at the same time); and/or (5) a customer tag that may specify the customer who generated the pay load carried in the XCF frame, among others.

[0080] In certain examples, XCF header fields may be used to match the incoming XCF frames at the XFEs 440. The matching rules may be configured (e.g., remotely configured), for example by the network controller and/or any combination of the header fields may be allowed to match a frame. The network controller may have a global view of the network, e.g., the end- to-end latency of a given path, and/or the packet error rate of a given link, among others. Some examples of the combined matching and forwarding behavior include any of: (1) incoming traffic that may be forwarded from one XFE 440 to another XFE 440 based on a unique Egress nickname; (2) an ongoing transmission may be preempted based on a traffic class and/or a timestamp to meet a latency budget; (3) packets may be dropped (e.g., for congestion avoidance) based on the traffic class and/or a priority, for example whilst fulfilling a packet loss ratio (e.g., while a packet loss ratio exceeds a threshold); and/or (4) aPDV may be enforced based on a traffic class, a flow ID, and/or a timestamp, among others.

Representative Internal Encapsulation and Forwarding Procedures

[0081] XFE and XAU internal procedures may be implemented.

[0082] FIG. 10 is a diagram of an example of XCF forwarding procedure 1000 associated with a XFE 440.

[0083] Referring to FIG. 10, the XCF forwarding procedure (e.g., a high level XCF forwarding process) at the XFE 440 may include certain forwarding operations and/or steps that may include any of the following: (1) a XFE 440, a XAU 450 and/or a Ethernet switch 460 at block 1010 may transmit an XCF frame over a link (e.g., link 1) to the XFE 440. At block 1022, the XFE 440 may receive the XCF frame sent over the link 1. At block 1024, the XFE 440 may map link 1 specific fields/header to XCF. At block 1026, the XFE 440 may perform ingress and egress processing, for example to enable queue operations and to provide a common switching layer. At block 1028, the XFE 440 may map the XFC to link 2 specific fields/header. At block 1029, the XFE 440 may transmit the XCF frame over a link (e.g., the link 2). At 1030, an XFE 440, an XAU and/or an Ethernet switch may receive the XCF frame over the link (e.g., the link 2).

[0084] For example, the XFE 440 may receive an XCF frame encapsulated in a data-link frame (e.g., Ethernet) over Link 1. The data-link frame may be processed by the reception engine (e.g., to detect collisions) at block 1022 and may be passed to the mapping layer at block 1024. The mapping layer at block 1024 (e.g., ingress mapping layer) may take care of mapping (e.g., may map) Link 1 frame fields onto XCF fields (e.g., Fragment ID). The resulting XCF frame may be passed to the common switching layer at block 1026.

[0085] The common switching layer at block 1026 may process the incoming XCF frame based on some rules/parameters configured by the network controller and may decide and/or determine where and how to forward the frame (e.g., to meet the latency budget, the PDV budget, and/or the packet loss ratio, among others). The processing pipeline of the common switching layer at block 1026 may have a plurality of stages (e.g., three stages) including ingress processing, egress processing, and/or queue management. After the processing at block 1026, the XCF frame may be passed to the mapping layer at block 1028 for transmission. The egress mapping layer at block 1028 may map (e.g., take care of mapping) the XCF fields onto Link 2 frame fields (e.g., the Priority field). The resulting Link 2 frame may be passed down for transmission over a link (e.g., the Link 2).

[0086] FIG. 11A is a diagram illustrating an example of an overall XFE internal forwarding procedure 1100. FIG. 1 IB is a diagram illustrating a first portion of the example XFE internal forwarding procedure (e.g., relating to block 1120 as shown in FIG. 11A). FIG. 11C is a diagram illustrating a second portion of the example XFE internal forwarding procedure (e.g., relating to block 1130 as shown in FIG. 11 A). FIG. 1 ID is a diagram illustrating a third portion of the example XFE internal forwarding procedure (e.g., relating to block 1140 as shown in FIG. 11 A). [0087] Referring to FIG. 11 A, an XFE 440 may include ports (e.g., ingress and egress ports 1110 and 1150), a processor and/or memory for performing translation to and/or from the XCF frames. The input frame 1160 (e.g., Frame In), that may be input to the XFE 440, may have a frame format including (1) a B/F header and payload field; (2) an XCF Opt field; (3) an XCF Source Address; (4) an XCF destination address field; (5) an Ethernet source address field; and/or (6) an Ethernet destination address field, among others. The output frame 1170 (e.g., Frame Out), that may be output from the XFE 440, may have a frame format the same as the input frame including (1) the B/F header and payload field; (2) the XCF Opt field; (3) the XCF Source Address; (4) the XCF destination address field; and/or (5) the Ethernet source address field; and/or (6) the Ethernet destination address field, among others.

[0088] An example of internal forwarding procedures related to an XCF frame arriving at the XFE port 3 (e.g., via ingress port 3) and relayed on port 2 is shown. The mapping and forwarding operations may include, but are not necessarily limited to, any of the following operation shown in FIGS. 11 A-l ID.

[0089] Referring to FIG. 1 IB, block 1120 generally refers to the XCF frame reception of one of the ingress ports 1110 (e.g., on port 3). The Frame Reception operation at block 1122 may include PHY operations at block 1124 and/or MAC operations at block 1126. The PHY operations may include frontend processing of the received XCF frame and baseband processing. The MAC operations may include CRC control operations, triggering of retransmission operations and/or frame reassembly operations including, for example, block ACK retransmissions. The mapper port 3 operation at block 1128 may include a De- encapsulation and Mapping operation including, for example, removal of link-specific header operations, mapping of link-specific frame fields to XCF operations and/or reassemble XCF fragments operations.

[0090] For example, block 1122 may relate to: (i) physical reception operations of the XCF frames including for example synchronization and/or frontend processing) and/or (ii) the MAC operations used for and/or required by the data-link layer technology used on port 3. At block 1128, the data-link frame may be de-encapsulated and mapped to the Ethernet-container XCF format. For instance, Order/Retry bits may be mapped from an IEEE 802.11 header to an XCF header. The XCF frame may be passed to the common switching layer at block 1130.

[0091] Referring to FIG. 11C, the common switching layer at block 1130 may include an Ingress processing operation at block 1132, an Egress processing operation at block 1134 and a Queue Management operation at block 1136. In the Ingress processing operation at block 1132, ingress processing may specify matching rules using a plurality of flow tables (e.g., Flow Tables 0 ... N) and output port(s). In certain examples, XCF frame matching may be based on any one or more of the fields/bits defined herein, for example related to FIGS. 6, 7, 8 and/or 9. For example, a XCF frame may be matched using an Ingress XFE nickname, an egress XFE nickname, a flow ID, a Hop Count, and/or Multi Destination fields, among others. Once a rule successfully matches the XCF frame, ingress processing may identify the output port for that XCF frame. The matching rules may be configured by the network controller. The matching rules may be set forth and/or provided in the flow tables (for example, in successive flow tables).

[0092] In block 1134 egress processing may specify actions to be applied to the XCF frame before transmission. For example, a decrement of the Hop Count field and/or a configuration of the most appropriate transmission queue may be applied (e.g., based on any of: (1) the Type, (2) the Subtype, (2) the timestamp, and/or (3) one or more Priority fields).

[0093] In block 1136, queue management may enforce a QoS at an XCF level with a module/mechanism/operation for multiple queues for transmission. The queues may implement a traffic shaper which may be used to, for example, optimize or guarantee performance, improve latency, and/or increase usable bandwidth for some kinds of frames by delaying other kinds of frames. For example, a latency budget and/or PDV budget may be enforced, at this stage. Once or on condition that the queue management determines and/or decides to transmit a frame, the queue management function may contact the underlying mapping layer.

[0094] Now referring to FIG. 1 ID, block 1140 generally refers to the XCF frame transmission on port 2. Block 1140 may include: (1) a Mapper port operation at block 1142 including a fragmentation operation at block 1143 and/or an encapsulation and mapping operation at block 1144, among others; and/or (2) a frame transmission operation at block 1145 including MAC operations at block 1146 and/or PHY operations at block 1147. The fragmentation operation at block 1143 may include: (1) a fragment XCF process; (2) an append XCF header process; and/or (3) a duplicate XCF header process, among others. The encapsulation and mapping operation at block 1144 may include: (1) a mapping of XCF options to link-specific frame fields process; and/or (2) an appending of the link-specific header process, among others. The MAC operations at block 1146 may include: (1) an append CRC process; (2) a scheduling/granting channel access process; and/or (3) a retransmission process, among others. The PHY operations at block 1147 may include: (1) a baseband processing process; and/or (2) a frontend processing process, among others. The plurality of egress ports 1150 may include, for example, four ports (e.g., with port 2 selected and/or used for transmission.

[0095] For example, in block 1142, the XCF frame may be mapped and/or encapsulated to the specific data-link layer frame format (e.g., IEEE 802.11) and in block 1145, the frame transmission may be related to (i) the MAC operations required by the data-link layer technology used on port 2, and/or (ii) the physical transmission of the XCF frame (e.g., synchronization and frontend processing).

[0096] FIG. 12 is a diagram of an example of XAU adaptation, encapsulation and forwarding procedure 1200.

[0097] Referring to FIG. 12, the XAU adaptation, encapsulation and forwarding procedure 1200 at the XAU 450 may include, but is not necessarily limited to, any of the following: (1) a legacy device (e.g., a legacy remote radio head (RRH), a legacy baseband unit (BBU) and/or a legacy switch) at block 1210 may transmit a legacy frame over a link (e.g., link 1) to the XAU 450. At block 1232, the XAU 450 may receive the legacy frame sent over link 1. At block 1234, the XAU 450 may map link 1 specific fields/header to the legacy protocol. At block 1036, the XAU 450 may perform legacy operations. At block 1238, the XAU 450 may translate and/or adapt the legacy protocol into XCF. At block 1240, the XAU 450 may perform a forwarding decision using rules, status and/or queue management operations. At block 1242, the XAU 450 may map the XFC to link 2 specific fields/header. At block 1244, the XAU 450 may transmit the XCF frame over the link (e.g., the link 2). At block 1250, an XFE 440, another XAU 450 and/or an Ethernet switch may receive the XCF frame over this link (e.g., the link 2).

[0098] For example, the XAU 450 may receive a legacy frame (e.g., IEEE 1904.3) encapsulated in a data-link frame (e.g., Ethernet) over link 1. The data-link frame may be processed by a reception engine at block 1232 (e.g., to detect collisions) and passed to a mapping layer at block 1234. The (ingress) mapping layer at block 1234 may map (e.g., take care of mapping) Link 1 frame fields into a legacy frame (e.g., using Fragment IDs). The resulting legacy frame may be passed to the legacy operations layer at block 1236.

[0099] The legacy operations layer at block 1236 may implement all the operations (e.g., timestamping), related to the legacy protocol. The legacy operation layer at block 1236 may pass the legacy frame to the translation/adaptation layer at block 1238. The translation/adaptation layer at block 1238 may frame (e.g., take care of framing) (e.g., packetization of a CPRI stream) and translate the legacy frame into the XCF frame format. The

XCF frame may be passed to the common switching layer at block 1240.

[0100] The common switching layer at block 1240 may implement the same or similar XFE forwarding functions described with respect to the XFE 440. After such processing, the XCF frame may be passed to the mapping layer at block 1242 for transmission.

[0101] The egress mapping layer at block 1242 may map (e.g., take care of mapping) the XCF fields onto Link 2 frame fields (e.g., the Priority field). The Link 2 frame may be passed (e.g., passed down) for transmission over the link (e.g., the Link 2).

[0102] FIG. 13A is a diagram of an example of an overall XAU encapsulation and forwarding internal procedure 1300. FIG. 13B is a diagram illustrating a first portion of the example XAU internal forwarding procedure (e.g., relating to block 1320 as shown in FIG. 13A). FIG. 13C is a diagram illustrating a second portion of the example XAU internal forwarding procedure (e.g., relating to block 1330 as shown in FIG. 13A). FIG. 13D is a diagram illustrating a third portion of the example XAU internal forwarding procedure (e.g., relating to block 1340 as shown in FIG. 13 A).

[0103] Referring to FIG. 13A, a XAU 450 may include ports (e.g., ingress and egress ports 1310 and 1350), a processor and/or memory for performing encapsulation and forwarding translation to and/or from the XCF frames. The input frame 1360 (e.g., Frame In), that may be input to the XAU 450, may have a frame format including (1) a B/F payload field and/or (2) a B/F header field, among others. The output frame 1370 (e.g., Frame Out), that may be output from the XAU 450, may have a frame format including (1) the B/F payload field; (2) the B/F header field; (3) the XCF Opt field; (4) the XCF Source Address field; (5) the XCF Destination Address field; (6) the Ethernet Source Address field; and/or (7) an Ethernet Destination Address field, among others.

[0104] An example of the XAU encapsulation and forwarding procedure related to a legacy frame arriving at the XAU port 1 (e.g., via ingress port 1) and relayed on port 4 is shown. The encapsulation and forwarding operation may include, but are not necessarily limited to, any of the following operations shown in FIGS. 13A-13D.

[0105] Referring to FIG. 13B, the Signal Reception operation at block 1322 may include PHY operations at block 1324 and/or MAC operations at block 1326. The PHY operations may include frontend processing of the received legacy frame and baseband processing. The MAC operations may include CRC control operations, triggering of retransmission operations and/or frame reassembly operations including, for example, block ACK retransmissions. The mapper port 1 operation at block 1328 may include a De-encapsulation and Mapping operation including, for example, removal of link-specific header operations, mapping of link-specific frame fields to F/B protocols. The translation F/B operation at block 1329 may include framing of F/B pay load into XCF format and/or appending of XCF header to the framed F/B pay load.

[0106] For example, block 1320 generally refers to signal reception (e.g., of a CPRI stream) on port 1. Block 1322 may include physical reception and MAC operations (if any). These operations may include that same or similar procedures as disclosed in block 1122 of FIG. 1 IB. In block 1328, a data-link header (e.g., any eventual data-link header) may be removed and the incoming signal mapped in the legacy protocol. This frame may be passed to the translation/adaptation layer 1329.

[0107] At block 1329, a non-packetized stream (e.g., any non-packetized stream) may be framed. The framing procedure may be configured by a network controller (e.g., configuring the size of a frame, for example each frame). The traffic may be mapped and encapsulated in the Ethernet-container XCF format (e.g., the Type and/or the Subtype XCF fields may be set at this stage). The XCF frame may be passed to the common switching layer at block 1330.

[0108] Referring to FIG. 13C, the common switching layer at block 1330 may include an ingress processing operation at block 1332, an egress processing operation at block 1334 and a queue management operation at block 1336.

[0109] In the ingress processing operation at block 1332, ingress processing may specify matching rules using a plurality of flow tables (e.g., Flow Tables 0 ... N) and output port(s). In certain examples, XCF frame matching may be based on any one or more of the fields/bits defined herein, for example related to FIGS. 6, 7, 8 and/or 9. For example, the XCF frame may be matched using the ingress nickname, the egress nickname, the flow ID, the hop count, and/or the Multi Destination fields, among others. Once a rule successfully matches the XCF frame, ingress processing may identify the output port for that XCF frame. The matching rules may be configured by the network controller. The matching rules may be set forth and/or provided in the flow tables (for example, in successive flow tables).

[0110] At block 1334 egress processing may specify actions to be applied to the XCF frame before transmission. For example, a decrement of a Hop Count value in the Hop Count field and/or a configuration of the most appropriate transmission queue (.e.g., based on any of: (1) the Type, (2) the Subtype, (3) the timestamp, and/or (4) the one or more Priority fields) may be applied. [0111] At block 1336, the queue management may, for example enforce a QoS at an XCF level with a module/mechanism/operation for multiple queues for transmission. The queues may implement a traffic shaper which may be used to optimize or guarantee performance, improve latency, and/or increase usable bandwidth for some kinds of frames by delaying other kinds of frames. For example, a latency budget and/or a PDV budget may be enforced, at this stage. Once or on condition that the queue management determines and/or decides to transmit a frame, the queue management function may contact the underlying mapping layer.

[0112] For example, block 1330 generally refers to the XCF frame forwarding procedures. Block 1332 may include ingress processing (e.g., with the same or similar procedures as disclosed in block 1132 of FIG. 11C. Block 1334 may include egress processing (e.g., with same or similar procedures as disclosed in block 1134 of FIG. 11C. Block 1336 may include queue management (e.g., with the same or similar procedures as disclosed in block 1136 of FIG. l lC.

[0113] Now referring to FIG. 13D, block 1340 generally refers to the XCF frame transmission on port 4. Block 1340 may include: (1) a Mapper port operation at block 1342 including a fragmentation operation at block 1343 and/or an encapsulation and mapping operation at block 1344, among others; and/or (2) a frame transmission operation at block 1345 including MAC operations at block 1346 and/or PHY operations at block 1347. The fragmentation operation at block 1343 may include: (1) a fragment XCF process; (2) an append XCF header process; and/or (3) a duplicate XCF header process, among others. The encapsulation and mapping operation at block 1344 may include: (1) a mapping of XCF options to link-specific frame fields process; and/or (2) an appending of the link-specific header process, among others. The MAC operations at block 1346 may include: (1) an append CRC process; (2) a scheduling/granting channel access process; and/or (3) a retransmission process, among others. The PHY operations at block 1347 may include: (1) a baseband processing process; and/or (2) a frontend processing process, among others. The plurality of egress ports 1350 may include, for example, four ports (e.g., with port 2 selected and/or used for transmission.

[0114] In certain examples, cross-domain multi -traffic encapsulation and forwarding may be used. This encapsulation and forwarding may be performed as disclosed herein.

[0115] FIG. 14 is a diagram illustrating a representative adaptive forwarding procedure, for example, as part of or in lieu of the Common Switching layer operation 1340 for the crosshaul entity (XE) (e.g., the XFE 440 and/or the XAU 450, among others) of FIGS. 11 A-l ID or 13A- 13D. Similar to FIGS. 11C and 13C, the common switching layer operation 1430 may include ingress processing operation 1432, egress processing operation 1434 and/or queue management operation 1436. The ingress processing and egress processing operations includes a plurality of flow tables (e.g., use of any number of flow tables 0 ... m). For example, Flow Table 0 may include matching rules such that: (1) on condition that the XCF. type of a packet is fronthaul (e.g., the packet is determined to be fronthaul traffic), processing may move to Flow Table 1; (2) on condition that the XCF.type of a packet is backhaul (e.g., the packet is determined to be backhaul traffic), processing may move to Flow Table 2; and (3) on condition that no other matches in Flow Table 0 occurs, the packet may be sent to a network controller (or may be discarded).

[0116] At Flow Table 1, a set of matching rules may be applied to determine a port and/or an egress processing Flow Table that processing may move to. For example, on condition that: (1) a priority of the packet is set to high; (2) the packet has not been recirculated (a recirculation counter associated with the number of times the packet has been processed by this Flow Table is set to 0); and (3) the XCF. subtype of the packet is fronthaul. cpri-o-e, the output port (e.g., the egress port) may be set to 4 and processing may move to egress processing Flow Table e.

[0117] As another example, on condition that: (1) a priority of the packet is set to high; (2) the packet has been recirculated (the recirculation counter is set to 1 or greater); and (3) the XCF. subtype of the packet is fronthaul. cpri-o-e, the output port (e.g., the egress port) may be set to 2 and processing may move to egress processing Flow Table e+1. As a further example, on condition that: (1) a priority of the packet is set to 0 the packet may be discarded.

[0118] Although certain matching rules are illustrated in Flow Table 1 of FIG. 14, other matching rules are possible. For example, Flow Tables may be similar to of different from Flow Table 1 of FIG. 14 and may include selection of an output port and/or egress processing Flow Table based on any information accessible from the XCF frame format of the packet.

[0119] Egress processing operation 1434 may include Flow Tables e, e+1 to m, among others. For example, at the Flow Table e, on condition that the Ethertype of the packet is XCF, an XCF. hop may be set to 1 and processing may move to Flow Table e+1. At Flow Table e+1, for example, on condition that: (1) the XCF. priority is 7, and (2) a first buffer size (e.g., for queue.1. buffer associated with queue 1) is less than a threshold, the packet may be forwarded to queue 1. At Flow Table e+1, on condition that: (1) the XCF. priority is 7, (2) the first buffer size is greater than the threshold; (3) and a second buffer is less than another threshold, the packet may be forwarded to queue 2. [0120] At Flow Table m, on condition that no other matches in egress processing Flow Tables occurs, the recirculation counter may be incremented and the packet may be sent back to the Flow Table 0 for processing.

[0121] In certain representative embodiments, at the Flow Table 0, (1) the incoming packet may be matched against a set of forwarding rules. If any of these rules matches the packet, the XE 440 and/or 450 may proceed with processing the packet in the following flow tables; (2) if none of the forwarding rules has successfully matched the packet, the XE 440 and/or 450 may sends the packet to the controller (e.g., network controller). In certain representative embodiments, the fronthaul traffic may be further processed in the Flow Table 1 and backhaul traffic may be further processed in the Flow Table 2.

[0122] At Flow Table 1 and/or 2, the packet may be matched against some other subfields (e.g., data subtype) to retrieve/determine the corresponding output port the packet should be forwarded to (e.g., for forwarding of the packet). The match may be based on additional metadata, for example, packet.recirculated, which may check whether it is the first time the packet is being processed by the flow table. If it is the first time (packet. recirculated==0), no packet recirculation occurred and the default port may be selected. If the packet has already been recirculated (packet.recirculated==l, or packet.recirculated==2, among others), the XE 440 and/or 450 may select an alternative port. If no output port is available, the XE 440 and/or 450 may discard the frame.

[0123] At Flow Table e, certain egress processing may be executed on the packet (e.g., decrementing the hop count (XCF.hop-=l)). At Flow Table e+1, the packet may be matched against certain priority fields (e.g., XCF. priority) to retrieve and/or determine the corresponding output queue from which the packet may be forwarded. This match may be based on the current status of the queue (e.g., queue.1. buffer indicates the amount of the occupied buffer (e.g., in bytes) of the queue 1). An ordered list of queue alternatives (and/or corresponding conditions, e.g., buffer occupancy) may be implemented in Flow Table e+1 and/or any other Flow Table. If no alternative queue is available, the recirculation counter may be incremented (e.g., packet.recirculated+=l), the packet processing may be restarted from Flow Table 0 and the packet may be redirected to Flow Table 1 or 2 depending on a traffic type of the packet.

[0124] FIG. 15 is a flow chart illustrating a representative adaptive forwarding procedure similar to FIG. 14. [0125] Now referring to FIG. 15, the representative procedure 1500 may include, at block 1510 the XE 440 receiving an incoming packet. At block 1520, the XE 440 and/or 450 may determine whether there is a forwarding rule (e.g., any forwarding rule) successfully matching the incoming packet. At block 1530, on condition that there is a forwarding rule that successfully matches the incoming packet, the XE 440 and/or 450 may select an output port and at block 1540 the XE 440 and/or 450 may select an output queue. At block 1580, on condition that there is not a forwarding rule that successfully matches the incoming packet, the XE 440 and/or 450 may discard the packet or may send the packet to a network controller. At block 1550, the XE 440 and/or 450 may determine whether a selected output port and queue fulfil (e.g., satisfy, meet and/or exceed) the packet traffic requirements. At block 1590, on condition that the selected output port and queue fulfil (e.g., satisfy, meet and/or exceed) the packet traffic requirements, the XE 440 and/or 450 may send the packet to the selected port and queue. At block 1560, on condition that the selected output port and queue does not fulfil (e.g., satisfy, meet and/or exceed) the packet traffic requirements, the XE 440 and/or 450 may determine whether there is an alternative queue (e.g., any queue) on the same selected port that fulfils (e.g., satisfies, meets and/or exceeds) the packet traffic requirements. If so, the XE 440 and/or 450 may select the queue that satisfies the packet traffic requirements and processing may return to block 1540.

[0126] At block 1570, on condition that no queue on the same selected port fulfils (e.g., satisfies, meets and/or exceeds) the packet traffic requirements, the XE 440 and/or 450 may determine whether there is an alternative port (e.g., any alternative port) that fulfils (e.g., satisfies, meets and/or exceeds) the packet traffic requirements. If so, the XE 440 and/or 450 may select the alternative port that satisfies the packet traffic requirements and processing may return to block 1530.

[0127] At block 1580, on condition that there is no alternative port that fulfils (e.g., satisfies, meets and/or exceeds) the packet traffic requirements, the XE 440 and/or 450 may discard the packet or may send the packet to the network controller.

[0128] For example, at block 1510 the XE 440 and/or 450 may receive a frame on a given port. At block 1520, the XFE may perform a look-up on the fields of the incoming frame. The XE 440 and/or 450 may use any combinations of the fields defined in the frame. Example fields may include any of: (1) a source address, (2) a destination address, (3) a priority field, (4) an Ethertype, (5) a type of payload, (6) a subtype of payload, (7) VLAN tags, (8) a QoS field, (9) a Flow ID, and/or (10) a Timestamp, among others. If the look-up is successful, processing may move to block 1530. Otherwise, processing may move to block 1580.

[0129] At block 1530, the XE 440 and/or 450 may retrieve from the forwarding table the output port the frame is to be or should be transmitted to. At block 1540, the XE 440 and/or 450 may retrieve from the forwarding table the output queue the frame is to be or should be transmitted to. At block 1550, the XE 440 and/or 450 may check if the packet traffic requirements can be fulfilled by the selected port and queue. The XE 440 and/or 450 may consider a current status of the port and queue during this operation.

[0130] Examples of packet traffic requirements may include any of: (1) a bandwidth requirement/threshold, a latency requirement/threshold, a jitter requirement/threshold, a bit error rate (BER) requirement/threshold, a packet loss rate requirement/threshold, a fragmentation indicator (e.g., whether fragmentation is allowed, for example, don't fragment this frame), a preemptable indicator, and/or ordered delivery indicator, among others. Examples of port status may include any of: a Received Signal Strength Indication (RSSI), a Channel Quality Indicator (QCI), BER, a packet loss rate, an idle/active, and/or a power-save mode (e.g., active), among others. Examples of queue status may include: (1) buffer occupation, and/or (2) transmission rate (e.g., packets per second, and/or bits per second, etc.), among others.

[0131] Although examples of packet traffic requirements are illustrated herein, including packet latency and BER, any combination of traffic, port and/or queue status may be used.

[0132] In a first example, the selected queue may match the packet latency requirement (for example, a packet may be scheduled to be sent over a given queue. The XE 440 and/or 450 may check the buffer occupation and/or transmission rate of the queue. The XE 440 and/or 450 may check if the packet can be transmitted in time to meet the latency requirement, given the current buffer occupation and/or transmission rate of the queue, to determine if the port and queue meet the packet traffic requirements.

[0133] In a second example, the selected port may match the bit error rate requirement (e.g., the packet traffic requirement may be or may include the BER which is associated to the port. The XE 440 and/or 450 may check if the BER on a given port satisfies the BER requirement of the packet to be transmitted).

[0134] In certain representative embodiments, if the packet traffic requirements are satisfied, processing may move to block 1590. Otherwise, processing may move to block 1560. At block 1560, if the condition are not fulfilled for the current selection of a port-queue combination, the XE 440 and/or 450 may check first if an alternative queue is available on the same port. Checking first the queue may be preferred (e.g., verses checking first the port). Changing the transmission queue may have a minor impact on the network since the same traffic flow may continue to be transmitted over the same path. In case of frames transmitted over multiple paths, a reordering mechanism in the network may be used and/or required, for example, on condition that ordered delivery is one of the requirements associated to the packet traffic. In certain representative embodiments, at block 1560, the XE 440 and/or 450 may check whether the current buffer occupation and/or transmission rate of a new queue allows the packet to be transmitted in time and to meet the latency requirement. If any of the queues on the same port satisfies the packet traffic requirements, processing may move to 1540 and the XE 440 and/or 450 may select that new queue. Otherwise, processing may move to block 1570.

[0135] If no alternative queues are available on the current port (e.g., the selected port), the XE 440 and/or 450 may check if an alternative port is available. The XFE may determine and/or may know in advance the altemative ports. In certain representative embodiments, certain (e.g., and not all) ports on a switch (e.g., the XE 440 and/or 450) may be available for a given packet. The network controller, in the same way it configured the default port and queue for forwarding the packet, may configure a list of altemative ports for a given packet match (e.g., during the matching procedure associated with block 1520).

[0136] As an example, similar to the procedures associated with block 1540, the XE 440 and/or 450 may check whether the current BER of a new port fulfils and/or satisfies the BER requirements of the packet. If any of the ports on the same XE 440 and/or 450 and/or switch satisfies the packet traffic requirements, processing may move to block 1530 and the new port may be selected. Otherwise, processing may move to block 1580.

[0137] If a packet has not been successfully matched and/or cannot be transmitted while fulfilling its packet traffic requirements, the XE 440 and/or 450 may discard the packet or may send the packet to the network controller. The decision to discard the packet or to forward the packet to the network controller may be based on the network controller's policies. The network controller may instruct the XE 440 and/or 450 regarding block 1580 operations. The network controller may change the forwarding rules based on any of: (1) the packets sent from the XE 440 and/or 450 to the network controller (e.g., the network controller may have the capability of checking the content of the packet and react accordingly; and/or (2) the packets with no matching rules may be discarded by the XE 440 and/or 450. The network controller may periodically check the forwarding statistics on the XE 440 and/or 450 (including discarded frames) and may change the forwarding rules to minimize the number of discarded frames. At block 2290, the XE 440 and/or 450 may send the packet to the selected port and queue (e.g., that meets the packet traffic requirements).

[0138] FIGS. 16-22 are diagrams illustrating representative encapsulation and forwarding operations using a representative network 1600.

[0139] Referring to FIGS. 16-22, the representative network 1600 may include an access network (e.g., 1670), a first transport segment (e.g., a segment 1610), a second transport segment (e.g., a segment 1620) and/or a core network (e.g., the core network 1655). The access network 1670 may include a plurality of WTRUs 102 (e.g., UE-1, UE-2 and UE-3), a plurality of RAUs 210-1 and 210-2 (e.g., RAU-1 and RAU-2) and/or one or more Digital Subscriber Line Access Multiplexers (DSLAMs)/Optical Terminal Multiplexers (OTMs) 1630. The first transport segment 1610 may include one or more XAUs 450-1, 450-2 and 450-3 (e.g., XAU- 1, XAU-2 and XAU-3), one or more XFEs 440-1 and 440-2 (e.g., XFE-1 and XFE-2), one or more Ethernet switches 430-1 and/or one or more fronthaul encoding/decoding servers 1640. The XAU-1 450-1 may be located at a boundary of the first transport segment 410 and may interface with the RAU-1 210-1 and the RAU-2 210-2 of the access network 1670. The XAU- 2 450-2 may be located at a boundary of the first transport segment 1610 and may interface with the DSLAM/OTM 1630 of the access network 1670. The XFE-2 440-2 may be located at the boundary of the first transport segment 1610 and may interface with one or more XFEs (e.g., the XFE-3 440-3) and/or Ethernet switches (e.g., Ethernet switch 430-2).

[0140] The second transport segment 1620 may include one or more XAUs 450-4 and 450-5 (e.g., XAU-4 and XAU-5), one or more XFEs 440-3 (e.g., XFE-3), one or more Ethernet switches 430-2 and/or one or more servers 480. The XAU-5 450-5 may be located at a boundary of the second transport segment 1620 and may interface with the core network 1655. For example, the access network 1670 may be composed of or include two RAUs 210-1 and 210-2 (e.g., RAU-1 and RAU-2) and a fixed access switch (e.g., the DSLAM/OTN 1630). The transport network 1605 may be composed of or include two segments with separate data-link domains, for instance the first transport segment 1610 may be an IEEE 802. Had wireless mesh-network, and the second transport segment 1620 may be IEEE 802.3aq fiber optic network. Each transport segment 1610 and 1620 may include several XAUs 450, XFEs 440, and Ethernet-compatible switches 430. The XCF domain 1605 may span over the two transport segments 1610 and 1620 and may be connected to the core network 1655. [0141] The XCF encapsulation and forwarding example in an Ethernet-compatible multi data- link scenario is illustrated in FIGS. 16-22 using example traffic flows. XCF frames may be forwarded from left to right in FIG. 16. Protocol headers may be added on the right side in FIGS. 16-22. A WTRU 102 (e.g., a UE-1) may be connected to the RAU-1 210-1 which may be configured with a particular functional split. The UE-1 102 traffic may not be identified until the fronthaul traffic (labeled ®) is decoded at Fronthaul encoding/decoding server 1640 connected to XAU-3 450-3. The fronthaul traffic © may be the fronthaul traffic associated to the RAU-1 210-1 and may contain or include a fronthaul-specific header depending on the employed interface. The latency budget and/or the Packet Delay Variation (PDV) budget may be associated with fronthaul traffic ® . For example, to decode CPRI traffic, the signal may be received within a certain delay by the BBU. The PDV may be as important as the latency requirement. Even if the latency requirement is fulfilled, the PDV may be too great (e.g., exceeding a threshold) and may affect the correctness of the CPRI decoding. From a transport network perspective, fronthaul traffic ® may be a priority (e.g., a high priority) traffic in terms of the latency and/or the PDV.

[0142] The WTRU 102 (e.g., the UE-2) may be connected to the RAU-2 210-2, which may be a legacy eNode-B (e.g., with no functional split). The UE-2 102 may communicate with one or more servers outside the operator's network, and the UE-2 102 may send backhaul traffic (labeled ©) to the core network 1655 e.g., directly to the core network). The UE-2 102 may be the Ethernet source address (Eth Src) and the XAU-5 450-5 may be the Ethernet Destination address (Eth Dst) in the outermost header. For simplicity, the XAU-5 450-5 may be considered as the transport network's point-of-presence in the core network 1655. A packet loss ratio budget may be associated with the backhaul traffic © and no maximum latency and/or PDV may be set and/or required. For example, the UE-2 102 may be performing a backup of the mobile phone apps on a remote server. From the transport network perspective, backhaul traffic © may be a low priority traffic (e.g., a priority which may be set below a threshold) in terms of the latency and/or the PDV, and may be a high priority (e.g., a priority which may be set above a second threshold) in terms of the packet loss ratio.

[0143] WTRU 102 (e.g., UE-3) may be connected to the DSLAM/OTM 1630, which may provide fixed-line access. The UE-3 102 may send backhaul traffic (@) to a Server 480 which is connected to the XAU-4 450-4. The UE-3 102 may be the Eth Src and the Server 480 may be the Eth Dst in the outermost header. A latency and/or the PDV budget may be associated with backhaul traffic @. For example, the UE-3 102 may be connected to the Server 480 for online-gaming. The backhaul traffic @ parameters/requirements may be relaxed relative to (e.g., may be more relaxed than) fronthaul traffic (Γ) parameters/requirements (e.g., the backhaul traffic @ may admit higher latency and/or PDV than fronthaul traffic (Γ), nevertheless fronthaul traffic (Γ) may still be bounded to a maximum value that cannot be exceeded. From a transport network perspective, the backhaul traffic @ may be a medium priority traffic in terms of latency, PDV and/or packet loss ratio.

[0144] Referring to FIG. 17, the frame format of the traffic after having been encapsulated in XCF frames is illustrated. The XCF Source Address (XCF Src) may refer to the Ingress XFE nickname and the XCF Destination Address (XCF Dst) may refer to the Egress XFE nickname. The traffic information carried in the XCF header (e.g., the Type, the Subtype, the Priority, the Frame Control field, and/or the Flow ID, among others) may be referred to as XCF Options (XCF Opt) due to space limitations in FIG. 17. In certain examples, the traffic flows may be encapsulated and forwarded as follows.

[0145] The network controller (not shown) may configure, on the XAU-1 450-1, the framing and encapsulation parameters regarding the fronthaul traffic (Γ) generated by the RAU-1 210- 1. The XAU-1 450-1 may append an XCF header to the fronthaul traffic (Γ) with the following field values. For example, the XAU-1 450-1 may be the XCF Src, which may be the Ingress XFE nickname in the XCF domain 1605. The XAU-3 450-3 may be the XCF Dst, and the fronthaul traffic (Γ) may be decoded at the Fronthaul encoding/decoding (FED) server 1640. The XAU-3 450-3 may be the egress point of the XCF domain 1605 for traffic directed to the FED server 1640. The XCF Opt values may include: (1) the Type: Data, (2) the Subtype: Fronthaul. CPRI-over-E, (3) the Priority: High, (4) the Pre-emptible: No, (5) the Timestamp, and/or (6) the Order: Yes (e.g., CPRI traffic may not be received out-of-order and reordering at the end points may introduce additional latency that may not be tolerated by the fronthaul interface). The XCF Opt values may be used by the XFEs 440, for example, to enforce locally the latency and/or the PDV subject to the rules configured by the network controller.

[0146] An external data-link domain specific header may be added to the XCF frame. It is contemplated that: (1) the first transport segment 1610 may be an IEEE 802.11 wireless mesh- network; and/or (2) the XAU-1 450-1 may encapsulate the XCF frame into a 802.11 frame and may transmit the 802.11 frame over the wireless link. For brevity and simplicity, Eth Src and Eth Dst fields of the additional data-link specific header may be considered in this example. One of skill in the art understands that this header contains or includes more link-specific fields that may be configured in the XAUs 450 and/or the XFEs 440 by the mapping layers. The fronthaul traffic © data-link specific header may include the following values.

[0147] The XAU-1 450-1 may be the Eth-Src, which may be the Source Address in the data- link domain 1610. The XAU-3 450-3 may be the Eth-Dst, which may be the Destination Address in the data-link domain 1610. In this case the XCF Src, the Eth Src, the XCF Dst and/or the Eth Dst may coincide since the XAU-1 450-1 and the XAU-3 450-3 belong to the same data-link domain 1610.

[0148] Similarly to the previous example, the network controller may configure, on the XAU-

1 450-1, the encapsulation parameters regarding the backhaul traffic © generated by the UE-

2 102. The XAU-1 450-1 may append an XCF header to the backhaul traffic © with the following field values. The XAU-1 450-1 may be the XCF Src, which may be the Ingress XFE nickname in the XCF domain 1610. The XAU-5 450-5 may be the XCF Dst, and the backhaul traffic © may be directed to the core network 1655. The XAU-5 450-5 may be the egress point of the XCF domain 1605 for the backhaul traffic ©. The XCF Opt values for the backhaul traffic © may include: (1) the Type: Data, (2) the Subtype: Backhaul. background (e.g., file transfer protocol (FTP) session), (3) the Priority: Low, (4) the Pre-emptible: Yes, (5) the Order: No (e.g., TCP implements reorder). The XCF Opt values may be used by the XFEs 440, for example, to enforce locally the packet loss ratio subject to the rules configured by the network controller.

[0149] In certain examples, an external data-link domain specific header may be added to the XCF frame with the following values. The XAU-1 450-1 may be the Eth Src, which may be the Source Address in the data-link domain 1610. The XFE-2 440-2 may be the Eth Dst, which may be the Destination Address in the data-link domain 1610. The backhaul traffic © may be (e.g., must be) firstly forwarded to the XFE-2 440-2 to reach the XAU-5 450-5 in the second transport segment 1620.

[0150] In certain representative embodiments, the network controller may configure, on the XAU-2 450-2, the encapsulation parameters regarding the backhaul traffic (@) generated by WTRU 102 (e.g., UE-3). The XAU-2 450-2 may append an XCF header to the backhaul traffic @ with the following field values. The XAU-1 450-1 may be the XCF Src, which may be the Ingress XFE nickname in the XCF domain 1605. The XAU-4 450-4 may be the XCF Dst and the backhaul traffic @ may be directed to the Server 480. The XAU-4 450-4 may be the egress point of the XCF domain 1605 for the backhaul traffic @. The XCF Opt values for the backhaul traffic @ may include: (1) the Type: Data, (2) the Subtype: Backhaul. video. livestream (e.g., for online gaming), (3) the Priority: Medium, (4) the preemptible: Yes, (5) the Order: Yes (e.g., an ordered delivery of Audio and Video frames may reduce the WTRU's perceived latency). The XCF Opt values may be used by the XFEs 440, for example to enforce locally the latency and/or the PDV subject to the rules configured by the network controller.

[0151] An external data-link domain specific header may be added to the XCF frame with the following values. The XAU-2 450-2 may be the Eth Src, which may be the Source Address in the data-link domain 1610. The XFE-2440-2 may be the Eth Dst, which may be the Destination Address in the data-link domain 1610. The backhaul traffic © may or must be firstly forwarded to the XFE-2 440-2 to reach the XAU-4 450-4 in the second transport segment 1620.

[0152] An example of the frame format of the XCF frames traffic after having been forwarded in the first transport segment 1610 is illustrated in FIG. 18. The traffic flows may be forwarded as follows.

[0153] The XFE-1 440-1 may forward the fronthaul traffic ® based on the XCF Dst and the XCF Opt values. The XCF Dst may determine an output port and the XCF Opt values (e.g., the Type, the Subtype, the Timestamp, the pre-emptible and/or the Order, among others) may determine the QoS internal queue management and switching of the fronthaul traffic ® . The network controller may monitor the transport network 1600 and may know or may determine the time required to transmit a frame from the XAU-1 450-1 to the XAU-3 450-3 and/or may know or may determine the time required to transmit a frame from the XFE-1 440-1 to the XAU-3 450-3. The rules configured on the XFE-1 440-1 may be related to an end-to-end path, for example to enforce local latency and/or PDV. For example, the fronthaul traffic ® frames may not be running out of (e.g., exceeding) the latency budget when forwarded by the XFE-1 440-1, but the fronthaul traffic may eventually run out of (e.g., exceed) the latency budget if or on condition that the XFE-1 440-1 delays (e.g., excessively delays) the forwarding of those frames. The latency budget and/or the PDV budget may refer to the end-to-end path (in this case the end of the path may be to the XAU-3 450-3). The XFE-1 440-1 may not remove the data-link specific header because the forwarding occurs in the same data-link domain 1610 and the header is still valid.

[0154] The XFE-1 440-1 may forward the backhaul traffic © based on the XCF Dst and/or the XCF Opt values. The backhaul traffic © may have lower priority in terms of the latency and/or the PDV compared to the fronthaul traffic © and may have a higher priority in terms of packet loss ratio compared to the fronthaul traffic ® . The fronthaul traffic ® may preempt (e.g., eventually preempt) the backhaul traffic ©, for example, to ensure the latency and/or the PDV of the fronthaul traffic ® . The backhaul traffic © may be delayed. In certain examples, the first transport segment 1610 may be a wireless mesh network and the backhaul traffic © may be subject to a packet loss ratio budget. The XFE-1 440-1 may transmit the backhaul traffic © on the frequency (and/or timeslot) with the lowest packet error probability. The packet error probability may be measured by the network controller that may configure the XFE-1 440-1 to forward the backhaul traffic © on the appropriate (e.g., most appropriate) frequency (and/or timeslot).

[0155] Ethernet Switch 430-1 may forward the backhaul traffic @ based on the Eth Dst and/or following the legacy Ethernet forwarding procedure. There may be no look-up procedure on the XCF header and the frame may be forwarded with no modification.

[0156] An example of the frame format of the XCF frames traffic after having been forwarded in the first transport segment 1610 and the second transport segment 1620 is illustrated in FIG. 19. The traffic flows may be forwarded as follows.

[0157] The XFE-2 440-2 may forward the fronthaul traffic ® based on the XCF Dst and/or the XCF Opt values, and may follow the same procedure disclosed for the XFE-1 440-1. The XFE-2 4402 may not remove the data-link specific header because the forwarding occurs in the same data-link domain 1610 and the header may still be still valid.

[0158] The XFE-2 440-2 may forward the backhaul traffic © based on the XCF Dst and/or the XCF Opt values, and may follow the same procedure disclosed for the XFE-1 440-1. The XFE-2 440-2 may forward the backhaul traffic © from the first transport segment 1610 to the second transport segment 1620 and may swap the data-link specific header. The data-link domain specific header may have the following values. The XFE-2 440-2 may be the Eth Src, which may be the Source Address in the data-link domain 1610. The XAU-5 450-5 may be the Eth Dst, which may be the Destination Address in the data-link domain 1620 and the egress point of the XCF domain 1605.

[0159] The XFE-2 440-2 may forward the backhaul traffic © based on the XCF Dst and/or the XCF Opt values. The network controller may configure the forwarding rules on the XFE- 2 440-2, for example to ensure the end-to-end latency and/or the PDV budget associated to the backhaul traffic @. The XFE-2 440-2 may forward the backhaul traffic @ in a similar way to the forwarding by the XFE-1 440-1 of the fronthaul traffic ® frames. The difference here may be in the different latency and/or PDV values. The backhaul traffic @ may be delayed more than the fronthaul traffic © frames. Since the XFE-2 440-2 may forward the backhaul traffic @ from the first transport segment 1610 to the second transport segment 1620, the XFE-2440- 2 may swap the data-link specific header. The data-link domain specific header may have the following values. The XFE-2 440-2 may be the Eth Src, which may be the Source Address in the data-link domain 1610. The XAU-4 450-4 may be the Eth Dst, which may be the Destination Address in the data-link domain 1620 and the egress point of the XCF domain 1605.

[0160] An example of the frame format of the XCF frames traffic after having been de- encapsulated in the first transport segment 1610 and forwarded in the second transport segment 1620 is illustrated in FIG. 20. The traffic flows may be forwarded as follows.

[0161] The network controller may configure, on the XAU-3 450-3 (e.g., which is in the first transport segment 1610), the deframing and de-encapsulation parameters regarding the fronthaul traffic ® generated by the RAU-1 210-1. The XAU-3 450-3 may strip the data-link and XCF headers. Depending on the employed functional split, the XAU-3 450-3 may append an additional header to the frame, and may forward the frame to the FED server 1640.

[0162] The XFE-3 440-3 may forward the backhaul traffic © based on the XCF Dst and/or the XCF Opt values. The forwarding procedure disclosed herein may apply.

[0163] The Ethernet Switch 430-2 may forward the backhaul traffic @ based on the Eth Dst and/or following the legacy Ethernet forwarding procedure. There may be no look-up procedure on the XCF header and the frame may be forwarded with no modification.

[0164] An example of the frame format of the traffic after having been de-encapsulated is illustrated in FIG. 21. The traffic flows may be forwarded as follows.

[0165] The fronthaul traffic ® may have reached the FED server 1640. No further operations may be done and/or required in the network 1600 for the fronthaul traffic (Γ).

[0166] The network controller may configure, on the XAU-5 450-5, the de-encapsulation parameters regarding the backhaul traffic © generated by the UE-2 102. The XAU-5 450-5 may strip the data-link and/or the XCF headers. The XAU-5 450-5 may append an additional header according to Core Network protocols (e.g., IP/MPLS) and may forward the traffic to a next hop.

[0167] The network controller may configure, on the XAU-4 450-4, the de-encapsulation parameters regarding the backhaul traffic @ generated by the UE-3 102. The XAU-4 450-4 may strip the data-link and/or the XCF headers. The XAU-4 450-4 may forward (e.g., simply forward) the backhaul traffic @ to the Server 480, for example, because the backhaul header may be a valid data-link header. It is contemplated that in this case, the XCF may be a way to implement a Metro Ethernet E-Line service from the UE-3 and the Server perspective.

[0168] An example of the frame format of the traffic after having been de-encapsulated and delivered is illustrated in FIG. 22. The traffic flows may be forwarded as follows.

[0169] The fronthaul traffic ® may have reached the FED server 1640. No further operations may be done and/or required in the network 1600 for the fronthaul traffic (Γ).

[0170] The backhaul traffic © may have reached the core network 1655. No further operations may be done and/or required in the network 1600 for the backhaul traffic ©.

[0171] The backhaul traffic @ has reached the Server 480. No further operations may be done and/or required in the network 1600 for the backhaul traffic ©.

[0172] FIG. 23 is a flowchart illustrating a representative method in a crosshaul entity.

[0173] Referring to FIG. 23, the representative method 2300 may include, at block 2310 the crosshaul entity 440 and 450 that may generate a crosshaul common frame (XCF) using a first data-link frame associated with the first link technology. For example, the crosshaul entity 440 and/or 450 may remove a link-specific header of the first data-link frame, and may map one or more link-specific fields and/or the link-specific header of the first data-link frame to a crosshaul protocol (e.g., a MAC-in-MAC protocol, a MAC Tunneling Protocol (MTC), a Multiprotocol Label Switching (MPLS), and/or other similar protocols, among others) associated with the XCF. At block 2320, the crosshaul entity 440 and/or 450 may generate the second data-link frame using the XCF. For example, the crosshaul entity 440 and/or 450 may add to the XCF a link-specific header of the second data-link frame for transmission over a second link technology, and may map one or more XCF fields and/or a XCF header to the second data-link frame in accordance with a second link protocol associated with the second data-link frame. The XCF may be encapsulated in the second data-link frame. At block 2330, the crosshaul entity 440 and/or 450 may send to another entity (e.g., a network entity) the second data-link frame including the encapsulated XCF.

[0174] In certain representative embodiments, the XE 440 and/or 450 may receive the first data-link frame over a first link technology via a first ingress port. For example, the first data- link frame may include an encapsulated legacy frame.

[0175] In certain representative embodiments, the XE 440 and/or 450 may determine legacy information from the first data-link frame and/or may perform legacy protocol operations using one or more first data-link fields and a first data-link header mapped to a legacy frame encapsulated in the first data-link frame. [0176] In certain representative embodiments, the XE 440 and/or 450 may receive the first data-link information over a first link technology via a first ingress port. For example, the first data-link information may include an encapsulated legacy frame and the XE 440 and/or 450 may frame the first data-link information to generate a first data-link frame.

[0177] In certain representative embodiments, the XE 440 and/or 450 may determine, based on XCF information and flow rules, a port to send the second data-link frame. For example, the XE 440 and/or 450 may send the second data-link frame using the determined port.

[0178] In certain representative embodiments, the XE 440 and/or 450 may determine, based on XCF information and flow rules, a Quality of Service (QoS) and/or a priority associated with the second data-link frame. For example, the XE 440 and/or 450 may send the second data-link frame in accordance with the determined QoS and/or priority.

[0179] In certain representative embodiments, the XE 440 and/or 450 may be a crosshaul adaption unit (XAU) or a crosshaul forwarding element (XFE).

[0180] In certain representative embodiments, the XE 440 and/or 450 may receive the first data-link information over a first link technology via a first ingress port and frame the first data-link information to generate a first data-link frame. For example, the first data-link information may include an encapsulated legacy frame.

[0181] In certain representative embodiments, the XE 440 and/or 450 may receive the first data-link frame over a first link technology via a first ingress port. For example, the first data- link frame may including an encapsulated XCF.

[0182] In certain representative embodiments, the XE 440 and/or 450 may receive rules for processing the XCF and may process the XCF based on the received rules.

[0183] In certain representative embodiments, the XE 440 and/or 450 may generate the XCF using backhaul traffic and/or fronthaul traffic.

[0184] In certain representative embodiments, the XE 440 and/or 450 may send the second data-link frame encapsulating backhaul traffic on condition that backhaul traffic was received in the first data-link frame and may send the second data-link frame encapsulating fronthaul traffic on condition that fronthaul traffic was received in the first data-link frame.

[0185] In certain representative embodiments, the XE 440 and/or 450 may wherein QoS parameters for sending second data-link frame encapsulating backhaul traffic and for sending the second data-link frame encapsulating fronthaul traffic are different. [0186] In certain representative embodiments, the encapsulated XCF in the data-link frames may be Ethernet compatible such that the encapsulated XCF in the data-link frames is ignored by legacy Ethernet switches 430 and 460.

[0187] In certain representative embodiments, the XE 440 and/or 450 may transmit a data frame for backhaul traffic and fronthaul traffic encapsulated in a data-link frame.

[0188] In certain representative embodiments, the crosshaul traffic may include at least one of the backhaul traffic and/or the fronthaul traffic. For example, the data frame may be for crosshaul traffic and the data frame may be a crosshaul traffic data frame in a common-haul frame format that may be Ethernet compatible.

[0189] In certain representative embodiments, the data frame may be received and transmitted by Ethernet switches 460.

[0190] In certain representative embodiments, the common-haul frame format may be a crosshaul common frame (XCF).

[0191] In certain representative embodiments, the XCF may be encapsulated as payload in an Ethernet frame and the XCF may be identified within an Ethernet header.

[0192] In certain representative embodiments, an XCF-capable node 440 and 450 may process the XCF frames and a non-XCF-capable node 430 and 460 may treat the XCF as an Ethernet frame.

[0193] In certain representative embodiments, the crosshaul traffic may be transported in a unified packet switching domain 405 and 1605 across a plurality of data-link transmission technologies 410 and 1610 and 420 and 1620.

[0194] In certain representative embodiments, the XCF header may include at least one of unique identification of XCF routing information, information on payload traffic in the XCF frames, in-band signaling information, retransmission, priority, quality of service (QoS), hop count, fragments, sequence, a unique egress crosshaul forwarding element (XFE) nickname, a unique ingress XFE nickname, a flow, a timestamp and/or a frame check, among others.

[0195] In certain representative embodiments, the traffic data may be encapsulated in XCF format for transport in the XCF domain 405 and 1605.

[0196] In certain representative embodiments, the XCF format may be adapted to transport the XCF via a non-XCF domain 415.

[0197] In certain representative embodiments, the non-XCF may be adapted to transport the non-XCF via an XCF domain 405 and 1605. [0198] In certain representative embodiments, the XCF domain 405 and 1605 may include a plurality of sub-domains 410, 420, 1610, and 1620 such that each sub-domain 410, 420, 1610, and 1620 has its own transmission technology or data-link technology.

[0199] In certain representative embodiments, the XCF format may include one or more of an identification of the traffic class carried in the XCF payload, an identification of the XCF payload format, control information for XCF frame-specific forwarding, QoS fields to prioritize different types of traffic, a counter specific to the avoidance of infinite loops within the XCF domain 405 and 1605, and/or Ingress and Egress nicknames that are unique within the XCF domain 405 and 1605 across multi data-link segments 410, 420, 1610 and 1620.

[0200] In certain representative embodiments, XCF encapsulation in Ethernet frames may include the identification of XCF format in Ethernet through Ethertype.

[0201] In certain representative embodiments, the XCF encapsulation in Ethernet frames may include forwarding in co-existing Ethernet switches 430 and 460 which may follow conventional mechanisms.

[0202] In certain representative embodiments, the XE 440 may forward incoming traffic to another XE 440 based on unique Egress nickname.

[0203] In certain representative embodiments, the XE 440 and/or 450 may preempt an ongoing transmission based on a traffic class and/or a timestamp, for example, to meet latency budget.

[0204] In certain representative embodiments, the XE 440 and/or 450 may drop packets for congestion avoidance based on a traffic class and/or a priority, for example, while fulfilling packet loss ratio.

[0205] In certain representative embodiments, the XE 440 and/or 450 may enforce Packet Delay Variation (PDV) based on the traffic class, a flow ID, and/or a timestamp.

[0206] In certain representative embodiments, the XE 440 and/or 450 may encapsulate a packetized fronthaul protocol data unit or a packetized backhaul protocol data unit directly into an XCF.

[0207] In certain representative embodiments, the packetized fronthaul protocol data unit and the packetized backhaul protocol data unit may be a media access protocol data unit (MPDU).

[0208] In certain representative embodiments, the XE 450 may translate non-packetized fronthaul protocol data or non-packetized backhaul protocol data and may encapsulate the non- packetized fronthaul protocol data or non-packetized backhaul protocol data into an XCF. [0209] In certain representative embodiments, the XE 440 and/or 450 may generate a media access service data unit (MSDU) from the MPDU and aXCF framing/translation protocol data unit (PDU) and may add an XCF header to the MSDU.

[0210] In certain representative embodiments, the XCF may be a data-link layer MSDU.

[0211] In certain representative embodiments, a network controller may generate rules for processing the XCF.

[0212] In certain representative embodiments, the network controller may generate parameters for processing the XCF.

[0213] In certain representative embodiments, the latency and/or PDV may be enforced locally subject to the rules for processing the XCF.

[0214] In certain representative embodiments, a packet loss ratio may be enforced locally subject to the rules for processing the XCF.

[0215] In certain representative embodiments, a latency budget and/or a PDV budget may be associated with the fronthaul traffic and/or the backhaul traffic.

[0216] In certain representative embodiments, a packet loss ratio budget may be associated with the fronthaul traffic and/or backhaul traffic.

[0217] In certain representative embodiments, the network controller may monitor the transport network 402 and 1600 and may know the time required to transmit a frame across or through a domain 405 and 1605.

[0218] In certain representative embodiments, processing rules may be related to the end-to- end path, for example, to enforce local latency and/or PDV.

[0219] In certain representative embodiments, the fronthaul traffic and/or the backhaul traffic may be transmitted on the frequency and/or timeslot with a lowest error probability.

[0220] In certain representative embodiments, the XE 450 may receive a data-link frame including an encapsulated legacy data frame.

[0221] In certain representative embodiments, the XE 450 may process the data-link frame to detect collisions.

[0222] In certain representative embodiments, the XE 450 may map first link frame fields of the data-link frame onto legacy frame fields.

[0223] In certain representative embodiments, the XE 450 may process the legacy frame using legacy protocol operations.

[0224] In certain representative embodiments, the XE 450 may translate the legacy frame into an XCF. [0225] In certain representative embodiments, the XE 450 may receive rules for processing the XCF.

[0226] In certain representative embodiments, the XE 450 may process the XCF based on the received rules.

[0227] In certain representative embodiments, the XE 450 may generate a second data-link frame using the XCF, including mapping the XCF fields onto second data-link frame fields.

[0228] In certain representative embodiments, the XE 450 may transmit the second data-link frame.

[0229] In certain representative embodiments, the XE 440 may receive a data-link frame including an encapsulated XCF.

[0230] In certain representative embodiments, the XE 440 may process the data-link frame to detect collisions.

[0231] In certain representative embodiments, the XE 440 may map first link frame fields of the data-link frame onto XCF fields.

[0232] In certain representative embodiments, the XE 440 may receive rules for processing the XCF.

[0233] In certain representative embodiments, the XE 440 may process the XCF based on the received rules.

[0234] In certain representative embodiments, the XE 440 may generate a second data-link frame using the XCF, including mapping the XCF fields onto second data-link frame fields.

[0235] In certain representative embodiments, the XE 440 may transmit the second data-link frame.

[0236] FIG. 24 is a flowchart illustrating another representative method in a crosshaul entity.

[0237] Referring to FIG. 24, the representative method 2400 may include, at block 2410 the crosshaul entity (XE) 440 and/or 450 that may receive a fronthaul packet, as a first type of packet, or a backhaul packet, as a second type of packet, over a first link technology. At block 2420, the XE 440 and/or 450 may generate a crosshaul common frame (XCF) from the first type of packet or the second type of packet. At block 2430, the XE 440 and/or 450 may select an egress port and a queue, as a combination, based on the type of received packet. At block 2440, the XE 440 and/or 450 may generate a transmit packet to send over a second link technology. For example, the transmit packet may include an encapsulated XCF. At block 2450, the XE 440 and/or 450 may send to another network entity using the selected combination, the transmit packet over the second link technology. [0238] In certain representative embodiments, the selection of the combination may be further based on one or more packet traffic requirements.

[0239] In certain representative embodiments, the one or more packet traffic requirements may include any of: (1) one or more port status requirements or (2) one or more queue status requirements.

[0240] In certain representative embodiments, the one or more packet traffic requirements may include any of: (1) a bandwidth requirement/threshold; (2) a latency requirement/threshold; (3) a jitter requirement/threshold; (4) a bit error rate (BER) requirement/threshold; (5) a packet loss rate requirement/threshold; (6) whether fragmentation is allowed; (7) whether preemption is allowed; or (8) an ordered delivery requirement.

[0241] In certain representative embodiments, the one or more port status requirements may include any of: (1) a Received Signal Strength Indication (RSSI); (2) a Channel Quality Indicator (QCI); (3) a bit error rate; (4) a packet loss rate; (5) an idle/active mode; or (6) a power-save mode.

[0242] In certain representative embodiments, the XE 440 and/or 450 may the one or more queue status requirements may include any of: (1) a buffer occupation; or (2) a transmission rate.

[0243] In certain representative embodiments, the XE 440 and/or 450 may determine whether the combination satisfies the one or more packet traffic requirements; and may send the transmit packet over the second link technology using the combination, on condition that the combination satisfies the one or more packet traffic requirements.

[0244] In certain representative embodiments, the XE 440 and/or 450, on condition that the combination does not satisfy the one or more packet traffic requirements: (1) may determine whether the egress port and a further queue, as a second combination satisfies the one or more packet traffic requirements, (2) on condition that the second combination satisfies the one or more packet traffic requirements, may select the second combination and may send the transmit packet over the second link technology using the second combination.

[0245] In certain representative embodiments, the XE 440 and/or 450, on condition that the egress port and any available further queue do not satisfy the one or more packet traffic requirements: (1) may determine whether a further egress port and a queue, as a third combination satisfies the one or more packet traffic requirements, and (2) on condition that the third combination satisfies the one or more packet traffic requirements, may select the third combination and may send the transmit packet over the second link technology using the third combination.

[0246] In certain representative embodiments, the XE 440 and/or 450 may perform a look-up on fields of the XCF. For example, the fields may include any of (1) a source address, (2) a destination address, (3) a priority field, (4) an Ethertype, (5) a type of payload, (6) a subtype of payload, (7) VLAN tags, (8) a QoS field, (9) a Flow ID, or (10) a Timestamp.

[0247] In certain representative embodiments, the XE 440 and/or 450 may apply matching rules associated with one or more flow tables to one or more of the looked-up fields to determine the selected combination.

[0248] In certain representative embodiments, the XE 440 and/or 450 may determine, for the combination, a buffer occupation of the queue or transmission rate of the queue, may determine whether the packet to be sent over the second link technology can be sent in time to satisfy a latency requirement of the packet, given the determined buffer occupation of the queue or determined transmission rate of the queue, and may select of the combination on condition that the latency requirement is satisfied.

[0249] In certain representative embodiments, the XE 440 and/or 450 may determine, for the combination, a bit error rate (BER) of the egress port, determine whether the packet to be sent over the second link technology can satisfy a BER requirement of the packet, given the BER of the egress port and may select the combination on condition that the BER requirement is satisfied.

[0250] In certain representative embodiments, the XE 440 and/or 450 may generate the XCF using a first data-link frame associated with the first link technology including and/or by: (1) removing a link-specific header of a first data-link frame, and (2) mapping one or more link- specific fields and/or the link-specific header of the first data-link frame to a crosshaul protocol associated with the XCF.

[0251] In certain representative embodiments, the XE 440 and/or 450 may generate a second data-link frame using the XCF including and/or by : (1) adding to the XCF a link-specific header of the second data-link frame for transmission over the second link technology, and (2) mapping one or more XCF fields and/or a XCF header to the second data-link frame in accordance with a second link protocol associated with the second data-link frame

[0252] In certain representative embodiments, the XE 440 and/or 450 may send the second data-link frame including the encapsulated XCF. [0253] In certain representative embodiments, the XE may be a crosshaul adaption unit (XAU) 450 or a crosshaul forwarding element (XFE) 440.

[0254] In certain representative embodiments, the XE 450 may receive first data-link information over the first link technology via a first ingress port, the first data-link information including an encapsulated legacy frame.

[0255] In certain representative embodiments, the encapsulated XCF in the data-link frames may be Ethernet compatible such that the encapsulated XCF in the data-link frames may be ignored by legacy Ethernet switches.

[0256] FIG. 25 is a flowchart illustrating a further representative method in a crosshaul entity.

[0257] Referring to FIG. 25, the representative method 2500 may include, at block 2510 the crosshaul entity (XE) 440 and/or 450 that may receive a fronthaul packet, as a first type of packet, or a backhaul packet, as a second type of packet. At block 2520, the XE 440 and 450 may select an egress port and queue combination based on: (1) the type of received packet and (2) one or more packet traffic requirements. At block 2530, the XE 440 and 450 may send to another network entity, a transmit packet using the selected egress port and queue combination.

[0258] Although features and elements are described 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. In addition, the methods described 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 non- transitory computer-readable storage media include, but are not limited to, a read only memory (ROM), 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 UE, WTRU, terminal, base station, RNC, or any host computer.

[0259] Moreover, in the embodiments described above, processing platforms, computing systems, controllers, and other devices including the constraint server and the rendezvous point/server 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."

[0260] 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 exemplary embodiments are not limited to the above-mentioned platforms or CPUs and that other platforms and CPUs may support the provided methods.

[0261] 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 is understood that the representative embodiments are not limited to the above-mentioned memories and that other platforms and memories may support the described methods.

[0262] 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.

[0263] 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.

[0264] 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. Suitable processors include, by way of example, 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), Application Specific Standard Products (ASSPs); Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), and/or a state machine.

[0265] 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.

[0266] 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, 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 infra; (ii) any of a number of embodiments of a WTRU, such as described infra; (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 infra; (iii) a wireless-capable and/or wired-capable device configured with less than all structures and functionality of a WTRU, such as described infra; or (iv) the like. Details of an example WTRU, which may be representative of any WTRU recited herein.

[0267] In certain representative embodiments, 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.).

[0268] 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 intermediate 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.

[0269] 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.

[0270] 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" or "group" 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.

[0271] 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.

[0272] 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. [0273] 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, [ 6 or means-plus-function claim format, and any claim without the terms "means for" is not so intended.

[0274] A processor in association with software may be used to implement a radio frequency transceiver for use in a wireless transmit receive unit (WTRU), user equipment (UE), terminal, base station, Mobility Management Entity (MME) or Evolved Packet Core (EPC), or any host computer. The WTRU may be used in conjunction with modules, implemented in hardware and/or software including a Software Defined Radio (SDR), and other components such as a camera, a video camera module, a videophone, a speakerphone, a vibration device, a speaker, a microphone, a television transceiver, a hands free headset, a keyboard, a Bluetooth® module, a frequency modulated (FM) radio unit, a Near Field Communication (NFC) Module, a liquid crystal display (LCD) display unit, an organic light-emitting diode (OLED) display unit, a digital music player, a media player, a video game player module, an Internet browser, and/or any Wireless Local Area Network (WLAN) or Ultra Wide Band (UWB) module.

[0275] Although the invention has been described in terms of communication systems, it is contemplated that the systems may be implemented in software on microprocessors/general purpose computers (not shown). In certain embodiments, one or more of the functions of the various components may be implemented in software that controls a general -purpose computer.

[0276] In addition, although the invention is illustrated and described herein with reference to specific embodiments, the invention is not intended to be limited to the details shown. Rather, various modifications may be made in the details within the scope and range of equivalents of the claims and without departing from the invention.