Method, architecture, device and system for path switching

Abstract

Processes, methods, architectures, devices, systems, apparatuses, and computer program products for path switching are disclosed. A wireless transmit-receive unit (WTRU), as a member of a group of WTRUs for performing collaborative services, may receive an indication of path switching of traffic between the WTRU and a network. The WTRU may discover a candidate WTRU-to-network relay that may be used to process the amount of traffic between the WTRU and the network. The WTRU may select a candidate WTRU to a network relay to perform the path switching.

Description

Cross-reference to related applications

[0001] This application claims the benefit of U.S. Patent Application No. 63 / 527,693, filed July 19, 2023, which is incorporated herein by reference in its entirety. Background Technology

[0002] This disclosure generally relates to the fields of communications, software, and coding, including, for example, methods, architectures, devices, and systems related to collaborative services. Summary of the Invention

[0003] When serving a single application and / or a single user, the communication (e.g., to improve throughput, coverage) and computing power of multiple WTRUs (Wireless Transmit-Receive Units) are aggregated, allowing the system to provide resources and services that meet the needs of such applications.

[0004] The ability to combine multiple WTRUs also allows for an enhanced user experience.

[0005] WTRU to Network Relay (WTRU2NW Relay) extends the coverage of WTRU by providing an indirect connection to 5GC (5G core network).

[0006] The goal is to define a mechanism that allows coordination of connecting WTRU groups to the WTRU2NW trunk and avoids some WTRUs becoming disconnected due to the inability to switch to the WTRU2NW trunk.

[0007] The following defines and describes methods and apparatus for improving the management of WTRU groups that cooperate to provide one or more services, and are protected under the appended claims. Attached Figure Description

[0008] A more detailed understanding can be obtained from the following detailed description given by way of example in conjunction with the accompanying drawings. As with the detailed description, the figures in such drawings are exemplary. Therefore, the figures and the detailed description should not be considered limiting, and other equally valid examples are possible. Furthermore, the same reference numerals (“reference numerals”) in the figures indicate the same elements, and wherein: Figure 1A This is a system diagram illustrating an exemplary communication system; Figure 1B It shows that it can be shown Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) used within the communication system shown; Figure 1C It shows that it can be shown Figure 1A A system diagram showing an exemplary radio access network (RAN) and an exemplary core network (CN) used within the communication system; Figure 1D It shows that it can be shown Figure 1A The system diagram shown illustrates yet another exemplary RAN and yet another exemplary CN used within the communication system. Figure 2 This is a timing diagram of a method for switching a WTRU group path to a WTRU2NW relay according to one embodiment; Figure 3 This is a timing diagram of a layer 2-based connection establishment method for a WTRU for a collaborative group according to one embodiment; Figure 4 This is a timing diagram of a layer 3-based connection establishment method for a collaborative group WTRU according to one embodiment; Figure 5 This is a timing diagram of a Layer 2-based WTRU2NW relay connection establishment method for a cooperative group according to one embodiment; Figure 6 This is a timing diagram of a layer 3-based WTRU2NW relay connection establishment method for a layer 3-based cooperative group according to one embodiment; Figure 7 This is a timing diagram of a WTRU2NW relay connection establishment method for multi-mode services according to one embodiment; Figure 8 This is a flowchart of a path switching method according to one embodiment; Figure 9 This is a flowchart of a method for collaborative services according to one embodiment; Figure 10 This is a flowchart of a path switching method for collaborative services according to one embodiment.

[0009] Figure 11 This is a flowchart of a path switching method for collaborative services according to one embodiment. Detailed Implementation

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

[0011] Abbreviations and acronyms AF application functions AMBR aggregation maximum bit rate NAS Non-Access Layer NW Network PC5 is an interface for direct (device-to-device or WTRU-to-WTRU) communication. ProSe proximity-based services RAT wireless access technology RAN (Radio Access Network) REQ request RRC Radio Resource Control RSP Response UE User Equipment, WTRU WTRU2NWWTRU to Network w / has.

[0012] Exemplary communication system The methods, apparatus, and systems presented herein are well-suited for communications involving wired and wireless networks. About Figures 1A to 1D An overview of various types of wireless devices and infrastructures is provided, wherein various elements of a network may utilize, perform, be arranged according to, and / or be adapted to and / or configured for use with the methods, devices and systems provided herein.

[0013] Figure 1AThis is a system diagram illustrating an exemplary communication system 100 that may implement one or more of the disclosed embodiments. The communication system 100 may be a multiple access system providing content such as voice, data, video, messaging, and broadcasting to multiple wireless users. The communication system 100 enables multiple wireless users to access such content through shared system resources including wireless broadband. 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 (ZT) Unique Word (UW) Discrete Fourier Transform (DFT) Extended OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0014] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104 / 113, a core network (CN) 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, it will 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 can be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include / or be user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0015] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d, for example, to facilitate access to one or more communication networks such as CN 106 / 115, Internet 110, and / or Network 112. For example, base stations 114a and 114b may be base transceiver stations (BTS), Node-B (NB), eNode-B (eNB), home Node-B (HNB), home eNode-B (HeNB), gNode-B (gNB), NRNode-B (NR NB), site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are each depicted as a single element, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0016] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a specific geographic area that may be relatively fixed or may change over time. A cell may also be divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each or any sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0017] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Any suitable air interface access technology (RAT) can be used to establish air interface 116.

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

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

[0020] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies, such as using New Radio (NR) to establish NR wireless access for air interface 116.

[0021] In one embodiment, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can, for instance, use a dual connectivity (DC) principle to jointly implement LTE radio access and NR radio access. Therefore, the air interface used by WTRUs 102a, 102b, and 102c can be characterized by multiple types of radio access technologies and / or by transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0022] In one embodiment, base station 114a and WTRUs 102a, 102b, and 102c may implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., Global Microwave Interconnection Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), GSMEDGE (GERAN), etc.

[0023] Figure 1A Base station 114b can be, for example, a wireless router, a home Node-B, a home eNode-B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in localized areas such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for use by drones), roads, etc. In embodiments, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In embodiments, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In embodiments, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish any of small cells, picocells, or femtocells. Figure 1A As shown, base station 114b can be directly connected to Internet 110. Therefore, base station 114b does not need to access Internet 110 via CN106 / 115.

[0024] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU 102a, 102b, 102c, and 102d. Data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although Figure 1AAs not shown, but will be understood, RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs employing the same RAT as or a different RAT than RAN 104 / 113. For example, in addition to being connected to RAN 104 / 113, which may be utilizing NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) employing any of the following radio technologies: GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or Wi-Fi.

[0025] CN 106 / 115 can also serve as a gateway for WTRU 102a, 102b, 102c, 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 / 114 or a different RAT.

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

[0027] Figure 1B This is a system diagram illustrating example WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other components / peripherals 138, etc. It will be understood that, while remaining consistent with the embodiments, WTRU 102 may include any sub-combination of the foregoing components.

[0028] Processor 118 can be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple 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) circuit, any other type of integrated circuit (IC), a state machine, etc. Processor 118 can perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 can be coupled to transceiver 120, which can be coupled to transmitting / receiving element 122. Although Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it will be understood that the processor 118 and transceiver 120 can be integrated together, for example, in an electronic package or chip.

[0029] Transmitting / receiving element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via air interface 116. For example, in one embodiment, transmitting / receiving element 122 can be an antenna configured to transmit and / or receive RF signals. In another embodiment, transmitting / receiving element 122 can be a transmitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, transmitting / receiving element 122 can be configured to transmit and / or receive both RF signals and optical signals. It will be understood that transmitting / receiving element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0030] Although the transmitting / receiving element 122 is in Figure 1B While depicted as a single element, WTRU 102 may include any number of transmitting / receiving elements 122. For example, WTRU 102 may employ MIMO technology. Thus, in one embodiment, WTRU 102 may include two or more transmitting / receiving elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interface 116.

[0031] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 can have multi-mode capability. Therefore, transceiver 120 can include multiple transceivers for enabling WTRU 102 to communicate via various RATs (e.g., such as NR and IEEE 802.11).

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

[0033] The processor 118 may receive power from the power supply 134 and may be configured to distribute power to other components in the WTRU 102 and / or control power to those other components. The power supply 134 may be any suitable device for powering the WTRU 102. For example, the power supply 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.

[0034] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to or instead of information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via 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 understood that, while remaining consistent with the embodiments, the WTRU 102 may acquire location information using any suitable location determination method.

[0035] The processor 118 can also be coupled to other components / peripherals 138, which may include one or more software and / or hardware modules / units providing additional features, functions, and / or wired or wireless connectivity. For example, components / peripherals 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (e.g., for photos and / or video), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Components / peripherals 138 may include one or more sensors, which may be gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors, or more of these.

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

[0037] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 can employ E-UTRA radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 can also communicate with CN 106.

[0038] RAN 104 may include eNode-Bs 160a, 160b, and 160c, but it will be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. eNode-Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, for example, eNode-B 160a may use multiple antennas to transmit radio signals to and receive radio signals from WTRU 102a.

[0039] Each of the eNode-B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in the uplink (UL) and / or downlink (DL), etc. Figure 1C As shown, eNode-B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0040] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. While each of the foregoing elements is depicted as part of the CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0041] The MME 162 can connect to each of the eNode-Bs 160a, 160b, and 160c in RAN 104 via the S1 interface and can act as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, etc. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0042] The SGW 164 can connect to each of the eNode Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 can typically route and forward user data packets to or from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions such as anchoring the user plane during eNode-B handover, triggering paging when DL data is available to WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0043] SGW 164 can be connected to PGW 166, which can provide WTRU 102a, 102b, 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0044] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to circuit-switched networks (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and conventional terrestrial line communication devices. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) or be able to communicate with such an IP gateway as an interface between CN 106 and PSTN 108. Additionally, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0045] Despite WTRU in Figures 1A to 1D While described as a wireless terminal, it is envisioned that, in some representative embodiments, such a terminal may (e.g., temporarily or permanently) use a wired communication interface with a communication network.

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

[0047] A WLAN in Infrastructure Basic Services Set (BSS) mode can have an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. The AP can have an interface to a Distribution System (DS) or another type of wired / wireless network that loads traffic into and / or loads traffic out of the BSS. Traffic originating outside the BSS destined for a STA can be delivered to the AP. Traffic from a STA to a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be sent between a source STA and a destination STA using a Direct Link Setup (DLS) (e.g., directly between them). In some representative embodiments, the DLS can use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as a "self-organizing" communication mode in this document.

[0048] When operating in 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of fixed width (e.g., a 20 MHz bandwidth) or dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, Carrier Sense Multiple Access - Collision Avoidance (CSMA / CA) can be implemented, for example, in an 802.11 system. For CSMA / CA, each STA, including the AP, can sense the primary channel. If a particular STA senses / detects that the primary signal is busy and / or determines that the primary signal is busy, that particular STA can back off. In a given BSS, at any given time, only one STA (e.g., only one station) can transmit.

