TW201739215A - Methods, apparatuses and systems directed to common transport of backhaul and fronthaul traffic - Google Patents

Abstract

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

Description

Traffic sharing transmission method, device and system for returning and forward return

Cross-reference to related applications

This application claims the benefit of U.S. Provisional Patent Application No. 62/298,428, filed on Feb. 22, 2016, and U.S. Provisional Patent Application No. 62/298,449, filed on Feb. 22, 2016, each of which is hereby All are incorporated by reference.

This application relates to wired and/or wireless communications.

For next-generation communication systems, such as fifth-generation (5G) communication systems, the goal is to achieve a set of ambitious key performance indicators (KPi) such as capacity, latency and/or efficiency, while Road operators are also faced with the challenge of reducing their costs (such as total cost of ownership) and expanding their service offerings. Current Radio Access Network (RAN) architectures, including Cloud RAN (C-RAN), are cost prohibitive and are not necessarily suitable for effectively meeting 5G requirements. Unmodified forward backhaul domains (starting with C-RAN) may include deterministic bandwidth hunger-to-peer links, such as the Common Public Radio Interface (CPRI) on fiber, which is too costly It is not scalable for high-density processing where large scale is expected in 5G, such as small cells and multiple input multiple output (MIMO) technology.

On the other hand, with the emergence of increasingly heterogeneous and independently managed technologies, the complexity of the reloading domain continues to grow, and as a result, its cost is also increasing, and this also presents a challenge, that is, to meet Strict end-to-end (E2E) latency requirements in 5G. There are currently methods for evolving forward backhaul and backhaul, such as CPRI for Ethernet on forward backhaul, such as the newly released standard IEEE 1904.3, and the software-defined network (SDN) in the backhaul. And/or Network Function Virtualization (NFV) enforceability.

Numerous specific details are set forth in the Detailed Description of the <RTIgt; It should be understood, however, that such embodiments and examples may be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, procedures, components, and circuits have not been described in detail to avoid obscuring the description. Further, the embodiments and examples not specifically described herein are also practiced, and thus the implementations described, disclosed, or otherwise disclosed, implicitly, and/or inherently (collectively referred to as "providing") may be substituted. Examples and other examples or combined with them. Example communication system

The methods, apparatus, and systems provided herein are well suited for communication involving both wired and wireless networks. Wired networks are well known. An overview of various types of wireless devices and infrastructure is provided in connection with Figures 1A through 1E, in which various elements of the network may be used to perform the methods, apparatus, and systems provided herein, in accordance with the methods and apparatus provided herein. And systems are arranged, and/or adapted and/or configured for use in the methods, apparatus, and systems provided herein.

FIG. 1A is a diagram of an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The example communication system 100 is provided for illustrative purposes only and is not limited to the disclosed embodiments. Communication system 100 can be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communication system 100 allows multiple wireless users to access such content by sharing system resources including wireless bandwidth. As an example, communication system 100 may use 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.

As shown in FIG. 1A, communication system 100 can include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, radio access network (RAN) 104, core network 106, public switched telephone network (PSTN). 108, the Internet 110 and other networks 112, but it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. For example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals, and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, pagers, mobile phones, personal digital assistants. (PDA), smart phones, laptops, small laptops, personal computers, wireless sensors, consumer electronics, and more.

Communication system 100 can 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 facilitate access to one or more communication networks by having a wireless interface with at least one of the WTRUs 102a, 102b, 102c, 102d, the network then It can be core network 106, internet 110, and/or network 112. As an example, base stations 114a, 114b may be base transceiver stations (BTS), Node Bs, eNodeBs, local Node Bs, local eNodeBs, website controllers, access points (APs), wireless routers, and the like. While each of the base stations 114a, 114b is depicted as a single component, it should be understood that the base stations 114a, 114b can include any number of interconnected base stations and/or network elements.

The base station 114a may be part of the RAN 104, and the RAN may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay. Nodes and so on. Base station 114a and/or base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic area known as a cell (not shown). The cell can be further divided into cell sectors. For example, a cell associated with base station 114a can be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, that is, one for each sector of the cell. In another embodiment, base station 114a may use multiple input multiple output (MIMO) technology whereby multiple transceivers may be used for each sector in a cell.

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

More specifically, as noted above, communication system 100 can be a multiple access system and can utilize one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, base station 114a and WTRUs 102a, 102b, 102c in RAN 104 may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) An empty mediation plane 116 is created. WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA can include High Speed Downlink Packet Access (HSDPA) and/or High Speed Uplink Packet Access (HSUPA).

In another embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may use Long Term Evolution (LTE) and/or Advanced LTE (LTE-A) is used to establish an empty intermediate plane 116.

In other embodiments, base station 114a and WTRUs 102a, 102b, 102c may implement IEEE 802.16 (Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Radio Access Technology for GSM Enhanced Data Rate Evolution (EDGE), GSM EDGE (GERAN).

As an example, base station 114b in FIG. 1A may be a wireless router, a local Node B, a local eNodeB, or an access point, and any suitable RAT may be used to facilitate wireless connectivity in a local area, such as a business location, residential , vehicles, campuses, etc. In one embodiment, base station 114b and WTRUs 102c, 102d may establish a wireless local area network (WLAN) by implementing a radio technology such as IEEE 802.11. In another embodiment, base station 114b and WTRUs 102c, 102d may establish a wireless personal area network (WPAN) by implementing a radio technology such as IEEE 802.15. In still another embodiment, base station 114b and WTRUs 102c, 102d may establish picocells or femtocells by using a cell based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.). As shown in FIG. 1A, the base station 114b can be directly connected to the Internet 110. Thus, the base station 114b does not necessarily need to access the Internet 110 via the core network 106.

The RAN 104 can be in communication with a core network 106, which can be configured to provide voice, data, application, and/or internet protocol voice to one or more of the WTRUs 102a, 102b, 102c, 102d ( VoIP) Any type of network that serves. For example, core network 106 may provide call control, billing services, action location based services, prepaid calling, internet connectivity, video distribution, etc., and/or perform advanced security functions such as user authentication. Although not shown in FIG. 1A, it should be appreciated that the RAN 104 and/or the core network 106 can communicate directly or indirectly with other RANs that use the same RAT or different RATs as the RAN 104. For example, in addition to being connected to the RAN 104 using the E-UTRA radio technology, the core network 106 can also communicate with another RAN (not shown) that uses the GSM radio technology.

The core network 106 can 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 a circuit switched telephone network that provides Plain Old Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use a shared communication protocol, which may be a Transmission Control Protocol (TCP), User Data Packet Protocol (UDP) in the TCP/IP Internet Protocol suite. ) and Internet Protocol (IP). Network 112 may include a wired or wireless communication network that is owned and/or operated by other service providers. For example, network 112 may include another core network connected to one or more RANs that may use the same RAT or a different RAT as RAN 104.

Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities, in other words, the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers that communicate with different wireless networks over different wireless links. . For example, the WTRU 102c shown in FIG. 1A can be configured to communicate with a base station 114a that uses a cell-based radio technology, and with a base station 114b that can use an IEEE 802 radio technology.

FIG. 1B is a system diagram of an example WTRU 102. The example WTRU 102 is provided for purposes of example and is not intended to limit the disclosed embodiments. As shown in FIG. 1B, 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/trackpad 128, a non-removable memory 130, and a removable Memory 132, power source 134, global positioning system (GPS) chipset 136, and other peripheral devices 138. It should be appreciated that the WTRU 102 may also include any sub-combination of the aforementioned elements while remaining consistent with the embodiments.

The processor 118 can 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 associated with the DSP core, a controller, a microcontroller , Dedicated Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA) circuits, any other type of integrated circuit (IC), state machine, and more. The processor 118 can perform signal encoding, 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 can be coupled to a transceiver 120 that can be coupled to the transmit/receive element 122. Although FIG. 1B depicts processor 118 and transceiver 120 as separate components, it should be understood that processor 118 and transceiver 120 can be integrated into one electronic component or wafer.

The transmit/receive element 122 can be configured to transmit signals to the base station (e.g., base station 114a) or receive signals from the base station (e.g., base station 114a) via the null plane 116. For example, in one embodiment, the transmit/receive element 122 can be an antenna configured to transmit and/or receive RF signals. In another embodiment, as an example, the transmit/receive element 122 can be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals. In still another embodiment, the transmit/receive element 122 can be configured to transmit and receive RF and optical signals. It should be appreciated that the transmit/receive element 122 can be configured to transmit and/or receive any combination of wireless signals.

Moreover, although the transmit/receive element 122 is depicted as a single element in FIG. 1B, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may use MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmission/reception elements 122 (e.g., multiple antennas) that transmit and receive wireless signals via the null intermediaries 116.

The transceiver 120 can be configured to modulate the signals to be transmitted by the transmitting/receiving element 122 and to demodulate the signals received by the transmitting/receiving elements 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, transceiver 120 may include multiple transceivers that allow WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11.

The processor 118 of the WTRU 102 may be coupled to a speaker/microphone 124, a keypad 126, and/or a display/touchpad 128 (eg, a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit), and may User input data from speaker/microphone 124, keypad 126, and/or display/touchpad 128 (eg, a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit) is received. The processor 118 can also output user profiles to the speaker/microphone 124, the keypad 126, and/or the display/trackpad 128. In addition, processor 118 can access signals from any suitable memory (e.g., non-removable memory 130 and/or removable memory 132) and store the information in these memories. The non-removable memory 130 can include random access memory (RAM), read only memory (ROM), hard disk, or any other type of memory storage device. The removable memory 132 can include a Subscriber Identity Module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from memory that is not physically located in the WTRU 102 and store the data in the memory (eg, at a server or local computer (not shown)).

The processor 118 can receive power from the power source 134 and can be configured to distribute and/or control power for other components in the WTRU 102. Power source 134 may be any suitable device that powers WTRU 102. For example, the power source 134 may include one or more dry battery packs (such as nickel-cadmium (Ni-Cd), nickel-zinc (Ni-Zn), nickel-hydrogen (NiMH), lithium-ion (Li-ion), etc., solar energy Batteries, fuel cells, etc.

The processor 118 can also be coupled to a GPS chipset 136 that can be configured to provide location information (e.g., longitude and latitude) related to the current location of the WTRU 102. The WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) plus or in place of GPS chipset 136 information via null intermediaries 116, and/or based on signal timing received from two or more nearby base stations. To determine its location. It should be appreciated that the WTRU 102 may obtain location information by any suitable positioning method while remaining consistent with the embodiments.

The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and/or hardware modules that provide additional features, functionality, and/or wired or wireless connections. For example, peripheral device 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photo or video), a universal serial bus (USB) port, a vibrating device, a television transceiver, a hands-free headset, a Bluetooth® mode. Group, FM radio unit, digital music player, media player, video game console module, internet browser, etc.

1C is a system diagram of RAN 104 and core network 106, in accordance with one embodiment. As described above, the RAN 104 can communicate with the WTRUs 102a, 102b, 102c via the null plane 116 using UTRA radio technology. The RAN 104 can also communicate with the core network 106. As shown in FIG. 1C, RAN 104 may include Node Bs 140a, 140b, 140c, each of which may include one or more transceivers in communication with WTRUs 102a, 102b, 102c via null intermediaries 116. Each of the Node Bs 140a, 140b, 140c may be associated with a particular cell (not shown) internal to the RAN 104. The RAN 104 may also include RNCs 142a, 142b. It should be appreciated that the RAN 104 may include any number of Node Bs and RNCs while remaining consistent with the embodiments.

As shown in FIG. 1C, Node Bs 140a, 140b can communicate with RNC 142a. Additionally, Node B 140c can communicate with RNC 142b. Node Bs 140a, 140b, 140c may communicate with respective RNCs 142a, 142b via an Iub interface. The RNCs 142a, 142b can communicate with each other via the Iur interface. Each of the RNCs 142a, 142b can be configured to control the respective Node Bs 140a, 140b, 140c to which it is connected. In addition, each of the RNCs 142a, 142b can be configured to perform or support other functions, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, and the like. .

The core network 106 shown in FIG. 1C may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and/or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements is described as being part of the core network 106, it should be understood that other entities other than the core network operator may also own and/or operate any of these elements.

The RNC 142a in the RAN 104 can be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 can then be connected to the MGW 144. MSC 146 and MGW 144 may provide WTRUs 102a, 102b, 102c with access to circuit switched networks such as PSTN 108 to facilitate communication between WTRUs 102a, 102b, 102c and conventional landline communication devices.

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

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

FIG. 1D is a system diagram of RAN 104 and core network 106 in accordance with another embodiment. As described above, the RAN 104 can communicate with the WTRUs 102a, 102b, 102c via the null plane 116 using E-UTRA radio technology. In addition, the RAN 104 can also communicate with the core network 106.

The RAN 104 may include eNodeBs 160a, 160b, and 160c, but it should be appreciated that the RAN 104 may include any number of eNodeBs while remaining consistent with the embodiments. Each eNodeB 160a, 160b, and 160c may include one or more transceivers to communicate with the WTRUs 102a, 102b, 102c via the null plane 116. In one embodiment, the eNodeBs 160a, 160b, 160c may implement MIMO technology. Thus, for example, eNodeB 160a may use multiple antennas to transmit wireless signals to, and receive wireless signals from, WTRU 102a.

Each eNodeB 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in the uplink and/or downlink, etc. . As shown in FIG. 1D, the eNodeBs 160a, 160b, 160c can communicate with each other on the X2 interface.

The core network 106 shown in FIG. 1D may include an active management gateway (MME) 162, a service gateway 164, and a packet data network (PDN) gateway 166. While each of the above elements is described as being part of the core network 106, it should be understood that other entities than the core network operator may also own and/or operate any of these elements.

The MME 162 may be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via an S1 interface and may act as a control node. For example, MME 162 may be responsible for authenticating the users of WTRUs 102a, 102b, 102c, initiating/deactivating bearers, selecting special service gateways during initial attachment of WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide control plane functionality to perform handover between the RAN 104 and other RANs (not shown) that employ other radio technologies such as GSM or WCDMA.

Service gateway 164 may be connected to each of eNodeBs 160a, 160b, 160c in RAN 104 via an S1 interface. The service gateway 164 can typically route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The service gateway 164 may also perform other functions, such as anchoring the user plane during handover between eNodeBs, and triggering paging, management, and storage of the WTRUs 102a, 102b, 102c when the downlink information is available to the WTRUs 102a, 102b, 102c Context and so on.

The service gateway 164 can also be coupled to a PDN gateway 166 that can provide the WTRUs 102a, 102b, 102c with access to a packet switched network, such as the Internet 110, to facilitate the WTRUs 102a, 102b, Communication between 102c and the IP-enabled device.

