Method, architecture, apparatus, and system for enabling terminal mobility in a single-domain reliable and available network

Abstract

Procedures, methods, architectures, apparatus, systems, devices, and computer program products are described that enable, support, and / or enhance terminal mobility in reliable and available wireless (RAW) networks. One method may include receiving, by a target RAW network node, a message from a current RAW network node to which the WTRU is attached to initiate a RAW handover of the WTRU. The message may include information including at least one of an ID of the WTRU, an ID of the current RAW network node to which the WTRU is attached, an ID of a RAW domain to which the current RAW network node belongs, and / or a description of QoS parameters required by a flow between the WTRU and the external node. The method may include determining, based at least on the information provided in the message, a track and subtrack for supporting QoS for the flow between the WTRU and the external node, and sending an acknowledgement message to the current RAW network node including the ID of the WTRU and / or a description of the QoS parameters that are acceptable for the flow.

Description

[Background technology]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 63 / 411,851, filed September 30, 2022, the contents of which are incorporated herein by reference in their entirety.

[0002] In general, the present disclosure is directed to the fields of communications, software, and / or encoding, including, for example, to methods, architectures, apparatus, and systems related to enabling, supporting, and / or improving terminal mobility. [Prior art documents] [Non-patent literature]

[0003] [Non-Patent Document 1] CJ. Bernardos (ed.), “RAW use cases”, RFC9450, August 2023 [Non-patent document 2] P. Thubert (ed.), “Reliable and Available Wireless Architecture / Framework”, draft-ietf-raw-architecture-04, March 2022. [Non-patent document 3] F. Theoleyre, et al., "Operations, Administration and Maintenance (OAM) features for RAW," draft-ietf-raw-oam-support-04, February 2022. [Non-patent document 4] R. Koodli (ed.), “Mobile IPv6 fast handovers”, RFC5568, 2009. [Non-patent document 5] H. Yokota, et al., "Fast handovers for proxy mobile IPv6", RFC5949, 2010. [Non-patent document 6] C. Perkins (ed.), “Mobility Support in IPv6”, RFC6275, 2011. Summary of the Invention

[0004] Embodiments may be directed to a method that may be implemented by a wireless transmit / receive unit (WTRU). The method may include determining that a reliable and available wireless (RAW) handover of the WTRU is imminent and, based on the determination that a RAW handover of the WTRU is imminent, sending first information to a RAW network node to which the WTRU is currently attached. The first information may indicate (i) quality of service (QoS) parameters required during and after the RAW handover for a flow between the WTRU and the external node, (ii) whether bi-casting is requested, and (iii) any of an identifier of the WTRU, an identifier of a target RAW network node to which the WTRU desires to attach, and / or an identifier of a RAW domain to which the target RAW network node belongs. The method may include receiving second information indicating that the WTRU is authorized to perform the RAW handover. The second information may include an indication of an acceptable QoS for the flow and an identifier of a target RAW network node to which the WTRU should attach. The method may include performing a handover to attach to the target RAW network node.

[0005] Embodiments may be directed to a wireless transmit / receive unit (WTRU) including circuitry, which may include any of a transmitter, a receiver, a processor, and / or a memory. The circuitry may be configured to determine that a reliable and available wireless (RAW) handover of the WTRU is imminent and, based on the determination that a RAW handover of the WTRU is imminent, send first information to a RAW network node to which the WTRU is currently attached. The first information may indicate (i) quality of service (QoS) parameters required during and after the RAW handover for flows between the WTRU and the external node, (ii) whether bi-casting is requested, and (iii) any of an identifier of the WTRU, an identifier of a target RAW network node to which the WTRU desires to attach, and / or an identifier of a RAW domain to which the target RAW network node belongs. The circuitry may be configured to receive second information indicating that the WTRU is authorized to perform the RAW handover. The second information may include an indication of an acceptable QoS for the flow and an identifier of a target RAW network node to which the WTRU should attach. The circuitry may be further configured to perform a handover to attach to the target RAW network node.

[0006] Embodiments may be directed to a method that may be implemented by a network node, such as a target reliable and available wireless (RAW) network node. The method may include receiving a message from a current RAW network node to which the WTRU is attached, initiating a RAW handover of the WTRU. The message may be received from the current RAW network node, and the message may include information including any of an identifier of the WTRU, an identifier of the current RAW network node to which the WTRU is attached, an identifier of a RAW domain to which the current RAW network node belongs, and / or a description of quality of service (QoS) parameters requested by a flow between the WTRU and the external node. The method may include determining a track and subtrack to support QoS for the flow between the WTRU and the external node based at least on the information provided in the message. The method may include sending an acknowledgement message to the current RAW network node, the message including at least one of the identifier of the WTRU and a description of the QoS parameters that may be accepted for the flow.

[0007] Embodiments may be directed to an apparatus including a circuit, which may include any of a transmitter, a receiver, a processor, and / or a memory. The circuit may be configured to receive a message initiating a RAW handover of a wireless transmit / receive unit (WTRU) from a current RAW network node to which the WTRU is attached to the apparatus. The message may be received from the current RAW network node, and the message may include information including any of an identifier of the WTRU, an identifier of the current RAW network node to which the WTRU is attached, an identifier of a RAW domain to which the current RAW network node belongs, and / or a description of quality of service (QoS) parameters requested by a flow between the WTRU and an external node. The circuit may be configured to determine a track and subtrack for supporting QoS for the flow between the WTRU and the external node based at least on the information provided in the message. The circuit may be configured to send an acknowledgement message to the current RAW network node, the acknowledgement message including at least one of the identifier of the WTRU and a description of QoS parameters that are acceptable for the flow.

[0008] A more detailed understanding may be had from the following detailed description, given by way of example in conjunction with the drawings attached hereto. The figures in the drawings, as well as the detailed description, are examples. In the strictest sense, the figure(s) and detailed description are not to be considered limiting, and other equally effective examples are possible and likely. Moreover, like reference numerals ("ref") in the drawings indicate like elements. [Brief explanation of the drawings]

[0009] [Figure 1A] FIG. 1 is a system diagram illustrating an example communication system. [Figure 1B]1B is a system diagram illustrating an example WTRU (Wireless Transmit / Receive Unit) that may be used within the communication system illustrated in FIG. 1A. [Figure 1C] 1B is a system diagram illustrating an example RAN (Radio Access Network) and an example CN (Core Network) that may be used within the communication system illustrated in FIG. 1A. [Figure 1D] FIG. 1B is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system illustrated in FIG. 1A. [Figure 2] 1 is an example diagram of a system for communication involving a RAW (Reliable and Available Wireless) domain according to one example embodiment. [Figure 3A] FIG. 10 is an example diagram illustrating control plane signaling for UE-controlled RAW-enabled mobility according to some embodiments. [Figure 3B] FIG. 10 is an example diagram illustrating control plane signaling for UE-controlled RAW-enabled mobility according to some embodiments. [Figure 4A] FIG. 1 is an example diagram illustrating control plane signaling for network-controlled RAW-enabled mobility according to some embodiments. [Figure 4B] FIG. 1 is an example diagram illustrating control plane signaling for network-controlled RAW-enabled mobility according to some embodiments. [Figure 5] 10 is a diagram illustrating an example of a format of a message data field in a mobility header according to an embodiment. [Figure 6] 10 is an example of the format of a Message Data field in a Mobility Header according to some embodiments. [Figure 7] 1 is an exemplary format of a RAW_ID mobility option according to some embodiments. [Figure 8] 1 is an exemplary format of a PoA_ID mobility option according to some embodiments. [Figure 9] 10 is an exemplary format for a RAW QoS mobility option according to an embodiment. [Figure 10] 10 is an example of a PoA ID sub-element according to an embodiment. [Figure 11] 10 is an example of a PSE ID sub-element according to an embodiment. [Figure 12] FIG. 10 is a diagram illustrating an example of a RAW ID sub-element according to an embodiment. [Figure 13] 1 illustrates an example flowchart of a method for enabling, supporting, and / or improving terminal mobility in a Reliable and Available Wireless (RAW) network, according to some embodiments. [Figure 14] 1 illustrates an example flowchart of a method for enabling, supporting, and / or improving terminal mobility in a Reliable and Available Wireless (RAW) network, according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0010] In the detailed description that follows, numerous specific details are set forth to provide a thorough understanding of the embodiments and / or examples disclosed herein. It will be understood, however, that the above-described embodiments and examples may be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the description that follows. Moreover, embodiments and examples not specifically described herein may be practiced in place of, or in combination with, the embodiments and other examples explicitly, implicitly, and / or inherently described, disclosed, or otherwise provided herein (collectively "provided"). Although various embodiments are described and / or claimed herein in which apparatuses, systems, devices, etc. and / or any elements perform operations, processes, algorithms, functions, etc. and / or any parts, it will be understood that any embodiment described and / or claimed herein assumes that any apparatus, system, device, etc. and / or any element is configured to perform any operation, process, algorithm, function, etc. and / or any part.

[0011] The methods, apparatus, and systems provided herein are well suited for communications involving both wired and wireless networks. An overview of various types of wireless devices and infrastructure is provided with respect to Figures 1A-1D, and various elements of the networks may utilize, perform, be arranged in accordance with, and / or be adapted and / or configured for the methods, apparatus, and systems provided herein.

