COORDINATED HANDOVER FOR A SET OF WTRUs USING XR AND MEDIA APPLICATIONS

Abstract

A system and method for allowing a group of WTRUs in a group to handover in a coordinated manner is disclosed. Considering application layer requirements, the system and method include procedures for handling mobility and handover of a subset of WTRUs or all WTRUs belonging to a group. The included procedures enable a single WTRU within a group of WTRUs to trigger handover for other WTRUs within the group. The system and method include a process of enabling a single WTRU to act as an anchor WTRU for handover of control messages, allowing the WTRU to cover handover messages transmitted by a network, allowing one WTRU in a group to coordinate handover for all WTRUs or subsets of WTRUs.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 397,243, filed on August 11, 2022, the contents of which are incorporated herein by reference. Background Art

[0003] A PDU set includes one or more PDUs carrying a payload of an information unit (e.g., a frame or video slice for an XRM service) generated at the application layer, and the one or more PDUs have the same importance requirements at the application layer. The application layer may require all PDUs in a PDU set to use the corresponding information unit. In some cases, when some PDUs are lost, the application layer can recover some of the information units.

[0004] The multimodal synchronization threshold can be defined as the maximum tolerable time interval between the onset of two stimuli, one presented to one sense and the other presented to another sense, such that the accompanying sensory objects are perceived as being synchronized. The synchronization threshold can be described as the maximum tolerable time interval between the transmission or reception of two streams.

[0005] In the definition of a PDU set, the information unit may be an application layer information unit. The terms "information unit" and "application layer information unit" are used interchangeably. The terms "application server" and "application function" are used interchangeably. Summary of the invention

[0006] A system and method are disclosed that allow a group of WTRUs in a group to perform handover in a coordinated manner. The system and method include procedures for handling mobility and handover of a subset of WTRUs or all WTRUs belonging to a group, taking into account application layer requirements. The included procedures enable a single WTRU within a group of WTRUs to trigger a handover for other WTRUs in the group. The system and method include procedures that enable a single WTRU to act as an anchor WTRU for handover control messages, thereby allowing the WTRU to override handover messages transmitted by the network, allowing one WTRU in the group to coordinate handover for all WTRUs or a subset of WTRUs.

[0007] A system and method for performing coordinated handover for a group of WTRUs executed in a wireless transmit receive unit (WTRU) is disclosed. The system and method include a transceiver and a processor, the transceiver and the processor configured to: receive a first coordinated handover configuration; receive a handover notification, the handover notification prompting a coordinated handover and including at least one handover condition triggering the coordinated handover; set a handover threshold based on the handover condition; determine a measurement value; and perform the coordinated handover when the measurement value meets the handover threshold. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] A more detailed understanding may be obtained from the following description given by way of example in conjunction with the accompanying drawings, in which like reference numerals indicate like elements, and in which:

[0009] Figure 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented;

[0010] Figure 1B is an example of an embodiment in which Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within an illustrated communication system;

[0011] Figure 1C is an example of an embodiment in which Figure 1A A system diagram of an example Radio Access Network (RAN) and an example Core Network (CN) used within the illustrated communication system;

[0012] Figure 1D is an example of an embodiment in which Figure 1A A system diagram of another example RAN and another example CN used within the illustrated communication system;

[0013] Figure 2A An example signal diagram illustrating an inter-gNB handover procedure;

[0014] Figure 2B Includes methods for inter-gNB handover procedures;

[0015] Figure 4A An example signal diagram illustrating a planned group handover;

[0016] Figure 4B A method for planning a group handover is illustrated; a signaling diagram for a conventional handover is illustrated;

[0017] Figure 4A An example signal diagram illustrating a planned group handover;

[0018] Figure 4B illustrates a method for planning group handovers;

[0019] Figure 5A An example signal diagram illustrating a WTRU triggered group handover;

[0020] Figure 5B A method performed in a WTRU for coordinating handover for a group of WTRUs;

[0021] Fig. 6A A signal diagram illustrating anchor-based handover; and

[0022] Figure 6B A method performed by an anchor WTRU is illustrated. DETAILED DESCRIPTION

[0023] Disclosed are systems, methods, and apparatus that allow a group of WTRUs in a group to perform handovers in a coordinated manner. The systems, methods, and apparatus may handle mobility and handovers for a subset of WTRUs or all WTRUs belonging to a group, taking into account application layer requirements. The systems, methods, and apparatus enable a single WTRU within a group of WTRUs to trigger a handover for other WTRUs in the group. The systems, methods, and apparatus enable a single WTRU to act as an anchor WTRU for handover control messages, thereby allowing the WTRU to override handover messages transmitted by the network, allowing one WTRU in a group to coordinate handovers for all WTRUs or a subset of WTRUs.

[0024] A system and method for performing coordinated handover for a group of WTRUs executed in a wireless transmit receive unit (WTRU) is disclosed. The system and method include a transceiver and a processor, the transceiver and the processor configured to: receive a first coordinated handover configuration; receive a handover notification, the handover notification prompting a coordinated handover and including at least one handover condition triggering the coordinated handover; set a handover threshold based on the handover condition; determine a measurement value; and perform the coordinated handover when the measurement value meets the handover threshold.

[0025] Figure 1A 1 is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The 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 code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero tail unique word discrete Fourier transform spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.

[0026] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110 and other networks 112, but it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a station (STA)) may be configured to send and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated process chain environment), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0027] The communication system 100 may also 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 to facilitate access to one or more communication networks, such as the CN 106, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an evolved Node B (eNB), a Home Node B, a Home evolved Node B, a next generation Node B such as a gNode B (gNB), a new radio (NR) Node B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0028] The base station 114a may be part of the RAN 104, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. The base station 114a and / or the base station 114b may be configured to send and / or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of licensed and unlicensed spectrums. A cell may provide coverage of wireless services to a specific geographic area, which may be relatively fixed or may change over time. The cell may be further divided into cell sectors. For example, a cell associated with the base station 114a may be divided into three sectors. Therefore, in one embodiment, the base station 114a may include three transceivers, i.e., one transceiver 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 sector of the cell. For example, beamforming may be used to send and / or receive signals in a desired spatial direction.

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

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

[0031] 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 Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-APro).

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

[0033] 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 together implement LTE radio access and NR radio access, for example using the dual connectivity (DC) principle. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions transmitted to / from multiple types of base stations (e.g., eNBs and gNBs).

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

[0035] Figure 1AThe base station 114b in the may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial locations, homes, vehicles, campuses, industrial facilities, sky corridors (e.g., for use by drones), roads, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or a femtocell. As Figure 1A As shown, the base station 114b may have a direct connection to the Internet 110. Therefore, the base station 114b may not be required to access the Internet 110 via the CN 106.

[0036] The RAN 104 may be in communication with the CN 106, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 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 user authentication. Although not described in detail in the accompanying drawings, the CN 106 may be configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. Figure 1A Although not shown in the figure, it will be appreciated that the RAN 104 and / or the CN 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may utilize NR radio technology, the CN 106 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

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

[0038] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). Figure 1A The illustrated WTRU 102c may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0039] Figure 1B is a system diagram illustrating an example WTRU 102. Figure 1B As shown, 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 global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0040] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal decoding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0041] The send / receive element 122 may be configured to send a signal to a base station (e.g., base station 114a) or receive a signal from the base station via an air interface 116. For example, in one embodiment, the send / receive element 122 may be an antenna configured to send and / or receive an RF signal. In an embodiment, the send / receive element 122 may be a transmitter / detector configured to send and / or receive, for example, IR, UV or visible light signals. In another embodiment, the send / receive element 122 may be configured to send and / or receive both RF signals and optical signals. It should be understood that the send / receive element 122 may be configured to send and / or receive any combination of wireless signals.

[0042] Although the transmit / receive element 122 Figure 1B Although depicted as a single element in the figure, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0043] 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 noted above, the WTRU 102 may have multi-mode capabilities. For example, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0044] The processor 118 of the WTRU 102 may be coupled to 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) and may receive user input data therefrom. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a 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, and a secure digital (SD) memory card, among others. In other embodiments, the processor 118 may access information from and store data in a memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

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