The core network 106 can facilitate communication with other networks. For example, core network 106 may provide WTRUs 102a, 102b, 102c with access to circuit-switched networks such as PSTN 108 to facilitate communication between WTRUs 102a, 102b, 102c and conventional landline communication devices. As an example, core network 106 may include or be in communication with an IP gateway, such as an IP Multimedia Subsystem (IMS) server, where the IP gateway acts as an interface between core network 106 and PSTN 108. In addition, core network 106 may also provide WTRUs 102a, 102b, 102c with access to network 112, which may include other wired or wireless networks owned and/or operated by other service providers.

FIG. 1E is a system diagram of RAN 104 and core network 106 in accordance with another embodiment. The RAN 104 may be an Access Service Network (ASN) that communicates with the WTRUs 102a, 102b, 102c over the null plane 116 by using IEEE 802.16 radio technology. As discussed further below, the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, RAN 104, and core network 106 may be defined as reference points.

As shown in FIG. 1E, the RAN 104 may include base stations 170a, 170b, 170c and ASN gateway 182, but it should be understood that the RAN 104 may include any number of base stations and ASN gateways while remaining consistent with the embodiments. . Each of the base stations 170a, 170b, 170c may be associated with a particular cell (not shown) in the RAN 104, and each base station may include one or more transceivers to communicate with the WTRU 102a via the null plane 116, 102b, 102c communicate. In one embodiment, base stations 170a, 170b, 170c may implement MIMO technology. Thus, for example, base station 180a can use multiple antennas to transmit wireless signals to, and receive wireless signals from, WTRU 102a. Base stations 170a, 170b, 170c may also provide mobility management functions such as handover triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 182 can act as a traffic aggregation point and can be responsible for implementing paging, user profile cache, routing to the core network 106, and the like.

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

The communication link between each of the base stations 170a, 170b, and 170c can be defined as an R8 reference point that includes protocols for facilitating WTRU handover and data transfer between base stations. The communication link between the base stations 170a, 170b, 170c and the ASN gateway 172 can be defined as an R6 reference point. The R6 reference point can include an agreement to facilitate mobility management based on an action event associated with each of the WTRUs 102a, 102b, 180c.

As shown in FIG. 1E, the RAN 104 can be connected to the core network 106. The communication link between the RAN 104 and the core network 106 can be defined as an R3 reference point, which, by way of example, includes protocols for facilitating data transfer and mobility management capabilities. The core network 106 may include a Mobile IP Home Agent (MIP-HA) 174, an Authentication and Authorization Accounting (AAA) server 176, and a gateway 178. While each of the foregoing elements is described as being part of the core network 106, it should be understood that entities other than the core network operator may also own and/or operate any of these elements.

The MIP-HA 174 may be responsible for implementing IP address management and may allow the WTRUs 102a, 102b, 102c to roam between different ASNs and/or different core networks. The MIP-HA 174 may provide the WTRUs 102a, 102b, 102c with access to a packet switched network, such as the Internet 110, to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices. The AAA server 176 can be responsible for implementing user authentication and supporting user services. Gateway 178 can facilitate interaction with other networks. For example, gateway 178 may provide WTRUs 102a, 102b, 102c with access to circuit-switched networks such as PSTN 108 to facilitate communication between WTRUs 102a, 102b, 102c and conventional landline communication devices. In addition, gateway 178 may also provide WTRUs 102a, 102b, 102c with access to network 112, which may include other wired or wireless networks owned and/or operated by other service providers.

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

FIG. 2 illustrates an example communication system 200 in which the embodiments herein may be practiced or implemented. The communication system 200 is provided for illustrative purposes only and does not limit the disclosed embodiments. As shown in FIG. 2, communication system 200 includes a base station 214 and WTRUs 202a, 202b. Those skilled in the art will appreciate that communication system 200 can include additional components not shown in FIG.

As an example, base station 214 may be any of base station 114 (FIG. 1A), Node B 140 (FIG. 1C), eNode B 160 (FIG. 1D), and base station 170 (FIG. 1E). Base station 214 may also include similar and/or different functions as base station 114, Node B 140, eNodeB 160, and base station 170. For example, base station 214 can include functionality for supporting 5G and implementing the processes, techniques, and the like included herein.

Base station 214 can be configured for small cell operation and/or deployment. The base station 214 can be configured to support any centimeter wave (cmW) and millimeter wave (mmW) operation. To simplify the description, the term may be used herein "x mW" refers to any of a cmW and mmW. Additionally and/or alternatively, base station 214 may also be configured to support various (eg, all or some) functions and/or features related to small cell operations and/or deployments specified by 3GPP system version 12. In this regard, the base station 214 can operate the x mW null interfacing plane in parallel, simultaneously, and/or otherwise with an empty interfacing plane of LTE, LTE-A, or similar type (collectively "LTE"). The base station 214 can be equipped with at least one of various advanced antenna configurations and beamforming techniques, for example, capable of allowing the base station 214 to simultaneously transmit LTE downlink channels in a wide beam pattern and x mW channels in one or more narrow beam patterns. technology. Base station 214 may also be configured to use and is adapted to process having the features (e.g., features and processes disclosed herein) do not have support for a WTRU or which x mW unused capacity on an LTE uplink transmission chain configuration.

As an example, each of the WTRUs 202a, 202b may be any of the WTRUs 102 (FIGS. 1A-1E). Each of the WTRUs 202a, 202b may also include similar and/or different functionality to the WTRU 102. The WTRUs 202a, 202b may include functionality for supporting the features of 5G and implementing the processes, techniques, and the like included herein. To simplify the description, when "WTRU 204" is used herein, it may refer to any of the WTRUs 202a, 202b.

WTRU 202a, 202b each of which can be configured to support operation x mW. The WTRUs 202a, 202b may be further configured to support various (eg, all or some) functions and/or features for user device operations and/or deployment as specified by the 3GPP system Release 12. WTRU 202a, 202b each of which can be parallel, concurrently, and / or connected to each other in other ways to operate the LTE air interface and x mW. WTRU 202a, 202b of each antenna may have two RF chains and incidental; wherein a group is configured to operate in the LTE band, and the other set is configured to operate in a frequency band x mW. However, the disclosure is not limited in this respect, and the WTRU may have any number of antenna groups and accompanying RF chains. WTRU 202a, 202b of each may include one or more baseband processors, and these functions may include a baseband processor and a baseband processor x mW LTE bands are bands or at least partially bound. As an example, these functions may be common for the baseband processing hardware block x mW and an LTE air interface. Review

In particular, the methods, apparatus, systems, devices, and computer program products of the present disclosure are directed to shared transmissions of both backhaul and forward backhaul traffic (collectively referred to as "crosshaul traffic"). Among the new methods and/or techniques provided herein, one of the new methods and/or techniques is a cross-trip common frame (XCF), where the XCF is adapted to carry any packet-based cross-trip traffic. Optimize forwarding and/or management of new control information and other information that can be performed. And in accordance with the XCF compatible with the MAC-in-MAC protocol, the forwarding of the XCF can be performed not only by the packet switching component that supports the shared XCF domain forwarding and management control (and thus the new control information), but also by the old Some MAC-in-MAC protocol (eg Ethernet) switchers do not perform with XCF domain shared forwarding control.

The new control information carried by XCF allows for multiplexing of different types of cross-trip traffic as well as forwarding and network management optimization. Such information may be carried in the payload and/or header of the MAC-in-MAC protocol frame. If it is carried in the payload, the switch needs to read a portion of the frame payload before making a forwarding decision, which may introduce additional delay. In addition, if 802.1AE is used, then the payload must be decrypted and re-encrypted on each hop, which will further increase the handover delay. In addition, adding new information to the payload may require the introduction of a new XCF layer and a new switch hardware design.

Alternatively, this additional information can be carried in the MAC-in-MAC header. For example, if additional information is carried inside a defined field of the MAC-in-MAC header template, this will ensure compatibility with the old switch. This means that the MAC-in-MAC legacy switch can interpret this field in accordance with the MAC-in-MAC protocol, and the XCF-capable switcher can interpret it in different ways and thereby Use for forwarding optimization for cross-trip traffic. A second alternative (such as using a MAC-in-MAC header as a baseline template for XCF) is more advantageous than the first alternative. Compatibility with existing hardware is maintained due to the separation of data and control planes, thus eliminating the need to modify existing legacy Ethernet hardware to support XCF (because it will act as a MAC at the hardware level) -in-MAC protocol parameters appear). As an example, if additional (new) control information is carried in a field shared by the Ethernet (802.2) sublayer, then compatibility with the MAC service will be maintained. In this case, MAC service compatibility avoids fields by placing the same column at different locations in the sublayer header (eg, mapping MAC-in-MAC over IEEE 802.11 with the IEEE 802.11ak mechanism). change. As described in detail below, the XCF can carry new control information and/or fields by instantiating the MAC-in-MAC template (examples of which are shown in FIG. 4).

In one embodiment, a method implemented in a network entity can include any of the following: using XCF to generate and transmit cross-travel traffic, wherein the XCF is encoded for MAC-in-MAC protocol compatibility and Supports shared XCF domain forwarding and/or management of cross-trip traffic. In one embodiment, the XCF may include one or more MAC-in-MAC protocol fields/parameters that are encoded to support any of the forwarding and management of cross-travel traffic.

In one embodiment, a method implemented in a network entity can include any of the following: using XCF to generate and transmit cross-travel traffic, wherein the XCF is MAC-in-MAC protocol compatible and encoded One or more MAC-in-MAC protocol fields/parameters to support shared XCF domain forwarding and/or management control (collectively referred to as "shared XCF domain control").

In one embodiment, the XCF may have structures and features based on the instantiation of a MAC-in-MAC protocol frame template ("MAC-in-MAC template"). Backward compatible with XCF's MAC-in-MAC, it can support legacy MAC-in-MAC switchers without XCF capability. These legacy switches are not subject to shared XCF domain control and thus cannot fully utilize the options set in the XCF to optimize cross-trip traffic forwarding processing. Switching machines with XCF capabilities can take advantage of shared XCF domain control.

Among the new methods and/or techniques provided herein, one of the new methods and/or techniques is for implementing a subset of XCF features on legacy MAC-in-MAC protocol (Ethernet) switchers. An enhanced solution to the problem of the size of the MAC table on the old Ethernet switch, which is caused by a packet switching element (such as a cross-trip forwarding entity (XFE) node) that supports XCF domain control. Multiple Ethernet addresses (for example, because the XCF address space is limited).

Between the new methods and/or technologies provided herein is the forwarding and management of cross-travel traffic based on the XCF structure by applying segmentation routing. This can be converted into (1) adding a new XCF header portion in the MAC-in-MAC portion of the baseline to define an ordered segment list; and (2) defining new control information (eg, last segment, new) EtherType) to enable the segmentation routing to function properly.

Also, between the new methods and/or techniques provided herein is a new architecture that includes for fast rerouting (without waiting for the central controller to react (eg, to events such as network component failures). Outgoing)) and an ordered list of fixed lengths associated with information on the fallback path of reduced traffic loss in the event of a network component failure (eg, a transmission link failure).

In accordance with the new methods and techniques provided herein, the structure and features of the XCF can be based on the following: (i) the instantiation of the MAC-in-MAC template for inter-transmission traffic transmission requirements, and (ii) segmentation routing. application.

FIG. 3 is a block diagram showing an example communication environment 300. The communication environment 300 can include a transmission network 301. The transport network 301 can include an old domain 303 and an XCF domain 304. The XCF domain 304 can include first and second sub-domains 306, 308 that are interconnected via a segment 310. One or more different transmission and data link technologies may be used within each of the first and second sub-domains 306, 308 and segment 310. The transmission or data link techniques used by the interface between the first and second sub-domains 306, 308 and segment 310 may be different from one another. Although different transport or data link techniques may be used, the first and second sub-domains 306, 308, segment 310, and other components (if any) that define the XCF domain 304 may support cross-sections using XCF. Shared transmission of the trip service. Although not shown, the XCF domain 304 can include: more segments for interconnecting the first and second sub-domains 306, 308; and/or one or more additional sub-domains; and for each additional sub-domain One or more additional segments used to interconnect this additional sub-domain with the first sub-domain 306, the second sub-domain 308, and/or other additional sub-domains, if any. Alternatively, XCF domain 304 may include only a single subdomain.

The first sub-domain 306 can include an XFE 312 interconnected with the inter-trip adaptation units (XAU) 316, 318, 319, and 320 and the Ethernet switch 322 via local segments. The first sub-domain 306 may also include an XFE 314 that is interconnected with the Ethernet switch 322 via a local segment and interfaced with the segment 310. The second sub-domain 308 can include a first XFE 324 that interfaces with the segment 310 and is interconnected with the Ethernet switch 334 via local segments. The second sub-domain 308 may also include a second XFE 326 interconnected with the XFE 324, the Ethernet switch 334, the XAUs 330, 322, and the third XFE 328 via local segments. The XFEs 312, 314, 324, 326, and 328 can perform XCF packet switching along with the Ethernet switchers 322, 334.

As described in more detail herein, the XCF processed in the XCF domain can be encoded for MAC-in-MAC protocol compatibility and to support shared forwarding and/or management of cross-travel traffic in the XCF domain. For example, XFEs 312, 314, 324, 326, and 328 can use the shared forwarding control of the XCF domain and can take advantage of the options set in the XCF to optimize cross-travel traffic forwarding. The Ethernet switch 322, 334 may be a legacy MAC-in-MAC (without XCF capability) switch that does not support shared forwarding control of the XCF domain. Since the XCF handled by the Ethernet switch 322, 334 is encoded for MAC-in-MAC protocol (backward) compatibility, MAC-in-MAC protocol forwarding control can be used. Older MAC-in-MAC switchers cannot take full advantage of the options set in XCF to optimize cross-trip traffic forwarding.

The XAUs 316, 318, 319, 320, 330, and 332 can adapt the XCF to exchange cross-travel traffic with external (eg, non-XCF) interconnect domains. The external interconnect domain may include: (or include domains associated with) access networks 336, 338; legacy domain 303; core network 340; cloud/data center, such as baseband unit (BBU) servo 342; access network 344; firewall 346, and the like. For example, the XAUs 316, 318 can exchange cross-travel traffic with the access networks 336, 338, respectively, by adapting the XCF; the XAUs 320, 330 can be adapted to the old domain 303 and/or the access network 344 by adapting the XCF. The cross-travel traffic is exchanged; and the XAU 332 can exchange cross-trip traffic with the core network 340 by adapting the XCF.

Communication environment 300 can include network controller 350. The network controller 350 can exchange various information with entities of the XCF domain 304, such as with XFEs 312, 314, 324, 326, and 328 and XAUs 316, 318, 319, 320, 330, and 332. This information may include rules, parameters, etc. for providing entities of the XCF domain 304 to perform forwarding and queue management.

