WO2017100394A1 - Procédés et appareil pour transport commun de trafic backhaul et fronthaul - Google Patents

Procédés et appareil pour transport commun de trafic backhaul et fronthaul Download PDF

Info

Publication number
WO2017100394A1
WO2017100394A1 PCT/US2016/065512 US2016065512W WO2017100394A1 WO 2017100394 A1 WO2017100394 A1 WO 2017100394A1 US 2016065512 W US2016065512 W US 2016065512W WO 2017100394 A1 WO2017100394 A1 WO 2017100394A1
Authority
WO
WIPO (PCT)
Prior art keywords
packet
xcf
combination
link
frame
Prior art date
Application number
PCT/US2016/065512
Other languages
English (en)
Inventor
Luca COMINARDI
Alain Mourad
Douglas R. Castor
John D. Kaewell
Original Assignee
Idac Holdings, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Idac Holdings, Inc. filed Critical Idac Holdings, Inc.
Publication of WO2017100394A1 publication Critical patent/WO2017100394A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/24—Multipath
    • H04L45/245—Link aggregation, e.g. trunking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/302—Route determination based on requested QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/302—Route determination based on requested QoS
    • H04L45/306—Route determination based on the nature of the carried application
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/302—Route determination based on requested QoS
    • H04L45/306—Route determination based on the nature of the carried application
    • H04L45/3065—Route determination based on the nature of the carried application for real time traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/64—Routing or path finding of packets in data switching networks using an overlay routing layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/66—Layer 2 routing, e.g. in Ethernet based MAN's
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/70—Routing based on monitoring results
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/22—Traffic shaping
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/32—Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/62—Queue scheduling characterised by scheduling criteria
    • H04L47/625—Queue scheduling characterised by scheduling criteria for service slots or service orders
    • H04L47/6255—Queue scheduling characterised by scheduling criteria for service slots or service orders queue load conditions, e.g. longest queue first
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/25—Routing or path finding in a switch fabric
    • H04L49/253—Routing or path finding in a switch fabric using establishment or release of connections between ports
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/50—Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate

Definitions

  • 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.
  • 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).
  • 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.).
  • 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.
  • a crosshaul forwarding element 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.
  • XCF new transport format
  • 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).
  • 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.
  • 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.
  • PDV Packet Delay Variation
  • 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.
  • 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;
  • WTRU wireless transmit/receive unit
  • 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;
  • XCF crosshaul common frame
  • 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;
  • XAU crosshaul adaptation units
  • 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.
  • FIG. 25 is a flowchart illustrating a further representative method in the XE. DETAILED DESCRIPTION
  • any number of different network architectures and/or network components may be used including networks with wired components and/or wireless components, for example.
  • 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.
  • 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.
  • CDMA code division multiple access
  • TDMA time division multiple access
  • FDMA frequency division multiple access
  • OFDMA orthogonal FDMA
  • SC-FDMA single- carrier FDMA
  • 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.
  • WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment.
  • 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.
  • UE user equipment
  • PDA personal digital assistant
  • smartphone a laptop
  • netbook a personal computer
  • a wireless sensor consumer electronics, and the like.
  • 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.
  • 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.
  • 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.
  • BSC base station controller
  • RNC radio network controller
  • 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.
  • the cell associated with the base station 114a may be divided into three sectors.
  • the base station 114a may include three transceivers, i.e., one for each sector of the cell.
  • the base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell.
  • MIMO multiple-input multiple-output
  • 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).
  • RAT radio access technology
  • 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.
  • 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).
  • 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).
  • E-UTRA Evolved UMTS Terrestrial Radio Access
  • LTE Long Term Evolution
  • LTE- A LTE- Advanced
  • 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.
  • 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 Code Division Multiple Access 2000
  • IS-95 Interim Standard 95
  • IS-856 Interim Standard 856
  • GSM Global System
  • 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.
  • 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).
  • 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).
  • WLAN wireless local area network
  • WPAN wireless personal area network
  • 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.
  • a cellular-based RAT e.g., WCDMA, CDMA2000, GSM, LTE, LTE- A, etc.
  • the base station 114b may have a direct connection to the Internet 110.
  • the base station 114b may not be required to access the Internet 110 via the core network 106.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • POTS plain old telephone service
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. IB is a system diagram illustrating an example WTRU 102.
  • 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.
  • GPS global positioning system
  • 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.
  • 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.
  • a base station e.g., the base station 114a
  • the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals.
  • the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example.
  • 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.
  • 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.
  • 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.
  • 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.
  • the WTRU 102 may have multi-mode capabilities.
  • 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.
  • 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.
  • 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.
  • SIM subscriber identity module
  • SD secure digital
  • 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).
  • 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.
  • 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.
  • dry cell batteries e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.
  • solar cells e.g., solar cells, fuel cells, and the like.
  • 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.
  • location information e.g., longitude and latitude
  • 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.
  • 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.
  • 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.
  • 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
  • FIG. 1C is a system diagram of the RAN 104 and the core network 106 according to an embodiment.
  • 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.
  • 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.
  • the eNode-Bs 140a, 140b, 140c may implement MIMO technology.
  • the eNode-B 140a for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.
  • RAUs radio access units
  • CAUs central access units
  • BBU Baseband Units
  • DUs Data Units
  • 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).
  • a new core network e.g., a 5G network (not shown).
  • 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.
  • 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.
  • MME mobility management entity gateway
  • SGW serving gateway
  • PDN gateway 146 packet datanetwork
  • 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.
  • 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.
  • 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.
  • 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.
  • the core network 106 may facilitate communications with other networks.
  • 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.
  • 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.
  • an IP gateway e.g., an IP multimedia subsystem (IMS) server
  • IMS IP multimedia subsystem
  • 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.
  • 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.
  • KPIs key performance indicators
  • next generation e.g., the fifth generation (5G)
  • 5G fifth generation
  • 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)
  • C-RAN cloud-RAN
  • the unmodified fronthaul domain 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.
  • CPRI common public radio interface
  • MIMO multiple-input multiple-output
  • 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.
  • E2E End-to-End
  • intelligence e.g., processing and/or network functions/ among others
  • the network infrastructure e.g., from one end to another and/or across a portion or all of the network infrastructure.
  • 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).
  • vendor equipment e.g., small cell vendor equipment
  • cooperative radio functions e.g., massive MIMO, coordinated multipoint (COMP) and the like.
  • Modified technology e.g., hardware and/or software
  • 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).
  • SDN software-defined networking
  • 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.
  • RAUs 210 may also be referred to as a remote access units.
  • 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).
  • 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.
  • 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.
  • a converged fronthaul and backhaul under common software defined network/network functions virtualization (SDN/NFV)-based control may be implemented.
  • 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).
  • QoS quality of service
  • methods, apparatus and systems may be implemented for a common-haul packet switching format and operations.
  • 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).
  • 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.
  • a first one of Ethernet header/frame extensions 310 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 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 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 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 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.
  • methods, apparatus and systems are disclosed herein, for example, for a solution that is Ethernet-compatible and that meets common-haul transport QoS requirements.
  • a common packet switching format e.g., an XCF
  • 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).
  • XCF The common frame format
  • the packet switching elements supporting an XCF format may be referred to as crosshaul forwarding elements (XFEs).
  • XFEs crosshaul forwarding elements
  • XAUs Crosshaul Adaptation Units
  • XAUs may be included in the Crosshaul switching network infrastructure to adapt the XCF format to outside (non-XCF) interconnected domains.
  • 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).
  • XFEs XCF-capable nodes
  • 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.
  • 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).
  • 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.
  • 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.
  • 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).
  • multi data-link segments e.g. 802.1 lad segments, and/or optical segments, among others.
  • 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.
  • 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.
  • 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
  • FIG. 4 is a diagram illustrating an example of a transport network infrastructure including an XCF domain.
  • 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.
  • 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.
  • the XAUs 450 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.
  • another segment e.g., a non-XCF domain segment 415.
  • 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 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.
  • 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 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 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.
  • 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.
  • 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.
  • FIG. 5 is a diagram of an example of XCF encapsulation.
  • 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.
  • B/F MPDU packetized B/F media access protocol data unit
  • the B/F module 510 may output a B/F non-packetized stream 514 to the XCF module 520.
  • 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.
  • 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.
  • 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.
  • PDUs protocol data units
  • 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 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).
  • the XCF frame may be a data-link layer MSDU 536.
  • 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.
  • 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.
  • 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 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.
  • 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).
  • the XCF implementation/design may include extension headers.
  • the extension headers may include extended label space for packet tagging, authentication header, and/or encapsulation security header, among others.
  • FIG. 6 is a diagram of an example of an XCF fixed header 600.
  • an example of an XCF header format 610 may include certain defined field including, but are not necessarily limited to any of the following:
  • 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);
  • 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.
  • the Data Type 0x1 : fronthaul.cpri; 0x2: fronthaul.ngfi; 0x10: backhaul. best.effort; 0x11 : backhaul. video. livestream; 0x12: backhaul. voip and the like;
  • FIG. 7 provides an example of a detailed description of the frame control field
  • a retransmission control field that may specify the retransmission policy that may be enforced by the data-link layer
  • a priority field that may specify a priority of the XCF frame (for example, higher values may mean a higher priority);
  • FIG. 8 provides an example of a detailed description of the QoS control field
  • 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);
  • 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);
  • 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;
  • an SDU e.g., an IP SDU, an Ethernet SDU, a NGFI SDU, and/or a CPRI SDU
  • (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;
  • 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;
  • 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;
  • 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));
  • 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
  • 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.
  • a field e.g., a multi-bit and/or 32- bit field
  • CRC cyclic redundancy check
  • FIG. 7 is a diagram of an example of an XCF fixed header frame control field 700.
  • a frame control field format 710 may include, but is not necessarily limited to, any of the following:
  • 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;
  • 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;
  • a logic level e.g., the logic level of 1
  • a XCF data or management type frame e.g., any XCF data or management type frame
  • 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);
  • a logic level e.g., the logic level of 1
  • a threshold e.g., 65,535 octets
  • 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;
  • a logic level e.g., the logic level of 1
  • the XCF data frame e.g., any XCF data frame
  • 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;
  • 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;
  • a logic level e.g., the logic level of 1
  • the XCF data frame e.g., any XCF data frame
  • 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
  • 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.
  • a logic level e.g., the logic level of 1
  • the XCF data frame e.g., any XCF data frame
  • FIG. 8 is a diagram of an example of an XCF fixed header priority and QoS control field.
  • 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 o
  • FIG. 9 is a diagram of XCF extension header exemplary identification tags.
  • 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.
  • a tenant tag that may specify the tenant of the XCF frame in a multi-tenant scenario
  • a service tag that may specify the service of the XCF frame (for example, 0x1 : bulk data transfer);
  • 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.
  • 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.
  • FIG. 10 is a diagram of an example of XCF forwarding procedure 1000 associated with a XFE 440.
  • 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.
  • a link e.g., link 1
  • the XFE 440 may map link 1 specific fields/header to XCF.
  • the XFE 440 may perform ingress and egress processing, for example to enable queue operations and to provide a common switching layer.
  • the XFE 440 may map the XFC to link 2 specific fields/header.
  • the XFE 440 may transmit the XCF frame over a link (e.g., the link 2).
  • an XFE 440, an XAU and/or an Ethernet switch may receive the XCF frame over the link (e.g., the link 2).
  • 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
  • mapping 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.
  • 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).
  • 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).
  • 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
  • the input frame 1160 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.
  • mapping and forwarding operations may include, but are not necessarily limited to, any of the following operation shown in FIGS. 11 A-l ID.
  • 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.
  • 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.
  • 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.
  • 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.
  • ingress processing may specify matching rules using a plurality of flow tables (e.g., Flow Tables 0 ... N) and output port(s).
  • Flow Tables 0 ... N Flow Tables 0 ... N
  • output port(s) e.g., Flow Tables 0 ... N
  • 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.
  • 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.
  • 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).
  • 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).
  • 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.
  • the queue management function may contact the underlying mapping layer.
  • 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.
  • 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).
  • the specific data-link layer frame format e.g., IEEE 802.11
  • 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).
  • FIG. 12 is a diagram of an example of XAU adaptation, encapsulation and forwarding procedure 1200.
  • 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.
  • a legacy device e.g., a legacy remote radio head (RRH), a legacy baseband unit (BBU) and/or a legacy switch
  • the XAU 450 may translate and/or adapt the legacy protocol into XCF.
  • the XAU 450 may perform a forwarding decision using rules, status and/or queue management operations.
  • the XAU 450 may map the XFC to link 2 specific fields/header.
  • the XAU 450 may transmit the XCF frame over the link (e.g., the link 2).
  • an XFE 440, another XAU 450 and/or an Ethernet switch may receive the XCF frame over this link (e.g., the link 2).
  • 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.
  • 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.
  • XCF frame may be passed to the common switching layer at block 1240.
  • 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.
  • 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).
  • 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).
  • 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
  • the input frame 1360 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.
  • FIGS. 13A-13D 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.
  • 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.
  • 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.
  • a data-link header e.g., any eventual data-link header
  • This frame may be passed to the translation/adaptation layer 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.
  • 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.
  • ingress processing may specify matching rules using a plurality of flow tables (e.g., Flow Tables 0 ... N) and output port(s).
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • the queue management function may contact the underlying mapping layer.
  • 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.
  • 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.
  • cross-domain multi -traffic encapsulation and forwarding may be used. This encapsulation and forwarding may be performed as disclosed herein.
  • 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.
  • 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).
  • 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).
  • 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.
  • the output port (e.g., the egress port) may be set to 2 and processing may move to egress processing Flow Table e+1.
  • the packet may be discarded.
  • Flow Table 1 of FIG. 14 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.
  • Egress processing operation 1434 may include Flow Tables e, e+1 to m, among others.
  • an XCF. hop may be set to 1 and processing may move to Flow Table e+1.
  • 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.
  • Flow Table e+1 on condition that: (1) the XCF.
  • the packet may be forwarded to queue 2.
  • the recirculation counter may be incremented and the packet may be sent back to the Flow Table 0 for processing.
  • 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).
  • the controller e.g., network controller.
  • the fronthaul traffic may be further processed in the Flow Table 1 and backhaul traffic may be further processed in the Flow Table 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 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.
  • 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.
  • FIG. 15 is a flow chart illustrating a representative adaptive forwarding procedure similar to FIG. 14.
  • the representative procedure 1500 may include, at block 1510 the XE 440 receiving an incoming packet.
  • the XE 440 and/or 450 may determine whether there is a forwarding rule (e.g., any forwarding rule) successfully matching 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.
  • the XE 440 and/or 450 may discard the packet or may send the packet to a network controller.
  • 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.
  • the XE 440 and/or 450 may send the packet to the selected port and queue.
  • 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.
  • an alternative queue e.g., any queue
  • 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.
  • an alternative port e.g., any alternative port
  • the XE 440 and/or 450 may discard the packet or may send the packet to the network controller.
  • the XE 440 and/or 450 may receive a frame on a given port.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • packet traffic requirements including packet latency and BER, any combination of traffic, port and/or queue status may be used.
  • 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.
  • 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).
  • processing may move to block 1590. Otherwise, processing may move to block 1560.
  • 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.
  • 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.
  • 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.
  • certain (e.g., and not all) ports on a switch e.g., the XE 440 and/or 450
  • 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).
  • 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.
  • 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.
  • the XE 440 and/or 450 may send the packet to the selected port and queue (e.g., that meets the packet traffic requirements).
  • FIGS. 16-22 are diagrams illustrating representative encapsulation and forwarding operations using a representative network 1600.
  • 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.
  • WTRUs 102 e.g., UE-1, UE-2 and UE-3
  • RAUs 210-1 and 210-2 e.g., RAU-1 and RAU-2
  • DSLAMs Digital Subscriber Line Access Multiplexers
  • OFTMs Optical Terminal Multiplexers
  • 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).
  • 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.
  • 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.
  • 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 ® .
  • 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.
  • fronthaul traffic ® may be a priority (e.g., a high priority) traffic in terms of the latency and/or the PDV.
  • the WTRU 102 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.
  • 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.
  • the UE-2 102 may be performing a backup of the mobile phone apps on a remote server.
  • 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.
  • WTRU 102 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 @.
  • 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.
  • the backhaul traffic @ may be a medium priority traffic in terms of latency, PDV and/or packet loss ratio.
  • 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
  • XCF Options XCF Opt
  • the traffic flows may be encapsulated and forwarded as follows.
  • the network controller 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the network controller may configure, on the XAU-
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 18 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • FIG. 19 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 20 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.
  • 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.
  • 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.
  • 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.
  • FIG. 21 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.
  • 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 ( ⁇ ).
  • 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.
  • Core Network protocols e.g., IP/MPLS
  • 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.
  • FIG. 22 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.
  • 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 ( ⁇ ).
  • 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 ⁇ .
  • 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 ⁇ .
  • FIG. 23 is a flowchart illustrating a representative method in a crosshaul entity.
  • 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.
  • 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.
  • 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
  • the crosshaul entity 440 and/or 450 may generate the second data-link frame using the XCF.
  • 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.
  • 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.
  • the XE 440 and/or 450 may receive the first data-link frame over a first link technology via a first ingress port.
  • the first data- link frame may include an encapsulated legacy frame.
  • 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.
  • 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.
  • 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.
  • QoS Quality of Service
  • the XE 440 and/or 450 may send the second data-link frame in accordance with the determined QoS and/or priority.
  • the XE 440 and/or 450 may be a crosshaul adaption unit (XAU) or a crosshaul forwarding element (XFE).
  • XAU crosshaul adaption unit
  • XFE crosshaul forwarding element
  • 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.
  • the first data-link information may include an encapsulated legacy frame.
  • the XE 440 and/or 450 may receive the first data-link frame over a first link technology via a first ingress port.
  • the first data- link frame may including an encapsulated XCF.
  • the XE 440 and/or 450 may receive rules for processing the XCF and may process the XCF based on the received rules.
  • the XE 440 and/or 450 may generate the XCF using backhaul traffic and/or fronthaul traffic.
  • 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.
  • 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.
  • 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.
  • the XE 440 and/or 450 may transmit a data frame for backhaul traffic and fronthaul traffic encapsulated in a data-link frame.
  • the crosshaul traffic may include at least one of the backhaul traffic and/or the fronthaul traffic.
  • 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.
  • the data frame may be received and transmitted by Ethernet switches 460.
  • the common-haul frame format may be a crosshaul common frame (XCF).
  • the XCF may be encapsulated as payload in an Ethernet frame and the XCF may be identified within an Ethernet header.
  • 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.
  • 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.
  • 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.
  • unique identification of XCF routing information information on payload traffic in the XCF frames
  • in-band signaling information retransmission
  • priority quality of service
  • QoS quality of service
  • hop count fragments
  • sequence 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.
  • the traffic data may be encapsulated in XCF format for transport in the XCF domain 405 and 1605.
  • the XCF format may be adapted to transport the XCF via a non-XCF domain 415.
  • the non-XCF may be adapted to transport the non-XCF via an XCF domain 405 and 1605.
  • 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.
  • 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.
  • XCF encapsulation in Ethernet frames may include the identification of XCF format in Ethernet through Ethertype.
  • the XCF encapsulation in Ethernet frames may include forwarding in co-existing Ethernet switches 430 and 460 which may follow conventional mechanisms.
  • the XE 440 may forward incoming traffic to another XE 440 based on unique Egress nickname.
  • 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.
  • 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.
  • the XE 440 and/or 450 may enforce Packet Delay Variation (PDV) based on the traffic class, a flow ID, and/or a timestamp.
  • PDV Packet Delay Variation
  • 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.
  • the packetized fronthaul protocol data unit and the packetized backhaul protocol data unit may be a media access protocol data unit (MPDU).
  • MPDU media access protocol data unit
  • 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.
  • 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.
  • MSDU media access service data unit
  • PDU framing/translation protocol data unit
  • the XCF may be a data-link layer MSDU.
  • a network controller may generate rules for processing the XCF.
  • the network controller may generate parameters for processing the XCF.
  • the latency and/or PDV may be enforced locally subject to the rules for processing the XCF.
  • a packet loss ratio may be enforced locally subject to the rules for processing the XCF.
  • a latency budget and/or a PDV budget may be associated with the fronthaul traffic and/or the backhaul traffic.
  • a packet loss ratio budget may be associated with the fronthaul traffic and/or backhaul traffic.
  • 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.
  • processing rules may be related to the end-to- end path, for example, to enforce local latency and/or PDV.
  • the fronthaul traffic and/or the backhaul traffic may be transmitted on the frequency and/or timeslot with a lowest error probability.
  • the XE 450 may receive a data-link frame including an encapsulated legacy data frame.
  • the XE 450 may process the data-link frame to detect collisions.
  • the XE 450 may map first link frame fields of the data-link frame onto legacy frame fields.
  • the XE 450 may process the legacy frame using legacy protocol operations.
  • 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.
  • the XE 450 may process the XCF based on the received rules.
  • the XE 450 may generate a second data-link frame using the XCF, including mapping the XCF fields onto second data-link frame fields.
  • the XE 450 may transmit the second data-link frame.
  • the XE 440 may receive a data-link frame including an encapsulated XCF.
  • the XE 440 may process the data-link frame to detect collisions.
  • the XE 440 may map first link frame fields of the data-link frame onto XCF fields.
  • the XE 440 may receive rules for processing the XCF.
  • the XE 440 may process the XCF based on the received rules.
  • the XE 440 may generate a second data-link frame using the XCF, including mapping the XCF fields onto second data-link frame fields.
  • the XE 440 may transmit the second data-link frame.
  • FIG. 24 is a flowchart illustrating another representative method in a crosshaul entity.
  • 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.
  • 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.
  • the XE 440 and/or 450 may select an egress port and a queue, as a combination, based on the type of received packet.
  • the XE 440 and/or 450 may generate a transmit packet to send over a second link technology.
  • the transmit packet may include an encapsulated XCF.
  • the XE 440 and/or 450 may send to another network entity using the selected combination, the transmit packet over the second link technology.
  • the selection of the combination may be further based on one or more packet traffic requirements.
  • 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.
  • 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.
  • a bandwidth requirement/threshold 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.
  • BER bit error rate
  • 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.
  • RSSI Received Signal Strength Indication
  • QCI Channel Quality Indicator
  • 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.
  • 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.
  • 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.
  • 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.
  • the XE 440 and/or 450 may perform a look-up on fields of the XCF.
  • 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.
  • 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.
  • 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.
  • 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.
  • BER bit error rate
  • 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.
  • 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
  • the XE 440 and/or 450 may send the second data-link frame including the encapsulated XCF.
  • the XE may be a crosshaul adaption unit (XAU) 450 or a crosshaul forwarding element (XFE) 440.
  • 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.
  • 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.
  • FIG. 25 is a flowchart illustrating a further representative method in a crosshaul entity.
  • 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.
  • 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.
  • the XE 440 and 450 may send to another network entity, a transmit packet using the selected egress port and queue combination.
  • ROM read only memory
  • RAM random access memory
  • 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.
  • 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.
  • CPU Central Processing Unit
  • FIG. 1 A block diagram illustrating an exemplary computing system
  • FIG. 1 A block diagram illustrating an exemplary computing system
  • FIG. 1 A block diagram illustrating an exemplary computing system
  • FIG. 1 A block diagram illustrating an exemplary computing systems, controllers, and other devices including the constraint server and the rendezvous point/server containing processors.
  • CPU Central Processing Unit
  • 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.
  • 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.
  • RAM Random Access Memory
  • ROM Read-Only Memory
  • 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.
  • 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.
  • 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.
  • DSP digital signal processor
  • ASICs Application Specific Integrated Circuits
  • ASSPs Application Specific Standard Products
  • FPGAs Field Programmable Gate Arrays
  • 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.
  • ASICs Application Specific Integrated Circuits
  • FPGAs Field Programmable Gate Arrays
  • DSPs digital signal processors
  • a signal bearing medium examples 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.).
  • 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.
  • 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.).
  • 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.
  • 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.
  • the phrase “A or B” will be understood to include the possibilities of “A” or “B” or “A and B.”
  • 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.
  • the term “set” or “group” is intended to include any number of items, including zero.
  • the term “number” is intended to include any number, including zero.
  • a range includes each individual member.
  • a group having 1-3 cells refers to groups having 1, 2, or 3 cells.
  • a group having 1-5 cells refers to groups having 1, 2, 3, 4, or 5 cells, and so forth.
  • 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.
  • WTRU wireless transmit receive unit
  • UE user equipment
  • MME Mobility Management Entity
  • EPC Evolved Packet Core
  • 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.
  • SDR Software Defined Radio
  • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