[0046] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information 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 received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with an embodiment.

[0047] The processor 118 may also be coupled to other peripherals 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, Modules, frequency modulation (FM) radio units, digital music players, media players, video game player modules, Internet browsers, virtual reality and / or augmented reality (VR / AR) devices and activity trackers, etc. Peripheral devices 138 may include one or more sensors. The sensor may be one or more of the following: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation 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, a humidity sensor, etc.

[0048] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with specific subframes for both UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference via signal processing performed by hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via the processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with specific subframes for both UL (e.g., for transmission) or DL ​​(e.g., for reception)) may be concurrent and / or simultaneous.

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

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

[0051] Each of the evolved Node Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, and scheduling of users in the UL and / or DL, among other things. Figure 1C As shown, the eNode-Bs 160a, 160b, 160c may communicate with one another via an X2 interface.

[0052] Figure 1C The illustrated CN 106 may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. Although the foregoing elements are depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0053] The MME 162 may be connected to each of the evolved Node-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, and selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c. 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 GSM and / or WCDMA.

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

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

[0056] The CN 106 may facilitate communications 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 communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may be in communication with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts 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 networks and / or wireless networks owned and / or operated by other service providers.

[0057] Although the WTRU Figures 1A to 1D Although described as wireless terminals, it is contemplated that in certain representative embodiments, such terminals may (eg, temporarily or permanently) use a wired communications interface with a communications network.

[0058] In a representative embodiment, the other network 112 may be a WLAN.

[0059] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for a BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or carries traffic away from the BSS. Traffic originating from outside the BSS and going to the STA may be reached by the AP and may be delivered to the STA. Traffic originating from the STA and going to a destination outside the BSS may be transmitted to the AP to be delivered to the corresponding destination. Traffic between STAs within the BSS may be transmitted by the AP, for example, wherein the source STA may transmit traffic to the AP, and the AP may deliver traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as point-to-point traffic. Direct link establishment (DLS) may be utilized to transmit point-to-point traffic between the source STA and the target STA (e.g., directly between them). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (eg, all STAs in the STA) may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad hoc" communication mode.

[0060] When using the 802.11ac infrastructure operating mode or a similar operating mode, the AP may send 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 dynamically set width. The primary channel may be an operating channel of the BSS and may be used by the STA to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access / collision avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. For CSMA / CA, a STA (e.g., each 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 at any given time in a given BSS.

[0061] High throughput (HT) STAs may communicate using a 40 MHz wide channel, for example, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0062] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz channels and / or 80MHz channels can be formed by combining continuous 20MHz channels. 160MHz channels can be formed by combining 8 continuous 20MHz channels, or by combining two non-continuous 80MHz channels (this can be called 80+80 configuration). For 80+80 configuration, after channel coding, the data can pass through a segment parser that can divide the data into two streams. Each stream can be processed by inverse fast Fourier transform (IFFT) and time domain processing separately. These streams can be mapped to two 80MHz channels, and data can be sent by the transmitter STA. At the receiver of the receiver STA, the above-mentioned operation for the 80+80 configuration can be reversed, and the combined data can be transmitted to the medium access control (MAC).

[0063] 802.11af and 802.11ah support operating modes below 1GHz. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support meter type control / machine type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only support for) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

[0064] WLAN systems (which may support multiple channels) and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include channels that may be designated as primary channels. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA (which supports the minimum bandwidth operating mode) from all STAs operating in the BSS. In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only support) a 1MHz mode, the primary channel may be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy, for example, because a STA (which only supports a 1MHz operating mode) is transmitting to the AP, all available bands may be considered busy even if most of the available bands remain idle.

[0065] In the United States, the available frequency band for 802.11ah is 902MHz to 928MHz. In South Korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz, depending on the country code.

[0066] Figure 1D1 is a system diagram illustrating the RAN 104 and the CN 106 in accordance with an embodiment. As noted above, the RAN 104 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0067] The RAN 104 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 104 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 180b may utilize beamforming to send signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a may, for example, use multiple antennas to send wireless signals to and / or receive wireless signals from the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In an embodiment, gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

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

[0069] 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 while not accessing other RANs (e.g., such as the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchors. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with the gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as the eNode-B 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement the DC principle 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-B 160a, 160b, 160c may act as a mobility anchor for the WTRUs 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

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

[0071] Figure 1D The illustrated CN 106 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possible data networks (DNs) 185a, 185b. Although the aforementioned elements are depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0072] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via the N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, support of network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selecting a specific SMF 183a, 183b, management of registration areas, termination of non-access stratum (NAS) signaling, mobility management, etc. The AMF 182a, 182b may use network slicing in order to customize CN support for the WTRU 102a, 102b, 102c based on the type of services utilized by the WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, etc. The AMF 182a, 182b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0073] The SMF 183a, 183b may be connected to the AMF 182a, 182b in the CN 106 via the N11 interface. The SMF 183a, 183b may also be connected to the UPF 184a, 184b in the CN 106 via the N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b, and configure traffic routing through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions such as managing and allocating WTRU IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notifications, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

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

[0075] The CN 106 may facilitate communications with other networks. For example, the CN 106 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts 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 networks and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to the DNs 185a, 185b via the UPFs 184a, 184b via the N3 interfaces to the UPFs 184a, 184b and the N6 interfaces between the UPFs 184a, 184b and the local DNs 185a, 185b.

[0076] Given that Figures 1A to 1D as well as Figures 1A to 1D Corresponding to the description of the present invention, one or more or all of the functions described herein with reference to one or more of the following items may be performed by one or more simulation devices (not shown): WTRU102a to 102d, base station 114a to 114b, evolved Node B 160a to 160c, MME 162, SGW 164, PGW 166, gNB180a to 180c, AMF 182a to 182b, UPF 184a to 184b, SMF 183a to 183b, DN 185a to 185b and / or any other device described herein. The simulation device may be one or more devices configured to mimic one or more or all of the functions described herein. For example, the simulation device can be used to test other devices and / or simulate network and / or WTRU functions.

[0077] The simulation device may be designed to implement one or more tests of other devices in a laboratory environment and / or in an operator network environment. For example, one or more simulation devices may perform one or more functions or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. One or more simulation devices may perform one or more functions or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device may be directly coupled to another device for the purpose of testing and / or performing tests using over-the-air wireless communications.

[0078] One or more simulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test scenario in a test lab and / or a non-deployed (e.g., testing) wired and / or wireless communication network to implement testing of one or more components. One or more simulation devices can be test equipment. Direct RF coupling and / or wireless communication via RF circuits (e.g., which can include one or more antennas) can be used by the simulation device to send and / or receive data.

[0079] Multimodal data is input data from different kinds of devices / sensors or output data going to different kinds of destinations (e.g., one or more WTRUs) required for the same task or application. Multimodal data may include more than one unimodal data and may include strong dependencies between each unimodal data. Unimodal data may be one type of data. A device or sensor that generates (i.e., transmits) unimodal data may be a WTRU or may use a WTRU to transmit unimodal data to a network. The unimodal data may be transmitted to an application hosted on another WTRU or an application hosted on a network server. A device or sensor that receives unimodal data may be a WTRU or may use a WTRU to receive unimodal data from a network. The unimodal data may be received from an application hosted on another WTRU or an application hosted on a network server.

[0080] The synchronization threshold defines the maximum tolerable time interval between the onsets of two stimuli. In most scenarios, one stimulus can be delivered on one stream and the second on another stream. One stimulus can be presented to one human sense (vision) and the other to another sense (touch) such that the corresponding sensory objects are perceived to be synchronized.

[0081] The business characteristics or patterns of multimodal streams may vary depending on the application. For example, a well-known category of multimodal use cases is virtual reality (VR) applications. In such applications, user posture change information can be captured by a VR headset and transmitted over a network to an application server in the network. The received posture information is processed, and new VR information is generated by the application server, including new multimodal data (e.g., audio, video, and tactile) corresponding to changes in the VR environment. The multimodal data is then transmitted to the VR headset via a downlink, which allows the multimodal data to be processed and presented to the user. Therefore, typical characteristics of the application include: periodic small amounts of data are transmitted to the application server via an uplink, followed by relatively large amounts of multimodal data, typically transmitted to the VR headset via a downlink.