Recently, for the EU H2020 5G-Crosshaul project, the design of a common packet switching format for cross-border traffic has begun. The XCF in accordance with the specification and patent application scope herein is likely to be an available solution for the shared packet switching format. XCF is intended to transmit and multiplex various (existing and new) forward backhaul and reload traffic with guaranteed QoS for different traffic profiles. As noted above, the XCF can be encoded for MAC-in-MAC protocol compatibility and to support shared forwarding and/or management of cross-travel traffic in the XCF domain.

The Vendor Backbone Bridge (IEEE 802.1ah-2008, also known as "MAC-in-MAC") is a set of architectures and protocols for routing on the provider's network that allow for the individual definition of each customer without loss. The interconnection of multiple vendors bridges the network in the case of virtual local area networks (VLANs). Vendor Backbone Bridge - Traffic Engineering (IEEE 802.1Qay-2009, also known as "PBB-TE") expands by eliminating flooding, dynamically created forwarding tables, augmenting tree agreements, and by separating data from the control plane MAC-in-MAC behavior. PBB-TE adapts Ethernet technology to carrier-loaded transmission networks and takes advantage of the economies of scale inherent in Ethernet.

The IEEE standard 802.11 was originally designed as an access network, assuming that the connected device would be the leaf node of the network. Recently, attention to the use of 802.11 links has not only increased in access, but also in the transmission network. For example, 802.11ad operates in the 60 GHz band and is capable of providing high frequency wide links that are also suitable for backhaul transmission. The IEEE 802.11ak revision optionally extends the 802.11 standard, thereby enabling communication links between devices to be used as transmission links within an IEEE Std 802.1Q compliant network. The IEEE 802.1Qbz and IEEE 802.1ac revisions together with IEEE 802.11ak define an enhanced scheme for bridging processing of 802.11 media. Thus, the MAC-in-MAC frame can be carried natively on the IEEE 802.11 link without performing conversion or encapsulation.

The MAC-in-MAC protocol can support legacy MAC-in-MAC switchers and support transparency across different domains and across different link technologies (eg optical, wireless, etc.) (for the user) interconnection. However, the MAC-in-MAC protocol was originally designed and used for backhaul carrier-level transmission and is therefore considered insufficient to be optimized to forward new traffic classifications, ie with strict delay and jitter. The forward return traffic of the demand or the mixture of forward return and reload.

Figure 4 is a block diagram showing an example template ("MAC-in-MAC Template") 400 of a MAC-in-MAC frame. The MAC-in-MAC template 400 can include a MAC-in-MAC header 402. The MAC-in-MAC header 402 may include a plurality of fields for specifying various parameters of the MAC-in-MAC protocol. For example, these fields include a B-Dest address field 404 for specifying (48-bit) Ethernet destination address and a B-Src for specifying (48-bit) Ethernet source address. Address field 406. As described in greater detail herein, the MAC-in-MAC template 400 can provide the XCF with the basis for carrying XCF domain control and providing backward compatibility with legacy Ethernet switchers.

Fig. 5 is a block diagram showing an intermediate form of an exemplary cross-trip common frame (XCF) 500 (hereinafter referred to as "XCF 500i"). The XCF 500 may be based on the instantiation of all or part of one or more MAC-in-MAC templates other than the MAC-in-MAC template 400 (as shown) or the MAC-in-MAC template 400. To simplify the description in the following description, various elements of the example communication environment shown in FIG. 3 (e.g., elements of transport network 301) may be referenced in conjunction with XCF 500 (and its intermediate form). The XCF 500 and its intermediate forms can be used, deployed, etc. in other communication environments as well as in the example communication environment shown in Figure 3, not specifically mentioned.

The XCF 500 can include an XCF header 502. The XCF header 502 may be based on an instantiation of a MAC-in-MAC header 402 with control information encoded to allow appropriate (proper/correct) forwarding of the XCF 500 using a MAC-in-MAC protocol, And shared forwarding and/or management control of the XCF domain ("XCF Domain Forwarding Control"). The encoding process used to encode the control information may be any type of encoding process that allows the XCF 500 to be interpreted using both the MAC-in-MAC protocol and the XCF domain forwarding control. For example, the encoding process can encode the control information so that the XCF header 502 (and/or XCF 500) can be interpreted using the MAC-in-MAC protocol, and the hash is applied to some or all of the XCF headers 502. The column function is followed by XCF field forwarding control to interpret the XCF header 502.

Alternatively, the encoding process may arrange XCF domain control information between one or more portions of the XCF header 502 (eg, fields, bits, etc.) by encoding control information that does not affect the use of MAC-in - The MAC protocol performs the appropriate forwarding processing of the XCF. For example, the XCF header 502 can include an XCF header subsection 503. The XCF sub-portion 503 can be based on the instantiation of the B-Dest address field 404 and the B-Src address field 406, wherein (i) the destination address and source address information are arranged in portions of the XCF sub-portion 503. Between, in order to allow the use of the MAC-in-MAC protocol to properly forward the XCF, and (ii) XCF domain control information (eg, control information related to active segmentation) is placed in one or more portions of the XCF sub-portion 502 In the meantime, it does not affect the proper forwarding processing of the XCF using the MAC-in-MAC protocol. In an embodiment in accordance with such an example, the encoding process of the control information may be similar to changing one or more bits of the B-Dest and/or B-Src address to XCF domain control information. The result of the encoding process may be that the XCF header subsection 503 has fewer bits than the conventional B-Dest and/or B-Scr address for destination and/or source addressing. Alternatively, a bit that changes usage may have a dual meaning. For example, a changed-purpose bit can simultaneously represent MAC-in-MAC protocol destination and/or source addressing and XCF-domain control information.

In an embodiment, the XCF header subsection 503 can include an XCF segmentation portion 504 and an XCF source portion 506. XCF segmentation portion 504 and XCF source portion 506 may be based on the instantiation of B-Dest address field 404 and B-Src address field 406, respectively. The legacy MAC-in-MAC switcher can interpret the XCF segmentation portion 504 as an old (e.g., 48-bit) Ethernet destination address and can interpret the XCF source portion 506 as legacy (e.g., 48-bit). Yuan) Ethernet source address. The forwarding decisions and controls performed by the XCF capable switcher may be based on a lookup associated with the XCF segmentation portion 504 and/or the XCF source portion 506.

The XCF segmentation portion 504 can carry XCF domain control information associated with the active segment of the XCF domain 304 (FIG. 3), such as segment 310 and any of the local segments of the sub-domains 306, 308. The XCF segmentation portion 504 can include an XCF destination address portion 508 and an XCF destination control portion 510. The XCF destination address portion 508 can indicate or represent the XCF domain forwarding address of the XCF 500. As an example, XCF destination address portion 508 can be an XCF capable switch (eg, XFE 312, 314, 324, 326, and 328 and any of XAU 316, 318, 319, 320, 330, and 332) (eg, 24-bit) unique identifier. The XCF destination control portion 510 can include XCF domain control information for forwarding optimization within the active segment. Such XCF domain forwarding optimization information may include various parameters that can be carried in various frame control fields of the XCF destination control portion 510. As shown in FIG. 5, examples of the frame control field may include an emergency field 516, a sequence field 518, a multi-destination field 520, a power management field 522, a preemption field 524, and a protection frame field 526. More data fields 528 and reserved fields 530.

The emergency field 516 can carry an emergency indicator. The emergency indicator can be as small as a single bit and can be set to a special value indicating that the XCF 500 needs to be processed immediately. The emergency indicator can be set to such a value for various reasons and/or conditions, such as when the XCF 500 carries explicit congestion notification (or any other OAM) information. The emergency field 516 can be considered by any destination XFE or CAU, such as any XFE or XAU having an address that matches or matches the XCF destination address portion 508. The XFE and/or XAU other than the destination XFE or XAU need not consider the emergency field 516.

The sequence field 518 can carry an ordered delivery service indicator. The ordered delivery service indicator can be as small as a single bit and can be set to a special value used to indicate that the XFE 500 needs (eg, requires) an orderly delivery service. In general, an ordered delivery service indicator can be set to such a value in an XCF that requires an in-order delivery service. The ordered delivery service indicator can be set to indicate that an orderly delivery service is required in a connection-oriented mode of operation, such as 802.2 LLC type 2.

The multi-destination field 520 can carry a multi-destination indicator. The multi-destination indicator can be as small as a single bit and can be set to a specific value used to indicate that the XCF 500 has multiple destinations (eg, via multicast, anycast, broadcast). When set to such a value, the XCF destination address 508 can specify a distribution tree for forwarding the XCF 500.

The power management field 522 can carry a power management indicator. The power management indicator can be as small as a single bit and can be set to a special value indicating that the power management mode is supported on the XFE and/or XAU of the transmitting XCF 500.

The preemption field 524 can carry a preemption indicator. The preemption indicator can be as small as a single bit and can be set to a special value indicating whether the XCF can be preempted. Typically, for non-critical traffic, the preemption indicator can be set to this value.

The protection frame field 526 can carry a protection frame indicator. The protection frame can be as small as a single bit and can be set to a specific value indicating that the payload already contains information processed by the cryptographic encapsulation algorithm. (For example, a default cipher suite such as GCM-AES-128).

More data field 528 can carry a more data indicator. The more information indicator can be as small as a single bit and can be set to a special value indicating that more data is expected to be sent belonging to the same I-SID. Typically, in any XCF data frame where more data belonging to the same I-SID is expected to be sent, the more data indicator will be set to such a value.

Reserved field 530 can carry bits that are reserved for future use.

In the example shown, the frame control field occupies 24 bits together, and the XCF destination address portion 508 occupies 24 bits of the XCF segment portion 504 (to the old (eg, 48-bit) Ethernet) The destination address corresponds to the example of the B-Dest address field 404 corresponding to the base address). The XCF segmentation portion 504 can allocate more bits to the XCF destination address portion 508 and assign fewer bits to the XCF destination control portion 510, and vice versa. Alternatively, all of the bits of XCF segmentation portion 504 may not be assigned to XCF destination address portion 508 and XCF destination control portion 510, and XCF segment portion 504 may allocate these bits accordingly.

The XCF source portion 506 can carry XCF domain control information associated with the payload of the XCF 500 ("XCF payload"). The XCF source portion 506 can include an XCF source address portion 512 and an XCF source control portion 514. The XCF source address portion 512 can indicate or represent the XCF domain source address of the XCF 500. For example, XCF source address portion 512 can be an XCF capable switcher that initiates XCF 500 (eg, XFE 312, 314, 324, 326, and 328 and any of XAU 316, 318, 319, 320, 330, and 332). A) (eg 24-bit) unique identifier. The XCF source control portion 514 can include XCF domain control information for forwarding optimization within the XCF domain 304. Such XCF domain forwarding optimization information may include various parameters that can be carried in various frame control fields of the XCF source control portion 510. As shown in FIG. 5, examples of these frame control fields may include a Quality of Service (QoS) profile/traffic field 532, an SN/TS field 534, and a sequence number/time stamp field 536.

The QoS Profile/Traffic Classification field 532 can carry a QoS Profile/Traffic Classifier indicator. As an example, the QoS profile/traffic classification indicator can be 8 bits; and a QoS profile associated with the XCF 500 (also referred to as traffic classification) can be specified. Examples of possible values and their meanings are: 0x1: fronthaul.cpri, 0x2: fronthaul.ngfi, 0x10: backhaul.best.effort, 0x11: backhaul.video.livestream, 0x12: backhaul.voip and so on. Different time delays, jitters, and bandwidth requirements are typically associated with each QoS profile/traffic classification. The extensions cpri and ngfi can refer to the Common Public Radio Interface (CPRI) and the Next Generation Forward Return Interface (NGFI), respectively.

The SN/TS field 534 may carry an SN/TS indicator. The SN/TS indicator can be as small as a single bit and can be set to a different value to indicate whether the sequence number/time stamp field 536 is interpreted as a sequence number or timestamp.

As an example, the sequence number/time stamp field 536 can be 15 bits and can carry a sequence number or time stamp. For example, if the SN/TS field 534 is set to 1, the sequence number/time stamp field 536 may contain a sequence number associated with an SDU (Service Data Unit) such as IP, Ethernet, NGFI, CPRI, and the like. . Otherwise, the sequence number/time stamp field 536 will contain a timestamp.

In the example shown, the frame control field of the XCF source control portion 514 occupies a total of 24 bits, and the XCF source address portion 512 occupies the 24-bit of the XCF source portion 506 (to match the old (eg 48) The bit) is based on the example of the B-Src address field 406 corresponding to the source address of the Ethernet. The XCF source portion 504 can allocate more bits to the XCF source address portion 512 and assign fewer bits to the XCF source control portion 514, and vice versa. Alternatively, all of the bits of XCF source portion 506 may not be allocated to XCF source address portion 512 and XCF source control portion 514, and XCF source portion 504 may allocate the bit accordingly.

In the example shown in FIG. 5, the instantiation of the MAC-in-MAC template 400 results in the XCF segmentation portion 504 and the XCF source portion 506 (with the B-Dest field 404 and the B-Src address field 406, respectively) Each of the corresponding ones is divided into a plurality of subfields; and some of the subfields may carry XCF domain control information. This segmentation can be based on one or more of the following: 1. The length of the Ethernet address is 48 bits, so the address must be globally unique. In the XCF domain, the addressing process does not need to be globally unique (eg, due to association with the vendor domain); allowing a portion of the address space to be used to carry XCF domain control information again/replace. 2. The old switching opportunity treats the XCF domain control information as part of the B-Dest and B-Src addresses. Indeed, using the MAC-in-MAC Template 400 or other standard-compliant MAC-in-MAC templates to instantiate XCF will enable legacy compatibility. 3. Since the XCF domain control information is used to optimize XCF forwarding, it should be available as soon as it is practical after the frame reception begins. By deploying XCF domain control information to the first received portion of the XCF, it is possible to implement efficient pass-through forwarding for delay-sensitive frames. 4. The destination and source address are the fields that are always present in the Ethernet, 802.1D, and 802.1Q networks. This eliminates the need to modify the standard MAC service interface to pass XCF domain control information from one network layer to another. For example, the mapping of these fields between Ethernet and 802.11 frames is defined by the standard MAC interface. 5. The destination and source address of the Ethernet network are always encoded at the beginning of the frame and will never be encrypted. In addition, 802.1AE encrypts 802.1Q tags (such as C-tags, S-tags) when operating with MacSec/LinkSec.