[0049] High-throughput (HT) STAs can communicate using a 40 MHz wide channel, for example, by combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels.

[0050] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels, or by combining two non-consecutive 80 MHz channels, which can be referred to as an 80+80 configuration. In the 80+80 configuration, data, after channel coding, can be passed through a fragment parser that splits the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed on each stream separately. The streams can be mapped onto two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations of the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC) layer, entities, etc.

[0051] 802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV Blank (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support instrument-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 (e.g., only support) certain and / or limited bandwidths. MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0052] WLAN systems that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as the primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STAs operating in the BSS that support the minimum bandwidth operating mode. In the 802.11ah example, for STAs that support (e.g., only support) the 1MHz mode (e.g., MTC type devices), the primary channel can 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 Sense and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, due to STAs (which only support the 1MHz operating mode) transmitting to the AP, the entire available band may be considered busy even if most of the band remains idle and potentially available.

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

[0054] Figure 1D This is a system diagram illustrating RAN 113 and CN 115 according to one embodiment. As described above, RAN 113 may employ NR radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 113 may also communicate with CN 115.

[0055] RAN 113 may include gNBs 180a, 180b, and 180c, but it will be understood that RAN 113 may include any number of gNBs while remaining consistent with the embodiments. gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from WTRUs 102a, 102b, and 102c. Thus, for example, gNB 180a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In one embodiment, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be located on unlicensed spectrum, while the remaining component carriers may be located on licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c may implement Coordinated Multipoint (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0056] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with a scalable digital architecture. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes of various lengths or scalable lengths or transmission time intervals (TTIs) (e.g., including different numbers of OFDM symbols and / or absolute times of varying durations).

[0057] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNodeBs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can use one or more of gNBs 180a, 180b, and 180c as mobile anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate / connect with gNBs 180a, 180b, and 180c while also communicating / connecting with another RAN (such as eNode-Bs 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c and one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, and 160c can act as mobile anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput to serve WTRUs 102a, 102b, and 102c.

[0058] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, support for network slicing, dual connectivity, interoperability between NR and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB180a, 180b, and 180c can communicate with each other via the Xn interface.

[0059] Figure 1DThe CN 115 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least two Session Management Functions (SMFs) 183a, 183b, and at least one Data Network (DN) 185a, 185b. While each of the foregoing elements is depicted as part of the CN 115, it will be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0060] AMF 182a and 182b can connect to one or more of the gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different Protocol Data Unit (PDU) sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating NAS signaling, mobility management, etc. AMF 182a and 182b can use network slicing, for example, to customize CN support for WTRU 102a, 102b, and 102c based on the service types being used by WTRU 102a, 102b, and 102c. For example, different network slices can be created for different use cases, such as services dependent on Ultra Reliable Low Latency (URLLC) access, services dependent on Enhanced Massive Mobile Broadband (eMBB) access, and services for MTC access. AMF 162 can provide control plane functions for handover between RAN 113 and other RANs (not shown) employing other radio technologies (such as LTE, LTE-A, LTE-A Pro) and / or non-3GPP access technologies (such as Wi-Fi).

[0061] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 115 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 115 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure traffic routing through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, or Ethernet-based.

[0062] UPFs 184a and 184b can be connected via the N3 interface to one or more of the gNBs 180a, 180b, and 180c in RAN 113. These gNBs can provide WTRUs 102a, 102b, and 102c with access to packet-switched networks (such as the Internet 110), for example, to facilitate communication between WTRUs 102a, 102b, and 102c and IP-enabled devices. UPFs 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multihomed PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobile anchoring.

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

[0064] Given Figures 1A to 1D and Figures 1A to 1D The corresponding description may be performed by one or more of the functions described herein with respect to any of the following: WTRU 102a to 102d, base stations 114a to 114b, eNode-B 160a to 160c, MME 162, SGW 164, PGW 166, gNB 180a to 180c, AMF 182a to 182b, UPF 184a to 184b, SMF 183a to 183b, DN 185a to 185b, and / or any other element / device described herein. A simulation device may be one or more devices configured to simulate one or more of the functions described herein. For example, a simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0065] Simulation devices can be designed to perform one or more tests on other devices in laboratory and / or carrier network environments. For example, one or more simulation devices may perform one or more functions when fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. One or more simulation devices may perform one or more functions when temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices may be directly coupled to another device for testing purposes and / or may use over-the-air wireless communication to perform tests.

[0066] One or more simulation devices may perform one or more (including all) functions when not implemented / deployed as part of a wired and / or wireless communication network. For example, a simulation device may be used to test scenarios in a laboratory and / or undeployed (e.g., under test) wired and / or wireless communication networks to perform tests on one or more components. One or more simulation devices may be test equipment. The simulation device may transmit and / or receive data using direct RF connection and / or wireless communication via an RF circuit system (e.g., which may include one or more antennas).

[0067] Introduction 5G ProSe The 5G ProSe service is used to directly discover available WTRU-to-WTRU network connections to enable direct communication between WTRUs, such as extending network coverage via relay connections, and to extend coverage between WTRUs via relays.

[0068] For direct communication between WTRUs, broadcast communication, multicast communication, and unicast communication are possible.

[0069] Device-to-device (D2D) direct communication allows two devices to communicate directly between them with or without network assistance. For unicast communication, the communicating entities use a Layer 2 ID (identifier) ​​to uniquely identify the WTRU. An application layer ID can be associated with one or more ProSe applications within the same WTRU; where a WTRU has more than one application layer ID, each application layer ID of the same WTRU is considered a different WTRU. Group communication mechanisms allow for one-to-many communication between WTRUs in a resource-efficient manner, thereby allowing messages to be easily propagated to large groups of people via a common downlink stream.

[0070] The WTRU to Network Relay (WTRU2NW Relay) extends the coverage of the WTRU by providing indirect connectivity to the 5GC (5G core network) via a Layer 2 relay and a Layer 3 relay. When a WTRU connects to a Layer 2 WTRU2NW relay, the gNB recognizes that the WTRU is connected via the Layer 2 WTRU2NW relay. When a WTRU connects to a Layer 3 WTRU2NW relay, the WTRU2NW relay notifies the 5GC that the WTRU has connected to that relay.

[0071] WTRU-to-WTRU trunks (WTRU2WTRU trunks) extend communication between WTRUs via Layer 2 trunks and Layer 3 trunks. When a WTRU connects to a Layer 2 WTRU2WTRU trunk, the Layer 2 trunk only forwards traffic between the two WTRUs, and the two WTRUs handle end-to-end connections between them. When a WTRU connects to a Layer 3 WTRU2WTRU trunk, the Layer 3 trunk forwards packets based on the WTRU's Layer 3 address.

[0072] By using the 5G ProSe service, WTRU can simultaneously have multiple connections to 5GC via direct connection and indirect connections to 5GC via relay.

[0073] WTRU aggregation Given the growing bandwidth and processing demands of emerging applications such as XR / Metaverse, one way to meet these demands is to aggregate resources from more than one device. Aggregating the communication (e.g., to improve throughput, coverage) and computing power of multiple WTRUs allows the system to provide the resources and services needed for such applications when serving a single application and / or a single user.

[0074] The ability to combine multiple WTRUs also allows for an enhanced user experience. For example, audio, video, and haptic information can be presented to the user for the same application and user. This can be achieved by aggregating VR headsets, headphones, and haptic suits, making the application experience truly immersive, rather than using a single WTRU to provide the application experience (which is quite limited due to various factors such as form factor and limited battery life).

[0075] Overview WTRUs within a group can switch paths to the same WTRU2NW trunk without affecting service experience. For certain applications (e.g., video games, public safety, XR, or vehicle users), a set of WTRUs may exist at the same location for some applications. Furthermore, due to various reasons (e.g., mobility, gNB overload, etc.), the WTRUs in this set may be changed to be indirectly connected to the WTRU2NW trunk.

[0076] In conventional 5G ProSe technology, no mechanism is defined between WTRU and WTRU2NW relays to allow coordination of WTRU groups to connect to WTRU2NW relays.

[0077] In the absence of proper support for coordination between WTRUs and WTRU2NW relays, some WTRUs may disconnect due to their inability to switch to a WTRU2NW relay, or finding another available WTRU2NW relay may require a longer latency than other relays. This will impact the quality of service (QoE) of the WTRU group. For example, if certain sensors (sensors within the WTRU group, such as those mentioned earlier in the examples of VR headsets, headphones, and haptic suits) are unavailable for rendering multimodal services to the user, the service may be disabled, or the user's QoE may degrade due to missing functionality (e.g., interaction latency, incorrect / outdated location information, etc.).

[0078] Therefore, according to the embodiment, for WTRUs in a group, the path can be switched to the same WTRU2NW trunk without affecting the service experience: - For WTRUs within the group, trigger a path switch to the WTRU2NW relay and select to start the WTRU; - The startup WTRU discovers and selects a WTRU2NW relay, and negotiates path switching for WTRUs within the selected WTRU2NW relay group; - This startup WTRU will notify other WTRUs in the group of information about the WTRU2NW relay; and - The starting WTRU and other WTRUs in the group connect to the selected WTRU2NW relay.

[0079] Therefore, according to the embodiment, for WTRUs in a group, the path can be switched to the same WTRU2NW trunk without affecting the service experience. WTRU2NW trunk: - Release RSC to support WTRU groups; Negotiation can support the establishment of a connection between the WTRU group and the initiating WTRU; - Reserve some resources for WTRU connectivity and PDU session support within the group; and - Establish a ProSe connection for each WTRU within the group.

[0080] Figure 2 This is a timing diagram of a method for switching a WTRU group path to a WTRU2NW relay according to one embodiment.

[0081] At the top, from left to right, are depicted as: WTRU1 (2001), WTRU2 (2002), WTRU3 (2003), WTRU2NW trunk 1 (2011), WTRU2NW trunk 2 (2012) and WTRU2NW trunk 3 (2013).

[0082] Assume that the three WTRUs described (WTRU1, WTRU2, and WTRU3 in this case) belong to a group (e.g., the WTRU group used in XR applications, the WTRU group used in collaborative services, etc.).

[0083] In 200, a WTRU member (WTRU1 in this case) in the WTRU group is triggered to switch the path to the WTRU2NW relay due to one or more reasons (e.g., poor channel quality, poor data rate, poor packet error rate, etc.).

[0084] As another example, when the WTRUs in a group are served by a WTRU2NW relay WTRU, the relay WTRU can trigger a group move if that relay WTRU is unable to handle the resources of the entire WTRU group.

[0085] As another example, when some members of a WTRU group are experiencing QoS degradation, an application or application server can trigger group mobility to switch the path to the WTRU2NW trunk.