[0012] 1A is a system diagram of an exemplary communication system in which one or more disclosed embodiments may be implemented. Communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messaging, broadcasts, etc., to multiple wireless users. Communication system 100 may enable multiple wireless users to access such content through sharing of system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods such as, for example, CDMA (Code Division Multiple Access), TDMA (Time Division Multiple Access), FDMA (Frequency Division Multiple Access), OFDMA (Orthogonal Frequency Division Multiple Access), SC-FDMA (Single Carrier FDMA), ZT UW DTS-s OFDM (ZT (Zero-tail) UW (Unique-word) DFT (Discreet Fourier Transform) Spread OFDM), UW-OFDM (Unique Word OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0013] 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, radio access networks (RANs) 104 / 113, core networks (CNs) 106 / 115, public switched telephone networks (PSTNs) 108, the Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d may all be referred to as “stations” and / or “STAs,” may be configured to transmit and / or receive wireless signals, and may include (or be) user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as UEs.

[0014] Further, the communications system 100 may include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d, e.g., to facilitate access to one or more communications networks, such as the CN 106 / 115, the Internet 110, and / or the network 112. By way of example, the base stations 114a, 114b may be any of a BTS (wireless base station equipment), a Node-B (NB), an eNode-B (eNB), a HNB (home Node-B), a HeNB (home eNode-B), a gNode-B (gNB), a NR NB (NR Node-B), a site controller, an AP (access point), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0015] The base station 114a may be part of the RAN 104 / 113, which may further include other base stations and / or network elements (not shown), such as, for example, a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies and may be referred to as a cell (not shown). The frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for wireless services over a particular geographic area, which may be relatively fixed or may change over time. Furthermore, a cell may be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in an embodiment, the base station 514a may include three transceivers, i.e., one for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each or every sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

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

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

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

[0019] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as, for example, New Radio (NR) radio access, which may establish the air interface 116 using NR.

[0020] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement both LTE radio access and NR radio access, e.g., using dual connectivity (DC) principles. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0021] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a wireless technology such as, for example, IEEE 802.11 (i.e., Wireless Fidelity (Wi-Fi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GERAN (GSM EDGE), or the like.

[0022] 1A may be, for example, a wireless router, a Home Node-B, a Home eNode-B, or an access point and may utilize any suitable RAT to facilitate wireless connectivity in a localized area, such as, for example, a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, etc. In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as, for example, IEEE 802.11, to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as, for example, IEEE 802.15, to establish a wireless personal area network (WPAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) that establishes either a small cell, a pico cell, or a femto cell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106 / 115.

[0023] The RAN 104 / 113 may be in communication with the CN 106 / 115 and may be any type of network configured to provide voice, data, application, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have various quality of service (QoS) requirements, such as, for example, different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as, for example, user authentication. 1A, it will be understood that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs employing the same RAT as the RAN 104 / 113 or a different RAT. For example, the CN 106 / 115, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, may also be in communication with another RAN (not shown) employing any of GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or Wi-Fi.

[0024] Additionally, the CN 106 / 115 may 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 providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as transmission control protocol (TCP), user datagram protocol (UDP), and / or IP in the TCP / IP Internet Protocol suite. The network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the network 112 may include another CN connected to one or more RANs that may employ the same RAT as the RAN 104 / 114 or a different RAT.

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

[0026] 1B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1B, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a GPS (Global Positioning System) chipset 136, and / or other elements / peripherals 138. It will be understood that the WTRU 102 may include any sub-combination of the above elements without departing from the spirit and scope of the present invention.

[0027] The processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors in conjunction with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any of other types of integrated circuits (ICs), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other function that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120, which may be coupled to a transmit / receive element 122. While FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together, for example, in an electronic package or chip.

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

[0029] 1B as a single element, the WTRU 102 may include any number of transmit / receive elements 122. For example, the WTRU 102 may employ MIMO techniques. Thus, in an embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0030] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and to demodulate signals received by the transmit / receive element 122. As mentioned above, the WTRU 102 may have multi-mode capabilities. Thus, for example, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate over multiple RATs, such as NR and IEEE 802.11.

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

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

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

[0034] Additionally, the processor 118 may be coupled to other elements / peripherals 138, which may include one or more software and / or hardware modules / units that provide additional features, functionality, and / or wired or wireless connectivity. For example, the elements / peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (e.g., for photos and / or videos), a Universal Serial Bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth module, a frequency modulated FM (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, etc. The elements / peripherals 138 may include one or more sensors, which may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, a direction sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0035] The WTRU 102 may include a full-duplex radio where transmission and reception of some or all of the signals (e.g., associated with a particular subframe for both the uplink (e.g., for transmission) and downlink (e.g., for reception)) may be parallel and / or simultaneous. The full-duplex radio may include an interference management unit to reduce and or substantially eliminate self-interference, either by hardware (e.g., a choke) or signal processing by a processor (e.g., by a separate processor (not shown) or by the processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio where transmission and reception of some or all of the signals (e.g., associated with a particular subframe for either the uplink (e.g., for transmission) or downlink (e.g., for reception)) may be half-duplex.

[0036] 1C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As mentioned above, the RAN 104 may employ E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. Additionally, the RAN 104 may be in communication with the CN 106.

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

[0038] Each of the eNode-Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink (UL) and / or downlink (DL), etc. As shown in FIG. 1C , the eNode-Bs 160a, 160b, 160c may communicate with each other via an X2 interface.

[0039] 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. While each of the above-mentioned elements is depicted as part of the CN 106, it will be understood that any one of the just-mentioned elements may be owned and / or operated by an entity other than the CN operator.

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

[0041] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via an S1 interface. In general, the SGW 164 may route and forward user data packets to the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions such as anchoring the user plane during inter-eNode-B handovers, triggering paging when DL data is available to the WTRUs 102a, 102b, 102c, and managing and storing the context of the WTRUs 102a, 102b, 102c.

[0042] The SGW 164 may be connected to a PGW 166 that 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.

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

[0044] Although the WTRU is described in Figures 1A-1D as a wireless terminal, it is expected that in certain exemplary embodiments, such a terminal may use a wired communication interface (e.g., temporarily or permanently) with the communication network.

[0045] In an exemplary embodiment, the other network 112 may be a WLAN.

[0046] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or interface to a distribution system (DS) or another type of wired / wireless network that carries traffic into and out of the BSS. Traffic to a STA originating from outside the BSS may arrive through the AP and be delivered to the STA. Traffic originating from a STA to a destination outside the BSS may be sent to the AP for delivery to the respective destination. Traffic between STAs within a BSS may be routed through the AP, for example, where a source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be routed between (e.g., directly between) a source and destination STA via a direct link setup (DLS). In one exemplary embodiment, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (e.g., all STAs) may communicate directly with each other. The IBSS mode of communication is sometimes referred to herein as an "ad hoc" mode of communication.

[0047] When using the 802.11ac infrastructure mode of operation or a similar mode of operation, an AP may transmit beacons on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a width that is dynamically set by signaling. The primary channel may be the operating channel of the BSS and may be used by STAs to establish a connection with the AP. In a typical embodiment, CSMA / CA (Carrier Sense Multiple Access / Collision Avoidance) may be implemented in an 802.11 system, for example. With CSMA / CA, STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit in a given BSS at any given time.

[0048] For example, a HT (high throughput) STA may use a 40 MHz wide channel for communication by combining a 20 MHz primary channel with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0049] A very high throughput (VHT) STA may support channels of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz width. A 40 MHz and / or 80 MHz channel may be constructed by combining contiguous 20 MHz channels. A 160 MHz channel may be constructed by combining eight contiguous 20 MHz channels or by combining two non-contiguous 80 MHz channels, sometimes referred to as an 80+80 configuration. For the 80+80 configuration, after channel encoding, the data may pass through a segment parser, which may split the data into two streams. IFFT (inverse fast Fourier transform) processing and time-domain processing may be performed on each stream separately. The streams may be mapped onto two 80 MHz channels, and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations for the 80+80 configuration described above may be reversed and the combined data may be sent to the MAC (Media Access Control) layer, etc.

[0050] Sub-1 GHz modes of operation are supported by 802.11af and 802.11ah. The operating bandwidths of the channels and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TVWS (TV White Space) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to an exemplary embodiment, 802.11ah may support meter-type control / machine-type communication, such as MTC devices in macro coverage areas. MTC devices may have limited capabilities, including support (e.g., only support) for some and / or limited bandwidths. An MTC device may include a battery with a battery life above a threshold (eg, to maintain a very long battery life).

[0051] A WLAN system that may support multiple channels and channel bandwidths, e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah, includes a channel that may be designated as a primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in a BSS. The bandwidth of the primary channel may be set and / or limited by the STA that supports the smallest bandwidth operating mode among all STAs operating in the BSS. In an 802.11ah example, the primary channel may be 1 MHz wide for a STA (e.g., an MTC-type device) that supports (e.g., only supports) the 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) setting may depend on the state of the primary channel. If the primary channel is busy, for example, due to a STA (that only supports a 1 MHz mode of operation) transmitting to the AP, the entire available frequency band may be considered busy even though most of the frequency band may remain idle and available.

[0052] In the United States, the available frequency bands that may be used by 802.11ah are 902 MHz to 928 MHz. In South Korea, the available frequency bands are 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11ah is 6 MHz to 26 MHz, depending on the country code.

[0053] 1D is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As mentioned above, the RAN 113 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. Additionally, the RAN 113 may be in communication with the CN 115.