The forwarding process on the legacy Ethernet switch is based on the lookup of the destination address of the Ethernet. For the XCF 500, it can be represented by the XCF destination address portion 508 and the XCF destination control portion 510. On the old Ethernet switch, the different combinations of XCF domain control bits can be interpreted as different Ethernet destination addresses. In this way, the proper configuration of the XCF domain control bit can also cause the old Ethernet switch to guide the cross-travel traffic on different ports (even if the old switch does not directly support it).

The XCF 500 can support legacy Ethernet switchers in the manner described below. The old Ethernet switch can interpret XCF as a standard MAC-in-MAC frame. The combination of the XCF destination address portion 508 and the XCF destination control portion 510 can be interpreted as an Ethernet destination address based on the XCF instantiation of the MAC-in-MAC template. The combination of the XCF source address portion 512 and the XCF source control portion 514 can be interpreted as an Ethernet source address based on the XCF instantiation of the MAC-in-MAC template. B-VID, I-SID, S-Tag, and C-Tag can be interpreted in accordance with the 802.1Q standard and based on the XCF paradigm of the MAC-in-MAC template.

The legacy Ethernet switch can forward the cross-trip traffic based on the combination of the XCF destination address portion 508 and the XCF destination control portion 510 (forming the equivalent of the Ethernet destination address) and the B-VID and I-SID. : According to the 802.1Q standard.

The XCF destination address portion 508 (which is unique to each XAU/XFE within the XCF domain) can be combined with any possible combination of the XCF destination control portion 510 (bits); thus, multiple Ethernet networks The address can be associated with each XAU/XFE (eg, an XFE with an XCF address of 0x00:11:22 can be associated with an Ethernet address of 0x00:11:22:uv:wx:yz, where u,v , w, x, y, z are any possible hexadecimal values). By appropriately configuring the control information to create different combinations of destination addresses that can be seen by the old switcher, some XCF domain control can also be implemented on the old Ethernet switch. This can be facilitated by making the new address field and control bits compatible with the MAC-in-MAC template and the legacy Ethernet switch.

FIG. 6 is a block diagram showing an example network entity 600 in which embodiments may be practiced or implemented. To simplify the description in the subsequent description, various elements of the example communication environment and/or XCF 500 shown in FIG. 3 may be referenced in connection with network entity 500.

Network entity 600 may include or be configured to be an XFE or XAU, such as one of XFE 312, 314, 324, 326, and 328 or XAU 316, 318, 319, 320, 330, and 332. The network entity 600 can include one or more inbound ports 601, a shared switching layer 603, and one or more outbound ports 605. Inbound port 601 can receive one or more MAC-in-MAC compatible frames. The MAC-in-MAC compatible frame may include XCF and other MAC-in-MAC compatible ("non-shared cross-trip") frames. The inbound port 601 can send a MAC-in-MAC compatible frame to the common switching layer 603.

The shared handover layer 603 can include a frame discriminator 611, first and second forwarding decision entities 613, 615, and first and second queue management entities 617, 619. The frame discriminator entity 611 can receive the MAC-in-MAC compatible frame from the inbound port 601. The frame discriminator entity 611 can distinguish the XCF frame from the non-shared cross-hop frame based on the matching field of the received frame (eg, the Src/Dst field) and the matching rule provided by the controller. As an example, the matching rules provided by the controller may include wildcard matching rules. The frame discriminator entity 611 can send the non-shared cross-hop frame to the first forwarding decision entity 613 (eg, for legacy forwarding decisions). The frame discriminator entity 611 can send the XCF to the second forwarding decision entity 615 (eg, for XCF forwarding decisions).

The first forwarding decision entity 613 can receive the non-shared cross-hop frame from the frame discriminator entity 611. The first forwarding decision entity 613 can use the old/corresponding forwarding process to process the non-shared cross-hop frame. The first forwarding decision entity 613 can send the processed non-shared cross-hop frame to the first queue management entity 617 (eg, for legacy queue management). The first queue management entity 617 can receive the non-shared cross-hop frame from the first forwarding decision entity 613. The first queue management entity 617 can process the non-shared cross-hop frame using the old/corresponding queue management process. The first queue management entity 617 can send the non-shared cross-hop frame to the outbound queue 605 according to the forwarding decision made by the first forwarding decision entity 613 and using the queue management performed by the first queue management entity 617. The appropriate outbound 埠.

The second forwarding decision entity 615 can receive the XCF from the frame discriminator entity 611. The second forwarding decision entity 615 can process the XCF using the XCF shared forwarding process. As an example, the second forwarding decision entity 615 can decode the XCF information present in the XCF. The second forwarding decision entity 615 can process the XCF information and can perform forwarding based on the processed XCF information. The second forwarding decision entity 615 can send the XCF to the second queue management entity 619 (eg, for XCF queue management).

The second queue management entity 619 can receive the XCF from the second forwarding decision entity 615. The second queue management entity 619 can perform the queue management process based on the XCF management rules. The second queue management entity 619 can send the XCF to the appropriate outbound port in the outbound port 605 based on the forwarding decision made by the second forwarding decision entity 615 in conjunction with the queue management performed by the second queue management entity 619.

FIG. 7 is a block diagram showing an example cross-stroke common frame (XCF) 700. The XCF 700 may be based on all or part of the instantiation of the MAC-in-MAC template 400 (or one or more MAC-in-MAC templates other than the MAC-in-MAC template 400) and the application of the segmentation route. The XCF 700 can facilitate the application of segment routing processing by adding new fields for carrying segmented routing control. The XCF 700 can include an XCF header MAC-in-MAC portion 705 and an XCF header segment routing portion 707. One of the XCF header MAC-in-MAC portion 705 and the XCF header segment routing portion 707 may include fields carrying segmentation routing control; examples of which are shown in fields 750-760. More details of the XCF 700 and its special fields 750-760 will be described below with reference to Figures 8-9.

Figure 8 is a block diagram showing an inter-trip common frame (XCF) 800 that is configured to support segmented routing. The XCF 800 can be a standalone form of XCF. Alternatively, XCF 800 can also be an intermediate form of XCF 700. The XCF 800 can be constructed based on the XCF 500 of Figure 5 (which can also be an intermediate form of the XCF 700). Although XCF 800 can be based on the instantiation of a different MAC-in-MAC template from XCF 500, to simplify the subsequent description, XCF 800 includes and builds on XCF 500.

The XCF 800 can facilitate the application of the segment routing process by adding a new field, such as fields 850-860, for carrying segmentation routing control in the XCF header 502. The segmentation routing control may include an ordered list of segments ("ordered segmentation lists") that the XCF may traverse. The ordered segment list can include an activity segment 804 and one or more inactive segments 809. At the specified time, only one of the segments is active, and the remaining segments will remain inactive until the processing of the active segment is completed. After its processing is complete, the activity segment 804 will become inactive and may be removed from the ordered segment list or added to the inactive segment 809. The next segment in the ordered segment list can be started (ie, become a new active segment, such as XCF segment 0), and can remain started until its processing is complete, thereby allowing for some or all The loop is repeated for the inactive segment.

If constructed on XCF 500 (Fig. 5), XCF header 502 of XCF 800 may include an XCF header MAC-in-MAC portion 805 and an XCF header segment routing portion 807. The XCF header MAC-in-MAC portion 805 can instantiate the MAC-in-MAC protocol frame in a manner similar to the exemplary XCF 500 (Figure 5). The XCF header segmentation routing portion 807 can be carried inside the MAC-in-MAC payload (Fig. 4) and can define a segmentation routing control field. The segmentation routing control field can carry the inactive segment 809 in the ordered segment list. Each segment in the ordered segment list can be identified by a combination of the XCF-Dst address and the XCF-Dst control field. The XCF segment 0 (XCF sub-portion 503) can identify the active segment 804. The XCF segment 1... k ... XCF segment k +1 can identify the inactive segment 809 in the ordered segment list.

New control information may be included in the XCF header MAC-in-MAC portion 805 and/or the XCF header segment routing portion 807 to allow for full operation of the XCF 800 with segment routing support. The new control information can be represented by various control fields, including the "Other Segments" field 850 and the new EtherType field 852.

The other segmentation fields 850 can be as small as a single bit and can be included in the XCF-Dst control bit 510. The other segmentation field 850 can be set to a value (eg, set to 0) for the last entry in the ordered list (ie, the last segment in the list) and can be set to be used for all Other values of other segmentation stack entries (for example, set to 1), which use signal announcements that there are still other segments present and need to be processed.

The new EtherType field 852 can be placed in the XCF header MAC-in-MAC portion 805. The new EtherType field 852 can signal the new value for the EtherType in the XCF header MAC-in-MAC portion 805 to identify the presence of the XCF header segment routing portion 807.

FIG. 9 is a block diagram showing an example cross-trip shared frame (XCF) 900 configured to support segmented routing. The XCF 900 can be a standalone form of XCF. Alternatively, XCF 900 can be an example of XCF 700. Although XCF 900 can be based on the instantiation of different MAC-in-MAC templates for XCF 500 and XCF 800, to simplify the subsequent description, XCF 900 includes and builds on XCF 500 and 800.

The XCF 900 can extend the XCF 800 to provide a fast reroute mechanism. This fast rerouting mechanism can be provided by adding a new field in the XCF header 502 (e.g., fields 954-960 in the XCF subsection 503). For example, in the event of a network component failure, a fast reroute mechanism can be employed to reroute traffic as quickly as possible. This behavior can be achieved by inserting a fixed length list of ordered paths ("Ordered Path List") into the XCF header 502. The ordered list of paths can be configured by the network controller for each segment (eg, in advance). In the case of a link failure, then the XFE can actively learn the fallback path using the ordered path list. In the additional new field there is a first path ("Path 1") field 954, a second path ("Path 2") field 956, a third path ("Path 3") field 958 and a fourth path. ("Path 4") field 960. Each of path 1 field 954, path 2 field 956, path 3 field 958, and path 4 field 960 is shown as having a length of two bits. However, each of the fields 954-960 can be longer or shorter than two digits.

Path 1 field 954 may identify a preferred path for forwarding XCF directed to the XFE (or XAU) identified by XCF-Dst address 508. Path 2 field 956 may identify a first fallback path if one or more link failures occur on the preferred path identified along path 1 field 954. Path 3 field 958 may identify the second back-off path if one or more link failures occur along the first back-off path identified by path 2 field 956. Path 4 field 960 may identify a third backoff path if one or more link failures occur along the second backoff path identified by path 3 field 958.

For each segment and thus for each XCF destination address, the network controller can define and/or configure the XFE to have four, more than four, four or fewer different paths for reaching the same XFE. Each path can be identified by two bits, more than two bits, or two or less bit values. By using the configured path and fields 954-960, the XFE can start rerouting traffic when a link failure is detected (for example, when there is no carrier on the link), without waiting for the network controller to respond to such events. Respond. As a result, XFE is able to minimize traffic loss and/or retransmission.

FIG. 10 is a block diagram showing an example network entity 1000 in which embodiments may be practiced or implemented. To simplify the description in the subsequent description, various elements of the example communication environment and/or XCF 500-900 shown in FIG. 3 may be referenced in connection with network entity 1000.

Network entity 1000 may include or be configured to be an XFE or XAU, such as XFE 312, 314, 324, 326, and 328 or one of XAUs 316, 318, 319, 320, 330, and 332. The network entity 1000 can include one or more inbound ports 1001, a shared switching layer 1003, and one or more outbound ports 1005. Inbound port 1001 can receive one or more MAC-in-MAC compatible frames. The MAC-in-MAC compatible frame may include an XCF and a non-shared cross-hop frame. The inbound port 1001 can send a MAC-in-MAC compatible frame to the common switching layer 1003.

The shared handover layer 1003 may include a frame discriminator 1011, first and second forwarding decision entities 1013, 1015, first and second queue management entities 1017, 1019, and a segmentation routing processing entity 1021. The frame discriminator entity 1011 can receive the MAC-in-MAC compatible frame from the inbound port 1001. The frame discriminator entity 1011 can distinguish between XCF frames and non-shared crosses based on matching fields of the received frame (eg, Src/Dst fields) and matching rules provided by the controller, such as wildcard matching rules. Itinerary frame. The frame discriminator entity 1011 may send the non-shared cross-hop frame to the first forwarding decision entity 1013. The frame discriminator entity 1011 can send the XCF to the second forwarding decision entity 1015.

The first forwarding decision entity 1013 may receive the non-shared cross-hop frame from the frame discriminator entity 1011. The first forwarding decision entity 1013 can process the non-shared cross-hop frame using the old/corresponding forwarding process. The first forwarding decision entity 1013 may send the processed non-shared cross-hop frame to the first queue management entity 1017. The first queue management entity 1017 can receive the non-shared cross-hop frame from the first forwarding decision entity 1013. The first queue management entity 1017 can process the non-shared cross-hop frame using the old/corresponding queue management process. The first queue management entity 1017 may send the non-shared cross-hop frame to the outbound interface 1005 according to the forwarding decision made by the first forwarding decision entity 1013 and the queue management performed by the first queue management entity 1017. The appropriate outbound 埠.

The second forwarding decision entity 1015 can receive the XCF from the frame discriminator entity 1011. The second forwarding decision entity 1015 can process the XCF using the XCF shared forwarding procedure. The second forwarding decision entity 1015 can decode the XCF information present in the XCF. The second forwarding decision entity 1015 can process the XCF information and can perform forwarding processing based on the processed XCF information. The second forwarding decision entity 1015 may send the XCF without the segmentation routing information to the second queue management entity 1019. The second forwarding decision entity 1015 can send the XCF with the segmentation routing information to the segment routing processing entity 1021.

The segmentation routing processing entity 1021 can receive and process the XCF with segmentation routing information based on the segmentation routing information. The segmentation routing processing entity 1021 may send the XCF that has been subjected to the segmentation routing process to the second queue management entity 1019.

The second queue management entity 1019 can receive the XCF from any of the second forwarding decision entity 1015 and the segment routing processing entity 1021. The second queue management entity 1019 can perform the queue management process based on the XCF management rules. The second queue management entity 1019 can send the XCF to the appropriate outbound in the outbound port 1005 in accordance with the forwarding decision made by the second forwarding decision entity 1015 and the queue management performed by the second queue management entity 1019. port. Cross-domain multi-service encapsulation and segmentation routing forwarding examples

Figure 11 shows an example of XCF encapsulation and forwarding in an Ethernet-compatible multiple data link environment. The XCF encapsulation and forwarding process can be based on fast rerouting supported segmentation routes. To simplify the illustration, the XCF encapsulation and forwarding paradigm is superimposed on the example communication environment 300 of FIG. The internal encapsulation and forwarding mechanisms will be provided below in conjunction with Figures 12 through 17.