[0086] For WTRU groups, an application group ID can be assigned by the application, and / or a layer 2 group ID can be assigned by the 5GC for addressing WTRU groups used for PC5 communication (sidelink-based device-to-device (WTRU-to-WTRU) communication, without the presence of a base station (gNB). Each WTRU in the group can obtain information about the group's member WTRUs (e.g., WTRU user information) and the number of group member WTRUs through the application. Here, the group ID refers to the application group ID.

[0087] In 201: WTRU1 can share its state (e.g., poor channel quality, poor data rate, etc.) and path switching needs with other WTRUs in the group via multicast or unicast. When WTRU1 shares its state, each WTRU in the group can respond to WTRU1.

[0088] WTRU1 can create a group member list from the WTRUs that responded to the information sharing in step 201, and can set the number of WTRUs in the WTRU group member list based on the number of WTRUs that responded in step 201. Alternatively, any WTRU with poor QoS can negotiate with other WTRUs, and some WTRUs can be selected as the starting WTRUs to perform relay discovery (WTRU1 is selected as the starting WTRU here), or the application can select the starting WTRUs to perform relay discovery based on its capabilities (such as processing power and battery capacity).

[0089] In step 202, WTRU1 performs a discovery process to discover available WTRU2NW relays within the group.

[0090] Other WTRUs within the group can perform a discovery process to discover available WTRU2NW relays within the group.

[0091] An RSC (Relay Service Code) can be assigned to each ProSe service that supports a WTRU group, and WTRUs within the group can discover WTRU2NW trunks that support the RSC.

[0092] When a group is formed for a specific service (e.g., a collaborative service), a dedicated RSC can be assigned to support that specific service. WTRUs within the group can discover WTRU2NW trunks that support the specific service via the dedicated RSC.

[0093] For Model B discovery mode, the WTRU can include the number of WTRUs in the group that will need to access the relay in the discovery request message. Based on well-known concepts in ProSe, in Model B (“Are you there?”), the initiating (discovering) WTRU sends a solicitation request message. The responding (discovering) WTRU sends a solicitation response message to be discovered. In Model A (“I’m here”), the initiating (announcing) WTRU sends an announcement message to be discovered. Model A uses a single discovery protocol message (announcing): the relay sends the announcement message periodically. Model B uses two discovery protocol messages (solicitation and response): the WTRU sends a solicitation message, and the relay replies with a response message.

[0094] The relay can notify multiple WTRUs, which can be granted access to the relay in a discovery response message for Model B discovery mode or in an announcement message for Model A discovery mode.

[0095] In section 203, WTRU1 and other WTRUs can exchange information about discovered WTRU2NW trunks, such as trunk ID, supported services, associated RSCs, and the number of WTRUs supporting access to that trunk. Candidate WTRU2NW trunks can be selected, for example, public trunks available to all WTRU group members.

[0096] For example, when WTRU1 and other WTRUs in the WTRU group have performed the discovery process, the relay discovered by each WTRU in the group (here, relay 1) can be selected.

[0097] In step 204, WTRU1 sends a PC5 connection establishment request to the selected WTRU2NW trunk, which includes an indication of group mobility. The connection establishment request may include the number of WTRUs in the group, which is obtained as described in steps 200 and 201.

[0098] In step 205, WTRU1 and WTRU2NW trunks can establish a secure connection. Once the connection is secure, WTRU1 can provide WTRU2NW trunks with information about the group-related WTRUs and / or the group ID. WTRU1 sends group-related information to WTRU2NW trunks, but only if the link is secure, making it impossible to eavesdrop on group-related information. Step 205 involves two messages: WTRU2NW trunks send a Direct Security Mode Command (DSM) to WTRU1. WTRU1 replies with a DSM completion message, which may contain group information. The DSM completion message is secure, i.e., it is protected by integrity / replay protection and encrypted.

[0099] In 206, when the relay accepts the request sent by WTRU1 in 204, it returns a PC5 connection establishment response.

[0100] When a relay accepts a WTRU group, the relay can reserve resources for that WTRU group, and the response message can include the resource ID of the reserved resource (Reserved Resource ID) to indicate the resources used for the WTRU group.

[0101] When the relay receives the group ID in step 204 or step 205, the relay may include the group ID in the message sent in step 206.

[0102] In section 207: After receiving a PC5 connection establishment response, WTRU1 can share the result with other WTRUs in the group and WTRU2NW trunk information (e.g., WTRU2NW trunk user information, discovered WTRU2NW trunk L2 IDs, etc.). WTRU1 can also share reserved resource IDs with other WTRUs.

[0103] In 208: Other WTRUs in the group send a PC5 connection establishment request containing a reserved resource ID to the relay.

[0104] Alternatively, after establishing connection security between the WTRU and the relay, a reserved resource ID can be shared.

[0105] In section 209, when a relay receives a PC5 connection establishment request containing a reserved resource ID, the relay checks whether the WTRU belongs to the WTRU group of WTRU1. If so, the WTRU is allowed access, and the relay can accept the request from that WTRU, and the relay returns a PC5 connection establishment response to that WTRU.

[0106] Alternatively, the relay may assign a temporary group ID to the WTRUs in the group. When the relay assigns a temporary group ID and the temporary group ID is included in the PC5 setup response to WTRU1, the temporary group ID can be shared with other WTRUs, and other WTRUs in the group can subsequently include the temporary group ID in their PC5 setup requests to the relay.

[0107] Alternatively, for path switching of a WTRU group, the path switching can be done through multiple WTRU2NW trunks, rather than all group members switching to the same WTRU2NW trunk.

[0108] For example, the WTRU group may not move to the WTRU2NW trunk (e.g., in step 203, no WTRU2NW trunk may be found to support the requested number of WTRUs, or the WTRU2NW trunk may reject the PC5 establishment request in step 208 due to insufficient resources (e.g., the WTRU2NW trunk reaches its limit / congestion / cannot guarantee QoS), or alternatively, the WTRU2NW trunk may inform the WTRUs in the WTRU group of its status, i.e., the WTRU2NW trunk does not have enough resources to support more WTRUs), or the WTRU2NW trunk may only reject additional WTRUs, or the WTRU2NW trunk may disconnect from the entire group and request / notify the WTRU group members to move to a different trunk; for example, providing a reason code or rejection code to indicate that a connection cannot be provided for the group; the WTRUs in the WTRU group determine the selection to initiate an alternative WTRU2NW trunk based on the reason / rejection code.

[0109] When a WTRU group cannot be moved to a WTRU2NW trunk, a new / different WTRU2NW trunk can be discovered to support all WTRUs that are members of the group, and these WTRUs can then be moved to the newly discovered trunk WTRU.

[0110] Alternatively, when a WTRU group cannot move to a WTRU2NW trunk, multiple WTRU2NW trunks can be used (e.g., in step 203, multiple WTRU2NW trunks can be selected to support the WTRU group). As another example, when a trunk WTRU rejects a PC5 establishment request in step 208, or when a trunk WTRU notifies the WTRU that its resources are insufficient to support more WTRUs, new / different trunk WTRUs can be discovered by performing steps 201, 202, and / or 203.

[0111] When using multiple WTRU2NW trunks, WTRU group members can negotiate which WTRU group member will join which WTRU2NW trunk, or when an additional WTRU2NW trunk is discovered, the remaining member WTRUs can move to the discovered additional WTRU2NW trunk by performing steps 207 to 209 separately.

[0112] When a WTRU group is connected to multiple WTRU2NW trunks, the application or application server can be provided with associated information (e.g., which member WTRU is bound to (associated with) which WTRU2NW trunk WTRU, including information about the member WTRU and the trunk WTRU). The application server can communicate with the 5GC to coordinate traffic flow for the WTRU group across multiple WTRU2NW trunks to meet certain QoS requirements (e.g., latency adjustment between links operated via different WTRU2NW trunks, bandwidth adjustment for each link operated via WTRU2NW trunks).

[0113] WTRUs can receive assistance from other WTRUs to enhance downlink or uplink performance. Many services and applications require high data rates for both uplink and downlink to support a certain level of quality of service (e.g., interactive gaming, XR services, video conferencing, etc.). Even in 5G systems, coverage limitations remain, where WTRUs may not be able to enjoy such bandwidth-intensive services.

[0114] To overcome this limitation, the coordinated operation of multiple WTRUs can be considered to enable the sending and receiving of data packets at high data rates. The coordinated operation of multiple WTRUs requires not only coordinated communication between the participating WTRUs, but also the understanding of the coordinated operation and the processing of data packets within the system.

[0115] Therefore, a mechanism is needed to coordinate the operation between multiple WTRUs and the system in order to control the coordinated operation between multiple WTRUs.

[0116] In embodiments related to connection establishment with Layer 2-based cooperative groups, WTRU: - Discover other WTRUs to help enhance their connectivity with 5GC; - Establish ProSe connections with other selected WTRUs and form collaborative groups; - The WTRU and other WTRUs in the cooperative group notify the gNB that the connection of each WTRU in the cooperative group is used for the traffic of that WTRU; and When a WTRU in a cooperative group is connected to another non-terminal gNB, the WTRU is transferred to the gNB that is the terminus of the cooperative group.

[0117] Cooperative services are services that enhance the performance or coverage of a target WTRU under 5GC by leveraging other WTRUs (auxiliary WTRUs). These auxiliary WTRUs transmit and receive at least a portion of the target WTRU's traffic with the network. The target WTRU and auxiliary WTRUs form a cooperative group (cooperative group, allocation group) that supports the cooperative services of the target WTRU. The target WTRU can also be referred to as a "consumer" WTRU.

[0118] When 5GC supports collaborative services and WTRU has subscribed to collaborative services from a service provider, WTRU needs to authorize the collaborative service as a target WTRU or auxiliary WTRU.

[0119] When a WTRU is authorized as the target WTRU for collaborative services, a collaboration group ID (assignment group ID, i.e., collaboration group ID) can be assigned to that WTRU for collaborative services from the 5GC or the application server. The 5GC can coordinate with the application server to assign collaboration group IDs (for example, the application server can inform the 5GC of the collaboration group ID assigned to the WTRU).

[0120] When a WTRU is authorized for collaborative services of multiple application services, a different collaboration group ID can be assigned to the WTRU for each application.

[0121] The collaboration group ID can be used as the application group ID for the ProSe service.

[0122] Alternatively, when a WTRU is authorized as a target WTRU for cooperative services, a Layer 2 group ID can be assigned by 5GC. The WTRU can use the Layer 2 group ID along with the associated cooperative service support indication (i.e., the indication to use cooperative services).

[0123] Collaborative services can be layer 2 based or layer 3 based.

[0124] For Layer 2 based collaboration services, the traffic of the collaboration group used for collaboration services terminates at the gNB.

[0125] For Layer 3 based collaboration services, the workload of the collaboration group used for collaboration services is terminated at the UPF or application server.

[0126] Figure 3 This is a timing diagram of a Layer 2-based connection establishment method using WTRUs in a cooperative group according to one embodiment. From top left to right, they are depicted as: WTRU1 (3001), WTRU2 (3002), WTRU3 (3003), gNB1 (3011), gNB2 (3012), AMF (3021), and SMF (3022). It should be noted that steps 304 to 305 are used to notify that the 5GC cooperative group has been initiated, steps 306a to 310a relate to the RRC update of the cooperative group for WTRU2, and steps 306b to 312b relate to the RRC update of the cooperative group for WTRU3 and are similar to the RRC update of the cooperative group for WTRU2 in steps 306a to 310a, but further depict a handover process that redirects WTRUs to the same network node serving the WTRUs (i.e., WTRU1 and WTRU2) in the cooperative group.

[0127] In 300, WTRU1, WTRU2, and WTRU3 are authorized as target WTRUs for collaborative services and / or as auxiliary WTRUs for Layer 2 based collaborative services. WTRU1 and WTRU2 are served by gNB1, and WTRU3 is served by gNB2. WTRU1, WTRU2, and WTRU3 are provided with policies and parameters for collaborative services (e.g., WTRU1 may be configured with a collaboration group ID and a Layer 2 group ID for authorized collaborative services; WTRU1, WTRU2, and WTRU3 may be provided with a ProSe discovery code specifically for collaborative services, as well as associated PDU session parameters for collaborative services, and an RSC associated with the collaborative services to discover WTRU2NW relays for collaborative services).

[0128] In a 301, WTRU1 can be triggered by an application or by WTRU internal logic or an application server to initiate a collaboration group (e.g., for better service experience or better coverage).

[0129] In a 302 update, WTRU1 discovers other WTRUs (i.e., auxiliary WTRUs) that can help enhance its connectivity with the 5GC. During the discovery process, WTRU1 may include indications of its requested cooperative services (e.g., any indicator of the requested cooperative service, the ID or RSC associated with the cooperative service, or a ProSe discovery code, DNN, etc., specific to the cooperative service). WTRU1 may also indicate which WTRUs it wants to support during the discovery process.

[0130] In the 303 response, WTRU2 and WTRU3 reply to the discovery request from WTRU1. The reply may include indications that these WTRUs support cooperative services as auxiliary WTRUs.

[0131] In 304, WTRU1 can notify its serving network node (here, gNB1) to initiate a cooperative group. For example, WTRU1 can therefore send an RRC update request to gNB1, which includes an indication of the cooperative group and a specified cooperative group ID (i.e., cooperative group ID) to be used for initiation. WTRU1 can indicate to gNB1 that WTRU1 is the target WTRU for that cooperative group.

[0132] Unless the collaboration group ID is assigned by 5GC or the application server, WTRU1 can be assigned a collaboration group ID as the target WTRU.

[0133] Alternatively, the collaboration group ID can be assigned by gNB and shared at step 305 (here shared by gNB1).

[0134] In section 305, when a network node receives an RRC update request for a cooperative group, the network node can send an RRC update response indicating whether it accepts the RRC update request. If accepted, the network node (here, gNB1) can associate WTRU1 with the cooperative group ID.

[0135] In step 306a, WTRU1 sends a PC5 establishment request to WTRU2. The PC5 establishment request may include an indication of a collaboration group and its assigned collaboration group ID. If such a group ID is provided at step 300, WTRU1 may include a Layer 2 group ID.

[0136] In 307a, WTRU2 sends a PC5 establishment response, which indicates whether the PC5 establishment request is accepted.

[0137] In 308a, WTRU2 sends an RRC update request to network node gNB1 (which is the serving network node of WTRU2) to establish an RRC connection for a cooperative group with a cooperative group ID. WTRU2 can indicate to network node gNB1 that WTRU2 is the auxiliary WTRU for that cooperative group. WTRU2 can also indicate to the network node that WTRU1 is the target WTRU for the cooperative group.

[0138] In 309a, when network node gNB1 receives an RRC update request for a coordination group, gNB can check the authorization information of the WTRU to determine whether the WTRU has been authorized for the coordination group. Network node gNB1 can send an RRC update response containing an indication of whether the WTRU has been authorized.

[0139] When a network node gNB1 receives an RRC update request for a cooperative group, it can update its list of WTRUs associated with that cooperative group. Here, network node gNB1 associates WTRU2 and WTRU1 with the cooperative group ID.

[0140] In 310a, WTRU2 can send an RRC establishment confirmation of the cooperative group to WTRU1 to notify that an RRC connection of the cooperative group has been successfully established with WTRU2.

[0141] In 306b, WTRU1 can send a PC5 establishment request to WTRU3. The PC5 establishment request can include an indication of the collaboration group and the assigned collaboration group ID. If a Layer 2 group ID is supplied at step 300, WTRU1 can include it.

[0142] In 307b, WTRU3 sends a PC5 establishment response, which indicates whether the PC5 establishment request is accepted.

[0143] In 308b, WTRU3 sends an RRC update request to network node gNB2 (which is the serving network node of WTRU3) to establish an RRC connection for a cooperative group with a cooperative group ID. WTRU3 can indicate to gNB2 that WTRU3 is the auxiliary WTRU for that cooperative group. WTRU3 can also indicate to gNB2 that WTRU1 is the target WTRU for that cooperative group.

[0144] In 309b, when receiving an RRC update request from a coordination group, network node gNB2 can check the authorization information of the WTRU to verify whether the WTRU has been authorized by the coordination group. Network node gNB2 can send an RRC update response, which indicates whether the node has been authorized.

[0145] In 310b, when network node gNB2 knows that the requested cooperative group is served by another network node (here, network node gNB1) that serves as the terminus of the data packets for that cooperative group, network node gNB2 can initiate the WTRU3 handover process between network nodes gNB1 and gNB2.

[0146] When switching starts, gNB2 can notify that a switch has been triggered (e.g., by including an indication in step 309b).

[0147] In 311b, after a successful handover, WTRU3 is handed over to network node gNB1.

[0148] In 312b, WTRU3 can send an RRC establishment confirmation of the cooperative group to WTRU1 to notify WTRU1 that it has successfully established an RRC connection of the cooperative group with WTRU3.

[0149] In 311b, if the handover fails, WTRU3 can be removed from the cooperative group, and WTRU1 will be notified of the handover failure and / or WTRU3 will be removed from the cooperative group. When the handover fails, the RRC connection between WTRU3 and the network node gNB2 of the cooperative group is released. In another embodiment, when a WTRU is removed from the cooperative group, WTRU1 can repeat the discovery steps to find another WTRU as an auxiliary WTRU for the cooperative group.

[0150] In another embodiment, when a new UEx is found to want to be part of the same cooperative group, the UEx can receive a cooperative group ID from WTRU1, and then the UEx can use the received cooperative group ID to receive updated RRC configuration.

[0151] Now turning to embodiments related to establishing connections with Layer 3-based cooperative groups, according to one embodiment, the WTRU can: - Discover other WTRUs to help enhance their connectivity with 5GC; - Establish ProSe connections with other selected WTRUs and form collaborative groups; and -WTRUs and other WTRUs in a collaboration group can request the establishment of a PDU session for the collaboration group's traffic.

[0152] In embodiments relating to the establishment of connections with layer 3-based cooperative groups, according to one embodiment, the SMF can: - Learn about the PDU sessions of each WTRU in the collaboration group during PDU session establishment; and - Identify the PDU session and notify the UPF (Endpoint) of this new collaboration group.

[0153] Figure 4 This is a timing diagram of a layer 3-based connection establishment method for a collaborative group WTRU according to one embodiment.

[0154] The diagram, from top left to top right, depicts: First WTRU1 (4001), Second WTRU2 (4002), Third WTRU3 (4003), First Network Node gNB1 (4011), Second Network Node gNB2 (4012), AMF (4021), and SMF (4022). Note that steps 404 to 405 are used to notify that the 5GC cooperative group has been started; steps 406a to 410a relate to the establishment or modification of the PDU session for the cooperative group of WTRU2; and steps 406b to 411b relate to the establishment / modification of the PDU session for the cooperative group of WTRU3, and are similar to the establishment / modification of the PDU session for the cooperative group of WTRU2 in steps 406a to 410a, but further describe the handover process of redirecting WTRUs to the same network node serving WTRU1 and WTRU2.

[0155] In 400, WTRU1, WTRU2, and WTRU3 are authorized as target WTRUs and / or auxiliary WTRUs in a Layer 3-based coordination group to provide coordination services. A Layer 3-based coordination group is a coordination group service where traffic from the coordination group terminates at a UPF or application server. WTRU1 and WTRU2 are served by network node gNB1, and WTRU3 is served by network node gNB2.

[0156] In a 401, WTRU1 can be triggered by an application or by WTRU internal logic or an application server to start a collaboration group (e.g., for better service experience or better coverage).

[0157] In a 402, WTRU1 discovers other WTRUs to help enhance its connectivity with 5GC. WTRU1 may contain a cooperative group indication (e.g., any indicator of the cooperative group, an ID or RSC associated with the cooperative service, or a ProSe discovery code, DNN, etc., specific to the cooperative group).

[0158] In 403, WTRU2 and WTRU3 send a response to the discovery request from WTRU1, which indicates that they support a cooperative group.

[0159] In step 404, as part of a notification that a cooperative group has been initiated, WTRU1 can notify 5GC of the initiation of the cooperative group. For example, WTRU1 can send a PDU session modification request with an indication of the cooperative group or the assigned cooperative group ID (i.e., the cooperative group ID) to be used for initiation. WTRU1 can notify 5GC that it is the target WTRU for that cooperative group. The cooperative group ID can be assigned by the WTRU, or by 5GC when the WTRU is authorized as the target WTRU to the cooperative group, or by 5GC in the PDU session modification response in step 405.

[0160] In 405, as part of the notification to initiate a collaboration group, when a PDU session modification request for the collaboration group has been received, the SMF can send a PDU session modification response with an indication of whether to accept the request.

[0161] In 406a, as part of an RRC update for a collaboration group, WTRU1 can send a PC5 establishment request to WTRU2. The PC5 establishment request may include an indication of the collaboration group and the assigned collaboration group ID.

[0162] In 407a, as part of an RRC update for a cooperative group, WTRU2 can send a PC5 establishment response, which has an indication of whether WTRU2 accepts being part of that cooperative group.

[0163] In 408a, as part of an RRC update for a collaboration group, WTRU2 sends a PDU session establishment request or PDU session modification request to the SMF to establish a PDU session for the collaboration group with the collaboration group ID. WTRU2 may notify the SMF that it is an auxiliary WTRU for that collaboration group.

[0164] In 409a, as part of a cooperative group's RRC update, when a cooperative group's PDU session establishment request or PDU session modification request is received, the 5GC can check the WTRU's authorization information to verify whether the WTRU has been authorized by the cooperative group. The SMF can send a PDU session establishment response or a PDU session modification response, which indicates whether the WTRU has been authorized.

[0165] In 410a, as part of the cooperative group's RRC update, WTRU2 can send an acknowledgment of the establishment of the cooperative group's PDU session to WTRU1 to notify WTRU1 that it has successfully established a cooperative group's PDU session with WTRU2.

[0166] In 406b, as part of the RRC update process for the cooperative group and the handover process of redirecting WTRUs to the same serving network node, WTRU1 sends a PC5 establishment request to WTRU3. The PC5 establishment request may include an indication of the cooperative group and the assigned cooperative group ID.

[0167] In 407b, as part of the cooperative group's RRC update and the handover process of redirecting WTRUs to the same serving network node, WTRU3 sends a PC5 setup response with an indication of whether it accepts the offer.

[0168] In 408b, as part of the RRC update process for the cooperative group and the handover process of redirecting WTRUs to the same serving network node, WTRU3 sends a PDU session establishment request or PDU session modification request to the SMF to establish a PDU session for the cooperative group with the cooperative group ID. WTRU3 can notify the SMF that WTRU3 is the auxiliary WTRU for that cooperative group.

[0169] In 409b, as part of the RRC update process for the cooperative group and the handover process for redirecting WTRUs to the same serving network node, when a cooperative group's PDU session establishment request or PDU session modification request is received, the 5GC can check the WTRU's authorization information to verify whether it has been authorized by the cooperative group. The SMF can send a PDU session establishment response or a PDU session modification response, which includes an indication of whether it has been authorized.

[0170] In 410b, as part of the RRC update of the cooperative group and the handover process of redirecting WTRUs to the same serving network node, WTRU3 can send an acknowledgment of the establishment of the cooperative group's PDU session to WTRU1 to notify WTRU1 that the cooperative group's PDU session has been successfully established with WTRU3.

[0171] In 411b, as part of the RRC update process for a cooperative group and the handover process for redirecting WTRUs to the same serving network node, the 5GC can trigger a handover process to move the WTRUs of the cooperative group to the serving gNB when it learns that the WTRUs of the cooperative group are served by multiple gNBs. For example, when the 5GC knows that WTRU3 is served by network node gNB2, it can transfer WTRU3 to network node gNB1 so that WTRU-AMBR can be applied to the cooperative group.

[0172] When WTRU2NW relays are involved, maintaining collaborative operations between WTRUs is crucial. When multiple WTRUs participate in cooperative operations, some WTRUs that are members of the cooperative operation group can move to an indirect connection via the WTRU2NW relay. Even when some cooperative operation group member WTRUs decide to move to an indirect connection via the WTRU2NW relay, it may be necessary to maintain the cooperative operation group.

[0173] In the context of WTRU2NW relay, and within the framework of maintaining collaborative operations (cooperative services) between WTRUs, and in an embodiment related to path switching to a Layer 2-based WTRU2NW relay for WTRUs in a cooperative group, WTRU: - Triggered to switch to an indirect connection via WTRU2NW relay; - Establish a trunk connection with the selected WTRU2NW trunk; - Notify the WTRU2NW relay of the collaboration group ID; -WTRU2NW relay establishes an RRC connection between the WTRU and its serving gNB; - For Layer 2 based cooperative groups, the WTRU2NW relay provides the cooperative group ID along with the WTRU ID to the serving network node; -WTRU establishes a PDU session via WTRU2NW trunk; - For Layer 2 based cooperative groups, if the WTRU2NW relay is bound to another network node that is different from the termination point, then the relay is handed over to the termination network node of the cooperative group. - For Layer 3 based collaboration groups, WTRU triggers the PDU session establishment process of the collaboration group via WTRU2NW relay.

[0174] Figure 5 This is a timing diagram of a Layer 2-based WTRU2NW relay connection establishment method for a cooperative group according to one embodiment. Depicted from top left to top right: WTRU1 (5001), WTRU2 (5002), where WTRU1 and WTRU2 are part of the same cooperative group; Layer 2 WTRU2NW relay WTRU (5011), first network node gNB1 (5021), second network node gNB2 (5031), PCF (5041), and UPF (5051).

[0175] In 500, WTRU1 and WTRU2 are authorized to provide collaborative services to collaboration groups based on Layer 2 and / or Layer 3. WTRU1 and WTRU2 are provided with policies and parameters for collaborative services and ProSe services. A collaboration group based on Layer 2 or Layer 3 is formed, with collaboration group ID1 (i.e., collaboration group ID 1), and WTRU1 and WTRU2 belong to the same collaboration group and have collaboration group ID1.

[0176] In 501, due to various reasons (such as poor channel quality, poor data rate, poor packet error rate, etc.), WTRU2 is triggered to switch the path to the WTRU2NW relay and sends a DCR (Direct Communication Request) to the relay WTRU. WTRU2 can notify the relay WTRU that WTRU2 belongs to the cooperative group with cooperative group ID1.

[0177] In 502, the relay WTRU receives the DCR from WTRU2 and sends a DCA (i.e., Direct Communication Acceptance) to WTRU2.

[0178] In 503, the relay WTRU sends an RRC update request to gNB1 (i.e., the serving gNB of the relay WTRU) to establish an RRC connection for WTRU2 via the relay WTRU. The relay WTRU may include WTRU2 information and the collaboration group ID in the RRC update request.

[0179] In a 504 error, when receiving an RRC update request from a cooperative group, gNB1 can check the WTRU's authorization information to verify whether it has been authorized by the cooperative group. gNB1 can then send an RRC update response with an indication of whether it accepts the request.

[0180] For Layer 2-based collaborative services, apply steps 505a and 506a.

[0181] In 505a, when gNB1 knows that the requested cooperative group is served by another gNB (here, gNB2) that is the endpoint of the data packets for that cooperative group, gNB1 can initiate a handover process for the relay WTRU between gNB1 and gNB2.

[0182] When a switchover is initiated, gNB1 can notify that a switchover has been triggered (e.g., via an indication included in step 504).

[0183] In 506a, after a successful handover process, the WTRU2NW trunk is handed over to gNB2.

[0184] For layer 3-based collaborative services, apply step 505b.

[0185] In 505b, after establishing a connection with the Layer 2 relay, WTRU2 sends a PDU session establishment request for cooperation group ID1. This PDU session establishment request may include cooperation group ID1 and / or the PDU session ID of the PDU session for cooperation group ID1, which was established while serving WTRU2 at gNB2. After WTRU2 successfully establishes a PDU session with gNB2 via the relay WTRU and gNB1, the PDU session with gNB2 is released.

[0186] In the context of WTRU2NW relay, maintaining cooperative operations between WTRUs, and according to an embodiment related to the Layer 3-based WTRU2NW relay of WTRUs in a Layer 3-based cooperative group, WTRU: - Triggered to switch to an indirect connection via WTRU2NW relay; - Establish a trunk connection with the selected WTRU2NW trunk; - Notify the WTRU2NW relay of the collaboration group ID; and -WTRU2NW relays the WTRU's cooperative group ID to 5GC.

[0187] In the context of WTRU2NW relay, maintaining cooperative operations between WTRUs, and according to an embodiment related to the Layer 3-based WTRU2NW relay in a Layer 3-based cooperative group for path switching, PCF: - Update the relay PDU connection of the WTRU2NW trunk in the WTRU to belong to the cooperative group; and - For L3 cooperative groups, the updated packet processing rules are notified to the SMF, so that the SMF can notify the UPF (endpoint) of the updated packet processing rules in order to enable PDU connections of WTRUs via WTRU2NW relay.

[0188] Figure 6 This is a timing diagram of a Layer 3 WTRU2NW relay connection establishment method for a Layer 3 cooperative group according to one embodiment. Depicted from top left to top right: a cooperative group including a first WTRU1 (6001) and a second WTRU2 (6002), a Layer 3 WTRU2NW relay (6011), an AMF (6021), an SMF (6031), a PCF (6041), and a UPF (6051).

[0189] In 600, WTRU1 and WTRU2 are authorized to provide collaborative services to a Layer 3 based collaboration group. WTRU1 and WTRU2 are provided with policies and parameters for collaborative services and ProSe services. A Layer 3 based collaboration group is formed, namely collaboration group ID1 (i.e., collaboration group ID 1), and WTRU1 and WTRU2 belong to the collaboration group of collaboration group ID1.

[0190] In step 601, WTRU2 is triggered to switch the path to the Layer 3 WTRU2NW relay. This can be due to various reasons (e.g., poor channel quality, poor data rate, poor packet error rate, etc.), and WTRU2 sends a DCR (Direct Communication Request) to the Layer 3 WTRU2NW relay. WTRU2 informs the Layer 3 WTRU2NW relay that WTRU2 belongs to cooperative group ID1.

[0191] In 602, WTRU2 and Layer 3 WTRU2NW relays can perform security procedures to establish a secure connection.

[0192] In 603, the Layer 3 WTRU2NW trunk can initiate the PDU session establishment process to serve the traffic of WTRU2 used for collaborative services.

[0193] In 604, the Layer 3 WTRU2NW relay can respond to DCA to WTRU2.

[0194] In 605, the Layer 3 WTRU2NW trunk can send a remote WTRU report to the SMF to notify the SMF that WTRU2 is accessing the Layer 3 WTRU2NW trunk and that WTRU2 belongs to cooperative group ID1.

[0195] In 606, the SMF can send a PDU session context update request to the PCF to notify the PCF that WTRU2 is bound to the Layer 3 WTRU2NW relay and that WTRU2 belongs to cooperative group ID1.

[0196] In 607, the PCF updates the PDU session context of the Layer 3 WTRU2NW relay accordingly, that is, associating WTRU2 with the cooperation group ID1 in the PDU session context.

[0197] In 608, the PCF can send a PDU session context update response to the SMF in order to update the PCC rules for collaboration group ID1.

[0198] In 609, SMF can use updated packet processing rules to update the UPF termination point of the traffic for collaboration group ID1.

[0199] In the context of WTRU2NW relay maintenance, and according to an embodiment related to path switching from WTRU to WTRU2NW relay for multi-mode XR services, WTRU: - Triggered to switch to an indirect connection via WTRU2NW relay; - The AF can be notified that the WTRU's connection has been changed to a trunk connection, and the AF will notify the PCF of this update; and -WTRU2NW relay notifies 5GC that WTRU has been bound to WTRU2NW relay.

[0200] In the context of WTRU2NW relays, maintaining collaborative operations between WTRUs, and according to embodiments related to path switching from WTRU to WTRU2NW relays for multi-mode XR services, PCF: -Based on the information received from the AF, the PCF knows that the WTRU belongs to a multi-mode service ID bound to the WTRU2NW relay; - Update the trunk PDU connection of the WTRU2NW trunk of the WTRU to belong to the multi-mode service ID; and - Notify the SMF of the updated packet processing rules so that the SMF can notify the UPF (Endpoint) of the updated packet processing rules in order to enable PDU connections of WTRU via WTRU2NW relay.

[0201] Figure 7This is a timing diagram of a WTRU2NW trunk connection establishment method for a multi-mode service according to one embodiment. It is depicted from top left to top right as follows: a first WTRU1 (7001) and a second WTRU2 (7002), the first and second WTRUs belonging to the same multi-mode service, a layer 3 WTRU2NW trunk (7011); an AMF (7021); an SMF (7031); a PCF (7041); a UPF (7051); and an AF (7061).

[0202] In 700, WTRU1 and WTRU2 have been authorized for the ProSe service and are provided with the ProSe service policies and parameters. WTRU1 and WTRU2 belong to the same multimode service. 5GC assigns a multimode service ID_1 to the multimode service containing WTRU1 and WTRU2.

[0203] In 701, due to various reasons (such as poor channel quality, poor data rate, poor packet error rate, etc.), WTRU2 is triggered to switch the path to the Layer 3 WTRU2NW relay, and WTRU2 sends a DCR (i.e., Direct Communication Request) to the WTRU2NW relay.

[0204] In 702, the WTRU2 and WTRU2NW relays perform a security procedure to establish secure communication.

[0205] In 703, the WTRU2NW trunk can initiate a PDU session establishment or PDU session modification process to serve the traffic of WTRU2.

[0206] In 704, the WTRU2NW relay can respond to DCA for WTRU2.

[0207] In 705, WTRU2 can notify the AF of the multimode service of the WTRU status update, indicating that WTRU2 has been changed to an indirect connection for the WTRU2NW trunk connection.

[0208] In 706, the AF can notify the PCF of a status update for the WTRU, indicating that WTRU2 has been changed to an indirect connection for the WTRU2NW trunk connection.

[0209] In 707, the WTRU2NW trunk can send a remote WTRU report to the SMF to notify the SMF that WTRU2 is accessing the WTRU2NW trunk.

[0210] In 708, the SMF sends a PDU session context update request to the PCF to notify the PCF that WTRU2 is bound to the WTRU2NW trunk.

[0211] In step 709, the PCF detects that WTRU2, a multimode service belonging to multimode service ID_1, has changed its connection to an indirect connection based on the input of AF in step 706 and the information received from WTRU2 in step 708.

[0212] In 710, PCF can update the PDU session context of the WTRU2NW relay and the PDU session context of the multimode service ID_1.

[0213] In 711, the PCF can send a PDU session context update response to the SMF in order to update the PCC rules of the multimode service ID_1.

[0214] In 712, SMF can use the update packet processing rules of the multimode service with multimode service ID_1 to update UPF.

[0215] Furthermore, when WTRU2NW relays are involved, in the context of maintaining collaborative operations between WTRUs, and according to embodiments related to path switching from WTRU to WTRU2NW relays for multi-mode XR services, WTRUs can be added to multi-mode XR services via WTRU2NW relays.

[0216] When a direct connection cannot be established by performing steps 701, 702, 703, and 704, the WTRU can join the multi-mode XR service via an indirect connection.

[0217] After connecting to the multimode XR service via the WTRU2NW relay, the application server can detect that a new collaborative operation service member has joined and can perform step 706, which includes the following indication: (a) The new WTRU has joined the multimode service via the WTRU2NW relay with the information of the new WTRU.

[0218] When a status update 706 is received from the AF, the PCF can perform step 709, and then perform steps 710 to 712.

[0219] Figure 8 This is a method implemented by a Wireless Transmit-Receive Unit (WTRU) according to one embodiment. The method may include: Receive (800) a first message including an indication for path switching of at least some traffic between the WTRU and the network, wherein the WTRU is a member of a WTRU group; Send a second (801) message to the other members of the WTRU group, the second message including the instruction; Discovery (802) can be used to process traffic between WTRUs and the network within the WTRU group at least one first candidate WTRU to network relay; Receive (803) an instruction from other members of the WTRU group relating to the discovery of at least one second candidate WTRU-to-network relay that can be used to handle traffic between WTRUs and the network within the WTRU group; (804) A WTRU-to-network relay is selected from at least one first candidate WTRU-to-network relay and at least one second candidate WTRU-to-network relay to handle traffic between WTRUs in the WTRU group and the network; and Path switching is performed on at least some traffic between the WTRU and the network via the selected WTRU to network relay (805).

[0220] According to one embodiment, the selected WTRU to network relay is shared between at least one first candidate WTRU to network relay and at least one second candidate WTRU to network relay.

[0221] According to one embodiment, the first message is received from one of the following: Application or application server; WTRU-to-network relay handles at least some traffic between the WTRU and the network.

[0222] According to one embodiment, a first message is triggered by an application or application server based on the group mobility of the members of the WTRU group because at least one member in the WTRU group experiences a quality of service degradation.

[0223] According to one embodiment, a first message is triggered by the WTRU-to-network relay that handles at least some traffic between the WTRU and the network because the WTRU-to-network relay that handles at least some traffic between the WTRU and the network does not have sufficient resources to handle traffic between members of the WTRU group and the network.

[0224] According to one embodiment, a WTRU group is formed for a collaborative service, with at least one first candidate WTRU to network relay and at least one second candidate WTRU to network relay supporting the collaborative service.

[0225] According to one embodiment, a wireless transmit-receive unit (WTRU) is also disclosed and described, which includes at least one processor configured to: Receive a first message including an indication for path switching between the WTRU and the network for at least some traffic, wherein the WTRU is a member of a WTRU group; Send a second message to the other members of the WTRU group, the second message including the instruction; Discover at least one first candidate WTRU-to-network relay that can be used to handle traffic between WTRUs and the network within the WTRU group; Receive instructions from other members of the WTRU group, which relate to the discovery of at least one second candidate WTRU-to-network relay that can be used to handle traffic between WTRUs and the network within the WTRU group; Select a WTRU-to-network relay from at least one first candidate WTRU-to-network relay and at least one second candidate WTRU-to-network relay to handle traffic between WTRUs in the WTRU group and the network; and Path switching is performed on at least some traffic between the WTRU and the network via a selected WTRU to network relay.

[0226] According to one embodiment of WTRU, at least one processor is configured to select a WTRU-to-network relay shared between at least one first candidate WTRU-to-network relay and at least one second candidate WTRU-to-network relay.

[0227] According to an embodiment of WTRU, the at least one processor is configured to receive a first message from one of the following: Application or application server; WTRU-to-network relay handles at least some traffic between the WTRU and the network.

[0228] According to an embodiment of WTRU, a first message is triggered by an application or application server based on the group mobility of the members of the WTRU group because at least one member in the WTRU group experiences a quality of service degradation.

[0229] According to an embodiment of WTRU, a first message is triggered by the WTRU-to-network relay that handles at least some traffic between the WTRU and the network because the WTRU-to-network relay that handles at least some traffic between the WTRU and the network does not have sufficient resources to handle traffic between members of the WTRU group and the network.

[0230] According to an embodiment of WTRU, WTRU groups are formed for collaborative services, with at least one first candidate WTRU to network relay and at least one second candidate WTRU to network relay supporting the collaborative service.

[0231] Figure 9 This is a method implemented by a Wireless Transmit-Receive Unit (WTRU) according to one embodiment. The method includes: Receive (900) configuration information for establishing collaborative services; Based on the received configuration information, receive (901) the first instruction for starting the WTRU cooperative group to implement cooperative services; Send a (902) discovery request to other WTRUs to assist WTRUs in the collaboration group in providing collaborative services to WTRUs; Receive (903) a response to the discovery request from at least one other WTRU, thereby indicating support for assistance to WTRUs in the collaboration group; Send (904) a second instruction to the network node serving the WTRU to initiate the cooperative group, the second instruction including information related to a WTRU selected from at least one other WTRU, the information indicating support for assistance to the WTRUs in the cooperative group; and Establish (905) device-to-device communication with the selected WTRU for performing collaborative services.

[0232] According to an embodiment of the method, the configuration information includes strategies and parameters for establishing collaborative services.

[0233] According to an embodiment of the method, the first instruction is received from either an application or an application server.

[0234] According to an embodiment of the method, the second instruction includes an identifier for the collaboration group.

[0235] According to an embodiment of the method, the identifier of the collaboration group is assigned by one of the following: Application or application server; WTRU.

[0236] According to an embodiment of the method, the second instruction is a Radio Resource Control (RRC) update request.

[0237] According to an embodiment of the method, the second instruction includes information that identifies the WTRU to the network node serving the WTRU as the target WTRU for the cooperative group.

[0238] According to an embodiment, a wireless transmit-receive unit (WTRU) is also disclosed, which includes at least one processor configured to: Receive configuration information used to establish collaborative services; Based on the received configuration information, receive the first instruction for starting the WTRU cooperative group to achieve cooperative services; Send discovery requests to other WTRUs to assist WTRUs in the collaboration group in providing collaborative services; Receive a response to a discovery request from at least one other WTRU, thereby indicating support for assistance to WTRUs in the collaboration group; Send a second instruction to the network node serving the WTRU to initiate a cooperative group, the second instruction including information related to a WTRU selected from at least one other WTRU, the information indicating support for assistance to the WTRUs in the cooperative group; and Establish device-to-device communication with the selected WTRU for performing collaborative services.

[0239] According to an embodiment of WTRU, this configuration information includes policies and parameters for setting up collaborative services.

[0240] According to the WTRU implementation, 10. The WTRU of claim 8 or 9, wherein at least one processor is configured to receive a first instruction from an application or an application server.

[0241] According to an embodiment of WTRU, the second instruction includes the identifier of the collaboration group.

[0242] According to an implementation of WTRU, the identifier for a collaboration group is assigned by one of the following: Application or application server; WTRU.

[0243] According to an embodiment of WTRU, the second instruction is a Remote Resource Control (RRC) update request.

[0244] According to an embodiment of WTRU, the second instruction includes information that identifies the WTRU to the network node serving the WTRU as the target WTRU for a cooperative group.

[0245] Figure 10 This is a method implemented by a Wireless Transmit-Receive Unit (WTRU) according to one embodiment. The method includes: Receive (1000) configuration information for performing collaborative services; A (1001) cooperative group is created based on the received configuration information. The cooperative group includes a WTRU and at least one other WTRU. Receive (1002) a message including an indication for switching at least some traffic of the WTRU to a network relay via the WTRU through an indirect path; Establish (1003) a connection with the WTRU-to-network relay, which establishes a connection between the WTRU and the network node serving the WTRU-to-network relay; and Send / receive (1004) at least some traffic via the connection established with the WTRU to the network relay.

[0246] According to an embodiment of the method, when the network node serving the WTRU to network relay is different from the network node serving the WTRU, the WTRU to network relay is handed over to the network node serving the WTRU.

[0247] According to an embodiment of the method, the connection to the network node serving the WTRU-to-network relay established for the WTRU is established via a Radio Resource Control (RRC) message.

[0248] According to an embodiment of the method, the collaborative service is a layer 2 or layer 3 based collaborative service.

[0249] According to an embodiment of the method, under the condition that the cooperative service is a layer 3 based cooperative service, the method includes establishing a protocol data unit session via WTRU to network relay.

[0250] According to one embodiment, a wireless transmit-receive unit (WTRU) is also disclosed and described, which includes at least one processor configured to: Receive configuration information for performing collaborative services; A cooperative group is created based on the received configuration information. The cooperative group includes WTRU and at least one other WTRU. Receive a message including an indication for switching at least some traffic of the WTRU to a network relay via the WTRU or through an indirect path; Establish a connection with the WTRU-to-network relay, which establishes a connection between the WTRU and the network node serving the WTRU-to-network relay; and Send / receive at least some traffic via the connection established with the WTRU to the network relay.

[0251] According to an embodiment of WTRU, if the network node serving the WTRU to network relay is different from the network node serving the WTRU, the WTRU to network relay is handed over to the network node serving the WTRU.

[0252] According to an embodiment of WTRU, at least one processor is configured to establish a connection with a network node of WTRU-to-network relay established for WTRU via Radio Resource Control (RRC) messages.

[0253] According to WTRU implementations, the collaboration service is a layer 2-based or layer 3-based collaboration service.

[0254] According to an embodiment of WTRU, at least one processor is configured to perform protocol data unit session establishment via WTRU to network relay under the condition that the cooperative service is a layer 3 cooperative service.

[0255] Figure 11 This is a flowchart of a path switching method for collaborative services according to one embodiment.

[0256] The method includes: Receive (1100) a trigger for path switching of at least some traffic between a WTRU group and a network node, the WTRU group comprising WTRUs and other WTRUs configured to communicate with the network node; Send (1101) a message to other WTRUs including an indication of path switching for at least some traffic; Determine (1102) at least the first candidate WTRU to network relay that can handle at least some traffic volume; In response to the message, an indication is received (1103) from one or more of the other WTRUs to at least a second candidate WTRU to the network relay, which can be used to process at least some traffic. (1104) Select a WTRU to network relay from at least a first candidate WTRU to network relay and at least a second candidate WTRU to network relay for relaying at least some traffic between WTRU groups and network nodes; Send (1105) a request to the selected WTRU to the network relay to perform a path switch for at least some traffic between the WTRU group and the network node; and Send (1106) information to other WTRUs, the information including instructing other WTRUs to perform path switching of at least some of the traffic between the WTRU group and the network node via the selected WTRU to the network relay.

[0257] According to another embodiment of the method, the path switching request is a connection establishment request that includes an indication of group mobility and receives a response message to the request, the response message indicating an identifier of a resource reserved by the selected WTRU for the WTRU group by the network relay, and wherein information including instructions to other WTRUs for path switching includes the identifier of the resource.

[0258] According to another embodiment of the method, the selected WTRU-to-network relay is shared between at least a first candidate WTRU-to-network relay and at least a second candidate WTRU-to-network relay.

[0259] According to another embodiment of the method, the trigger is received from one of the following: Applications or application servers; and WTRU to network relay handles at least some of the traffic between WTRU groups and network nodes.

[0260] According to another embodiment of the method, the trigger received from the application or application server is caused by at least one member of the WTRU group experiencing a decline in service quality.

[0261] According to another embodiment of the method, since the WTRU to network relay handling at least some traffic between the WTRU group and the network node does not have sufficient resources to handle the at least some traffic, the WTRU to network relay handling at least some traffic between the WTRU group and the network node receives a trigger.

[0262] According to another embodiment of the method, a group of WTRUs is formed for a collaborative service, with at least a first candidate WTRU to network relay and at least a second candidate WTRU to network relay supporting the collaborative service.

[0263] According to one embodiment, a wireless transmit-receive unit (WTRU) is also disclosed and described, which includes at least one processor configured to: Receive a trigger to perform path switching on at least some traffic between a WTRU group and a network node, the WTRU group comprising WTRUs and other WTRUs configured to communicate with the network node; Send messages to other WTRUs that include instructions for path switching of at least some traffic volume; Identify at least a first candidate WTRU to the network trunk that can handle at least some traffic volume; In response to the message, an indication is received from one or more of the other WTRUs that at least a second candidate WTRU can be used to process at least some traffic to the network relay; Select a WTRU to network relay from at least a first candidate WTRU to network relay and at least a second candidate WTRU to network relay for relaying at least some traffic between WTRU groups and network nodes; Send a request to the selected WTRU to the network relay to perform a path switch for at least some traffic between the WTRU group and the network node; and Send information to other WTRUs, the information including instructing other WTRUs to perform path switching of at least some of the traffic between the WTRU group and the network node via a selected WTRU to network relay.

[0264] According to one embodiment, the path switching request is a connection establishment request that includes an indication of group mobility and receives a response message to the request, the response message indicating an identifier of a resource reserved by the selected WTRU for the WTRU group by the network relay, and wherein information including instructions to other WTRUs for path switching includes the identifier of the resource.

[0265] According to one embodiment, the selected WTRU to network relay is shared between at least a first candidate WTRU to network relay and at least a second candidate WTRU to network relay.

[0266] According to one embodiment, the trigger is received from one of the following: Applications or application servers; and WTRU to network relay handles at least some of the traffic between WTRU groups and network nodes.

[0267] According to one embodiment, the trigger received from the application or application server is caused by at least one member of the WTRU group experiencing a decline in service quality.

[0268] According to one embodiment, a WTRU to network relay that handles at least some traffic between the WTRU group and the network node receives a trigger because the WTRU to network relay that handles at least some traffic between the WTRU group and the network node does not have sufficient resources to handle the at least some traffic.

[0269] According to one embodiment, a group of WTRUs is formed for a collaborative service, with at least a first candidate WTRU to network relay and at least a second candidate WTRU to network relay supporting the collaborative service.

[0270] in conclusion Although features and elements have been provided above in specific combinations, those skilled in the art will understand that each feature or element may be used alone or in any combination with other features and elements. This disclosure is not limited in its description of the specific embodiments described herein, which are intended as illustrative of various aspects. Many modifications and variations may be made without departing from its spirit and scope, as will be apparent to those skilled in the art. Any element, action, or instruction used in the description of this application should not be construed as critical or essential to the invention unless expressly provided so. In addition to those listed herein, functionally equivalent methods and apparatus within the scope of this disclosure will be apparent to those skilled in the art based on the foregoing description. Such modifications and variations are intended to fall within the scope of the appended claims. This disclosure is limited only by the terms of the appended claims and the full scope of equivalents conferred by such claims. It should be understood that this disclosure is not limited to the specific methods or systems described herein.

[0271] For simplicity, the foregoing embodiments have been discussed in terms of terminology and structure relating to communication-capable devices (i.e., radio wave transmitters and receivers). However, the embodiments discussed are not limited to these systems, but can be applied to other systems that use other forms of electromagnetic waves or non-electromagnetic waves (such as sound waves).

[0272] It will also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the term “video” or the term “image” may mean any of a snapshot, a single image, and / or multiple images displayed on a time basis. As another example, when referred to herein, the term “user equipment” and its abbreviation “UE,” the term “remote,” and / or the term “head-mounted display” or its abbreviation “HMD” may mean or include (i) a wireless transmit and / or receive unit (WTRU); (ii) any of several embodiments of a WTRU; (iii) a device particularly configured with some or all of the construction and functions of a WTRU and having wireless and / or wired (e.g., tetherable) capabilities; (iv) a device configured with fewer than all the construction and functions of a WTRU and having wireless and / or wired capabilities; or (iv) a similar device. References herein Figures 1A to 1D Details of an example WTRU are provided, which may represent any WTRU described herein. As another example, various disclosed embodiments herein are further illustrated. The above text and The following text It is described as utilizing a head-mounted display. Those skilled in the art will recognize that devices other than head-mounted displays can be used, and some or all of the embodiments of this disclosure and the various disclosures can be modified accordingly without excessive experimentation. Examples of such other devices may include drones or other devices configured to stream information to provide an adaptive, realistic experience.

[0273] Furthermore, the methods described herein can be implemented in computer programs, software, or firmware incorporated into computer-readable media for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of non-transitory 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 internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM discs and digital multifunction disks (DVDs). The processor associated with the software can be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

[0274] Variations of the methods, apparatus, and systems provided above are possible without departing from the scope of the invention. Given the wide variety of embodiments that can be applied, it should be understood that the illustrated embodiments are merely examples and should not be construed as limiting the scope of the appended claims. For example, embodiments provided herein include handheld devices that may include or be used with any suitable voltage source (such as a battery) that provides any suitable voltage.

[0275] Furthermore, in the embodiments provided above, a processing platform, computing system, controller, and other means including a processor are mentioned. These means may include at least one central processing unit (“CPU”) and memory. According to the practice of those skilled in the art of computer programming, references to actions and symbolic representations of operations or instructions can be performed by various CPUs and memories. Such actions and operations or instructions may be referred to as “execution,” “computer execution,” or “CPU execution.”

[0276] Those skilled in the art will understand that the actions and symbols representing operations or instructions include the CPU's manipulation of electrical signals. An electrical system represents a data bit, which can cause a final conversion or reduction of an electrical signal and is maintained in a memory location within a storage system, thereby reconfiguring or otherwise altering the CPU's operation and other signal processing. The memory location maintaining the data bit is a physical location having specific electrical, magnetic, optical, or organic properties corresponding to or representing the data bit. It should be understood that the embodiments are not limited to the platforms or CPUs described above, and other platforms and CPUs may support the provided methods.

[0277] Data bits can also be maintained on a computer-readable medium, including disks, optical disks, and any other CPU-readable volatile (e.g., random access memory (RAM)) or non-volatile (e.g., read-only memory (ROM)) mass storage system. The computer-readable medium can include cooperative or interconnected computer-readable media that exist only on the processing system or are distributed across multiple interconnected processing systems that may be located locally or remotely on the processing system. It should be understood that the embodiments are not limited to the above-described memories, and other platforms and memories may support the provided methods.

[0278] In the illustrative embodiments, any operations, processes, etc., described herein can be implemented as computer-readable instructions stored on a computer-readable medium. These computer-readable instructions can be executed by a processor of a mobile unit, network element, and / or any other computing device.

[0279] The differences between the hardware and software implementations of various aspects of the system are minor. The use of hardware or software is typically (but not always, as the choice between hardware and software can become important in certain situations) a design choice representing a cost-efficiency trade-off. Various vehicles (e.g., hardware, software, and / or firmware) may exist to implement the processes and / or systems and / or other technologies described herein, and the preferred vehicle may vary depending on the context in which the processes and / or systems and / or other technologies are deployed. For example, if the implementer determines that speed and accuracy are most important, then the implementer may choose the primary hardware and / or firmware vehicle. If flexibility is most important, then the implementer may choose the primary software implementation. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.

[0280] The foregoing detailed description has illustrated various embodiments of the apparatus and / or processes using block diagrams, flowcharts, and / or examples. Those skilled in the art will understand that each function and / or operation within such block diagrams, flowcharts, or examples can be implemented individually and / or collectively by a wide range of hardware, software, firmware, or virtually any combination thereof, with respect to the inclusion of one or more functions and / or operations in such block diagrams, flowcharts, or examples. In embodiments, several portions of the subject matter described herein can be implemented via application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integration formats. However, those skilled in the art will recognize that all or part of some aspects of the embodiments disclosed herein can be equivalently implemented in integrated circuits as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or virtually as any combination thereof, and that designing circuit systems and / or writing code for software and / or firmware in accordance with this disclosure will be entirely within the skill of those skilled in the art. Furthermore, those skilled in the art will understand that the mechanisms of the subject matter described herein can be distributed as a program product in various forms, and the illustrative examples of the subject matter described herein apply regardless of the specific type of signal-bearing medium used for actual distribution. Examples of signal-bearing media include, but are not limited to, the following: recordable media, such as floppy disks, hard disk drives, CDs, DVDs, digital magnetic tapes, computer memory, etc.; and transmission media, such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.).