[0054] The RAN 113 may include gNBs 180a, 180b, and 180c, although it will be understood that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In an embodiment, the gNBs 180a, 180b, and 180c may implement MIMO techniques. For example, the gNBs 180a and 180b may utilize beamforming to transmit and / or receive signals to the WTRUs 102a, 102b, and 102c. Thus, for example, the gNB 180a may use multiple antennas to transmit and / or receive wireless signals to the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation techniques. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of the just-mentioned component carriers may be on a non-licensed spectrum while the remaining component carriers may be on a licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) techniques. For example, the WTRU 102a may receive coordinated transmissions from the gNBs 180a and 180b (and / or 180c).

[0055] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for separate transmissions, separate cells, and / or separate portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of different or scalable lengths (e.g., including different numbers of OFDM symbols and / or different absolute time lengths with persistence).

[0056] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without accessing another RAN (e.g., eNode-Bs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with a gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as, for example, an eNode-B 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-Bs 160a, 160b, 160c may act as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput in serving the WTRUs 102a, 102b, 102c.

[0057] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to user plane functions (UPFs) 184a, 184b, routing of control plane information to access and mobility management functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D , the gNBs 180a, 180b, 180c may communicate with each other via an Xn interface.

[0058] 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one SMF (Session Management Function) 183a, 183b, and possibly a DN (Data Network) 185a, 185b. While each of the above elements is depicted as part of the CN 115, it will be understood that any of the just-mentioned elements may be owned and / or operated by an entity other than the CN operator.

[0059] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling sessions of separate protocol data units (PDUs) with separate requirements), selecting a particular SMF 183a, 183b, managing registration areas, terminating NAS signaling, mobility management, etc. Network slicing may be used by the AMF 182a, 182b to customize CN support for the WTRUs 102a, 102b, 102c, for example, based on the type of service being utilized for the WTRUs 102a, 102b, 102c. For example, separate network slices may be established for separate use cases, e.g., services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services related to MTC access, etc. The AMF 162 may provide control plane functionality for switching between the RAN 113 and other RANs (not shown) employing other radio technologies, e.g., LTE, LTE-A, LTE-A Pro, etc., and / or non-3GPP access technologies, e.g., Wi-Fi.

[0060] The SMFs 183a and 183b may be connected to the AMFs 182a and 182b in the CN 115 via an N11 interface. Additionally, the SMFs 183a and 183b may be connected to the UPFs 184a and 184b in the CN 115 via an N4 interface. The SMFs 183a and 183b may select and control the UPFs 184a and 184b and configure the routing of traffic through the UPFs 184a and 184b. The SMFs 183a and 183b may perform other functions, such as managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0061] The UPFs 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface and may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks such as, for example, the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPFs 184, 184b may perform other functions such as, for example, routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, etc.

[0062] The CN 115 may facilitate communication with other networks. For example, the CN 115 may include or communicate with an IP gateway (e.g., an IMS (IP Multimedia Subsystem) server) that acts as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In an embodiment, the WTRUs 102a, 102b, 102c may be connected to local DNs (data networks) 185a, 185b through an N3 interface to the UPFs 184a, 184b, and the UPFs 184a, 184b via an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

[0063] 1A-1D and the corresponding description thereof, one or more or all of the functions described herein in connection with one or more of the WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other element(s) or device(s) described herein may be performed by one or more emulation elements / devices (not shown). The emulation devices may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functionality.

[0064] The emulation device may be designed to implement one or more tests of other devices in a lab environment and / or in an operator's network environment. For example, one or more emulation devices may perform one or more, or all, functions while fully or partially implemented and / or deployed as part of a wired and / or wireless communications network to test other devices in the communications network. One or more emulation devices may perform one or more, or all, functions while temporarily implemented / deployed as part of a wired and / or wireless communications network. The emulation device may be directly coupled to another device for testing purposes and / or may perform testing using over-the-air (OTA) wireless communications.

[0065] The one or more emulation devices may perform one or more functions, inclusive, while not implemented / deployed as part of a wired and / or wireless communications network. For example, the emulation devices may be utilized in testing laboratories and / or testing scenarios in undeployed (e.g., testing) wired and / or wireless communications networks to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include, e.g., one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0066] Based on time, resource reservation, and policy enforcement by a distributed shaper, Deterministic Networking provides the ability to carry designated unicast or multicast data streams for real-time applications with extremely low data loss rates and bounded latency, for example, to support time-sensitive and mission-critical applications in converged enterprise infrastructures.

[0067] Wireless operates in a shared medium, and transmissions cannot be completely deterministic due to uncontrolled interference, including self-induced multipath fading. The Internet Engineering Task Force (IETF) Reliable and Available Networking (RAW) is an effort to provide Deterministic Networking (DetNet) along paths that include at least one wireless element. RAW ensures high reliability and availability for Internet Protocol (IP) connectivity over wireless media. Wireless media presents significant challenges for achieving deterministic properties, such as low packet error rate, bounded sequential loss, and bounded latency. RAW extends the concepts of the IETF DetNet Working Group (WG) to ensure high reliability and availability for IP networks that utilize scheduled wireless segments and other media, such as frequency- and / or time-shared physical media resources with probabilistic traffic, such as IEEE Standard 802.15.4 time slotted channel hopping (TSCH), Third Generation Partnership Project (3GPP) 5G ultra-reliable low latency communication (URLLC), IEEE 802.11ax / be, and L-band Digital Aeronautical Communications System (LDACS). Like DetNet, RAW technology aims to maintain abstraction below the wireless layer and address the Layer 3 aspects of supporting applications that require high reliability and availability.

[0068] The RAW architecture framework (see, for example, Non-Patent Document 2) may include the following key RAW operations: RAW distinguishes between long and short forwarding timescales, where the long timescale is used for route computation and the short timescale is used more for per-packet forwarding decisions; RAW operates in the network plane at the forwarding timescale of a single DetNet flow with a complex path called a track; tracks may be pre-established and deployed by means outside the scope of RAW, and tracks may be strict or loose, depending on whether each hop or just a subset of hops is observed and controlled by RAW.

[0069] The RAW architecture is structured as an OODA loop with the following steps: Observe, Orient, Decide, Act (OODA). "Observe" refers to network-plane measurement protocols for operations, administration, and maintenance (OAM) observing end-to-end packet delivery as well as some or all hops along the track. "Orient" refers to controller-plane elements reporting link statistics to a path computation element (PCE) in a centralized controller, which computes and implements the track and provides metadata that directs routing decisions. "Decide" refers to the runtime distributed path selection engine (PSE) determining the subtrack to be used for the next packet(s) routed along the track. "Act" refers to the data-plane operations of packet (hybrid) automatic repeat request (ARQ), replication, elimination, and ordering that operate at the DetNet service layer to enhance end-to-end transmission reliability. Additionally, the RAW architecture covers signaling in place once a decision is made by a node along the path from the PSE down the track.

[0070] The overall OODA loop optimizes the use of redundancy to achieve the reliability and availability required by the Service Level Agreement (SLA) while minimizing the use of constrained resources such as spectrum and batteries.

[0071] As explained above, RAW separates the path computation time scale, during which complex paths are recomputed, from the path selection time scale, during which forwarding decisions are made for one or a few packets. RAW operates on the path selection time scale. The RAW problem is to determine which of the alternative solutions proposed by the Path Computation Element (PCE) should be used for each packet to provide reliable and available service while minimizing the waste of constrained resources. In this sense, RAW defines a PSE, a counterpart of the PCE, that performs rapid local adjustments of forwarding tables within the diversity of the tracks selected by the PCE. The PSE can take advantage of richer forwarding capabilities, including PAREO (packet (hybrid) ARQ, replication, elimination, and ordering) and scheduled transmissions at faster time scales.

[0072] As introduced above, a track means a networking graph that can be followed to transmit packets with equal treatment, and in contrast to the definition of a path above, a "track" is not necessarily linear: a track may contain multiple paths that may branch and recombine, for example to allow for RAW PAREO operations.

[0073] In DetNet terminology, a track may have the following properties: (i) the track has one Ingress node and one Egress node that operate as DetNet edge nodes; (ii) the track is reversible, meaning that packets can be routed back to the Ingress against the flow of data packets, e.g., carrying OAM or control measurements; (iii) the vertices of the track are DetNet relay nodes that operate at the DetNet service sublayer and provide PAREO functionality; and (iv) the topological edges of the graph are sequential sequences of DetNet transit nodes that operate at the DetNet forwarding sublayer.

[0074] A sub-track is a track within a track. The RAW PSE may select a sub-track on a packet-by-packet or group-of-packets basis to provide the desired reliability for the transmitted flow.

[0075] The IEEE 802.11 standard defines a mechanism for STAs to request neighbor reports from APs, which may contain information about other APs (e.g., belonging to the same extended service set or different ones). A neighbor report request may be sent to an AP, which returns a neighbor report containing information about known neighboring APs that are candidates for service set transition. The neighbor report may contain information about neighboring APs. The request / report pair just described allows STAs to obtain information about the neighborhood of an associated AP to be used as potential roaming candidates.

[0076] An example of a Neighbor Report format (e.g., as defined in section 9.4.2.37 of the IEEE 802.11-2016 standard) is shown in Table 1 below.

[0077] [Table 1]

[0078] There can be several use cases (see, for example, Non-Patent Document 1), however, reliability and availability may be key requirements for wireless heterogeneous networks. One example is, for example, XR (eXtended Reality) applications, such as immersive gaming, digital twinning, etc. In the just-mentioned environment, UEs may move and change their points of attachment, while they demand strict and predictable behavior in terms of latency and / or resilience and / or availability and / or throughput.