In the example shown, the XCF can be forwarded from left to right, and the contract header added in the XCF is displayed on the right side of the XCF. In one embodiment, access network 344 in communication environment 300 can include a fixed access switch. The (data link) sub-domain 306 can be an IEEE 802.11ad wireless mesh network. The (data link) sub-domain 308 can be an IEEE 802.3aq fiber network. The data link legacy domain 303 can be a synchronous digital hierarchy (SDH) network.

The following traffic flows can display XCF encapsulation and segmentation routing forwarding based on XCF 900. For clarity of illustration, the B-VID, I-SID, S-tag, C-tag, etc. carried in the XCF header are collectively referred to as the "XCF Field". Example traffic flow 1 and 2

For the following description, the terms "[1]" and the term "[2]" refer to the traffic of traffic streams 1 and 2 identified by a similar form of box numbers in Figure 11 and surrounded by brackets. The number refers to the forwarding phase of the traffic stream identified by a similar form of circled number in Figure 11. Forwarding phase ( 1 ) example

The WTRU 302a may be connected to the access network 336. Access network 336 can be configured to have a particular functional partition. Until the baseband unit (BBU) server 342(5) decodes the forward backhaul data [1], the traffic of the WTRU 302a's traffic (WTRU-1 data) may not be identified. The forward backhaul data [1] may be forward backhaul data associated with the access network 336 (eg, CPRI traffic), and it may include forward header specific headers depending on the interface used. . Delay and packet delay variation budgets may be associated with forward backhaul data [1]. For example, to decode CPRI traffic, the BBU server 342 must receive the signal within a certain delay. Packet delay variation (PDV) is just as important as latency requirements. Indeed, even if the delay requirements are met, an excessive (eg large) PDV will affect the correctness of the CPRI decoding. According to the transmission network, the forward backhaul data [1] can be a high priority message in terms of delay and PDV. Forwarding phase ( 2 ) example

The network controller 350 can configure the frame and encapsulation parameters associated with the forward backhaul data [1] generated by the access network 336 on the XAU 316. The XAU 316 can attach the XCF header to the forward return data [1]. The XCF header can be instantiated with one or more of the following field values: a. - If the XCF is initiated by XAU 316, the XCF Src carries the XCF source address in the XCF field of XAU 316; - Since the forward backhaul data [1] is intended for decoding on the BBU server 342 and the XAU 319 is the XCF destination address of the traffic directed to the BBU server 342, the XCF Dst carries the XAU 319 XCF destination address; c. - The XCF-Dst control value of the example can include: Urgent: 0, Sequence: 1 (CPRI traffic cannot be received out of order: Reordering on the endpoint will introduce a forward backhaul interface Additional delays that cannot be tolerated), multiple destinations: 0, preemption: 0, protection frame: 0, other segments: 0, path 1:1, path 2: 2, path 3: 3; d. - example The XCF-Src control value may include: QoS profile/traffic classification: Fronthaul.CPRI-over-E, SN/TS bit: TS, timestamp value: current timestamp. The XFE can use these values to locally implement the latency and PDV of the rules that are compliant with the network controller configuration; and e. - B-VID and I-SID can be configured at this stage, while S-tags and C-tags are only It is configured on the XAU if the encapsulated frame does not contain these tags. In this case, it is possible that the forward-backed data [1] appears when the forward header does not contain the S-tag and the C-tag in the specific header.

S1 may be an active segment (eg, including any of XCF Dst, XCF Dst Ctrl, XCF Src, and XCF Src Ctrl), and no other segments are added in the XCF header segment routing portion 507. This is because it is possible for the BBU server 342(5) to decode the forward backhaul traffic [1], and it may not be possible to further distinguish the traffic until the BBU correctly decodes the signal. The XAU 316 can maintain the flow state associated with the traffic flow [1]. In embodiments where sub-domain 306 is an IEEE 802.11 wireless mesh network, XAU 316 can map the XCF onto an 802.11 frame and can send it to XAU 319 over a wireless link. Forwarding phase ( 3 ) example

The XFE 312 may forward the forward backhaul traffic according to one or more of the following information based on the information contained in the S1 and XCF fields: a. XCF Dst and XCF Dst control path 1 (assuming path 1 is active): Determine output以及; and b. XCF Dst control and XCF Src control field: determine forward backhaul traffic [1] QoS and internal queue management and switching, such as based on QoS profile / traffic classification, time stamp, preemption, order, etc. Wait to confirm.

The network controller 350 can continue to monitor the transport network 301 and can learn the time (e.g., required) required to transfer a frame from the XAU 316 to the XAU 319. Rules configured on XFE 312 can be associated with an end-to-end path to implement QoS requirements locally. For example, when forwarding by XFE 312, the frame of forward back data [1] will not exhaust the delay budget. However, if XFE 312 excessively delays the forwarding processing of these frames, then they may Run out of delay budget. In fact, the QoS requirements involve an end-to-end path (in this example, the end of the path is XAU 319). Forwarding phase ( 4 ) example

The network controller 350 can configure the XAU 319 with the decoding frame and decapsulation parameters associated with the forward backhaul traffic [1] generated by the access network 336. Since S1 will terminate on XAU 319, and since the XCF Dst address is the address of XAU 319 and the other segment bits are set to 0, XAU 319 can strip the XCF header. Depending on the functional partition used, the XAU 319 can attach an additional header to the frame and forward it to the BBU server 342 (5). Forwarding phase ( 5 ) example

The BBU server 342 can decode the forward backhaul data [1], which generates the WTRU-1 data [2]. Thereafter, the WTRU-1 data [2] can be sent back to the XAU 319. Forwarding phase ( 6 ) example

The network controller 350 can configure the frame and encapsulation parameters associated with the WTRU-1 data [2] generated by the BBU server 342 on the XAU 319. Assuming that WTRU-1 data [2] must be analyzed by firewall 346, network controller 350 can determine/determine one or more paths for WTRU-1 data [2] in the following manner. a. S2 (from XAU 319 to XFE 314) may be set to active segmentation: the segment belongs entirely to subdomain 306, and XFE 314 is the switcher to pass through from subdomain 306 to subdomain 308. This segment can belong to the XCF header MAC-in-MAC portion. b. S3 (from XFE 314 to XFE 328) can be set to the first segment coming in the ordered list. This segment belongs entirely to subdomain 308. And the segment can belong to the XCF header segment routing part. c. S4 (from XFE 328 through firewall 346 to XAU 332) can be set to the last segment. The segment belongs to subdomain 308, and XAU 332 can be an adaptation function to be taken from XCF domain 304 to core network 340. This segment can belong to the XCF header segment routing portion.

The XAU 319 may append the XCF header to the WTRU-1 data [2], where the header has the following field values for S2: a. XCF Src: may be carried in the XCF domain of the XAU 319 (as the source) XCF source address; b. XCF Dst: XCF destination address that can carry the first segment (ie, XFE 314); c. The XCF-Dst control value of the example may include: urgent: 0, order: 0, multiple Destination: 0, preemption: 1, protection frame: 0, other segments: 1 (indicates other segments carried in the XCF header segment routing part), path 1:1, path 2: 2, path 3: 3; d. The XCF-Src control value of the example may include: QoS profile/traffic classification: backhaul.video.stream, SN/TS bit: SN, sequence number value: current video frame number. The XFE can use these values to locally implement the delay and PDV of the rules that are compliant with the network controller configuration; and e. At this stage, the B-VID, I-SID, S-tag can be configured for the WTRU-1 data [2]. And C-tags.

The XAU 319 can be the only node in the network that maintains the state associated with the traffic flow [2]. Assuming sub-domain 306 is an IEEE 802.11 wireless mesh network, XAU 319 can map XCF onto an 802.11 frame and can transmit it over a wireless link. Forwarding phase ( 7 ) example

Similar to the forwarding phase (3) paradigm, the XFE 312 can forward the reload traffic according to one or more of the following information based on the information contained in the S2 and XCF fields [2]: a. XCF Dst and XCF Dst control paths 1 (assuming path 1 is active): determine output 埠; and b. XCF Dst control and XCF Src control field: determine [2] QoS and internal queue management and switching, eg based on QoS profile/traffic classification , preemption, order, etc. to determine. Forwarding phase ( 8 ) example

The legacy Ethernet switch 322 can forward WTRU-1 data based on the information contained in the MAC-in-MAC portion of the XCF header containing the S2 and XCF fields [2]. The old Ethernet switch can interpret the XCF format as a plain MAC-in-MAC frame as follows: a. Due to the XCF instantiation of the MAC-in-MAC template, the XCF Dst address and the XCF Dst Control can be interpreted as an Ethernet destination address; and b. Similarly, the XCF Src address and XCF Src control can be interpreted as an Ethernet source address.

B-VID, I-SID, S-tag, and C-tag can be interpreted in accordance with standards.

The old Ethernet forwarding process can be based on: a. Ethernet destination address: Inside the XCF domain, the XCF Dst address (ie, 24-bit) is unique to each XAU/XFE, and the XCF Dst bit The address can be combined with any possible combination of XCF Dst control bits (ie, 24-bit). Thus, multiple Ethernet addresses can be associated with each XAU/XFE. The old Ethernet switcher forwards either of these combinations to the same XAU/XFE; and b. B-VID and I-SID: according to the 802.1Q standard. Forwarding phase ( 9 ) example

XFE 314 can be the destination of S2. The XFE 314 can detect that the frame needs to be forwarded by performing a lookup on the following fields: a. Urgent: If set to 0, the frame should not be processed locally by the XAU/XFE. In S2, the bit can be set to 0; and b. Other segments: If set to 1, there are other segments in the XCF header segment routing portion. In S2, the bit can be set to 1.

Next, XFE 314 can replace S2 with S3, which can remove them from the XCF header segment routing portion. Thereafter, XFE 314 can forward the XCF using the information contained in S3, for example, following the procedure described in the Forwarding Phase (7) example. Assuming sub-domain 308 is an IEEE 802.3aq fiber network, XFE 314 may not map the frame and may send XCF directly over the fiber link. Forwarding phase ( 10 ) example

After the XCF header (including all segments) on the WTRU-1 data [2] has been pushed at the XAU 316, the link between the XFE 324 and the XFE 326 will fail. The result is that path 1 (originally configured by the controller on S3) is not available (as shown by the dashed line marked with X ). The XFE 324 can detect a link failure and, in accordance with the information contained in S3 on the fallback path, the XFE 324 can decide to forward the XCF on path 2 through the Ethernet switch 334 instead of the XFE 326. Thus, XFE 324 can forward XCF based on the information contained in S3, which can be as follows: a. XCF Dst and XCF Dst control path 2 (path 1 is not available due to link failure, path 2 is active): Determine output 埠; and b. XCF Dst control and XCF Src control field: determine QoS for WTRU-1 data [2] and internal queue management and handover, eg based on QoS profile/traffic classification, timestamp, preemption, Order and so on to determine.

If path 2 also fails, XFE 324 can forward XCF based on path 3. If path 3 also fails, the same process can be performed and XFE 324 needs to forward the frame based on path 4. Forwarding phase ( 11 ) example

The Ethernet switch 334 can forward the XCF according to the procedure described in (8) using the information contained in S3. Forwarding phase ( 12 ) example

As an example, as described in the forwarding phase (9) example, XFE 328 may terminate S3 and replace it with S4. The XFE 328 can detect that the frame needs to be forwarded to the firewall 346 first (instead of forwarding directly to the XAU 332) by performing a lookup process on the following fields: a. The XCF Dst alone may not be sufficient to determine the output; and b. Using the traffic classification, B-VID, and ID in combination, it can be determined that the WTRU-1 data [2] needs to pass through the firewall 346 before reaching the core network 340.

As an example, XFE 328 can forward the XCF using the information contained in S4 in accordance with the procedures described in the forwarding phase (7) example. Forwarding phase ( 13 ) example

Firewall 346 does not make any switching decisions. It can (for example, eventually) block or drop traffic in accordance with network control plane decisions. For example, firewall 346 can block any communication directed to any particular IP address. In this example, the firewall does not block WTRU-1 data [2] and it can be transparently relayed to XAU 328. Forwarding phase ( 14 ) example

Network controller 350 may configure the WTRU-1 profile [2] response frame and decapsulation parameters on XAU 328. Since S4 will terminate on XAU 328, and since the XCF Dst address is the address of XAU 328 and the other segment bits are set to 0, XAU 328 can strip the XCF header. Thereafter, XAU 328 can forward WTRU-1 data [2] to core network 340. In accordance with the protocol used in core network 340, XAU 328 may append additional headers to WTRU-1 data [2] before forwarding it. Example traffic flow A

For the subsequent description, the term "[A]" refers to the traffic of traffic flow A identified by a similar form of box letter in Figure 11, and the capital letter surrounded by brackets refers to the 11th. The forwarding phase of the traffic flow identified by a similar form of box letter is shown. Forwarding phase ( A ) example

The WTRU 302b may be connected to an access network 338, which may be a radio access network without functional partitioning. The WTRU 302b can communicate with some servers other than the operator network and can directly send the reloaded traffic [A] to the core network 340. For simplicity, the legacy switch 348 can be considered to be the point of presence of the transport network in the core network 340. The packet loss rate budget can be associated with the reload traffic [A] and does not require maximum latency or PDV here. For example, the WTRU 302b may perform a mobile phone application backup on a remote server. According to the transmission network, the reloaded traffic [A] is a low-priority traffic in terms of delay and PDV, but has a high priority in terms of packet loss rate. Forwarding phase ( B ) example

The network controller 350 can configure the frame and encapsulation parameters associated with the backhaul data [A] generated by the WTRU 302b on the XAU 318. XAU 318 may append the XCF header with the following field value to the reload traffic [A]: a. XAU 318 is XCF Src: it is the XCF source address in the XCF domain; b. XAU 320 is XCF Dst The return data [A] will be forwarded via the old domain 303 to reach the core network 340. Thus, XAU 320 is the XCF destination address used to reload traffic [A]. c. The XCF-Dst control values of the example may include: Urgent: 0, Sequence: 0, Multiple destinations: 0, Preemption: 1, Protection frame: 1, Other segments: 0; d. Example XCF-Src The control value may include: QoS profile/traffic classification: backhaul.ftp-session, SN/TS bit: SN, sequence number value: current sequence number. The XFE can use these values locally to implement local delays and PDVs that comply with the rules configured by the network controller; and e. At this stage, B-VID, I-SID, S can be configured for the reload traffic [A]. - Labels and C-tags.

The SA is an active segment (such as any of XCF Dst, XCF Dst Ctrl, XCF Src, and XCF Src Ctrl), and no other segments are added in the XCF header segment routing portion. Assuming sub-domain 306 is an IEEE 802.11 wireless mesh network, XAU 318 can map XCF onto an 802.11 frame and can transmit it over a wireless link. Forwarding phase ( C ) example