[0281] Those skilled in the art will recognize that devices and / or processes are typically described in the manner set forth herein, and that engineering practice is subsequently used to integrate such described devices and / or processes into data processing systems. That is, at least a portion of the devices and / or processes described herein can be integrated into a data processing system through a reasonable number of experiments. Those skilled in the art will recognize that a typical data processing system typically includes one or more of the following: a system unit housing, a video display device, a memory such as volatile and non-volatile memory, a processor such as a microprocessor and a digital signal processor, a computing entity such as an operating system, drivers, a graphical user interface and application processes, one or more interactive devices such as a touchpad or screen, and / or a control system including feedback loops and control motors (e.g., feedback for sensing position and / or speed; control motors for moving and / or adjusting components and / or quantity). A typical data processing system can be implemented using any suitable commercially available components, such as those commonly found in data computing / communication and / or network computing / communication systems.

[0282] The topics described herein sometimes illustrate different components that are included within or connected to different other components. It should be understood that such depicted architectures are merely examples, and many other architectures that achieve the same functionality can actually be implemented. Conceptually, any arrangement of components used to achieve the same functionality is effectively “associated” so that the desired functionality can be achieved. Therefore, any two components combined herein to achieve a particular function can be considered “associated” with each other so that the desired functionality is achieved regardless of the architecture or intermediate components. Similarly, any two such associated components can also be considered “operably connected” or “operably coupled” to each other to achieve the desired functionality, and any two components that can be suchly associated can also be considered “operably coupled” to each other to achieve the desired functionality. Specific examples of being operablely coupled include (but are not limited to) physically matable and / or physically interactive components, and / or wirelessly interactive and / or logically interactive components.