[0079] FIG. 2 illustrates an example system 200 for communication including a RAW domain, according to an example embodiment. As shown in the example of FIG. 2, the system 200 may include one or more RAW nodes, e.g., Node 1-1, Node 1-2, Node 1-3, Node 1-4, and Node 1-5. While five RAW nodes are depicted in the example of FIG. 2, it should be understood that this is for illustrative purposes only and that any number of RAW nodes may be included according to some embodiments. In the example of FIG. 2, mobile UE(s), e.g., UE1, is running an XR application 205 that may request connectivity with strict QoS to an XR server 210. In contrast to a static scenario in which possible “tracks” (and therefore “sub-tracks”) do not change due to mobility, a mobility scenario poses additional complexities that have not yet been tackled.

[0080] Control plane solutions need to handle mobility well, for example by proactively preparing the network for changes in the UE's point of attachment and the impact this has in terms of new sub-tracks used for traffic. This requires inter-PSE coordination for handover preparation. L2 specific extensions can be used to help the UE decide where to roam if stringent conditions need to be maintained (e.g., requiring RAW support).

[0081] The IETF DETNET and RAW WGs are responsible for defining data plane and control plane mechanisms to support deterministic networking in wired and wireless multi-hop networks. However, current solutions are limited to static scenarios where neither the UE nor internal and / or local network nodes move.

[0082] The example embodiments described herein may provide at least a solution for solving the UE mobility problem in a single-domain RAW network. For example, some embodiments may be directed to the need for a UE to signal a single-domain RAW transport network about an impending handover and carry QoS requirements to be maintained during and after the movement to another PSE. Furthermore, some embodiments may be directed to the need for a mobile network to signal a single-domain RAW transport network about an impending handover and carry QoS requirements to be maintained during and after the movement to another PSE. Furthermore, some embodiments may be directed to what messages need to be exchanged between RAW nodes (e.g., PSEs) to prepare and coordinate the impending UE handover so that application QoS can be maintained.

[0083] Some embodiments of the present disclosure may define and / or provide new RAW-specific UE-PSE and PSE-to-PSE interactions. The just-described interactions may enable a UE to move within the RAW domain while maintaining the QoS required for the UE's flow(s). The just-described interactions may be defined to (i) enable the network to react ahead of the UE's mobility, e.g., by calculating the track and subtrack required by the UE at its future location, and / or (ii) support temporal bicasting, e.g., during L2 handover, to maximize resilience.

[0084] As described in more detail below, embodiments may provide a RAW control plane solution that addresses terminal mobility, for example, by proactively preparing the RAW network for changes in the terminal's point of attachment. Some embodiments may provide inter-PSE coordination signaling for handover preparation, providing both a terminal and network control approach. Further embodiments may provide Mobile IPv6 extensions that implement the above-described control plane solutions. Additionally, some embodiments may provide L2-specific extensions that help a terminal or UE determine where to roam if stringent conditions need to be maintained (e.g., requiring RAW support).

[0085] As introduced above, certain example embodiments may provide and / or configure RAW control plane extensions for UE mobility. Figures 3A and 3B illustrate example diagrams depicting control plane signaling for UE-controlled RAW-enabled mobility according to some embodiments.

[0086] The examples of Figures 3A and 3B depict example operations and signaling when a UE moves from one Point of Attachment (PoA) (node1-1) to another PoA (node1-2) within a RAW domain. Signaling extensions between the UE and the RAW domain and between the PSEs are shown in Figures 3A and 3B. In the example just described, it may be assumed that the UE is running an XR application that demands stringent QoS and is therefore required from the DETNET / RAW solution. What has just been described creates a flow between the UE and an external node, an XR server in the example just described. However, the external node could be another type of node or server. In the example just described, a single RAW domain is considered; however, multiple RAW domains may be envisioned. It may be assumed that mechanisms for setting up the just described flows are already in place.

[0087] As illustrated in the examples of FIGS. 3A and 3B, at 300, optionally, different PoAs in the RAW domain could advertise RAW-specific information, for example, using L2 extensions. This information could be obtained, for example, using the IEEE 802.11 neighbor report extensions described above, or by other mechanisms. This information could assist a UE in deciding whether and where to move (e.g., taking into account local policies and advertised capabilities for each available PoA). Some non-limiting example information elements (IEs) that the advertisement (e.g., beacon) described above could include for each available PoA in a region are PoA_ID, PSE_ID, and / or RAW_ID. PoA_ID is a unique identifier (within the RAW domain) of the PoA. PoA_ID could have the form of an L2 / L3 address or any other identifier (ID). PSE_ID is a unique identifier (within the RAW domain) of the PSE associated with the PoA. In most cases, every RAW node will have a co-located PSE instance. It may have an L2 / L3 address or any other form of ID. The RAW_ID is a unique identifier for the RAW domain. As an example of a technique to carry the advertisements just mentioned, IEEE 802.11 neighbor reports can be used.

[0088] 3A and 3B, the UE may detect or determine that a handover (HO) is imminent at 305 (e.g., depending on purely radio conditions or whether other factors are also taken into account) and send a message (e.g., a RAW HO indication) to the network, e.g., to the current PoA, at 310. In some embodiments, the just-mentioned message may include one or more of the following: UE_ID: UE identifier, nPoA_ID: Identifier of the new PoA to which the UE is most likely to attach. It may have an L2 / L3 address or any other form of ID. nRAW_ID: A unique identifier of the RAW domain to which the nPoA belongs. Some embodiments may be directed to the case of mobility within the same RAW domain. QoS: A description of the QoS parameters demanded by the flow, which could be one of a set of several parameters, e.g., latency, resiliency, throughput, etc.; and / or ● Bi-casting Requested (Y / N): Whether the UE requests bi-casting of traffic during handover for extra resilience. If not requested, the network may still do as deemed necessary to grant the requested QoS.

[0089] It is noted that some of the just mentioned parameters could have been learned through the optional beaconing mentioned in step 300 or any other means. It is further noted that beacons could also be used to help the UE filter or rank potential target PoAs, for example based on RAW support and the domains they belong to.

[0090] As illustrated in the examples of FIGS. 3A and 3B , at 320, the current PoA (e.g., Node 1-1) may send a RAW handover initiate (e.g., RAW_HO_initiate) message to the target new PoA (e.g., Node 1-2). In the just-described embodiments, the UE may be considered to be the entity that performs the PoA selection. The selection process may be considered to be performed using radio measurements, a required throughput from the UE side, an available throughput from the RAW node side, etc. Thus, the UE may also indicate the target PoA in the message sent at 320. In some embodiments, the just-described message may include one or more of the following: UE_ID: Identifier of the UE to which handover is to be performed; oPoA_ID: Identifier of the current (old) PoA to which the UE is currently attached. It may have an L2 / L3 address or any other form of ID. oRAW_ID: a unique identifier of the RAW domain to which the oPoA belongs. Some embodiments may be directed to the case of mobility within the same RAW domain, and / or QoS: A description of the QoS parameters demanded by the flow. For example, it could be one of a set of several parameters, such as latency, resiliency, or throughput.

[0091] It is noted that the new PoA (nPoA) can generally be obtained from the message sent by the UE at 310, but if the UE does not provide the information, the network may make the selection based on the demanded QoS, the UE's current location, and / or additional information the network may have. In that case, the target nPoA (e.g., node 1-2) can be communicated to the UE in the message sent at 350.

[0092] In the example of Figures 3A and 3B, at 330, the nPoA may calculate the tracks and subtracks required to support the QoS of the flow by using the RAW mechanism based on the information provided in the message received at 320.

[0093] 3A and 3B, nPoA may send an acknowledgement message (e.g., RAW_HO_ACK) to the old PoA (e.g., node 1-1) at 340. In some embodiments, the just-mentioned acknowledgement message may include one or more of the following: UE_ID: Identifier of the UE to which handover is to be performed, and / or QoS: A description of the QoS parameters that can be tolerated for the flow. For example, this could be one of a set of several parameters, such as latency, resiliency, throughput, etc. Note that this could be equal to or lower than the QoS requested in 320.

[0094] For example, according to some embodiments, if it is not possible to support the requested QoS, the nPoA may propose a lower QoS in the acknowledgement message sent at 340 .

[0095] 3A and 3B, at 350, the old PoA (oPoA) may send a command message (e.g., RAW HO ACK) to the UE indicating that the UE can now perform L2 handover and provide the accepted QoS and target PoA. According to some embodiments, at 360, substantially in parallel with the message sent at 350, as an optional feature determined by the network, a bi-casting procedure may be initiated in which downlink (DL) traffic received by the oPoA is duplicated and sent to the nPoA to minimize packet loss during the actual L2 handover. The just-described bi-casting procedure may be implemented by using the Packet Replication, Elimination, and Ordering Function (PREOF) defined by IETF DETNET.

[0096] As illustrated in the examples of Figures 3A and 3B, at 365, the UE may perform an L2 handover to attach to an nPoA (e.g., Node 1-2). Upon detection of the UE's attachment by the nPoA, a RAW mechanism may be used to activate the subtracks required for the UE's flows at the new location. As illustrated at 370, RAW signaling may be used to set up new forwarding states and / or to use the new subtracks. Optionally, as shown at 380, once all required RAW forwarding states are met, Bi-casting can be stopped if the just-described feature is initiated.