[0082] Based on the changes in the posture information received over the uplink, latency may be specified and may need to meet certain minimum requirements between the user's head movement (referred to as "motion") and the presentation or display of updated (information about the VR environment) multimodal information (referred to as "photons" for video and "sound" for audio) received over the downlink to the user using the WTRU. This may include motion-to-photon latency in the range of 7ms to 15ms while maintaining the required resolution of up to 8k, providing user data rates up to 1Gbit / s and motion-to-sound latency of <20ms.

[0083] Unimodal data is described as a data flow to and / or from a WTRU, and multimodal data is described as comprising multiple data flows to and / or from multiple WTRUs.

[0084] A multimodal data set is a set of unimodal data flows for the same task or application. For example, a multimodal data set may be a set of IP flows and / or QoS flows between multiple WTRUs and a single application server (identified by a QoS flow identifier [QFI]). For example, an IP flow may carry sensor data, video information, tactile data, audio data, etc.

[0085] The handover process in a 5G system may be network controlled and classified into two types of mobility, such as cell-level mobility and beam-level mobility. Cell-level mobility requires triggering explicit RRC signaling.

[0086] Figure 2AAn example signal diagram 200 illustrating an inter-gNB handover procedure is shown. The example signal diagram 200 includes a WTRU 210, a source gNB 220, and a target gNB 230. Although the WTRU 210, the source gNB 220, and the target gNB 230 are referred to in the singular, it should be understood that the plurality of each may be used and the singular description is intended to provide a clearer understanding of the signaling in the process.

[0087] exist Figure 2A As can be seen in FIG. 1 , an example signal diagram illustrating an inter-gNB handover process is shown;

[0088] Cell level mobility includes inter-gNB handover. The signal diagram 200 begins with the source gNB 220 transmitting a handover request 205 to the target gNB 230. For example, in an inter-gNB handover, the source gNB 220 initiates the handover and issues a handover request to the target gNB 230 over the Xn interface. The target gNB 230 performs 207 an admission control procedure and transmits a handover request confirmation 215 to the source gNB 220. For example, once the admission control procedure is performed by the target gNB 230, the target gNB 230 provides the new RRC configuration to the source gNB 220 in its response. The source gNB 220 transmits an RRC reconfiguration message 225 to the WTRU 210. For example, the RRC reconfiguration message 225 may include at least a cell ID and all information required to access the target cell (e.g., beam specific information). Upon receiving the RRC reconfiguration message 225, the WTRU 210 switches 227 to the new cell. For example, WTRU 210 performs a handover. WTRU 210 transmits an RRC reconfiguration complete message 235 to the target gNB 230 to complete the handover.

[0089] Figure 2B The method 250 includes providing a handover request from an old gNB (currently used gNB) to a new gNB (potential gNB for handover) at 260. At 270, the method 250 includes acknowledging the handover request from the new gNB to the old gNB. At 280, the method 250 includes transmitting an RRC reconfiguration message from the original gNB to the WTRU. At 290, the method 250 includes transmitting an RRC reconfiguration complete message to the new gNB.

[0090] When the Intra-NR RAN Handover procedure is supported, messages may be exchanged directly between gNBs via the Xn interface, for example, to transfer the WTRU 210 context from the source gNB 220 to the target gNB 230. Once the target gNB 230 triggers the Handover Complete phase, the resources at the source gNB 220 are released.

[0091] In a conventional HO process, the WTRU 210 releases the connection to the source cell before establishing connectivity to the target cell, thereby terminating uplink transmission and downlink transmission. This results in service interruption in the range of tens of milliseconds (usually about 30 milliseconds to 60 milliseconds). To address this problem, a dual active protocol stack (DAPS) has been introduced. During the handover, DAPS allows the WTRU 210 to simultaneously establish connectivity to both the source cell and the target cell (in some examples, only the primary cell (PCell) is used) for a short period of time, thereby allowing connectivity to the source cell to remain active for the reception and transmission of user data until data can be transmitted and received in the target cell. Once the handover is completed, the uplink transmission of user data is switched to the target cell when the random access process is completed. For the source cell and the target cell, a common PDCP entity is configured, and PDCP sequence number continuity can be maintained throughout the process of achieving in-order delivery of user data. In a parallel configuration, downlink user data is forwarded from the source cell (so as to be sent to the WTRU until the handover is completed) to the target cell (buffered for sending to the WTRU once the handover is completed). Once the handover is complete, uplink user data is switched from the source cell to the target cell. Once the target cell notifies the source cell of a successful handover, the source cell stops sending data in the downlink. If the handover fails, the WTRU falls back to the source cell.

[0092] Conditional Handover (CHO) may be a handover procedure performed by the WTRU 210 based on a CHO configuration received from the network, with the goal of reducing failures when users are mobile. The WTRU may perform a handover when one or more conditions defined for the handover are met. Once the WTRU 210 receives the CHO configuration, the WTRU 210 may start evaluating the execution conditions and may stop once the handover has been performed. CHO may prepare multiple candidate target cells instead of one target cell, allowing the handover command to be transmitted to the WTRU 210 while the radio configuration is still good. This reduces any potential handover failures that may occur due to poor radio conditions, as in a traditional handover process. The CHO configuration contains candidate cells and execution conditions generated by the source gNB 220. The execution conditions consist of one or two trigger conditions (e.g., SSB and / or CSI-RS measurements).

[0093] Figure 4A An example signal diagram illustrating a planned group handover;

[0094] Figure 4BA method for planning a group handover is illustrated; a signaling diagram 300 for a conventional HO is illustrated. Diagram 300 may also depict DAPS HO. Diagram 300 depicts a single WTRU 310 interacting with a source gNB 320 and a target gNB 330. At a first time, the WTRU 310 transmits a measurement report 315 to the source gNB 320. The measurements performed by the WTRU 310 on various physical layer parameters (e.g., SSB and / or CSI-RS) to calculate cell quality may be used by the WTRU 310 and / or the network in determining whether to perform a handover.

[0095] At 325, the source gNB 320 and the target gNB 330 exchange messages to prepare for the handover process. Message 325 may be used to exchange state information. The state information may be used to prepare for the handover to the target gNB 330. At 325, the target gNB 330 may indicate in a message to the source gNB 320 whether the handover is accepted.

[0096] The source gNB 320 issues a handover command 305 to the WTRU 310. The source gNB 320 triggers the handover by transmitting an RRCReConfiguration message to the WTRU 310.

[0097] The WTRU 310 then attaches to the target gNB 330 via signaling 335. Once the trigger conditions for performing a handover are met (e.g., the measurement of the CSI-RS from the source cell is below a threshold and / or the measurement of the CSI-RS from the target cell is above a threshold), the WTRU 310 may synchronize with the target cell and may complete the RRC handover procedure by transmitting an RRCReconfigurationComplete message 335 to the target gNB 330. When determining when to initiate the handover procedure, the system may not take into account what uplink and downlink user plane procedures are occurring, or those that may need to occur soon, leading to various problems such as delayed transmission of important data, retransmission of data causing further delays, and wasted resources due to connectivity disruption caused by the handover.

[0098] A plot of the corresponding radio conditions is provided at the bottom of the diagram 300. The plot illustrates a threshold 350 as well as source cell radio conditions 3201 and target cell radio conditions 3301. As illustrated, when the source cell radio condition 3201 falls below the threshold 350, the measurement report signal 315 is transmitted.

[0099] For conventional HO, the grey area 360 illustrates the interruption time. Typically, no uplink traffic or downlink traffic can be sent during this time.

[0100] For DAPS HO, the grey area 360 illustrates the time when the WTRU 310 attempts to attach to the target gNB 330 but is still attached to the source gNB 320. During this time represented by the grey area 360, the source gNB 320 forwards packets to the target gNB 330 where the packets are buffered waiting for the WTRU 310 to attach to the target gNB 330. During this time represented by the grey area 360, the radio quality on the source gNB 320 may be poor.