[0283] Regarding any basic plural and / or singular terms used herein, those skilled in the art can convert from plural to singular and / or from singular to plural as appropriate to the context and / or application. For clarity, various singular / plural permutations may be explicitly described herein.

[0284] Those skilled in the art will understand that, generally, the terms used herein and especially in the appended claims (e.g., the body of the appended claims) are intended to be largely "open-ended" terms (e.g., the term "comprising" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "including" should be interpreted as "including but not limited to," etc.). Those skilled in the art will further understand that if a particular number of the introduced claims are intended to be recited, then such intention will be expressly stated in the claims, and without such recitation, such intention does not exist. For example, the term "single" or similar language may be used where only one item is intended. To aid understanding, the appended claims and / or the description herein may include the use of the introductory phrases "at least one" and "one or more" to introduce multiple recitations of claims. However, the use of such phrases should not be construed as implying that a claim recitation introduced by the indefinite article "a" limits any particular claim to include only one such recitation, even when the same claim includes the introductory phrase "one or more" or "at least one" and indefinite articles such as "a" (e.g., "a" should be interpreted as meaning "at least one" or "one or more"). The same applies to the use of definite articles used to introduce claim recitations. Furthermore, even if a specific number of introduced claim recitations is explicitly stated, those skilled in the art will recognize that this statement should be interpreted as meaning at least the number recitations (e.g., in the absence of other modifiers, simply stating "two recitations" means at least two recitations or two or more recitations). Furthermore, in cases where conventions such as "at least one of A, B, and C" are used, this construction is generally intended to convey the meaning of the convention as understood by a person skilled in the art (e.g., "a system having at least one of A, B, and C" will include, but is not limited to, systems having only A, only B, only C, both A and B, both A and C, both B and C, and / or both A, B, and C). In cases where conventions such as "at least one of A, B, or C" are used, a person skilled in the art will generally understand that the meaning of the convention is expected to be such that (e.g., "a system having at least one of A, B, or C" will include, but is not limited to, systems having only A, only B, only C, both A and B, both A and C, both B and C, and / or both A, B, and C). A person skilled in the art will further understand that any transitional words and / or phrases (whether in the specification, claims, or drawings) that actually give two or more alternative terms should be understood to be intended to include the possibility of including one, any, or both of the terms. For example, the phrase “A or B” would be understood to include the possibility of “A” or “B” or “A and B”.Furthermore, as used herein, the term "any" followed by a list of multiple items and / or multiple item categories is intended to include "any," "any combination," "any number," and / or "any combination of any number" of items and / or item categories, individually or in combination with other items and / or other item categories. Additionally, as used herein, the term "set" is intended to include any number of items, including zero. Furthermore, as used herein, the term "number" is intended to include any number, including zero. And as used herein, the term "many" is intended to be synonymous with "multiple."