[0097] 4A and 4B illustrate example diagrams depicting control plane signaling for network-controlled RAW-enabled mobility according to some embodiments. More specifically, FIGS. 4A and 4B depict example operations and signaling when a UE moves from one PoA (e.g., node1-1) to another PoA (e.g., node1-2) within a RAW domain. In the examples of FIGS. 4A and 4B, mobility may be detected and handled by the network with low (or no) involvement from the UE (e.g., as is the case in 3GPP-based networks). In the just-described example, it may again be assumed that the UE is running an XR application that demands strict QoS and is therefore required by the DETNET / RAW solution. This creates a flow between the UE and an external node, an XR server in the just-described example. However, further examples are possible according to some embodiments. In the just-described example, a single RAW domain is considered. However, multiple RAW domains may be envisioned according to other embodiments. It may be assumed that the mechanisms for setting up the flow just described have already occurred.

[0098] As illustrated in the examples of FIGS. 4A and 4B, UE connectivity for traffic flows with stringent QoS requirements is established between the UE and an external node. In the examples of FIGS. 4A and 4B, the UE may be moving at 405, e.g., a handover is imminent to a new PoA. The impending handover may be determined by the UE or may be triggered or commanded by the network. In the example of FIG. 4, the network may control the handover by using, for example, 3GPP availability reports and knowledge of the UE's location. As illustrated in 410, the network may initiate the process by sending a message (e.g., a RAW HO indication) to the current PoA (oPoA, e.g., node 1-1). As used herein, the term "network" is intended to be as general as possible and does not exclude all possible options, but examples of network entities that may send the message at 410 may include an access and mobility management function (AMF), a gNB, a user plane function (UPF), an IEEE 802.11 access point, or the like. In an embodiment, the just-mentioned message (eg, RAW HO indication) may include one or more of the following: UE_ID: UE identifier, nPoA_ID: Identifier of the new PoA to which the UE is most likely to attach. It may have an L2 / L3 address or any other form of ID. nRAW_ID: A unique identifier of the RAW domain to which the nPoA belongs. In the scope of this disclosure, this is only for mobility within the same RAW domain. QoS: A description of the QoS parameters demanded by the flow, which could be one of a set of several parameters, e.g., latency, resiliency, throughput, etc.; and / or ● Bi-casting Requested (Y / N): Whether the UE requests bi-casting of traffic during handover for extra resilience. If not requested, the network may still do as deemed necessary to grant the requested QoS.

[0099] 4A and 4B, the network may trigger the following signaling at 415: At 420, the current PoA (e.g., node 1-1) may send a RAW Handover Initiate (e.g., RAW HO Initiate) message to the target new PoA (e.g., node 1-2). According to some embodiments, the just-mentioned message may include one or more of the following: UE_ID: Identifier of the UE to which handover is to be performed; oPoA_ID: Identifier of the current (old) PoA to which the UE is currently attached. It may have an L2 / L3 address or any other form of ID. oRAW_ID: a unique identifier of the RAW domain to which the oPoA belongs. Some embodiments may be directed to the case of mobility within the same RAW domain, and / or QoS: A description of the QoS parameters demanded by the flow. For example, it could be one of a set of several parameters, such as latency, resiliency, or throughput.

[0100] 4A and 4B, at 430, with the information provided in the message received at 420, the nPoA (e.g., node 1-2) may calculate the track and / or subtrack required to support the QoS of the flow, for example, by using the RAW mechanism. At 440, the nPoA may send an acknowledgement message (e.g., RAW HO ACK) to the old PoA. According to some embodiments, the acknowledgement message may include one or more of the following: UE_ID: Identifier of the UE to which handover is to be performed, and / or QoS: A description of the QoS parameters that can be tolerated for the flow. It could be one of a set of several parameters, for example, latency, resiliency, throughput, etc. It is noted that the tolerated QoS could be equal to or lower than the QoS requested in the message at 420.

[0101] In some embodiments, if it is not possible to support the requested QoS of the flow, the nPoA may propose a lower QoS when sending the message at 440 .

[0102] 4A and 4B, at 450, the old PoA may send a command message (e.g., RAW HO ACK) to the UE indicating that the UE can now perform L2 handover and providing an indication of the accepted QoS and target PoA. In some embodiments, substantially in parallel with the message at 450, as an optional feature determined by the network, a bi-casting procedure may be initiated at 460 in which downlink (DL) traffic received by the oPoA is duplicated and sent to the nPoA as well, e.g., to minimize packet loss during the actual L2 handover. The just-described bi-casting procedure may be implemented by using the Packet Replication, Elimination, and Ordering Function (PREOF) defined by IETF DETNET.

[0103] In the example of Figures 4A and 4B, the UE may perform an L2 handover and attach to an nPoA (e.g., Node 1-2) at 465. Upon detection of the UE's attachment by the nPoA, a RAW mechanism may be used to activate the subtracks required for the UE's flows at the new location. At 470, RAW signaling may be used to set up a new forwarding state and / or a new subtrack. Once the required RAW forwarding state is in place, at 480, Bi-casting can be stopped if the just-described feature is initiated.

[0104] The control plane extensions introduced above can be implemented by different protocols. For example, some embodiments may provide or specify Proxy Mobile IPv6 and Proxy Mobile IPv6 fast handover extensions. In some embodiments, the RAW HO Initiate and RAW HO ACK messages can be implemented by extending the Handover Initiate (HI) and Handover Acknowledgement mobility headers RFC5568 (Non-Patent Document 4), RFC5949 (Non-Patent Document 5).

[0105] Some embodiments may provide or configure an extension to the HI message of RFC 5568 and RFC 5949. Figure 5 illustrates an example format of a message data field in a Mobility Header according to an embodiment. The IP field may include a source address (e.g., an IP address of the oPoA) and / or a destination address (e.g., an IP address of the nPoA). The Message Data may include one or more of the following: Sequence # (e.g., may be the same as defined in RFC5568), an "S" flag (e.g., as defined in RFC5568 and set to zero in this embodiment), a "U" flag (e.g., a buffer flag, which may be the same as defined in RFC5568), a "P" flag (e.g., a proxy flag used to distinguish the message from that defined in RFC5568 and which is set), an "F" flag (e.g., a forwarding flag used to request setting up Bi-casting for the just-mentioned flow), a spare (e.g., may be the same as defined in RFC5568), and a Code (e.g., where RFC5568 defines the just-mentioned field and its values, 0 and 1, the Code is set to zero according to some embodiments). The Mobility Options field may include one or more mobility options, and the encoding and format are defined in RFC6275 (Non-Patent Document 6).

[0106] To uniquely identify the target UE, a UE identifier is included in the Mobile Node Identifier option. This option may be used to carry the UE_ID parameter described herein with respect to some embodiments. In accordance with some embodiments, one or more of the following new options (as discussed above): RAW_ID, PoA_ID, and / or QoS may be used in the extended HI message of FIG. 5.

[0107] Some embodiments may configure or define an extension of the Handover Acknowledgement (Hack) message in RFC 5568. Figure 6 shows an example of the format of the Message Data field in the Mobility Header according to some embodiments. The IP field may include a source address (e.g., copied from the destination address of the Handover Initiate message to which the just-mentioned message is a response) and / or a destination address (e.g., copied from the source address of the Handover Initiate message to which the just-mentioned message is a response). For the Message Data, the handling of the Sequence # and reserved fields may be the same as in RFC 5568. Additionally, the Message Data may include a "U" flag (e.g., a buffer flag that may be the same as defined in RFC 5568), a "P" flag (e.g., a proxy flag that may be set and used to distinguish messages from those defined in RFC 5568), an "F" flag (e.g., a forwarding flag that may be used to request bicast setup for the just-mentioned flow), a spare (e.g., the same as defined in RFC 5568), and a Code (e.g., RFC 5568 defines the just-mentioned field and its values ​​0 (Handover Accepted or Successful) through 4 and 128 through 130; values ​​131 and 132 are defined in RFC 5949). For purposes of RAW mobility, a new value, 133, is defined for the Code field to indicate that the requested QoS is not acceptable and / or a lower QoS is proposed. The Mobility Options field contains one or more mobility options, and the encoding and format are defined in RFC 6275. The mobility options that uniquely identify the target mobile node are copied from the corresponding RAW HO Initiation message. In some embodiments, the following new options may be used in the just-mentioned messages: RAW_ID, PoA_ID, and / or RAW QoS.

[0108] Some example embodiments may provide or configure a new mobility option. Figure 7 illustrates an example format of a RAW_ID mobility option according to some embodiments. As illustrated in the example of Figure 7, the RAW_ID mobility option may include an Option Type field, an Option Length field, a RAW ID Length field, a RAW ID field, and a reserved field. In example embodiments, the Option Length may be an 8-bit unsigned integer (e.g., the length of the option in octets excluding the Option Type and Option Length fields), the RAW ID Length may be an 8-bit unsigned integer (e.g., the length of the RAW ID field in octets), and the RAW ID may be a variable-length field that identifies the RAW domain.

[0109]

[0047] Figure 8 illustrates an exemplary format of a PoA_ID mobility option according to some embodiments. As illustrated in the example of Figure 8, the PoA_ID mobility option may include an Option Type field, an Option Length field, a PoA ID Length field, a PoA ID Format field, and a PoA ID field. In an exemplary embodiment, the Option Length may be an 8-bit unsigned integer (e.g., the length of the option in octets excluding the Option Type and Option Length fields), the PoA ID Length may be an 8-bit unsigned integer (e.g., the length of the PoA ID field in octets), and the PoA ID Format is an 8-bit unsigned integer (e.g., identifies the format of the PoA ID. Possible values ​​may be 0 (reserved), 1 (IP address - v4 or v6, determined by the length of the PoA ID), 2 (L2 address - 48 bits or 64 bits, determined by the length of the PoA ID), 3 (URI), and 4-255 (reserved for future use)), and the PoA ID (e.g., a variable-length field identifying the PoA).