The XFE 312 can forward the backhaul traffic based on the information in the SA and XCF fields as follows: a. XCF Dst address and XCF Dst control: determine output 埠; and b. XCF Dst control and XCF Src control field: OK The QoS of the backhaul [A] and the internal queue management and handover are determined, for example, based on QoS profile/traffic classification, time stamp, preemption, order, and the like.

The network controller 350 can continuously monitor the transport network 310 and can know the time (e.g., required) required to transfer a frame from the XAU 318 to the XAU 320. Rules configured on XFE 312 can be associated with an end-to-end path to implement QoS requirements locally. Forwarding phase ( D ) example

The network controller 350 can configure the XBOX 320 with the demodulation box and decapsulation parameters associated with the reload traffic [A] associated with the WTRU 302b. Since the SA will terminate on the XAU 320, and since the XCF Dst address is the address of the XAU 320 and the other segmented bits are set to 0, the XAU 320 can strip the XCF header. The XAU 320 can forward the reload traffic [A] to the point of presence, the legacy switch 348. The XAU 320 can append additional headers to the reload traffic [A] in accordance with the protocol used in the old domain 303. Forwarding phase ( E ) example

The legacy switch 348 is external to the XCF domain 304 and can operate as an old point of presence.

An example of multiple XCF traffic profiles that traverse the same XFE is given by the forwarding stages (3), (7), and (C). Multiplexed forward traffic [1] and reloaded traffic [2], [A] can be multiplexed on the same XFE, where the XFE can use the XCF control field to implement QoS requirements. Old Ethernet switch MAC table filling example

In order to relieve the size of the MAC table on the old Ethernet switch, it is not necessary to save all the Ethernet addresses associated with each XFE, and it can be used for running on the old Ethernet switch. Correctly fill the MAC learning algorithm of the MAC table. The padding of the MAC table may be performed in the following manner: the combination of the control information carried by the XCF destination control section 510 controls the forwarding decision performed by the old Ethernet switcher to implement one of the XCF features on the node without the XCF capability. Subset.

Figures 12 and 13 show an example of the old Ethernet switch MAC table padding triggered by the controller via one or more XFEs. To simplify the description in the subsequent description, various elements of the example communication environment shown in FIG. 3 can be referenced in connection with FIGS. 12 and 13.

Usually, the old Ethernet switch can process the frame and forward it based on the destination address of the Ethernet. The old Ethernet switch can learn the address of the Ethernet from the frame it receives, and then store this information in the internal MAC table. Whenever such a switch receives a new frame, it saves the frame's source Ethernet address along with the frame (which receives the frame from that frame) in a table. This means that the next time the switch receives a frame with this Ethernet address as its destination, it will know (by viewing it in its address table) which frame to forward the frame to. Since the old Ethernet switch is not controlled by the network controller (which means that the network controller cannot directly fill the MAC table), the MAC table padding can be switched externally to the old Ethernet network. The machine sends multiple Ethernet frames with specific source Ethernet addresses to trigger. These source addresses may correspond to different combinations of control information carried in the XCF source address portion 512 and the XCF destination control portion 510.

Figure 12 shows how the MAC table is populated by XFEs 324, 326, 328 on the legacy Ethernet switch 334. In the following example, there may be three possible routes for each pair of nodes including the XFE and the old Ethernet switch (for example, the old Ethernet switch 334 can reach the XFE 328 based on the following route: directly XFE 328 is reached via XFE 326 (XFE 326-XFE 328); and via XFE 324, 326 (XFE 324 - XFE 326 - XFE 328)). Each route can be identified by a different combination of control bits. For example, the first route used to reach XFE 328 can be identified by a combination of XCF source address portion 512 forming the Ethernet address 328.1 and control information carried in XCF destination control portion 510. Similarly, the second route can be identified by the Ethernet address 328.2, and the third route can be identified by the Ethernet address 328.3. For XFE 324, 326, similar route identification based on the combined change of control information carried in XCF source address portion 512 and XCF destination control portion 510 is also available.

Usually, the MAC learning process is always active on the old Ethernet switch. This means that as long as the old switch receives a frame with an Ethernet source address that is not stored in the MAC table, the old Ethernet switch adds a new entry to the MAC table. If the XCF source address portion 512 and the XCF source control portion 514 represent the Ethernet source address, the network controller can relax the MAC table size by disabling some features, such as a timestamp. For example, different routes may be identified by the QoS profile/traffic classification field in the XCF source control portion 514. Thus, traffic directed to the same destination but with different QoS profiles can be forwarded on different ports.

In order to operate the legacy Ethernet switch 334 to populate its MAC table 1301 (Fig. 13), the network controller can instruct each XFE to send the XCF source address portion 512 to the legacy Ethernet switch 334 and A plurality of Ethernet frames combined with different control information carried in the XCF source control section 514 (as the Ethernet source address). Examples 1201, 1203, and 1205 of such Ethernet source and destination address values for frames sent from the XFE to the Ethernet switch 334 are shown in FIG.

After receiving all the frames reported in FIG. 12, the old Ethernet switch 324 can populate the MAC table based on the Ethernet source addresses of the frames and the UI from which they are received. 1301 (figure 13). By using the MAC table 1301 populated based on the transmitted frame, the network controller can control the specific combination of the XCF domain control information forming the Ethernet address stored in the MAC table, while in the old The cross-travel traffic is guided on the Ethernet switch 334. Internal encapsulation and forwarding examples

Provided below are examples of XFE and XAU internal processes.

Figure 14 is a block diagram showing an example of an advanced XCF forwarding process 1400 performed at XFE. The XCF forwarding process 1400 can include any of the following.

As shown at 1402, the XFE can receive the XCF on link 1 (e.g., 802.11). The receiving engine can process the data link frame (e.g., 802.11) (e.g., detect collisions) and the frame can be passed to the (inbound) mapping layer (1404).

As shown at 1406, the (inbound) mapping layer can perform the mapping of the link field of link 1 to the MAC-in-MAC XCF when needed (eg, mapping an 802.11 frame to a MAC-in-MAC template) in). The resulting XCF can be passed to the shared switching layer (1408).

As shown at 1410, the shared switching layer can process the incoming XCF based on some rules and/or parameters configured by the network controller and can decide where to forward the frame and how to forward the frame (as an example) In order to meet the delay budget, PDV budget, packet loss rate, fallback path, etc.). The processing pipeline can include three phases, namely inbound processing (1412), outbound processing (1414), and queue management (1416). After processing, the XCF can be passed to the (outbound) mapping layer for transmission over link 2 (1418).

As shown at 1420, the (outbound) mapping layer can perform the process of mapping the XCF field to the frame field of link 2 (eg, prioritization) as needed (eg, mapping the XCF onto the 802.11 frame). The resulting link 2 frame can be passed to the transport engine for transmission on link 2 (1422). As shown at 1424, the transport engine can transmit the resulting link 2 frame on link 2.

Figure 15 shows an example of an internal forwarding process 1500 associated with XCF arriving at XFE 埠 3 and relaying on 埠 2. Mapping and forwarding can be performed using the following processing blocks.

Various processes associated with receiving the XCF on 埠3 may be performed at processing block 1502. As shown in processing block 1504, what is performed may be the process of physically receiving the XCF (eg, synchronization and front-end processing). It is also possible to perform (eg required) MAC operations required by the data link layer technology used on 埠3. As shown in processing block 1506, the data link frame can be mapped to the Ethernet template XCF format. As an example, addresses 1 and 2 in 802.11 can be mapped to destination and source addresses in the Ethernet. The XCF can be passed to the shared switching layer (1508).

An XCF forwarding process can be performed at processing block 1510. As shown in processing block 1512, the inbound process can specify a matching rule and one or more output ports. XFE can match XCF based on address, label, and control field/bit and any combination thereof (for example, XCF can pass XCF Dst. address, XCFSrc. address, stream hash, TTL, and QoS profile fields). Come to be matched). After the rule successfully matches the XCF, the inbound process can identify the output port of the frame. This matching rule can be configured by the network controller. As shown in processing block 1514, the outbound processing can specify the action to apply to the XCF prior to transmission. As an example, such processing may include reducing TTL in the presence of a C-tag, and configuration of the most appropriate transmission queue based on QoS profiles, timestamps, and/or priority fields. As shown in processing block 1516, the queue management can implement QoS at the XCF level using a variety of queue transmission mechanisms. This queue can implement a traffic shaper. The traffic shaper can be used to optimize or guarantee performance by delaying other types (such as QoS requirements that can be implemented at this stage), improving latency and/or increasing the available bandwidth of some types of frames. After the queue management decides to transmit the frame, it can contact the underlying mapping layer.

A process for facilitating XCF transmission on 埠2 may be performed at processing block 1518. As shown in processing block 1520, the XCF can be mapped to a particular data link layer frame format (e.g., IEEE 802.11). As shown in processing block 1522, the MAC operations required (e.g., required) for the data link layer technology used on 埠2 may be performed. It is also possible to perform processes for physical transmission of XCF (eg, synchronization and front-end processing).

Figure 16 is a block diagram showing an example advanced XCF adaptation/conversion process 1600 on the XAU. The adaptation/conversion and forwarding process 1600 can include any of the following.

As shown at 1602, the XAU can receive the old frame (ie, IEEE 1904.3) encapsulated in the data link frame (ie, Ethernet) on link 1. The data link frame can be processed by the receiving engine (e.g., for detecting collisions) and can be passed to the (inbound) mapping layer (1604).

As shown at 1606, the (inbound) mapping layer can perform the process of mapping the frame field of link 1 to the old frame (e.g., segment ID). The old frame thus obtained can be passed to the old operational layer (1608).

As shown in 1610, the old operational layer can implement all operations associated with the old agreement (eg, tag timestamps). The old operational layer can pass the old frame to the conversion/adaptation layer (1612).

As shown in 1614, the conversion/adaptation layer can be used for grouping frames (eg, packetization of CPRI streams) and converting old frames to XCF. The resulting XCF can be passed to the shared switching layer (1616).

As shown at 1618, the shared switching layer can implement the same XFE forwarding function as previously described. After this processing, the XCF can be passed to the (outbound) mapping layer for transmission (1620).

As indicated by 1622, the (outbound) mapping layer can map XCF fields to link 2 frame fields (eg, prioritization) as needed. The resulting link 2 frame can be passed to the transport layer for transmission over link 2 (1624). As shown at 1626, the transport engine can transmit the resulting link 2 frame on link 2.

Figure 17 shows an example of an internal forwarding process 1700 associated with XCF arriving at XAU 埠 3 and relaying on 埠 2. The mapping and forwarding process can be performed using the following processing blocks.

A process associated with receiving a signal (i.e., a CPRI stream) on 埠1 can be performed at processing block 1702. As shown in processing block 1704, what may be performed may be physical reception and MAC operations (if any) (e.g., using the process as described in Fig. 15, i.e., processing block 1.1). As shown in processing block 1706, any final data link fields can be removed and the incoming signals can be mapped in the legacy protocol. After processing block 1706, the frame can be passed to the conversion/adaptation layer. As shown in processing block 1708, any non-encapsulated stream can be framed. The frame process can be configured by the network controller (for example, the size of each frame). Traffic can be mapped in the MAC-in-MAC XCF format (ie, the QoS profile field and timestamp are set at this stage). When using segmented routing supported XCF, the XCF header segmentation routing portion can be added to the XCF header MAC-in-MAC portion. In addition, an ordered list of segments can also be added. Thereafter, the XCF can be passed to the shared switching layer.

An XCF forwarding process can be performed at processing block 1710. As shown in processing block 1712, inbound processing may be performed (e.g., using the same process as described in FIG. 15, i.e., processing block 1512). As shown in processing block 1714, the outbound processing can be performed (e.g., using the same process as described in FIG. 15, i.e., processing block 1514). As shown in processing block 1716, queue management can be performed (e.g., using the same process as described in FIG. 15, i.e., processing block 1516).

A process for facilitating XCF transmission on 埠4 may be performed at processing block 1718. As shown in processing block 1720, what may be performed may be a mapping and encapsulation process (e.g., using the same process as described in FIG. 15, i.e., processing block 1520). As shown in processing block 1722, what may be performed may be a MAC operation and a physical transfer process (e.g., using the same process as described in FIG. 15, i.e., processing block 1522).

Figure 18 is a flow diagram showing a representative process 1800 for a shared transmission for cross-trip traffic. The representative process 1800 can be implemented in a network entity, such as XFE, XAU, or a network entity otherwise disclosed herein and/or illustrated in Figures 3 and 11 through 17.

Referring to Figure 18, the network entity can receive a plurality of MAC-in-MAC compatible frames (1802) including XCF. In one embodiment, the XCF may be encoded for MAC-in-MAC compatible protocols and support shared forwarding and/or management of cross-trip traffic. In one embodiment, the XCF may include one or more MAC-in-MAC protocol fields/parameters encoded to support any of forwarding and management of cross-travel traffic.

In one embodiment, the XCF may include an XCF header. The XCF header may be based on an instantiation of a MAC-in-MAC header of control information, wherein the control information is encoded to allow proper forwarding of the XCF using MAC-in-MAC protocol XCF domain forwarding control. In one embodiment, the encoding process for encoding the control information may include allowing any encoding type of the XCF to be interpreted using the MAC-in-MAC protocol and the XCF domain forwarding control. In one embodiment, the encoding process may encode control information such that the MAC-in-MAC protocol may be used to interpret the XCF header and/or XCF, and XCF may be used after applying a function to some or all of the XCF headers. Domain forwarding control to interpret the XCF header and/or XCF. In one embodiment, the encoding process may encode control information to arrange XCF domain control information between one or more portions of the XCF header that do not affect the proper forwarding of the XCF using the MAC-in-MAC protocol.

In one embodiment, the XCF header may include an XCF header subsection. The XCF subsection may be based on the instantiation of the B-Dest address field and the B-Src address field, where: (i) destination and source addressing information is placed between portions of the XCF subsection to allow for use The MAC-in-MAC protocol to properly forward the XCF, and (ii) the XCF domain control information is arranged in one or more portions of the XCF sub-portion, which does not affect the proper forwarding of the XCF using the MAC-in-MAC protocol. In one embodiment, the encoding process of the control information is similar to changing one or more bits of the B-Dest and/or B-Src address to XCF domain control information. In one embodiment, the result of the encoding may be that the XCF header subsection has fewer bits than the regular B-Dest and/or B-Src address for destination and/or source addressing. In one embodiment, the bit of the changed purpose may have a dual meaning; the changed use of the bit represents both the MAC-in-MAC protocol destination and/or source addressing and the XCF domain control information.

In one embodiment, the XCF header may include an XCF header sub-portion, and the XCF header sub-portion may include an XCF segment portion and an XCF source portion. The XCF segmentation portion and the XCF source portion may be based on the instantiation of the B-Dest address field and the B-Src address field, respectively.