[0285] Furthermore, where features or aspects of this disclosure are described in accordance with the Markush Group, those skilled in the art will recognize that this disclosure is also described in accordance with any individual member or subgroup of the Markush Group.

[0286] As those skilled in the art will understand, for any and all purposes, such as providing a written description, all scopes disclosed herein also encompass any and all possible subscopes and combinations thereof. Any listed scope can be readily identified as sufficiently descriptive and such that the same scope can be decomposed into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each scope discussed herein can be readily decomposed into a lower third, a middle third, and an upper third, etc. Those skilled in the art will also understand that all language, such as “at most,” “at least,” “greater than,” “less than,” etc., includes the listed numbers and refers to a scope that can subsequently be decomposed into subscopes as described above. Finally, as those skilled in the art will understand, a scope includes each individual member. Thus, for example, a group having 1 to 3 units refers to a group having 1, 2, or 3 units. Similarly, a group having 1 to 5 units refers to a group having 1, 2, 3, 4, or 5 units, and so on.

[0287] Furthermore, unless otherwise stated, the claims should not be construed as being limited to the order or elements provided. Additionally, the use of the term "for the means of" in any claim is intended to invoke 35 USC §112, ¶ 6 or the means plus function claim format, and any claim without the term "for the means of" is not intended to do so.