[0110] 9 illustrates an exemplary format for a RAW QoS mobility option according to an embodiment. As depicted in the example of FIG. 9, the RAW QoS mobility option may include an Option Type field, an Option Length field, a MinBandwidth field, a MaxLatency field, a MaxLatencyVariation field, a MaxLoss field, a MaxConsecutiveLossTolerance field, and a MaxMisordering field. In an exemplary embodiment, Option Length may be an 8-bit unsigned integer (e.g., the length of the option in octets, excluding the Option Type and Option Length fields, which may be set to 24), MinBandwidth may be a 32-bit unsigned integer (e.g., MinBandwidth is the minimum bandwidth that must be guaranteed for the flow. MinBandwidth is specified in octets per second), MaxLatency may be a 32-bit unsigned integer (e.g., MaxLatency is the maximum latency from ingress to egress(es) of a single packet of the flow. MaxLatency is specified as an integer number of nanoseconds), and MaxLatencyVariation may be a 32-bit unsigned integer (e.g., MaxLatencyVariation is the difference between the minimum and maximum end-to-end one-way latency).MaxLatencyVariation is specified as an integer in nanoseconds), and MaxLoss can be a 32-bit unsigned integer (e.g., MaxLoss is the maximum packet loss rate for a flow between Ingress and Egress(es)). MaxConsecutiveLossTolerance may be a 32-bit unsigned integer (e.g., some applications have special loss requirements, such as MaxConsecutiveLossTolerance. The MaxConsecutiveLossTolerance parameter describes the maximum number of consecutive packets that are allowed to be lost. The MaxConsecutiveLossTolerance can be measured, for example, based on sequence numbers), and MaxMisordering may be a 32-bit unsigned integer (e.g., MaxMisordering describes the maximum allowed number of packets that can be received out of order. A value of 0 for MaxMisordering indicates that in-order delivery is required, and no misordering can be tolerated. The MaxMisordering can be measured, for example, based on sequence numbers. When a packet arrives at egress after a packet with a higher sequence number, the difference in sequence number values ​​cannot be larger than "MaxMisordering+1").

[0111] Some embodiments may provide or configure a method for extending the neighbor report. As an example of an L2-specific solution for advertising RAW capabilities to roaming UEs, the method may extend the neighbor report by adding new sub-elements to the NeighborListSet defined in section 9.4.2.37 of the IEEE 802.11-2016 standard. According to some embodiments, the sub-elements may include a PoA ID sub-element, a PSE ID sub-element, and a RAW ID sub-element.

[0112] 10 illustrates an example of a PoA ID sub-element according to an embodiment. As shown in the example of FIG. 10, the PoA ID sub-element may include a sub-element ID to be assigned by IEEE, a length field indicating the length of the PoA ID, and a PoA ID field indicating the ID of the PoA.

[0113] 11 illustrates an example of a PSE ID subelement according to an embodiment. As shown in the example of FIG. 11, the PSE ID subelement may include a subelement ID to be assigned by the IEEE, a length field indicating the length of the PSE ID, and a PSE ID field indicating the ID of the PSE.

[0114] 12 illustrates an example of a RAW ID sub-element according to an embodiment. As shown in the example of FIG. 12, the RAW ID sub-element may include a sub-element ID to be assigned by IEEE, a length field indicating the length of the RAW ID, and a RAW ID field indicating the ID of the RAW domain.

[0115] FIG. 13 is an example flow diagram illustrating an example method for enabling, supporting, and / or enhancing terminal mobility in a reliable and available wireless (RAW) network, according to some exemplary embodiments. The example method of FIG. 13 and the disclosures accompanying this specification may be considered a generalization or combination of the various disclosures set forth above. For ease and simplicity of explanation, the example of FIG. 13 may be described with reference to the architectures or systems described above, for example, with respect to FIGS. 1A-1D and / or 2. However, the example method depicted in FIG. 13 may likewise be performed using different architectures. According to some embodiments, the method of FIG. 13 may be implemented by a UE or WTRU, such as, for example, the WTRU 102 described above. For example, in one embodiment, the method of FIG. 13 may be implemented by a UE 1 as illustrated in FIGS. 2, 3A, 3B, 4A, and / or 4B and described above. As noted above, the method of Figure 13 may be modified to include any of the steps, procedures, and / or details illustrated in the examples of Figures 2, 3A, 3B, 4A, and / or 4B. Additionally, it is noted that the method and / or blocks of Figure 13 may be modified to include or replace any one or more of the procedures or blocks described elsewhere herein. As noted above, those skilled in the art will understand that Figure 13 is provided by way of example and that modifications are possible while remaining within the scope of certain exemplary embodiments.

[0116] 13, the method may include determining that a reliable and available wireless (RAW) handover of the WTRU is imminent at 1305. For example, a RAW handover of the WTRU may be imminent if, for example, it is configured to occur (e.g., is about to occur) within a certain time period or threshold, which may be determined based on, for example, radio conditions, mobility, and / or other factors.

[0117] In some demonstrative embodiments, based on a determination that a RAW handover of the WTRU is imminent, the method may include, at 1310, sending first information to a RAW network node to which the WTRU is currently attached. For example, the first information may include and / or indicate any one or more of: (i) quality of service (QoS) parameters required during and after the RAW handover for flows between the WTRU and the external node; (ii) whether Bi-casting is requested; and / or (iii) an identifier of the WTRU, an identifier of a target RAW network node to which the WTRU desires to attach, and / or an identifier of a RAW domain to which the target RAW network node belongs. In accordance with some examples, the RAW network node currently serving the WTRU and / or the target RAW network node may be or include a Point of Attachment (PoA) within the RAW domain. In some demonstrative embodiments, the QoS parameters may be or include one or more of latency, resiliency, and / or throughput parameters.

[0118] According to an example embodiment, as illustrated in the example of Figure 13, the method may include receiving 1315 second information indicating that the WTRU is authorized (e.g., is capable of or is enabled) to perform a RAW handover. In one example, the second information may include an indication of an acceptable QoS for the flow and an identifier of a target RAW network node to which the WTRU should attach. As shown in the example of Figure 13, the method may include, at 1320, performing the handover to attach to the target RAW network node.

[0119] 13, the method may optionally include receiving RAW-specific information that assists the WTRU in determining that a handover is imminent and / or that assists the WTRU in determining a target RAW network node to which it wishes to attach. According to some examples, the RAW-specific information includes any of a Point of Attachment (PoA) identifier, an identifier of a path selection engine (PSE) associated with the Point of Attachment (PoA), and / or an identifier of a RAW domain.

[0120] FIG. 14 is an exemplary flow diagram illustrating an example method for enabling, supporting, and / or improving terminal mobility in a reliable and available wireless (RAW) network, according to some exemplary embodiments. The example method of FIG. 14 and the disclosures accompanying this specification may be considered a generalization or combination of the various disclosures set forth above. For ease and simplicity of explanation, the example of FIG. 14 may be described with reference to the architectures or systems described above, for example, with respect to FIGS. 1A-1D and / or 2. However, the example method depicted in FIG. 14 may likewise be performed using different architectures. According to some embodiments, the method of FIG. 14 may be implemented by a network node or element, such as, for example, the target RAW network node described above. For example, in one embodiment, the method of FIG. 14 may be implemented by Nodes 1-2, as illustrated in FIGS. 2, 3A, 3B, 4A, and / or 4B and described above. As noted above, the method of Figure 14 may be modified to include any of the steps, procedures, and / or details illustrated in the examples of Figures 2, 3A, 3B, 4A, and / or 4B. Additionally, it is noted that the method and / or blocks of Figure 14 may be modified to include or replace any one or more of the procedures or blocks described elsewhere herein. As noted above, those skilled in the art will understand that Figure 14 is provided by way of example and that modifications are possible while remaining within the scope of certain exemplary embodiments.

[0121] 14, the method may include, at 1405, receiving a message from a current RAW network node to which the WTRU is attached that initiates a RAW handover of the WTRU. In an embodiment, the message may be received from the current RAW network node, and the message may include or indicate information including one or more of: an identifier of the WTRU, an identifier of the current RAW network node to which the WTRU is attached, an identifier of the RAW domain to which the current RAW network node belongs, and / or a description of quality of service (QoS) parameters required by the flow between the WTRU and the external node. In one example embodiment, the target RAW network node and / or the current RAW network node may be or may include a Point of Attachment (PoA) within the RAW domain.

[0122] 14 , the method may include determining a track and subtrack for supporting QoS for the flow between the WTRU and the external node based at least on the information provided in the message at 1410. In an embodiment, the method may include sending an acknowledgement message to the current RAW network node, which may include or indicate at least one of an identifier of the WTRU and a description of QoS parameters that may be acceptable for the flow, as illustrated at 1415.

[0123] In an example embodiment, the method may include receiving duplicated traffic from the WTRU, provided that a bicast procedure is initiated. In an example embodiment, upon detecting a WTRU attachment, the method may include activating a subtrack supporting the flow using a RAW mechanism.

[0124] In an exemplary embodiment, the QoS parameters accepted for a flow are lower than the QoS parameters requested by the flow, provided that the QoS parameters requested by the flow cannot be supported. According to one example, the QoS parameters may include one or more of latency, resiliency, and / or throughput parameters.