[0101] Although not shown, conditional HO also suffers from outage time.

[0102] As the user moves, the user may consume multimodal application data in changing scenarios. The user may have multiple devices with different capabilities and form factors (e.g., headphones for audio, a haptic suit for touch, VR glasses for video). In such scenarios, the user may consume data from the same application server using those WTRUs simultaneously. However, when the user moves from one location to another (e.g., in a vehicle or while walking), the user's connection may be handed over from the first cell to the second cell, for example due to degraded connectivity associated with the first cell. During the handover, downlink data and uplink data may be delayed, as described above in Figure 3 Delaying XRM data with relatively strict latency, jitter, and synchronization requirements may result in user perceived data interruptions or a relatively low quality of experience. In addition, when a group of devices moves together (e.g., when in the same vehicle or attached to the same person), it is important to minimize differences in the overall latency associated with the devices' streams. For example, if one device performs a handoff operation before a second device, the latency observed at each device may be temporarily increased. In multimodal applications, such an increase in latency experienced at one device and not at a second device may result in a negative user experience due to the streams becoming unsynchronized.

[0103] When the handover process is performed, there is a period of time when uplink data and downlink data may be delayed, such as Figure 3 exemplified. Thus, the XRM services provided to the user may be interrupted until the handover process is complete. However, multimodal communications involve the transmission of data modes with different requirements, some of which are more stringent than others (e.g., the latency requirements for tactile data are more stringent than those for video and audio data). Violating the requirements of one data mode may impact the overall application experience (i.e., QoS and QoE are degraded). Therefore, when performing a handover of a WTRU associated with a multimodal session, the interruption of these services may be minimized.

[0104] The state of other WTRUs that are part of the same application experience may not be considered when determining when to initiate and then perform a handover. Performing a handover without considering application layer activity is not optimal because data may be delayed during the handover process. This may be even more critical in scenarios where multiple WTRUs are used. If there is a lack of coordination when performing handovers on multiple WTRUs used by a user for the same application, the handover process may be triggered and therefore completed at different times, or the handover may be optimized by, for example, considering user plane processes for each WTRU separately, the cell quality of each WTRU as perceived by the network / WTRU. When handover optimization is performed for isolated individual WTRUs, and the interruption and / or change of service (application layer changes, such as changes in codecs) for each individual WTRU may occur at different times, this may result in handovers being performed for the WTRUs at different times. This may cause the relative delay between the interrelated multimodal streams to exceed the maximum synchronization threshold, affecting the overall QoE, and may also result in an increase in the overall interruption of the overall application experience.

[0105] To avoid impacts on the overall quality of experience, benefits may be gained by ensuring that the handover process occurs in a coordinated manner between a group of associated WTRUs, between data bursts, or during less important data bursts. Currently, systems do not typically provide a way to configure a group of WTRUs to initiate handovers simultaneously or nearly simultaneously. When determining when to start the handover process, such an approach may take into account service characteristics (e.g., the periodic nature of some uplink and downlink services), the importance level of specific data sets within a unimodal stream (e.g., some video frames are more important than other video frames), and the importance level of unimodal streams of a multimodal session (e.g., an audio stream is more important than a tactile stream). Therefore, not only considering cell quality can minimize disruptions to the overall application experience. In other words, more careful planning of when to initiate a handover can result in less data being delayed at the application layer and subsequently discarded. For example, a handover plan may take into account the status of other WTRUs that are part of the same application experience.