Claims

1. A method implemented by a wireless transmit-receive unit (WTRU), the method comprising: Receive a trigger to perform path switching on at least some traffic between a WTRU group and a network node, the WTRU group including the WTRU and other WTRUs configured to communicate with the network node; Send a message to the other WTRUs including an indication of path switching for at least some of the traffic; Identify at least a first candidate WTRU to the network relay that can be used to handle at least some of the traffic volumes; In response to the message, an indication is received from one or more of the other WTRUs that at least a second candidate WTRU capable of handling the at least some of the traffic to the network relay. A WTRU to network relay is selected from the at least first candidate WTRU to network relay and the at least second candidate WTRU to network relay for relaying the at least some traffic between the WTRU group and the network node; Send a request to the selected WTRU to the network relay to perform path switching on at least some of the traffic between the WTRU group and the network node; as well as Send information to the other WTRUs, the information including instructing the other WTRUs to perform path switching on at least some of the traffic between the WTRU group and the network node via the selected WTRU to network relay.

2. The method of claim 1, wherein the path switching request is a connection establishment request, the connection establishment request including an indication of group mobility and receiving a response message to the request, the response message indicating an identifier of the resource reserved by the selected WTRU to the network relay for the WTRU group, and wherein, The information that includes instructing the other WTRUs to perform the path switch includes the identifier of the resource.