[0125] Although features and elements are provided above in particular combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. The present disclosure should not be limited to the specific embodiments described in this application, but rather as illustrations of various aspects. Many modifications and variations may be made without departing from its spirit and scope, as will be apparent to those skilled in the art. No element, act, or instruction used in the description of this application should be construed as critical or essential to the invention unless explicitly provided as above. Functionally equivalent methods and apparatuses within the scope of the present disclosure, in addition to those recited herein, 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 present disclosure should be limited only by the appended claims, along with the full scope of equivalents to which such claims are entitled. It should be understood that the present disclosure is not limited to any particular method or system.

[0126] The foregoing embodiments are described, for simplicity, with respect to the terminology and structure of infrared capable devices, i.e., infrared emitters and receivers. However, the described embodiments are not limited to the systems just described and may be applied to other systems that use electromagnetic waves or other forms of non-electromagnetic waves, such as acoustic waves.

[0127] Furthermore, it should be understood that the terms used herein are used only for the purpose of describing particular embodiments and are not intended to be limiting. As used herein, the term “video” or “image” can mean either a snapshot, a single image, and / or multiple images displayed on a time basis. As another example, when referred to herein, the term “user equipment” and abbreviation “UE,” the term “remote,” and / or the term “head-mounted display” or abbreviation “HMD” can mean or include (i) a wireless transmit and / or receive unit (WTRU), (ii) any of numerous embodiments of a WTRU, (iii) a wireless and / or wired capable (e.g., tethered) device configured with, among other things, some or all of the structure and functionality of a WTRU, (iii) a wireless and / or wired capable device configured with less than all of the structure and functionality of a WTRU, or (iv) the like. Details of an example WTRU, which may represent any WTRU described herein, are provided with respect to FIGS. 1A-1D . As another example, various disclosed embodiments hereinbefore and hereinafter are described as utilizing a head-mounted display. Those skilled in the art will recognize that devices other than a head-mounted display may be utilized, and that some or all of the present disclosure and various disclosed embodiments may be modified accordingly without undue experimentation. Examples of such other devices may include drones or other devices configured to stream information to provide an adapted reality experience.

[0128] Additionally, the methods provided herein may 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 electrical signals (transmitted over wired or wireless connections) and computer-readable recording media. Examples of computer-readable recording media include, but are not limited to, ROM (described), RAM (random access memory), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, and optical media such as magneto-optical media, e.g., CD-ROM disks and digital versatile disks (DVDs). A processor associated with software may be used to implement a radio frequency transceiver for use in a UE, WTRU, terminal, base station, RNC, or any host computer.

[0129] Modifications of the methods, apparatus, and systems provided above are possible without departing from the scope of the present invention. In view of the wide variety of embodiments that may be applied, it should be understood that the illustrated embodiments are merely examples and should not be taken as limiting the scope of the following claims. For example, the embodiments provided herein include handheld devices that include or may be utilized with any suitable voltage source, such as, for example, a battery and the like, that provides any suitable voltage.

[0130] Furthermore, in the embodiments provided above, mention is made of processing platforms, computing systems, controllers, and other devices that include processors. The devices mentioned may include at least one CPU (Central Processing Unit) and memory. In accordance with the practices of those skilled in the art of computer programming, references to operations and symbolic representations of operations or instructions may be performed by various CPUs and memories. Such operations and operations or instructions may be referred to as being "executed," "computer-executed," or "CPU-executed."

[0131] Those skilled in the art will understand that the operations and symbolically represented operations or instructions include the manipulation of electrical signals by a CPU. The electrical system reconfigures or otherwise alters the operation of the CPU, as well as the processing of other signals, by representing data bits that can cause the resulting transformation or reduction of the electrical signals and the retention of the data bits in memory locations in a memory system. The memory locations where the data bits are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties that correspond to or represent the data bits. It should be understood that embodiments are not limited to the platforms or CPUs described above, and that other platforms and CPUs may support the provided methods.

[0132] Additionally, data bits may be maintained on computer-readable media including magnetic disks, optical disks, and any other volatile (e.g., Random Access Memory (RAM)) or non-volatile (e.g., Read-Only Memory (ROM)) mass storage system that is readable by a CPU. Computer-readable media may include computer-readable media that reside exclusively in a processing system or that are distributed among, cooperating with, or interconnected to multiple interconnected processing systems that may be local or remote to a processing system. It should be understood that embodiments are not limited to the memories described above, and that other platforms and memories may support the provided methods.

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

[0134] Few distinctions remain between hardware and software implementations of system aspects. The use of hardware or software is generally (though not always, in that the choice between hardware and software can be important in some situations) a design choice representing a cost vs. efficiency trade-off. There may be various means (e.g., hardware, software, and / or firmware) by which the processes and / or systems and / or other techniques described herein may be achieved, and the preferred means may vary depending on the context in which the processes and / or systems and / or other techniques are deployed. For example, if an implementer determines that speed and accuracy are most important, the implementer may opt for a primarily hardware and / or firmware implementation. If flexibility is most important, the implementer may opt for a primarily software implementation. Alternatively, the implementer may opt for a combination of hardware, software, and / or firmware.

[0135] The foregoing detailed description has set forth various embodiments of devices and / or processes through the use of block diagrams, flowcharts, and / or examples. To the extent that the block diagrams, flowcharts, and / or examples, as described above, include one or more functions and / or operations, those skilled in the art will understand that each function and / or operation within the block diagrams, flowcharts, or examples, individually and / or collectively, may be implemented by a wide range of hardware, software, firmware, or substantially any combination thereof. In embodiments, some portions of the subject matter described herein may be implemented via Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), Digital Signal Processors (DSPs), and / or other integrated formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein may equivalently be implemented, in whole or in part, in integrated circuits, as one or more computer programs executing on one or more computers (e.g., as one or more programs executing on one or more computer systems), as one or more programs executing on one or more processors (e.g., as one or more programs executing on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing circuitry and / or writing software and / or firmware code is well within the skill of those skilled in the art in light of this disclosure. Additionally, those skilled in the art will understand that the subject matter mechanisms described herein may be distributed as a program product in various forms, and that exemplary embodiments of the subject matter described herein apply regardless of the particular type of signal-bearing medium used to actually effect the distribution.Examples of signal-bearing media include, but are not limited to, the following: recordable-type media such as, for example, floppy disks, hard disk drives, CDs, DVDs, digital tape, computer memory, and transmission-type media such as, for example, digital and / or analog communications media (e.g., fiber optic cables, wave guides, wired communications links, etc.).

[0136] Those skilled in the art will recognize that it is common in the art to describe devices and / or processes in the manner described herein and then use engineering techniques to integrate the above-described devices and / or processes into a data processing system. That is, at least a portion of the devices and / or processes described herein may be integrated into a data processing system through a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system may generally include one or more of the following: a system unit housing; a video display device; memory, such as volatile and non-volatile memory; a processor, such as a microprocessor and a digital signal processor; computational entities, such as an operating system, drivers, a graphical user interface, and application programs; one or more interaction devices, such as a touchpad or screen; and / or a control system including feedback loops and control motors (e.g., feedback for sensing position and / or velocity, control motors for moving and / or adjusting components and / or quantities). A typical data processing system may be implemented utilizing any suitable commercially available components, such as those typically found in data computing / communication systems and / or network computing / communication systems.

[0137] The subject matter described herein sometimes illustrates different components contained within or connected to different other components. It should be understood that the depicted structures above are merely examples, and that many other structures that achieve the same functionality may actually be implemented. In a conceptual sense, any arrangement of components that achieve the same functionality is effectively "associated" such that the desired functionality may be achieved. Thus, any two components that combine to achieve specific functionality herein may be understood as being "associated" with each other such that the desired functionality is achieved regardless of structure or intermediate components. Similarly, any two components so associated may also be considered to be "operably connected" or "operably coupled" to each other to achieve the desired functionality, and any two components capable of being so associated may also be considered to be "operably coupleable" to each other to achieve the desired functionality. Specific examples of operably coupleable include, but are not limited to, physically matable and / or physically interacting components, wirelessly interacting and / or wirelessly interacting components, and / or logically interacting and / or logically interacting components.

[0138] With respect to the use of substantially any plural and / or singular term herein, those skilled in the art will be able to convert from plural to singular and / or from singular to plural as appropriate to the context and / or application. Various singular / plural permutations may be expressly set forth herein for purposes of clarity.

[0139] It will be understood by those skilled in the art that terms used herein in general, and in the appended claims in particular (e.g., the body of the appended claims), are generally intended as "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "including" should be interpreted as "including but not limited to," etc.). It will be further understood by those skilled in the art that if a specific number of recitations in a submitted claim are intended, such intention will be explicitly set forth in the claim, and that such intention would not be given absent such recitation. For example, where only one item is intended, "single" or similar language may be used. As an aid to understanding, the following appended claims and / or description herein may include the use of the introductory phrases "at least one" and "one or more" to present claim recitations. However, use of the above phrases should not be construed as meaning that filing a claim statement with the indefinite article "a" or "an" limits any particular claim that includes the above-filed claim statement to embodiments that include only one such statement, even when the same claim includes the preface phrase "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should be interpreted to mean "at least one" or "one or more"). The same holds true for the use of definite articles used to file a claim statement. Additionally, even when a specific number of statements in a filed claim is explicitly recited, those skilled in the art will recognize that the recitation should be interpreted to mean at least the recited number (e.g., the mere recitation of "two statements" without any other modifiers means at least two statements, or more than two statements).Furthermore, in instances where a convention similar to "at least one of A, B, and C, etc." is used, the above configuration is generally intended in the sense that one of ordinary skill in the art would understand the convention (e.g., "a system having at least one of A, B, and C" includes, but is not limited to, systems having A only, B only, C only, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). In instances where a convention similar to "at least one of A, B, or C, etc." is used, the above configuration is generally intended in the sense that one of ordinary skill in the art would understand the convention (e.g., "a system having at least one of A, B, or C" includes, but is not limited to, systems having A only, B only, C only, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). It will be further understood by those skilled in the art that any disjunctive word and / or phrase providing two or more alternative terms, whether in the specification, claims, or drawings, should be understood to contemplate the possibility of including one of the terms, either term, or both terms. For example, the phrase "A or B" will be understood to include the possibilities of "A" or "B" or "A and B." Furthermore, as used herein, the term "any of" followed by a description of a plurality of items and / or a plurality of groups of items is intended to include "any of," "any combination of," "any more of," and / or "combination of any more of" the items and / or groups of items, either individually or in conjunction with other items and / or other groups of items. Furthermore, as used herein, the term "set" is intended to include any number of items, including zero. Additionally, as used herein, the term "number" is intended to include any number, including zero. Furthermore, as used herein, the term "multiple" is intended to be synonymous with "plurality."