The network entity may distinguish the XCF from other MAC-in-MAC compatible frames based on the received MAC-in-MAC compatible frame matching field and the matching rules provided by the controller (1804). The network entity can obtain XCF information (1806) arranged in the XCF. The network entity can obtain the XCF information arranged in the XCF by decoding the XCF and processing the decoded XCF. The network entity can perform forwarding based on the acquired XCF information (1808). The network entity can perform the queue management process (1810) based on the XCF management rules.

The network entity can optionally process other MAC-in-MAC compatible frames (1812). For example, a network entity may use any of the following to perform processing of other MAC-in-MAC compatible frames: (i) legacy forwarding and queue management procedures, and (ii) Forwarding and queue management of MAC-in-MAC compatible protocols for other MAC-in-MAC compatible frames. The network entity can transmit any of the XCF and other MAC-in-MAC compatible frames (1814).

Figure 19 is a flow diagram showing a representative process 1900 for a shared transmission for cross-trip traffic. The representative process 1800 can be implemented in a network entity, such as XFE, XAU, or a network entity otherwise disclosed herein and/or illustrated in Figures 3 and 11 through 17. The representative process 1900 is similar to the representative process 1800 (Fig. 18), and for simplicity, the various embodiments common to both processes are not repeated here.

Referring to Figure 19, the network entity can receive a plurality of MAC-in-MAC compatible frames including XCF (1902). The XCF can be based on the sample of the MAC-in-MAC protocol frame and the application of the segmentation route.

The network entity may distinguish the XCF from other MAC-in-MAC compatible frames based on the received MAC-in-MAC compatible frame matching field and the matching rules provided by the controller (1904). The network entity can obtain XCF information (1906) arranged in the XCF. The network entity can obtain the XCF information set in the XCF by decoding the XCF and processing the decoded XCF. The network entity can determine from the XCF information to use the segmentation route (1908). The network entity may perform forwarding processing based on the acquired XCF information and segmentation routing information extracted from the XCF (1910). In one embodiment, the segmentation routing information may include an ordered list of segments that the XCF may pass through. In one embodiment, the XCF may include an XCF header having first and second portions. The first portion can carry an active segment, and the second portion can carry an ordered segmented list. In one embodiment, the first portion may correspond to an XCF destination address of the XCF header and an XCF destination control portion. In one embodiment, the second portion may correspond to the payload of the XCF header.

In one embodiment, only one of the plurality of segments may be active at a given time. Until the processing of the active segment is completed, the remaining segments can remain inactive. The network entity may update the matching field with the segmentation routing information for the next segment based on whether the active segmentation is complete (1912). In one embodiment, the activity segment may become inactive after processing is complete, and/or may be removed from the list. In one embodiment, the next segment in the ordered list will become the active segment and will remain active until its processing is completed. In response to deactivation, the active segment may be removed from the first portion of the XCF header and will be replaced with a newly initiated segment from the ordered list in the second portion of the XCF header. In one embodiment, the segmentation routing information may include a rerouting mechanism for rerouting the XCF. This rerouting mechanism can be facilitated by a fixed length list of ordered paths carried in the XCF header.

In one embodiment, the forwarding decisions and controls may be based on a lookup associated with the XCF segmentation portion and/or the XCF source portion. The XCF segmentation portion may carry XCF domain control information associated with active segments of the XCF domain. In one embodiment, the XCF segmentation portion may include an XCF destination address portion and an XCF destination control portion. The XCF destination address portion may indicate or may represent the XCF domain forwarding address of the XCF. In one embodiment, the XCF destination address portion may include a unique identifier of the XCF capable switcher.

In one embodiment, the XCF destination control portion may include XCF domain control information for forwarding optimization within the active segment. The XCF domain forwarding optimization information may include one or more information carried in one or more frame control fields of the XCF destination control portion.

In one embodiment, the XCF source portion may carry XCF domain control information associated with the payload of the XCF. The XCF source portion may include an XCF source address portion and an XCF source control portion. The XCF source address portion may indicate or may represent the XCF domain source address of the XCF. In one embodiment, the XCF source address portion includes a unique identifier of the XCF capable switcher that originated the XCF. In one embodiment, the XCF source control portion may include XCF domain control information for forwarding optimization within the XCF domain.

The network entity can perform the queue management process (1914) based on the XCF management rules. The network entity can optionally process other MAC-in-MAC compatible frames (1916). For example, a network entity may use any of the following to perform processing of other MAC-in-MAC compatible frames: (i) legacy forwarding and queue management procedures, and (ii) Forwarding and queue management of MAC-in-MAC compatible protocols for other MAC-in-MAC compatible frames. The network entity can transmit any XCF and other MAC-in-MAC compatible frames (1918). in conclusion

For the purposes of this example, an example XCF (as shown in Figure 5, Figures 7 through 9) and representative operations and/or processes performed using these frames are provided here, and other shared cross-talk frames are provided. It can also be used. Other shared cross-talk frames (also known as Common Frame Format (CFF) frames) and details of the operations and processes used to use such frames can be filed on January 31, 2017 in US Provisional Patent Applications Found in No. 62/452,741, the entire disclosure of which is incorporated herein by reference.

While the features and elements are described above in terms of specific combinations, those skilled in the art will appreciate that each feature or element can be used alone or in combination with other features and elements. The disclosure is not limited in terms of the specific embodiments described herein, and these embodiments should be considered as examples of various aspects. Numerous modifications and variations are possible without departing from the spirit and scope of the disclosure. The elements, acts or instructions used in the description of the present application should not be construed as essential or essential to the invention, unless explicitly provided in this manner. Functionally equivalent methods and apparatus within the scope of the present disclosure will be apparent to those skilled in the art from the foregoing description. Such modifications and variations are intended to fall within the scope of the appended claims. The disclosure is limited solely by the scope of the appended claims and the full scope of the equivalents It should be understood that the present disclosure is not limited to a particular method or system.

It is also understood that the terminology used herein is for the purpose of describing particular embodiments and the The term "video" as used herein may refer to any of a snapshot, a single image, and/or multiple images displayed on a time basis. As another example, the term "user equipment" and its abbreviation "UE" as referred to herein may refer to (i) a wireless transmission and/or reception unit (WTRU) as described above; (ii) a plurality of WTRUs as described above. Any of the embodiments; (iii) a device having wireless capabilities and/or wired capabilities (e.g., connectable), in particular, the device is configured with some or all of the structure and functionality of the WTRU as described above; a device having wireless capabilities and/or cable capabilities configured with relatively few structures and functions compared to all of the structures and functions of the WTRU as described above; or (iv) similar devices. Details of an example WTRU that may represent any of the WTRUs described herein are provided herein with respect to Figures 1A-1E.

Moreover, the methods described herein can be implemented in a computer program, software or firmware embodied in a computer readable medium for execution by a computer or processor. Examples of computer readable media include electronic signals (transmitted over a wired or wireless connection) and computer readable storage media. Examples of computer readable storage media include, but are not limited to, read only memory (ROM), random access memory (RAM), scratchpad, cache memory, semiconductor memory devices, such as internal hard drives, and removable Magnetic media such as magnetic sheets, magneto-optical media, and optical media such as CD-ROM discs and digital versatile discs (DVD). A processor associated with the software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Various variations of the methods, apparatus, and systems provided above are possible without departing from the scope of the invention. In view of the various embodiments that can be applied, it is to be understood that the illustrated embodiments are only a few examples and are not to be construed as limiting the scope of the appended claims. For example, embodiments provided herein include a handheld device, where the device can include any suitable voltage source or be used with any suitable voltage source, any suitable voltage source of any suitable voltage providing any suitable voltage, any suitable The voltage is, for example, a battery or the like.

Furthermore, processing platforms, computing systems, controllers, and other devices including processors are mentioned in the above embodiments. These devices may include at least one central processing unit ("CPU") and memory. References to the behavior or symbolic representation of an operation or instruction may be performed by different CPUs and memories in accordance with the practice of those skilled in the art of computer programming. Such behaviors and operations or instructions may be referred to as "execution," "computer execution," or "CPU execution."

One of ordinary skill in the art will appreciate that the behavior and the operations or instructions represented by the symbols include the manipulation of the electronic signals by the CPU. The electronic system represents the transformation or reduction of the results that may result in the electronic signal, and the storage of the data bits in the memory location in the memory system, thereby reconfiguring or otherwise altering the CPU operation and other signal processing data bits. yuan. The memory location holding the data bit is a physical location having a particular electrical, magnetic, optical or organic property corresponding to or representing the data bit. It should be understood that the embodiments herein are not limited to the above described platforms or CPUs, and that other platforms and CPUs may also support the described methods.

The data bits can also be held on a computer readable medium, including the magnetic disk, the optical disk, and any other volatiles (such as random access memory ("RAM")) or non-volatile (for example, random access memory ("RAM")) that can be read by the CPU. Read memory ("ROM")) large storage area system. The computer readable medium can comprise a cooperating or interconnected computer readable medium that can exist either exclusively on the processing system or in a plurality of interconnected processing systems local or remote to the processing system. It should be understood that these example embodiments are not limited to the above described memory, and that other platforms and memories may also support the described methods.

In one illustrative embodiment, any of the operations, processes, and the like described herein can be implemented as computer readable instructions stored on a computer readable medium. The computer readable instructions can be executed by a mobile unit, a network element, and/or a processor of any other computing device.

There is almost no difference between hardware and software implementation in all aspects of the system. Whether using hardware or software is usually (but not always, because in some contexts, the choice between hardware and software may be important) is a compromise that represents a compromise between cost and efficiency. select. The processes and/or systems and/or other techniques described herein can be implemented by various vehicles (eg, hardware, software, and/or firmware), and preferred carriers can be deployed with the process and/or system and / or the context of other technologies change. For example, if the implementation determines that speed and accuracy are paramount, the implementer may choose to primarily employ hardware and/or firmware carriers. If flexibility is paramount, the implementer can choose the implementation that primarily uses software. Alternatively, the implementer may choose some combination of hardware, soft body and/or firmware.

The above detailed description has described various embodiments of the devices and/or processes in the <RTIgt; As such block diagrams, flow diagrams, and/or examples include one or more functions and/or operations, those skilled in the art will appreciate that each of the functions and/or The operations may be performed individually and/or collectively by a wide range of hardware, software, firmware or any combination thereof. In one embodiment, portions of the subject matter described herein may be implemented by means of an application integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), and/or other integrated formats. . However, those skilled in the art will appreciate that aspects of the embodiments disclosed herein may be implemented in whole or in part in an integrated circuit as one or more computers running on one or more computers. A program (eg, as one or more programs running on one or more computer systems) as one or more programs running on one or more processors (eg, as one or more microprocessors) One or more programs running on it are implemented, implemented as firmware, or implemented as almost any combination thereof, and in accordance with the present disclosure, circuit design and/or code writing for software and/or firmware also falls within It is within the technical scope of those skilled in the art. Moreover, those skilled in the art will appreciate that the mechanisms of the subject matter described herein can be distributed in various forms as a program product, and the description of the subject matter described herein, regardless of the particular type of signal bearing medium used to actually perform the distribution. Sexual embodiments are applicable. Examples of signal-bearing media include, but are not limited to, recordable media such as floppy disks, hard disk drives, CDs, DVDs, digital tapes, computer memory, and the like, as well as transmission type media such as digital and/or Or analog communication media (eg, fiber optic cable, waveguide, wired communication link, wireless communication link, etc.).

Those skilled in the art will recognize that in the art, devices and/or processes are described in the manner set forth herein, and engineering practices are used thereafter to integrate such described devices and/or processes into a data processing system. It is very common. That is, at least a portion of the devices and/or processes described herein can be integrated into a data processing system with a reasonable amount of experimentation. Those skilled in the art will recognize that typical data processing systems may typically include system unit housings, video display devices, memory such as volatile and non-volatile memory, such as microprocessors and digital signal processors. A processor, such as a computing system, a driver, a graphical user interface, and an application, such as a touchpad or a screen, or one or more interaction devices, and/or includes a feedback loop and A control system that controls the motor (eg, feedback for sensing position and/or speed, control motor for acting and/or regulating components and/or parameters). A typical data processing system can be implemented using any suitable commercially available components, such as those typically found in data computing/communication and/or network computing/communication systems.

The subject matter described herein sometimes shows different elements contained within or connected to other different elements. It should be understood that the architecture so described is merely an example, and that many other architectures for implementing the same functionality can be implemented in practice. Conceptually, any arrangement of elements that perform the same function is effectively "associated", thereby achieving the desired function. Accordingly, any two components herein combined to achieve a particular function can be considered to be "associated" with each other, thereby achieving the desired functionality, regardless of architecture or intermediate components. Likewise, any two elements that are associated in this manner can also be seen as "operably connected" or "operably coupled" to each other in order to achieve the desired function, and any two that can be associated in this manner. The elements may also be considered to be "operably coupled" to each other in order to achieve the desired function. Specific examples of being operatively coupled include, but are not limited to, elements that can be physically paired and/or physically interacting and/or elements that can interact in a wireless manner and/or wirelessly interact and/or Components that logically interact and/or can interact logically.

The use of substantially any plural and/or singular terminology herein may be used to change from the plural to the singular and/or from the singular to the plural, depending on the context and/or application. For the sake of clarity, various singular/plural permutations can be explicitly set forth herein.