[0106] The following presents group handover parameters for group handover and how to deploy these parameters. The following presents group WTRU planned handover, including procedures for handling mobility and handover of a subset of WTRUs or all WTRUs belonging to a group, taking into account application layer requirements. The following describes WTRU triggered group handover, presenting procedures that enable a single WTRU within a group of WTRUs to trigger a handover for other WTRUs within the group. These procedures are required in scenarios where the WTRUs within the group are ready or required to perform a handover before the other WTRUs, and doing so may potentially reduce QoE. Anchor based group handover is described, and procedures that enable a single WTRU to act as an anchor WTRU for handover control messages are presented, allowing a single WTRU to override the handover messages transmitted by the network, allowing one WTRU in the group to coordinate the handover for all WTRUs or a subset of WTRUs. The group handover parameters include parameters for the group handover process and how to deploy these parameters within the network. The following parameters may be deployed to the network by an application function or application server in the network (e.g., via a NEF) or by the WTRU. These parameters may be configured at application startup, and / or may be configured / updated multiple times during the lifetime of the application (eg, triggered by a change in the WTRU's mode or priority).

[0107] A group of WTRUs may be identified by a multimodal session ID, which may be specified by an IP 4-tuple, SUPI, GPSI, or DNN / S-NSSAI combination. This may be shared among a group of WTRUs, and the multimodal session ID may be linked or mapped to the set of WTRUs that have used or authorized multimodal sessions. Alternatively, an external group identifier may be used to identify the group.

[0108] A second parameter identifying a specific WTRU (either within a group of WTRUs or outside a group of WTRUs of interest) for coordinating the group handover process may also be provisioned to the network and the participating WTRUs, which is referred to as the anchor WTRU. An anchor WTRU is used herein to describe a single WTRU that acts as a master WTRU or coordinator WTRU that handles handover control signaling for a group of WTRUs. The parameter may be specified as a SUPI, GPSI, IP address, or 5G-S-TMSI.

[0109] A group of WTRUs associated with any of a common application, a common experience, or a common session may be assigned one or more RAN-specific group IDs, such as a group RNTI (G-RNTI), a sub-group RNTI, or a multi-modal RNTI, by a base station. Such RAN-specific group IDs may be assigned in addition to a per-WTRU ID (e.g., C-RNTI) and may be common or shared by the WTRUs in the group, for example, when sending and / or receiving any RAN signaling (e.g., RRC messages) during the processing of connectivity, handover, and scheduling related procedures.

[0110] The network may maintain a list of WTRU identifiers for a group of WTRUs that may require a group handover. The list may include WTRUs with the same multimodal session ID or external group identifier, or WTRUs associated with the same common application, common experience, or common session. The WTRU may provide this information to the RAN node via RRC signaling. For example, the WTRU may provide the multimodal session ID in the WTRUAssistanceInformation message. The gNB may maintain a list of WTRU identifiers that share the same multimodal session ID. The network may provide a list of WTRU identifiers to one or more WTRUs in the group. The WTRU may use the list of WTRU identifiers for any D2D / SL communications. The WTRU identifier may be a C-RNTI or an L2 identifier. The AF / AS may provide a "treated together" indication to the RAN, and the RAN may be used to determine which WTRUs are highly interrelated and, for example, whether to perform a handover for a subgroup of WTRUs that are "treated together".

[0111] Group WTRU planned handover includes a process that allows handovers to be coordinated between a group of WTRUs (as described above) so that handovers are triggered and / or completed for all WTRUs or a subset of WTRUs at similar times. Priorities between WTRUs (e.g., some WTRUs may have a higher affinity / relationship with each other (e.g., based on the multi-modal synchronization threshold described above)) may make a WTRU more susceptible to being affected, resulting in a handover, or may be based on the priorities assigned to the modalities supported by each WTRU [assigning a higher priority to the video modality than the tactile modality], or whether the WTRU is an anchor WTRU, which may indicate which subset of WTRUs is handed over first. The priorities assigned to WTRUs may change over time (e.g., tactile traffic may be prioritized when mobility is expected in a session, or a regular WTRU becomes an anchor WTRU). In another scenario, only a subset of WTRUs in the group may be handed over to the new cell / gNB (in the case of limited resources, adverse radio link conditions, or certain features not supported by the target cell). As a result, service to a subset of WTRUs may be temporarily terminated (eg, until resources become available or may be handed over to a cell that can provide resources because the source cell no longer supports the WTRUs and the target cell has limited capacity at the time of the pending handover).

[0112] In conjunction with the above description, the following description provides methods that can be used to perform handover for a group of WTRUs using the same multimodal application while minimizing the relative delay between the multimodal streams (in accordance with the synchronization threshold). In the example presented below, WTRU-1, WTRU-2, and WTRU-3 are used for the same application, and the network (or anchor WTRU described below) can perform handover for WTRU-1 and WTRU-2 at the same time.

[0113] exist Figure 4A In the first example group handover shown, only a subset of WTRUs are handed over to the target cell / gNB and connectivity to the other WTRUs in the group is terminated, i.e., WTRU-3 receives a connectivity termination notification, allowing only WTRU-1 and WTRU-2 to communicate. Figure 4A In the second example group handover shown, the WTRUs selected not to handover together in a coordinated manner receive a handover configuration from the network to perform the handover in a conventional manner, i.e., WTRU-3 may not handover to the target cell together, while WTRU-1 and WTRU-2 handover together. The system may be configured to use one of the two procedures described above.

[0114] Figure 4AAn example signal diagram 400 is illustrated for a planned group handover. The signal diagram 400 depicts a plurality of WTRUs 410 involved in a group handover. Specifically, three WTRUs are shown, although any number of WTRUs may be included in the plurality of WTRUs 410. The three WTRUs depicted include WTRU1 410.1, WTRU2 410.2, and WTRU3 410.3. The signal diagram 400 includes a source gNB 420 and a target gNB 430.

[0115] At 402, the signaling diagram 400 includes the RAN (e.g., the source gNB 420) receiving service characteristics / mode information using the procedures defined herein. At 404, the signaling diagram 400 includes the source gNB 420 configuring the WTRU 410 measurement procedures, and the WTRU 410 reporting the characteristics / mode being used based on the configuration. The RAN (e.g., the source gNB 420) may configure the WTRU 410 to detect or identify the service characteristics / mode for a particular session. The request includes information received by the RAN at 402 (also defined herein). The request may include an ID that uniquely identifies the multimodal session. Pre-existing information of the service characteristics / mode (e.g., collected through learning) may be provided to the RAN and the WTRU 410. Alternatively, the WTRU 410 may receive the information defined herein directly from the corresponding AF / AS. This may include configuration and reporting in the NR standard defined at 402, 404.

[0116] The WTRU 410 may be configured by the source gNB 420 with one or more handover (HO) modes and / or parameters associated with HO modes supported / allowed by the RAN. Such handover modes may include normal HO, CHO, DAPS, or any other HO process that may support, for example, HO of multimodal services. Optionally, at 406, the WTRU 410 analyzes the application traffic to identify traffic characteristics / patterns (e.g., in the UL). Element 406 may be triggered by messaging transmitted with respect to element 404. Alternatively, the WTRU 410 may automatically initiate element 406 based on a pre-configured configuration on the WTRU without having to receive messaging transmitted with respect to element 404. For example, at 406, when a multimodal session / XR session has been established, the WTRU may begin monitoring and analyzing the traffic.

[0117] The WTRU 410 may exchange individually identified or retained traffic characteristics / patterns between other WTRUs in the group, such as using D2D or sidelink communication links, at 408; collaboratively improve traffic characteristics or pattern related data between a group of WTRUs through learning techniques (such as federated learning and distributed learning) and enabling all WTRUs to have the traffic characteristics / patterns of other WTRUs. This exchange enables a single WTRU 410 to transmit traffic characteristics / pattern information of all WTRUs in the group to the RAN at 412.

[0118] Optionally, at 412, the WTRU 410 informs the RAN of the identified traffic characteristic / pattern. Element 412 may be performed by all WTRUs of the group, or by only a subset of the WTRUs, or by a single WTRU. The message 412 may include information about the specific traffic characteristic / pattern detected / identified. In certain configurations, the message 412 may also inform the RAN of its preferred method for performing a handover (e.g., normal handover, CHO, DAPS).

[0119] Optionally, at 414, the RAN (e.g., source gNB 420) analyzes the application traffic to identify traffic characteristics / patterns (e.g., in the DL). Element 414 may be performed in the order described herein or may be performed in parallel with elements 406 to 412. Alternatively, in some configurations, traffic analysis for characteristic / pattern identification may be performed only by the RAN, and thus, element 414 may be initiated when establishing a multimodal / XR session. In some configurations, traffic characteristic / pattern detection / identification may be performed in the UPF. The UPF may communicate the results to the RAN.

[0120] At 416, based on measurement information related to wireless connectivity, the RAN (e.g., source gNB 420) detects that a handover may be required for at least one WTRU in the group. The source gNB 420 may analyze the collected information on traffic characteristics / patterns received from the WTRUs, RAN, or UPF in the group. The source gNB 420 may detect whether there is an opportunity to perform the handover in advance. The unimodal flows may be distributed among the group of WTRUs, and in some scenarios, the traffic characteristics / patterns between the unimodal flows may be different (e.g., when the video service may be idle, the tactile service may not be idle). Therefore, when deciding the most appropriate time for the handover, all different characteristics / patterns of the same application received from multiple WTRUs may be considered (e.g., the idle traffic windows of two WTRUs are aligned at similar times). The RAN may identify whether a subset of WTRUs within the group may be handed over together, and whether to terminate connectivity to other WTRUs that are not handed over together.

[0121] In some scenarios, an application may require multimodal flows, and therefore the WTRUs associated with those flows will be processed together. A process together indication may be provided by the AF / AS to the RAN, and the RAN may use this indication to determine, for example, whether to terminate other WTRUs or reject all WTRUs. If all WTRUs cannot be processed together, this may trigger the application AF / AS to perform changes.

[0122] Diagram 400 illustrates that a source gNB transmits a handover request at 418 to a target gNB 430, such as by transmitting the handover request over an Xn interface. The request 418 may include WTRU group related information and multimodal application requirements (e.g., synchronization thresholds) (as described herein). The request 418 may include a list of WTRUs to be handed over. Each WTRU in the list may have a priority indication. The priority indication is used in the event that the target gNB 430 cannot accept all WTRUs in the group. The target gNB 430 may use the priority to decide which WTRU in the WTRU set to allow handover. This may include procedures in the standard.

[0123] The target gNB 430 may receive the WTRU group and service related information at 422, as described herein. The service related information may also include requirements for multimodal flows (e.g., synchronization thresholds). Based on the received information, the target gNB 430 decides whether all WTRUs may be handed over, or which subset of WTRUs may be handed over. The target gNB 430 may perform admission control at 424 for all selected WTRUs in the group.

[0124] In a scenario where not all WTRUs in the group have been handed over to the target cell, if a handle together indication (described herein) is provided, the RAN / target cell may inform the application (WTRU or AF / AS) that not all WTRUs have been handed over, and which WTRUs have been handed over and which WTRUs have not been handed over. In this case, the application (e.g., WTRU or AF / AS) may perform the corresponding application layer tasks. For example, the AF / AS may change the configuration of the modality (e.g., by reducing the frame rate, which may also reduce the radio resource utilization of the modality and thus free up resources in the target cell) while retaining the service requirements (such as synchronization thresholds), which may allow the remaining WTRUs to be admitted to the new target cell.

[0125] The target gNB 430 may confirm the handover request by responding to the source gNB 420 with an RRC configuration message 426 carrying the handover request confirmation. The message 426 may include a list of WTRUs accepted by the target gNB 430 for handover.

[0126] In the scenario where only a subset of WTRUs are identified for handover to the target cell / gNB and connectivity to other WTRUs is temporarily terminated at 432 (scenario 1 440), an optional handover status notification 428 is transmitted to the WTRUs that are not selected for handover, indicating that only some of the WTRUs will be handed over to the target gNB 430. The connectivity termination message 432 may specify when the WTRU may retry to reestablish connectivity or perform a handover. This may include a timer, duration of termination, geographic location, or other cells / gNBs to which the WTRU may connect when in coverage. In the case of scenario 1 440, the WTRU may notify the application that connectivity will be terminated due to the handover, where the handover notification message indicates that connectivity to the WTRU will be temporarily terminated.

[0127] The WTRU 410 selected for handover together receives an RRCReconfiguration message 434 from the RAN (e.g., source gNB 420) indicating the possibility of performing a handover. The message may specify information about when the handover may be performed. A separate RRCReconfiguration message 436 may be transmitted to each WTRU in the group (e.g., if the configuration differs between the WTRUs in the group). Alternatively, a single RRCReconfiguration message 434, 436 may be transmitted to the group RNTI (G-RNTI), subgroup RNTI, or multimodal RNTI configured for the group of WTRUs. In the first type of information, this may refer to traffic characteristics. This may be based on the priority of the traffic. For example, the handover may be advanced to occur before receiving traffic of a certain priority or before sending traffic of a certain priority. This may be based on a flag in the PDU header. For example, the handover may be advanced to occur before receiving traffic with the flag or before sending traffic with the flag. In the second type of information, this may refer to specific time information (e.g., a specific time interval). In the third type of information, this may refer to traffic volume. For example, the handover may be advanced to occur after the WTRU has received K DL PDUs or after the WTRU has sent K UL PDUs. In addition, the message may include more than one threshold set for triggering the handover. The threshold may be selected based on the traffic type. The message may indicate whether the WTRU is able to synchronize the handover time directly between WTRUs over the D2D communication link (which may be used when the RAN does not specify a specific handover time). The messages 434, 436 may include information about the cell to which they are handing over (e.g., cell ID).

[0128] In some scenarios, a message indicating the possibility of handover is transmitted to the relevant AF / AS so that the AF / AS can decide whether to perform any relevant application layer operations.

[0129] In the second scenario, the WTRUs selected not to handover together receive an RRCReconfiguration message 438 from the RAN (e.g., source gNB 420), triggering a normal handover procedure. The message 438 may also include information about the cell to which they are handing over (e.g., cell ID).

[0130] The WTRU 410 may notify the application at 442 about the upcoming handover so that decisions can be made regarding relevant application layer adjustments (e.g., whether to change the video codec due to the disruption to connectivity caused when performing the handover). In other words, the WTRU application is notified that a handover event has occurred or is about to occur. The WTRU application may use this information when considering how and whether to adjust the codec settings. For example, when multiple packets are dropped or received in errors, the WTRU application may normally determine to adjust the codec settings (such as frame rate), but if the handover has already occurred, the WTRU application may choose to forgo such setting changes. This may be because the WTRU application may assume that the dropped packets are due to a transient event (i.e., the handover). The application (e.g., at the WTRU and / or AF / AS) may be notified of the temporary disconnection or the subset of WTRUs configured to fall back to normal HO, and the WTRU / application may make a decision to change the parameters of the service to help the WTRU adapt to the handover, such as by changing the index of the QoS rule (if each modality has been configured with multiple PCC rules indexed according to the codec settings, or the number of frames per second (fps) for each modality is configured to ensure that all WTRUs can qualify).

[0131] When the selected conditions are met, such as when the WTRU is not receiving or transmitting critical data, the WTRU may perform a handover at 444. The handover may be performed during an identified time (e.g., a specific time window, the start and end of a data burst may be identified and the handover may be performed at the end of the burst). Once the WTRU moves the RRC connection to the target gNB 430, the WTRU may transmit an RRCReconfigurationComplete message 446, 448 to the target gNB 430. Additionally, on some configurations of the process, the WTRU 410 may include the cause / condition of the handover in the message, such as a handover performed due to selecting Threshold Set 1.

[0132] There may be a transfer and reception of data at 452. This may include any data held / buffered at the WTRU or RAN or both prior to performing the handover, such as high priority data.

[0133] As presented, these procedures may allow handover of a set of WTRUs or a subset of WTRUs (e.g., WTRUs with stricter synchronization thresholds) within a group to be planned so that the handover is performed in a coordinated manner. These procedures may also allow connectivity to certain WTRUs to be temporarily terminated, or their handover to be performed using the normal handover procedure, allowing for the WTRU subsets to be prioritized. This enables the system to ensure that the latency requirements of the application (e.g., synchronization thresholds) are met.

[0134] Figure 4B A method 450 for planning a group handover is illustrated. The method 450 includes, at 460, detecting that a handover is needed based on traffic pattern related information. At 470, the method 450 includes terminating connectivity for some WTRUs if necessary. For example, the termination may be determined by a target gNB. At 480, the method 450 includes handing over the connectivity of the WTRUs. At 490, the method 450 includes signaling to perform the handover and switch to a new cell. At 495, the method 450 includes transferring data.

[0135] Figure 5A An example signal diagram 500 is illustrated for a WTRU triggered group handover, such as by using CHO. The signal diagram 500 depicts a plurality of WTRUs 510 involved in a group handover. Specifically, two WTRUs are shown, although any number of WTRUs may be included in the plurality of WTRUs 510. The two WTRUs depicted include WTRU1 510.1 and WTRU2 510.2. The signal diagram 500 includes a source gNB 520 and a target gNB 530, as well as an additional target gNB 530.1. Figure 4A The initial elements described. For example, these initial elements include element 502.

[0136] In some configurations, the WTRU may inform the RAN that it prefers to use CHO and why (e.g., prefers / requires CHO due to latency requirements for tactile flows in the UL). This information may then be used when deciding whether to use CHO.

[0137] A WTRU triggered group handover enables the WTRU to notify some or all WTRUs in the group when it plans to handover to another cell / gNB. Although these procedures utilize the CHO procedure, the normal HO procedure may also be modified to allow the WTRU to trigger a group handover. The WTRU notification informs the WTRU that the second WTRU is handing over to the target cell X. The WTRU notification may enable the WTRU to determine to handover to cell X more easily (e.g., to lower the threshold in order to coordinate the handover between the WTRUs of the group so as to minimize their interruption time and maintain synchronization between the multimodal streams).

[0138] Figure 5A Two examples of transmitting a handover notification are illustrated. Figure 5A In the first example, the WTRU (WTRU-1) that is preparing for handover notifies the other WTRUs that are selected (selected by the RAN in the exemplary process below) for handover together via the network. Figure 5A In a second example, WTRU-1 directly transmits a handover notification using D2D / SL communication to other WTRUs selected for handover together.

[0139] At 504, the source gNB 520 may use CHO for all WTRUs or a subset of WTRUs in the group based on information about traffic characteristics / patterns. For example, due to stringent latency requirements for some flows of a multimodal session, the RAN may perform CHO only on the corresponding WTRUs instead of a normal handover. Other parameters may be used.

[0140] The source gNB 520 may select one or more candidate cells belonging to one or more candidate gNBs 530, 530.1 and transmit a handover request message 506, 508 requesting CHO. The source gNB 530 may consider candidate cells and gNBs that can meet the requirements of a set of WTRUs. The message 506, 508 may include multimodal / XRM session related information (e.g., session ID, required services) and flow information and its requirements (e.g., the session includes a tactile flow requiring URLLC). One or more target gNBs 530, 530.1 may perform admission control 512, 514. If multimodal / XR session awareness information is transmitted to the target gNB 530, 530.1, the multimodal / XR session may be aware that the admission control 512, 514 may be performed.

[0141] The target gNB 530, 530.1 may prepare for the handover by transmitting 516, 518 a handover request confirmation to the source gNB 520. The message 516, 518 may indicate whether the requested WTRU group or only a subset of WTRUs may be accepted for handover. The message may indicate whether the gNB supports multimodal / XR sessions and services. The message may indicate one or more restrictions or rules for performing a handover of multimodal / XR sessions and services. For example, such restrictions / rules may include a validity time window (e.g., start time, end time, duration) indicating when the handover may be performed.

[0142] The selected WTRU 510 may receive an RRC message 522, 524 (e.g., RRCReconfiguration, Handover Command) from the RAN (source gNB 520) containing the configuration of the CHO candidate cell and the CHO execution condition. The CHO execution condition may include service characteristic / mode information and service priority information to be used to decide when to perform CHO. The CHO execution condition may include a radio link measurement threshold associated with the radio link quality between the WTRU and the candidate cell. The message may include a list of WTRUs selected to be handed over together (e.g., so as to allow them to communicate with each other to perform HO). The message may also indicate the possibility of performing the handover in advance. The message may specify information about when the handover may be performed. This may be based on the priority of the service. For example, the handover may be advanced to occur before receiving a service of a certain priority or before sending a service of a certain priority. This may be based on a flag in the PDU header. For example, the handover may be advanced to occur before receiving a service with the flag or before sending a service with the flag. In the second type of information, this may refer to specific time information (e.g., a specific time interval). In the third type of information, this may refer to the traffic volume. For example, the handover may be advanced to occur after the WTRU has received K DL PDUs or after the WTRU has sent K UL PDUs. In addition, the message may include more than one threshold set for triggering the handover. The threshold is selected based on the type of traffic.

[0143] The WTRU 510 may notify applications about outstanding handovers so that decisions can be made regarding relevant application layer adjustments (e.g., whether to change the video codec due to disruption to connectivity when performing the handover). In some scenarios, a message indicating the possibility of a handover is transmitted to the relevant AF / AS so that the AF / AS can decide whether to perform any relevant application layer operations. The message may include two sets of measurement thresholds. One soft HO condition set indicates when a HO may / can be performed, allowing the WTRU (e.g., based on XR traffic characteristics / patterns) to make a final decision. A second hard HO condition set indicates when the WTRU must perform a HO.

[0144] The WTRU 510 may transmit an RRC response message 526, 528 (e.g., an RRCReconfigurationComplete message) to the source gNB 520. In some configurations, the messages 526, 528 may include a configuration selected from the configurations received at 522, 524 (e.g., a threshold for performing a handover). If early data forwarding is applied, the source gNB 520 may transmit an early state transfer message 532. The message 532 may include information of the WTRU group (e.g., a multimodal session ID, the WTRUs that are part of the group). The message 532 may include any information related to the XRM session (e.g., an ID) and / or information related to a PDU set (e.g., a PDU set ID) and / or multimodal synchronization / correlation information indicating any interdependencies between PDUs / streams / sessions (e.g., a multimodal session correlation ID).

[0145] The WTRU 510 may begin evaluating CHO execution conditions for the candidate cells at 534, also including traffic characteristics / patterns, and may obtain information from any layer (e.g., application, PDU, PDU set, packet, and data). The WTRU 510 may analyze the traffic and decide if CHO must be performed before delivering high priority traffic. If there are any periods when no traffic is delivered, those periods may be used to perform CHO (e.g., for one or more WTRUs in a WTRU group configured with a CDRX configuration, CHO may be configured to be performed during an off / sleep duration during which the WTRU is not expected to transmit / receive data).

[0146] If there is traffic that can be transmitted before performing CHO, then in the scenario where the handover notification is transmitted by the network (option 1), the WTRU-1 510.1 transmits a handover notification 536 to the source gNB 520 to notify the decision made at 534. The notification 536 may include the time at which the WTRU-1 510.1 decides to perform the handover (this may be in the form of an absolute time, a relative time, a time window) and information about the cell to which it is handing over (e.g., a cell ID).

[0147] All WTRUs or a subset of WTRUs in the group ( Figure 5AWTRU-2 510.2 in the example may receive a handover notification 538 from the source gNB 520 notifying WTRU-1 510.1 that it is handing over to the target gNB 530. In a scenario where a subset of WTRUs are selected (e.g., by the RAN based on the target gNB capabilities, or may be determined based on the requirements of the flows (e.g., synchronization thresholds)) to perform the handover together, only the selected subset of WTRUs may receive the notification 538. The notification 538 may indicate whether D2D / SL connectivity may be used to further synchronize the handover time. The notification may also indicate whether to lower the CHO threshold (and by how much), or whether another set of CHO thresholds is to be used. The notification 538 may include information about the cell to which it is handing over (e.g., cell ID).

[0148] In the scenario where the handover notification is transmitted directly via D2D / SL communication (scenario 545), all WTRUs or a subset of WTRUs in the group ( Figure 5A WTRU-2 510.2 in FIG. 5A receives a handover notification 542 from WTRU-1 510.1 directly using D2D communications, notifying WTRU-1 510.1 that it is handing over to the target gNB 530. In a scenario where a subset of WTRUs are selected (which may be determined based on the requirements of the flows (e.g., synchronization thresholds)) to perform the handover together, only the selected subset of WTRUs may receive the message. The notification 542 may include the time at which the WTRU-1 decides to perform the handover (this may be in the form of an absolute time, a relative time, a time window). Alternatively, the notification 542 may indicate whether to lower the CHO threshold (and by how much), or whether another set of CHO thresholds is to be used. The notification 542 may include information about the cell to which it is handing over (e.g., cell ID). Alternatively, WTRU-1 510.1 may broadcast the message to all nearby WTRUs. The broadcast may include information about the WTRU group (e.g., multimodal session ID, WTRUs that are part of the group). Upon reception, nearby WTRUs determine whether they are part of a group that may be affected by the handover of WTRU-1 510.1.

[0149] The WTRU receiving the handover notification 538, 542 may decide to perform the handover at the time specified by WTRU-1 510.1, or may lower the handover threshold at 544 to facilitate the handover. Alternatively, the WTRU may select a different set of CHO thresholds (e.g., a second set of pre-configured CHO conditions) at 544. If the CHO candidate cell satisfies the corresponding CHO execution condition (e.g., soft HO condition), and the traffic characteristics meet the traffic conditions, the WTRU may release connectivity from the source cell before transmitting RACH / RRC to the target cell at 546. The WTRU may maintain connection with both the source gNB 520 and the target gNB 530, continuing to send traffic from both cells before detaching from the source gNB 520. Once the WTRU receives confirmation from the target cell (e.g., confirmation that resources are allocated to meet the requirements of the flow at 548), the WTRU may release the connection to the source cell. The WTRU may perform a handover during the identified time (eg, may identify a specific time window, the start and end of a data burst, and perform a handover at the end of the burst). Soft handover conditions may be ignored when hard CHO execution conditions are specified and the corresponding conditions are met.

[0150] The WTRU may synchronize with the selected cell at 546 and complete the handover process by transmitting an RRCReconfigurationComplete message 548. The message 548 may include any information related to the XRM session (e.g., ID) and / or information related to the PDU set (e.g., PDU set ID) and / or multimodal synchronization / correlation information indicating any interdependencies between PDUs / flows / sessions (e.g., multimodal session correlation ID). The target gNB 530 may transmit a handover success message 552 to the source gNB 520 notifying all WTRUs or a subset of WTRUs in the group that have successfully accessed the target cell.

[0151] The source gNB 520 may transmit an SN state transfer message 554 to the target gNB 530. The source gNB 520 may transmit a handover cancel message 556 to all target gNBs 530.1, canceling the CHO for the WTRU.

[0152] This example may allow a WTRU to notify some or all WTRUs in a group (e.g., WTRUs with stricter synchronization thresholds) of a planned handover so that the handover is performed in a coordinated manner. This may allow the WTRUs to coordinate directly between themselves to ensure that they are handed over at similar times, minimizing relative handover delays between the WTRUs. This enables the 5G system to ensure that the latency requirements of the application (e.g., synchronization thresholds) are met.

[0153] Figure 5BA method 550 for coordinated handover for a group of WTRUs is included, performed in a WTRU. The method 550 includes receiving a first coordinated handover configuration at 560. At 570, the method 550 includes receiving a handover notification. The handover notification may provide a reminder of a possible coordinated handover. The handover notification may include a handover condition that triggers the coordinated handover. At 580, the method 550 includes setting a handover threshold based on the handover condition. At 590, the method 550 includes monitoring the handover threshold. At 595, the method 550 includes performing a coordinated handover when the handover threshold is met.

[0154] Fig. 6A A signal diagram 600 is illustrated for anchor based handover. Anchor based group handover may provide for a WTRU within a WTRU group to act as an anchor device. As an anchor device, the WTRU may be allowed to coordinate the group handover in order to perform the handover. Such an approach may allow the HO to be performed taking into account more accurate / up-to-date context information (e.g., connectivity conditions) related to the WTRU group. The WTRUs within the group may continue to receive control messages from the RAN, however, the messages received from the anchor device may be able to overwrite the same control messages received from the RAN, thereby providing the ability to coordinate the handover of a group of WTRUs.

[0155] Two types of anchor-based handovers may be performed. In a first example, the anchor WTRU 610.1 may directly transmit a planned handover request to the other selected WTRUs using D2D / SL communication for handover. In a second example, the anchor WTRU 610.1 may transmit a planned handover request to the other selected WTRUs via the network. In both scenarios, the anchor WTRU 610.1 may generate a planned handover request and override the handover request transmitted by the network.

[0156] Anchor-based handover may include Figure 4A402 to 414 of FIG. 600 includes at 602 collecting / receiving handover related information and measurements and application layer information and measurements. A configuration message may be transmitted to the selected anchor WTRU 610.1 to provide information for configuring the WTRU 610.1 as an anchor WTRU and coordinating the HO process. The configuration message may specify when the WTRU 610.1 begins and ends its role as an anchor WTRU. For example, by providing a specified time window, time duration, or geographic area. The configuration message may include information about the WTRU (610.2) that the anchor WTRU 610.1 is serving. In 602, the WTRU 610 that is part of the group receives a configuration message indicating that the anchor WTRU has been configured. The WTRU configuration message may also include a wait timer value that indicates how long the WTRU may wait for a HO-related message from the anchor WTRU 610.1 before acting on the HO-related message received from the network when the HO-related message from the network first arrives. At 602, collecting and receiving handover related information and measurements may include Figure 4A The anchor-based handover elements described in 402 to 414 of . In 602, as stated, the measurements may include handover-related information and measurements, and may include application layer information and measurements.

[0157] Element 604 is similar to Figure 4A Element 416 of , includes detecting that at least one WTRU needs to be handed over. Element 605 is similar to Figure 4A Element 418 of , including source gNB 620 transmitting a handover request to target gNB 630. Elements 606 and 608 are similar to Figure 4A 422 and 424 of , which include the target gNB 630 receiving information related to the WTRU 610 group and the multimodal session at 606. The target gNB 630 performs admission control at 608 taking into account the information received at 606. Element 615 is similar to Figure 4A Element 426 of the present invention includes the target gNB 630 confirming the handover request 605 by responding 615 to the source gNB 620 with an RRC configuration carrying the handover request confirmation.

[0158] The WTRUs 610 in the group may receive a handover request as an RRCReconfiguration message from the RAN (e.g., the source gNB 620). Element 612 is similar to Figure 4A Element 438 of . In some scenarios, the message from the RAN may be transmitted to the WTRU 610 via the anchor WTRU 610.1. The WTRU 610 may wait for the HO message from the anchor WTRU 610.1, as configured at 602, and then act / perform based on the message.

[0159] In one example (such as Fig. 6A 1), the anchor WTRU 610.1 transmits a planned handover request 625 directly to the WTRU 610.2 selected for handover together. The message 625 is similar to or takes the form of an RRCReconfiguration message. The message 625 may be similar to Figure 4A Message 434 in. Message 625 may be transmitted to the WTRUs 610 selected for handover together using a unicast or multicast sidelink transmission. Alternatively, the message 625 may be a broadcast sidelink transmission. In this case, the receiving WTRUs may determine whether they are in the group of WTRUs 610 selected for handover together.

[0160] In another example (such as Fig. 6A 2), the anchor WTRU 610.1 may transmit a planned handover request 635 to the RAN (source gNB 620) to be transmitted as a planned handover request 645 to the selected subset of WTRUs 610. Message 645 may be similar to or in the form of an RRCReconfiguration message. Message 645 may indicate the issuer of the configuration (whether it is an anchor WTRU or a RAN node) (e.g., including its ID) to allow the WTRU 610 to determine whether message 645 is a configuration message from the RAN or a configuration message from the anchor WTRU 610.1 and forwarded only by the RAN. Message 645 may be similar to Figure 4A Message 434 in.

[0161] In the case of message 645, the selected subset of WTRUs 610 receive a planned handover request 625, 645 from the anchor WTRU 610.1 via the RAN. The messages 625, 645 may be similar to or in the form of an RRCReconfiguration message. Figure 4A Message 434 in WTRU 610. The WTRU 610 may notify the application about the handover and switch to the new cell at 614 at a similar time. Element 614 is similar to Figure 4A Elements 442, 444.

[0162] Once the WTRU 610 moves the RRC connection to the target gNB 630, the WTRU 610 may transmit an RRCReconfigurationComplete message 655, 665 to the target gNB 630. In some configurations, the WTRU 610 may include the cause / condition of the handover in the message, e.g., the handover was performed due to selection of Threshold Set 1. In some configurations, the message from the RAN may be transmitted to the WTRU 610 via the anchor WTRU 610.1.

[0163] At 616, the WTRU 610 may communicate and receive data. Element 616 is similar to Figure 4A Element 452. In some configurations, messages from the RAN may be transmitted to the WTRU 610 via the anchor WTRU 610.1.

[0164] The order of steps may vary, depending on when the anchor WTRU 610.1 decides to perform a handover.In some configurations, control traffic or user plane traffic or both may be routed via the anchor device.

[0165] Figure 6B A method 650 performed by an anchor WTRU is illustrated. The method 650 includes collecting / receiving handover related information and measurements, such as from a source gNB, at 660. At 670, the method 650 may include the anchor WTRU receiving a conventional handover request from the source gNB, and may include the anchor WTRU transmitting a conventional handover request to other WTRUs, as described above with respect to option 1 and option 2. At 680, the method 650 includes switching to a new cell and transmitting messaging accordingly. At 690, the method 650 includes transferring data via a target gNB.

[0166] Although features and elements are described above in specific combinations, it will be understood by those of ordinary skill in the art that each feature or element may be used alone or in any combination with other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (sent via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as built-in hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile disks (DVDs)). A processor associated with software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method, performed in a wireless transmit receive unit (WTRU), for coordinated handover for a group of WTRUs, the method comprising: receiving a first coordinated handover configuration; receiving a handover notification, the handover notification prompting a coordinated handover and including at least one handover condition triggering the coordinated handover; Setting a handover threshold based on the handover condition; Determine the measurement value; as well as The coordinated handover is performed when the measurement value satisfies the handover threshold. 2 . The method of claim 1 , wherein the at least one handover condition comprises an overall QoE falling below a threshold. The method of claim 1 , wherein the measurement value comprises a traffic burst indicator. The method of claim 1 , wherein the handover notification is communicated using device-to-device connectivity. The method of claim 1 , further comprising monitoring the measured value.

6. The method of claim 1, wherein the set handover threshold is communicated to the group of WTRUs. The method of claim 1 , wherein the first coordinated handover configuration is communicated via sidelink communications.

8. The method of claim 1, wherein the first coordinated handover configuration is communicated via PC5 communications.

9. The method of claim 1, wherein the group of WTRUs comprises a common group identification (ID).

10. The method of claim 1, wherein the set of WTRUs are grouped based on a common application.

11. The method of claim 1 , wherein the set of WTRUs are grouped based on a common application experience.

12. A wireless transmit receive unit (WTRU) for performing a coordinated handover for a group of WTRUs, the WTRU comprising: processor; and a transceiver communicatively coupled to the processor, The processor and the transceiver operate to: receiving a first coordinated handover configuration; receiving a handover notification, the handover notification prompting a coordinated handover and including at least one handover condition triggering the coordinated handover; Setting a handover threshold based on the handover condition; Determine the measurement value; as well as The coordinated handover is performed when the measurement value satisfies the handover threshold.

13. The WTRU of claim 12, wherein the at least one handover condition comprises an overall QoE falling below a threshold.

14. The WTRU of claim 12, wherein the measurement value comprises a traffic burst indicator.

15. The WTRU of claim 12, wherein the handover notification is communicated using device-to-device connectivity.

16. The WTRU of claim 12, wherein the processor and the transceiver operate to monitor the measurement value.

17. The WTRU of claim 12, wherein the first coordinated handover configuration is communicated via sidelink communications.

18. The WTRU of claim 12, wherein the group of WTRUs comprises a common group identification (ID).

19. The WTRU of claim 12, wherein the set of WTRUs are grouped based on a common application.

20. The WTRU of claim 12, wherein the set of WTRUs are grouped based on a common application experience.

Images