3. The method of claim 1, wherein the selected WTRU to network relay is shared between the at least first candidate WTRU to network relay and the at least second candidate WTRU to network relay.

4. The method of claim 1, wherein the trigger is received from one of: Applications or application servers; and WTRU to network relay for processing at least some of the traffic between the WTRU group and the network node.

5. The method of claim 4, wherein the trigger received from the application or the application server is caused by at least one member of the WTRU group experiencing a quality of service degradation.

6. The method of claim 4, wherein the trigger is received from the WTRU to network relay that processes at least some of the traffic between the WTRU group and the network node because the WTRU to network relay that processes at least some of the traffic does not have sufficient resources to process the at least some of the traffic.

7. The method of any one of claims 1 to 6, wherein the WTRU group is formed for collaborative services, and the at least first candidate WTRU to network relay and the at least second candidate WTRU to network relay support the collaborative services.

8. A wireless transmit-receive unit (WTRU) comprising at least one processor, said at least one processor being configured to: Receive a trigger to perform path switching on at least some traffic between a WTRU group and a network node, the WTRU group including the WTRU and other WTRUs configured to communicate with the network node; Send a message to the other WTRUs including an indication of path switching for at least some of the traffic; Identify at least a first candidate WTRU to the network relay that can be used to handle at least some of the traffic volumes; In response to the message, an indication is received from one or more of the other WTRUs that at least a second candidate WTRU capable of handling the at least some of the traffic to the network relay. A WTRU to network relay is selected from the at least first candidate WTRU to network relay and the at least second candidate WTRU to network relay for relaying the at least some traffic between the WTRU group and the network node; Send a request to the selected WTRU-to-network relay to perform path switching on at least some of the traffic between the WTRU group and the network node; as well as Send information to the other WTRUs, the information including instructing the other WTRUs to perform path switching on at least some of the traffic between the WTRU group and the network node via the selected WTRU to network relay.

9. The WTRU of claim 8, wherein the path switching request is a connection establishment request, the connection establishment request including an indication of group mobility and receiving a response message to the request, the response message indicating an identifier of a resource reserved by the selected WTRU for the WTRU group by the network relay, and wherein, The information that includes instructing the other WTRUs to perform the path switch includes the identifier of the resource.

10. The WTRU of claim 8, wherein the selected WTRU-to-network relay is shared between the at least first candidate WTRU-to-network relay and the at least second candidate WTRU-to-network relay.

11. The WTRU of claim 8, wherein the trigger is received from one of the following: Applications or application servers; and WTRU to network relay for processing at least some of the traffic between the WTRU group and the network node.

12. The WTRU of claim 11, wherein the trigger received from the application or the application server is caused by at least one member of the WTRU group experiencing a quality of service degradation.

13. The WTRU of claim 11, wherein the trigger is received from the WTRU to network relay that processes at least some of the traffic between the WTRU group and the network node because the WTRU to network relay that processes at least some of the traffic does not have sufficient resources to process the at least some of the traffic.

14. The WTRU of any one of claims 8 to 13, wherein the WTRU group is formed for a collaborative service, and the at least first candidate WTRU to network relay and the at least second candidate WTRU to network relay support the collaborative service.

Images