La présente invention concerne des procédés et des systèmes pour le transport commun de trafic backhaul et fronthaul. Une entité crosshaul (XE) peut comprendre un élément d'acheminement crosshaul (XFE) ou une unité d'adaptation crosshaul (XAU). Le XFE peut recevoir une trame de liaison de données (DLF) comprenant une trame commune crosshaul (XCF) encapsulée. Le XFE peut traiter la DLF en vue de détecter des collisions et de mapper des premiers champs de trame de liaison de la DLF sur des champs XCF. Le XFE peut recevoir des règles de traitement de la XCF. Ces règles peuvent être transmises au moyen d'un contrôleur de réseau. La XFE peut traiter la XCF sur la base des règles reçues. En outre, la XFE peut générer une seconde DLF au moyen de la XCF, consistant à mapper les champs XCF sur des seconds champs DLF. Le XFE peut ajouter un en-tête XCF à la XCF. Le XFE peut transmettre la seconde DLF. La XAU peut traduire une trame patrimoniale en une XCF.
PCT/US2016/065512 2015-12-11 2016-12-08 Procédés et appareil pour transport commun de trafic backhaul et fronthaul WO2017100394A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201562266363P 2015-12-11 2015-12-11
US62/266,363 2015-12-11

Publications (1)

Publication Number Publication Date
WO2017100394A1 true WO2017100394A1 (fr) 2017-06-15