[0140] Additionally, where features or aspects of the present disclosure are described in terms of a Markush group, those skilled in the art will further appreciate that the present disclosure is thereby described in terms of any individual element of an element of a Markush group or subgroup of elements of a subgroup.

[0141] As will be understood by those skilled in the art, for any and all purposes, including, for example, with respect to providing a written description, all ranges disclosed herein also include any and all possible subranges and combinations of those subranges. Any range described can be readily recognized as being fully described and that the same range can be at least equally broken down into halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range described herein can be readily broken down into lower, middle, and upper thirds, etc. As will be further understood by those skilled in the art, all terms, such as "up to," "at least," "greater than," "less than," etc., refer to ranges that are inclusive of the recited number and can subsequently be broken down into subranges as described above. Finally, as will be understood by those skilled in the art, a range includes each individual element. Thus, for example, a group having 1 to 3 cells refers to a group having 1, 2, or 3 cells. Similarly, a group having 1 to 5 cells refers to groups having 1, 2, 3, 4, or 5 cells, and so on.

[0142] Moreover, the claims should not be read as limited to the order or elements presented unless expressly stated. Additionally, the use of the term "means for" in any claim is intended to invoke 35 U.S.C. § 112(6) or means-plus-function claim format, and any claim without the term "means for" does not have such an intention.

Claims

1. 1. A method implemented by a wireless transmit / receive unit (WTRU), comprising: determining that a reliable and available wireless (RAW) handover of the WTRU is imminent; Based on the determination that the RAW handover of the WTRU is imminent, sending first information to a RAW network node to which the WTRU is currently attached, the first information indicating (i) quality of service (QoS) parameters required during and after the RAW handover by flows between the WTRU and an external node, (ii) whether Bi-casting is requested, and (iii) any of an identifier of the WTRU, an identifier of a target RAW network node to which the WTRU wishes to attach, and / or an identifier of a RAW domain to which the target RAW network node belongs; receiving second information indicating that the WTRU is authorized to perform the RAW handover, the second information including an indication of an acceptable QoS for the flow and an identifier of the target RAW network node to which the WTRU should attach; performing the handover and attaching to the target RAW network node; A method comprising:

2. receiving RAW-specific information that assists the WTRU when determining that the handover is imminent and / or when determining the target RAW network node to which the WTRU wishes to attach; 2. The method of claim 1, comprising:

3. 3. The method of claim 2, wherein the RAW-specific information includes any of a Point of Attachment (PoA) identifier, an identifier of a Path Selection Engine (PSE) associated with the Point of Attachment (PoA), and / or an identifier of the RAW domain.

4. 4. The method of claim 1, wherein the QoS parameters include RAW augmented parameters including one or more of bounded latency, jitter, reliability, and / or availability.

5. 4. The method of any one of claims 1 to 3, wherein the QoS parameters include one or more of latency, resiliency and / or throughput parameters.

6. 6. The method of claim 1, wherein either the RAW network node currently serving the WTRU and / or the target RAW network node comprises a Point of Attachment (PoA) within the RAW domain.

7. 1. A wireless transmit / receive unit (WTRU), comprising: A circuit including any one of a transmitter, a receiver, a processor, and a memory, determining that a reliable and available wireless (RAW) handover of the WTRU is imminent; Based on the determination that the RAW handover of the WTRU is imminent, send first information to a RAW network node to which the WTRU is currently attached, the first information indicating (i) quality of service (QoS) parameters required during and after the RAW handover by flows between the WTRU and an external node, (ii) whether Bi-casting is requested, and (iii) any of an identifier of the WTRU, an identifier of a target RAW network node to which the WTRU wishes to attach, and / or an identifier of a RAW domain to which the target RAW network node belongs; receiving second information indicating that the WTRU is authorized to perform the RAW handover, the second information including an indication of an acceptable QoS for the flow and the identifier of the target RAW network node to which the WTRU should attach; Performing the handover and attaching to the target RAW network node. A circuit configured as follows:

1. A WTRU comprising:

8. The circuit comprises: receiving RAW-specific information that assists the WTRU when determining that the handover is imminent and / or when determining the target RAW network node to which the WTRU wishes to attach; 8. The WTRU of claim 7, configured to:

9. 10. The WTRU of claim 8, wherein the RAW-specific information includes any of a Point of Attachment (PoA) identifier, an identifier of a Path Selection Engine (PSE) associated with the Point of Attachment (PoA), and / or an identifier of the RAW domain.

10. 10. The WTRU of claim 7, wherein the QoS parameters include RAW augmented parameters including one or more of bounded latency, jitter, reliability, and / or availability.

11. 10. The WTRU of claim 7, wherein the QoS parameters include one or more of latency, resiliency, and / or throughput parameters.

12. 12. The WTRU of claim 7, wherein either the RAW network node currently serving the WTRU and / or the target RAW network node comprises a Point of Attachment (PoA) within the RAW domain.

13. receiving, by a target reliable and available wireless (RAW) network node, a message to initiate a RAW handover of a wireless transmit / receive unit (WTRU) from a current RAW network node to which the WTRU is attached; the message is received from the current RAW network node, and the message includes information including any of an identifier of the WTRU, an identifier of the current RAW network node to which the WTRU is attached, an identifier of a RAW domain to which the current RAW network node belongs, and / or a description of quality of service (QoS) parameters required by a flow between the WTRU and an external node. And, determining, by the target RAW network node based at least on the information provided in the message, a track and sub-track to support QoS for the flow between the WTRU and the external node; sending an acknowledgement message to the current RAW network node, the acknowledgement message including at least one of an identifier of the WTRU and a description of the QoS parameters that can be accepted for the flow; A method comprising:

14. 14. The method of claim 13, comprising receiving duplicated traffic from the WTRU on the condition that a bicast procedure is initiated.

15. activating, by the target RAW network node upon detecting the attachment of the WTRU, the subtrack for supporting the flow using a RAW mechanism.

15. The method according to claim 13 or 14, comprising:

16. 16. The method according to claim 13, wherein the QoS parameters admitted to the flow are lower than the QoS parameters requested by the flow under the condition that the QoS parameters requested by the flow cannot be supported.

17. 17. The method of any one of claims 13 to 16, wherein the QoS parameters include RAW augmented parameters including one or more of bounded latency, jitter, reliability, and / or availability.

18. 17. The method of any one of claims 13 to 16, wherein the QoS parameters include one or more of latency, resiliency and / or throughput parameters.

19. 19. The method of any one of claims 13 to 18, wherein either the target RAW network node and / or the current RAW network node comprises a Point of Attachment (PoA) within the RAW domain.

20. 1. An apparatus comprising: A circuit including any one of a transmitter, a receiver, a processor, and a memory, receiving a message from a current RAW network node to which the wireless transmit / receive unit (WTRU) is attached to initiate a RAW handover of the WTRU; the message is received from the current RAW network node, the message including information including any of an identifier of the WTRU, an identifier of the current RAW network node to which the WTRU is attached, an identifier of a RAW domain to which the current RAW network node belongs, and / or a description of quality of service (QoS) parameters required by a flow between the WTRU and an external node; determining a track and subtrack to support QoS for the flow between the WTRU and the external node based at least on the information provided in the message; sending an acknowledgement message to the current RAW network node that includes at least one of an identifier of the WTRU and a description of the QoS parameters that can be accepted for the flow; A circuit configured as follows: An apparatus comprising:

21. 21. The apparatus of claim 20, wherein the circuitry is configured to receive duplicate traffic from the WTRU under the condition that a bicast procedure is initiated.

22. The circuit comprises: Upon detecting the attachment of the WTRU, activate the subtrack to support the flow using a RAW mechanism.

22. The device according to claim 20 or 21, configured to:

23. 23. The apparatus according to claim 20, wherein the QoS parameters granted to the flow are lower than the QoS parameters requested by the flow under the condition that the QoS parameters requested by the flow cannot be supported.

24. 24. The apparatus of any one of claims 20 to 23, wherein the QoS parameters include RAW augmented parameters including one or more of bounded latency, jitter, reliability, and / or availability.

25. 24. The apparatus of any one of claims 20 to 23, wherein the QoS parameters include one or more of latency, resiliency and / or throughput parameters.

26. 26. The method of any one of claims 20 to 25, wherein the device and / or any of the current RAW network nodes comprises a Point of Attachment (PoA) within the RAW domain.

Images