Those skilled in the art will appreciate that, in general, terms used herein, particularly in the context of additional patent applications (e.g., subject matter in the scope of additional claims), should generally be construed as "open" (for example, the term "include" It should be interpreted as "including but not limited to", the term "having" is to be interpreted as "having at least" and the term "comprising" is to be interpreted as "including but not limited to" and the like. It will be further understood by those skilled in the art that, if the scope of the claimed patent is directed to a particular number, such intent should be explicitly recited in the scope of the application, and if no such It does not exist. For example, if only one item is expected, the term "single" or similar language may be used. As an aid to understanding, the scope of the appended claims and/or the description herein may include the use of the introductory phrases "at least one" and "one or more". However, the use of such phrases should not be construed as a limitation of the scope of the claims. The scope of the patent application is limited to embodiments that include only one such description, even if the same patent application scope includes the introductory phrase "one or more" or "at least one" and such as "one" or "one". The same is true for indefinite articles (for example, "a" and/or "a" should be interpreted to mean "at least one" or "one or more". This is also true when using definite articles to introduce the scope of the patent application. In addition, even if a specific number of patent application scopes are specifically recited, those skilled in the art will recognize that such a description should be interpreted to mean at least the recited (eg, in the absence of other modifiers) The unmodified narrative of "two narratives" means at least two narratives or two or more narratives). Moreover, in these examples, if a protocol similar to "at least one of A, B, and C, etc." is used, such a structure should generally have the meaning of the protocol as understood by those skilled in the art (for example, "System having at least one of A, B, and C" will include, but is not limited to, only having A, only having B, having only C, having A and B, having A and C, having B and C, and/or Systems with A, B, C, etc.). In instances where a protocol similar to "at least one of A, B, or C, etc." is used, such a structure should generally have the meaning of the protocol as understood by those skilled in the art (for example, "having A," A system of at least one of B or C" includes but is not limited to having only A, only having B, having only C, having A and B, having A and C, having B and C, and/or having A, B, and C, etc. Etc. system). It will be further understood by those skilled in the art that, in the specification, the scope of the claims, or the accompanying drawings, The possibility of one, any or both of the items. For example, the phrase "A or B" will be understood to include the possibilities of "A" or "B" or "A and B." In addition, the term "any one" as used herein that is followed by a series of multiple items and/or multiple item categories is intended to include items and/or project categories that are separate or combined with other projects and/or other item categories. "any one", "any combination", "any number of" and/or "any combination of multiples". Moreover, the term "set" as used herein is intended to include any number of items, including zero. Additionally, the term "amount" as used herein is intended to include any quantity, including zero.

Moreover, if the features or aspects of the present disclosure are described in terms of a Markush group, those skilled in the art will recognize that the present disclosure is thus in accordance with any single member or member of the Markush group. Group description.

All ranges disclosed herein are intended to cover any and all possible sub-ranges and sub-ranges thereof for any and all purposes. Any of the ranges listed can be readily considered to fully describe and enable the same range that is broken down into at least two equal parts, three equal parts, four equal parts, five equal parts, ten equal parts, and the like. As a non-limiting example, each of the ranges discussed herein can be easily broken down into the lower third, the middle third, and the upper third. Those skilled in the art will appreciate that all languages such as "at most", "at least", "greater than", "less than" and the like encompass the recited digits and are intended to be subsequently decomposed as described above. The range of subranges. Finally, as will be understood by those skilled in the art, a range will include each individual member. Thus, for example, a group having 1-3 cells refers to a group having 1, 2, or 3 cells. Likewise, a group having 1-5 units refers to a group having 1, 2, 3, 4, or 5 cells, and so on.

In addition, the scope of patent application should not be construed as being limited to the described order or elements. In addition, the term "means for" used in the scope of any patent application is intended to invoke 35 U.S.C. §112, ¶6 or device-plus-function patent application range format, and without the words " The scope of any patent application for "means for" does not have such a meaning.

100, 200‧‧‧ communication system
102, 102a, 102b, 102c, 102d, 202a, 202b, 302a, 302b ‧ ‧ WTRU
104‧‧‧Radio Access Network (RAN)
106, 340‧‧‧ core network
108‧‧‧Public Switched Telephone Network (PSTN)
110‧‧‧Internet
112‧‧‧Other networks
114a, 114b, 170a, 170b, 170c, 214‧‧ ‧ base station
116‧‧‧Intermediate mediation
118‧‧‧Processor
120‧‧‧ transceiver
122‧‧‧Transmission/receiving components
124‧‧‧Speaker/Microphone
126‧‧‧Keypad
128‧‧‧Display/Touchpad
130‧‧‧ Non-removable memory
132‧‧‧Removable memory
134‧‧‧Power supply
136‧‧‧Global Positioning System (GPS) chipset
138‧‧‧ Peripherals
140a, 140b, 140c‧‧‧ Node B
142a, 142b‧‧‧ Radio Network Controller (RNC)
144‧‧‧Media Gateway (MGW)
146‧‧‧Action Switching Center (MSC)
148‧‧‧Serving GPRS Support Node (SGSN)
150‧‧‧Gateway GPRS Support Node (GGSN)
160a, 160b, 160c‧‧‧e Node B
162‧‧‧Action Management Gateway (MME)
164‧‧‧ service gateway
166‧‧‧ Packet Data Network (PDN) Gateway
172‧‧‧Access Service Network (ASN) Gateway
174‧‧‧Action IP Local Agent (MIP-HA)
176‧‧‧Authorization and Authorization Accounting (AAA) Server
178‧‧‧Chute
301‧‧‧Transport network
303‧‧‧Data link old domain
304‧‧‧Inter-trip forwarding entity (XFE) domain
306, 308‧‧ ‧ subdomain
Section 310‧‧
312, 314, 324, 326, 328‧‧‧ Inter-trip forwarding entities (XFE)
316, 318, 319, 320, 330, 332‧‧‧ Cross-stroke Adaptation Unit (XAU)
322, 334‧‧‧ Ethernet switch
336, 388, 344‧‧‧ access network
342‧‧‧Baseband Unit (BBU) Server
346‧‧‧Firewall
348‧‧‧Old switch machine
350‧‧‧Network Controller
400‧‧‧MAC-in-MAC template
402‧‧‧MAC-in-MAC header
404‧‧‧B-Dest address field
406‧‧‧B-Src address field
500, 700, 800, 900‧‧‧ Cross-Travel Common Frame (XCF)
502‧‧‧XCF header
503‧‧‧XCF subsection
504‧‧‧XCF segmentation
506‧‧‧XCF source section
508‧‧‧XCF destination address section
510‧‧‧XCF Destination Control Section
512‧‧‧XCF source address section
514‧‧‧XCF source control section
516‧‧‧Emergency field
518‧‧‧ sequence field
520‧‧‧Multiple destinations
522‧‧‧Power Management Field
524‧‧‧ Grab the field
526‧‧‧protection frame
528‧‧‧More information fields
530‧‧‧Reserved fields
532‧‧‧Quality of Service (QoS) Profile/Traffic Field
534‧‧‧SN/TS field
536‧‧‧Sequence/time stamp field
600, 1000‧‧‧ network entities
601, 1001‧‧‧ Inbound 埠
603, 1003, 1408‧‧‧share switching layer
605, 1005‧‧‧ outbound information
611, 1011‧‧‧ frame discriminator
613, 615, 1013, 1015‧‧ ‧ forwarding decision entity
617, 619, 1017, 1019‧‧‧ listed management entities
705‧‧‧MAC-in-MAC part
707‧‧‧XCF header segment routing part
750-760, 850-860, 954-960‧‧‧ fields
804‧‧‧ activity segmentation
809‧‧‧Inactive segmentation
1021‧‧ ‧ Processing entity
Examples of 1201, 1203, 1205‧‧
1301‧‧‧MAC form
1412‧‧‧Inbound processing
1414‧‧‧Outbound processing
1416‧‧‧ queue management
1502, 1504, 1506, 1508, 1518, 1520, 1522, 1702, 1704, 1708, 1718; 1720, 1722‧ ‧ processing blocks
1800‧‧‧ representative process
IP‧‧‧Internet Protocol
XCF‧‧‧cross-trip sharing frame

A more detailed understanding can be obtained from the Detailed Description section given below by way of example with reference to the accompanying drawings. As in the Detailed Description, the figures in the figures are examples. As such, the drawings and detailed description are not to be considered as limiting, In addition, the same reference numerals ("ref.") in the drawings indicate the same elements, and wherein: FIG. 1A is a system diagram of an exemplary communication system in which one or more of the disclosed embodiments may be implemented; 1B is a system diagram of an exemplary wireless transmit/receive unit (WTRU) that can be used within the communication system shown in FIG. 1A; FIGS. 1C, 1D, and 1E are diagrams that can be shown in FIG. 1A. An exemplary radio access network used within a communication system and a system diagram of an example core network; FIG. 2 illustrates an example environment in which embodiments may be practiced or implemented; and FIG. 3 is a diagram showing crosshaul Block diagram of an example communication environment for a Common Frame (XCF) domain; Figure 4 is a block diagram showing an example template for a MAC-in-MAC frame; Figure 5 is a cross-talk common frame showing an example (XCF) block diagram; Figure 6 is a block diagram showing an example network entity in which embodiments may be practiced or implemented; Figure 7 is a block diagram showing an example XCF with segmented routing control; The figure shows an example XCF configured to support segmentation routing. Figure 9 is a block diagram showing an example fast rerouting mechanism for XCF with segmented routing control; Figure 10 is a block diagram showing an example network entity in which embodiments may be practiced or implemented; Figure 11 shows an example of XCF encapsulation and forwarding based on segmented routing processing supported by fast reroute in an Ethernet-compatible multi-link scenario; Figures 12 and 13 show the old A block diagram of an example of an Ethernet switch MAC table padding; Figure 14 is a block diagram showing an example of advanced XCF forwarding processing performed on a cross-trip forwarding entity (XFE); Figure 15 is a diagram showing A block diagram of an internal forwarding process of an example of XFE; Figure 16 is a block diagram showing an example of advanced XCF adaptation/conversion processing on a cross-stroke adaptation unit (XAU); Figure 17 is an example showing an example of XAU A block diagram of the internal forwarding process; FIG. 18 is a flow chart showing a representative process of the shared transmission for the cross-trip traffic; and FIG. 19 is a flow showing the representative process of the shared transmission for the cross-travel traffic Figure.

1800‧‧‧ representative process

Claims (26)

A method implemented in a network entity, the method comprising: receiving a plurality of MAC-in-MAC compatible frames, including a cross-trip shared frame (XCF); based on the received MAC-in-MAC The matching field of the compatible frame and the matching rule provided by the controller distinguish the XCF from other MAC-in-MAC compatible frames; for the XCF, obtain the XCF information arranged in the XCF; Obtain XCF information to perform forwarding; and perform a queue management process based on XCF management rules. The method of claim 1, further comprising: processing the other MAC-in-MAC compatible frame using any of the following: (i) an old forwarding and queue management process, and (ii) a forwarding and queue management process in accordance with a MAC-in-MAC compatible protocol for the other MAC-in-MAC compatible frames. The method of any of the preceding claims, further comprising: determining, for the XCF, from using the segmentation route from the XCF information, wherein performing forwarding is further based on segmentation routing information extracted from the XCF; Use the segmentation routing information of one segment to update the matching field. The method of claim 3, wherein the XCF is based on the instantiation of a template of the MAC-in-MAC protocol frame and an application of the segmentation route. The method of claim 3, wherein the XCF includes an ordered list of information indicating a fallback path for fast rerouting, the method further comprising: responsive to detecting that at least a portion of the previous path is unavailable, Use this ordered list of information indicating the fallback path for fast rerouting. The method of any of the preceding claims, wherein obtaining XCF information arranged in the XCF comprises: decoding the XCF; and processing the decoded XCF. The method of any of the preceding claims, further comprising: transmitting any of the XCF and other MAC-in-MAC compatible frames. A method as claimed in any one of the preceding claims, wherein the XCF is encoded for MAC-in-MAC protocol compatibility, and for any of shared forwarding and management for supporting the cross-travel traffic. The method of claim 8, wherein the XCF includes one or more MAC-in-MAC protocol fields encoded as any of the shared forwarding and management supporting the cross-travel traffic/ parameter. The method of any of the preceding claims, wherein the XCF comprises an XCF header. The method of claim 10, wherein the XCF header is based on an instantiation of a MAC-in-MAC header with control information encoded to allow MAC-in-MAC Any one of the agreement and the XCF domain forwarding control to forward the XCF appropriately. The method of claim 11, wherein the encoding for encoding the control information comprises allowing the MAC-in-MAC protocol and the XCF domain forwarding control to be used to interpret any type of encoding of the XCF. The method of claim 12, wherein the encoding encodes the control information such that the XCF header and any one of the XCFs are used after applying a function to some or all of the XCF headers. The MAC-in-MAC protocol and the XCF domain forwarding control are interpretable. The method of claim 12, wherein the encoding, by encoding the control information, arranging XCF domain control information without affecting the use of the MAC-in-MAC protocol to properly forward the XCF header of the XCF Between one or more parts. A network entity comprising a circuit, wherein the circuit includes a processor and a memory storing instructions executable by the processor, the circuit configured to: receive a plurality of MAC-in-MAC compatible frames, including Cross-stroke common frame (XCF); distinguishing the XCF from other MAC-in-MAC-compatible messages based on the matching field of the received MAC-in-MAC compatible frame and the matching rule provided by the controller a frame; for the XCF, acquiring XCF information arranged in the XCF; performing forwarding based on the acquired XCF information; and performing a queue management process based on the XCF management rule. The network entity of claim 15, wherein the circuit is configured to: process the other MAC-in-MAC compatible frame using any of: (i) legacy forwarding and The queue management process, and (ii) the forwarding and queue management process in accordance with a MAC-in-MAC compatible protocol for the other MAC-in-MAC compatible frames. A network entity comprising a circuit, the circuit comprising a processor and a memory storing executable instructions of the processor, the circuit configured to: receive a plurality of MAC-in-MAC compatible frames, including cross-stroke a common frame (XCF); distinguishing the XCF from other MAC-in-MAC compatible frames based on the matching field of the received MAC-in-MAC compatible frame and the matching rule provided by the controller; Obtaining XCF information arranged in the XCF for the XCF; determining, using the segmentation route from the XCF information; performing forwarding processing based on the acquired XCF information and segmentation routing information extracted from the XCF; The queue management process is performed based on the XCF management rules. The network entity of claim 17, wherein the circuit is configured to: for the XCF, update the matching field using a segmented segmentation routing information. The network entity of any one of clauses 15 to 18, wherein the circuitry configured to acquire XCF information disposed in the XCF comprises the circuitry configured to perform the following processing: decoding The XCF; and processing the decoded XCF. The network entity of any one of clauses 15 to 19, wherein the circuit is configured to transmit any of the XCF and other MAC-in-MAC compatible frames. The network entity of any one of clauses 15 to 20, wherein the XCF is encoded for MAC-in-MAC protocol compatibility, and for supporting the sharing of the cross-travel traffic. Any of forwarding and management. The network entity of any one of clauses 15 to 21, wherein the XCF includes an XCF header. The network entity of claim 22, wherein the XCF header is based on an example of a MAC-in-MAC header with control information, the control information being encoded to allow use of the MAC Any one of the -in-MAC protocol and the XCF domain forwarding control to properly forward the XCF. The network entity of claim 23, wherein the encoding for encoding the control information comprises allowing the MAC-in-MAC protocol and the XCF domain forwarding control to be used to interpret any type of encoding of the XCF. The network entity of claim 24, wherein the encoding process encodes the control information such that any one of the XCF header and the XCF is applied to some or all of the XCF headers. It is interpretable that the function uses the XCF domain forwarding control and uses the MAC-in-MAC protocol. The network entity of claim 24, wherein the encoding, by encoding the control information, arranging the XCF domain control information to the XCF standard that does not affect the proper forwarding of the XCF using the MAC-in-MAC protocol Between one or more parts of the head.