Family

ID=57614481

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2016/065512 WO2017100394A1 (fr) 2015-12-11 2016-12-08 Procédés et appareil pour transport commun de trafic backhaul et fronthaul

Country Status (1)

Country Link
WO (1) WO2017100394A1 (fr)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019083097A1 (fr) * 2017-10-25 2019-05-02 에스케이텔레콤 주식회사 Appareil de station de base et procédé de transmission de paquets de données
CN111247831A (zh) * 2017-10-16 2020-06-05 三星电子株式会社 用于在无线通信系统中改进前传接口的方法和装置
WO2020151802A1 (fr) * 2019-01-21 2020-07-30 Telefonaktiebolaget Lm Ericsson (Publ) Procédés et appareils de dépôt de paquets dans un réseau de fronthaul
JP2021505020A (ja) * 2017-11-29 2021-02-15 ホアウェイ・テクノロジーズ・カンパニー・リミテッド フレーム集約方法、ネットワーク設定フレーム送信方法およびデバイス
CN112822569A (zh) * 2019-11-15 2021-05-18 中国移动通信有限公司研究院 一种监控处理方法及设备
WO2022100373A1 (fr) * 2020-11-11 2022-05-19 中兴通讯股份有限公司 Procédé de liaison terrestre sans fil, dispositif associé, dispositif d'accès et support de stockage lisible par ordinateur
CN114731287A (zh) * 2019-12-05 2022-07-08 三菱重工业株式会社 通信处理装置、通信处理方法及程序以及网络层的头部的数据结构
WO2022169530A1 (fr) * 2021-02-03 2022-08-11 Qualcomm Incorporated Communications sans fil à base de groupes
CN114731287B (zh) * 2019-12-05 2024-05-31 三菱重工业株式会社 通信处理装置、通信处理方法及程序以及网络层的头部的数据结构

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6430188B1 (en) * 1998-07-08 2002-08-06 Broadcom Corporation Unified table for L2, L3, L4, switching and filtering
GB2404826A (en) * 2003-08-01 2005-02-09 Motorola Inc Packet router which re-routes packet to an alternative output port when the primary output port buffer is overloaded
US20070058632A1 (en) * 2005-09-12 2007-03-15 Jonathan Back Packet flow bifurcation and analysis
US20130329633A1 (en) * 2012-06-10 2013-12-12 Cisco Technology, Inc. System and method for transporting digital baseband streams in a network environment

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6430188B1 (en) * 1998-07-08 2002-08-06 Broadcom Corporation Unified table for L2, L3, L4, switching and filtering
GB2404826A (en) * 2003-08-01 2005-02-09 Motorola Inc Packet router which re-routes packet to an alternative output port when the primary output port buffer is overloaded
US20070058632A1 (en) * 2005-09-12 2007-03-15 Jonathan Back Packet flow bifurcation and analysis
US20130329633A1 (en) * 2012-06-10 2013-12-12 Cisco Technology, Inc. System and method for transporting digital baseband streams in a network environment

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ALEKSANDRA CHECKO ET AL: "Cloud RAN for Mobile Networks -a Technology Overview", IEEE COMMUNICATIONS SURVEYS, 31 October 2014 (2014-10-31), http://orbit.dtu.dk/en/publications/cloud-ran-for-mobile-networks--a-technology-overview%2893ef1d01-38a8-4a66-b6da-009789a8b9f1%29.html, XP055203271, DOI: 10.1109/COMST.2014.2355255 *

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111247831A (zh) * 2017-10-16 2020-06-05 三星电子株式会社 用于在无线通信系统中改进前传接口的方法和装置
CN111247831B (zh) * 2017-10-16 2023-04-07 三星电子株式会社 用于在无线通信系统中改进前传接口的方法和装置
US11419180B2 (en) 2017-10-25 2022-08-16 Sk Telecom Co., Ltd. Base station apparatus and data packet transmission method
CN111133792A (zh) * 2017-10-25 2020-05-08 Sk电信有限公司 基站设备和数据分组发送方法
CN111133792B (zh) * 2017-10-25 2023-09-19 Sk电信有限公司 基站设备和数据分组发送方法
WO2019083097A1 (fr) * 2017-10-25 2019-05-02 에스케이텔레콤 주식회사 Appareil de station de base et procédé de transmission de paquets de données
JP2021505020A (ja) * 2017-11-29 2021-02-15 ホアウェイ・テクノロジーズ・カンパニー・リミテッド フレーム集約方法、ネットワーク設定フレーム送信方法およびデバイス
US11272396B2 (en) 2017-11-29 2022-03-08 Huawei Technologies Co., Ltd. Frame aggregation method, network setting frame sending method, and device
JP7040734B2 (ja) 2017-11-29 2022-03-23 ホアウェイ・テクノロジーズ・カンパニー・リミテッド フレーム集約方法、ネットワーク設定フレーム送信方法およびデバイス
EP3703316A4 (fr) * 2017-11-29 2021-03-31 Huawei Technologies Co., Ltd. Procédé d'agrégation de trame, procédé d'envoi de trame de configuration de réseau, et dispositif
WO2020151802A1 (fr) * 2019-01-21 2020-07-30 Telefonaktiebolaget Lm Ericsson (Publ) Procédés et appareils de dépôt de paquets dans un réseau de fronthaul
US11956155B2 (en) 2019-01-21 2024-04-09 Telefonaktiebolaget Lm Ericsson (Publ) Methods and apparatus for packet dropping in a fronthaul network
CN112822569A (zh) * 2019-11-15 2021-05-18 中国移动通信有限公司研究院 一种监控处理方法及设备
CN112822569B (zh) * 2019-11-15 2023-08-15 中国移动通信有限公司研究院 一种监控处理方法及设备
CN114731287A (zh) * 2019-12-05 2022-07-08 三菱重工业株式会社 通信处理装置、通信处理方法及程序以及网络层的头部的数据结构
CN114731287B (zh) * 2019-12-05 2024-05-31 三菱重工业株式会社 通信处理装置、通信处理方法及程序以及网络层的头部的数据结构
WO2022100373A1 (fr) * 2020-11-11 2022-05-19 中兴通讯股份有限公司 Procédé de liaison terrestre sans fil, dispositif associé, dispositif d'accès et support de stockage lisible par ordinateur
WO2022169530A1 (fr) * 2021-02-03 2022-08-11 Qualcomm Incorporated Communications sans fil à base de groupes

Similar Documents

Publication Publication Date Title
RU2693859C1 (ru) Эффективные механизмы планирования восходящей линии связи для двойного соединения
WO2017100394A1 (fr) Procédés et appareil pour transport commun de trafic backhaul et fronthaul
US11374871B2 (en) System and method for dynamic bandwidth adjustments for cellular interfaces in a network environment
CN105706415B (zh) 针对实时视频应用的用于路由器的基于体验质量的队列管理
CN112368980B (zh) 用于将一个或多个在网业务添加到mpls网络中的方法
US11159423B2 (en) Techniques for efficient multipath transmission
US10420134B2 (en) System and method to facilitate subframe scheduling in a split medium access control radio access network environment
EP3586489B1 (fr) Procédés et éléments de réseau pour un contrôle multi-connectivité
US20150229970A1 (en) Methods and systems for packet differentiation
US20190075438A1 (en) Methods and apparatuses for enabling physical layer sharing among multiple wireless communication entities
EP3915298B1 (fr) Procédés et appareil de transmission de données radio sur un réseau fronthaul
WO2013144747A1 (fr) Mise en œuvre d'epc dans un ordinateur en nuage à plan de données openflow
US11558778B2 (en) Techniques for file aware communications
WO2020159847A1 (fr) Établissement de liaison entre un dispositif de commande d'équipement radio (rec) et un équipement radio (re) dans un réseau de type fronthaul
EP2530990B1 (fr) Entrelacement de paquets audio et vidéo
KR102267116B1 (ko) 패킷 전송 방법, 프록시 서버 및 컴퓨터 판독가능 저장 매체
WO2016074211A1 (fr) Procédé d'envoi de données et contrôleur
EP3252978A1 (fr) Dispositifs, procédés et programmes informatiques permettant de transmettre ou de recevoir des données de charge utile et des données de récupération de charge utile
WO2018106868A1 (fr) Découpage de ressources de commutateur en tranches
WO2017147076A1 (fr) Procédés, appareils et systèmes destinés au transport commun de trafic backhaul et fronthaul
US11234163B1 (en) Dynamic eCPRI header compression
US20240056885A1 (en) Multi-access traffic management
WO2017172681A1 (fr) Atténuation de calculs crc dans des réseaux à routage de segments

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16819248

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16819248

Country of ref document: EP

Kind code of ref document: A1