IP address allocation processing method for multi-hop u2u relay connection

Abstract

A first relay wireless transmit / receive unit (WTRU) may be configured to receive configuration information indicating a first Internet Protocol (IP) address pool for allocating an IP address for a connection with the first relay WTRU. The first relay WTRU may receive the end-to-end route setup request message from the first terminal WTRU. The end-to-end route establishment request message indicates the second relay WTRU and the second terminal WTRU. The first relay WTRU may transmit an end-to-end route establishment response message to establish an end-to-end route between the first terminal WTRU and the second terminal WTRU via the first relay WTRU and the second relay WTRU. The first relay WTRU may assign the first IP address in the first IP address pool to the first terminal WTRU. The first relay WTRU may send a request message indicating a request for a second IP address of a second terminal WTRU.

Description

[0001] Cross-references to related applications This application claims priority to U.S. Provisional Application No. 63 / 586102, filed September 28, 2023, and U.S. Provisional Application No. 63 / 586104, filed September 28, 2023, the entire contents of each of which are incorporated herein by reference. Background Technology

[0002] 5G ProSe defines several features, such as 5G ProSe direct discovery, 5G ProSe direct communication, 5G ProSe User Equipment to Network (U2N) relay, and / or 5G ProSe User Equipment to User Equipment (U2U) relay. 5G ProSe U2U relay enables indirect communication between two terminal WTRUs. For U2U relay, 5G ProSe U2U relay discovery and / or 5G ProSe communication via U2U relay can be defined. For 5G ProSe U2U relay discovery, both Model A discovery and / or Model B discovery can be supported. Model A can use a single discovery protocol message (e.g., announcement), while Model B can use two discovery protocol messages (e.g., request and / or response).

[0003] It also supports discovery integration into the PC5 unicast link establishment process. 5G ProSe communication via U2U relays is possible using Layer 2 U2U relays and / or Layer 3 U2U relays. For Layer 2 U2U relays and / or Layer 3 U2U relays, schemes can be defined for 5G ProSe communication establishment with discovery processes and / or for integrating discovery into the PC5 unicast link establishment process.

[0004] Using a Layer 2 U2U relay, an end-to-end PC5 link can be established between terminal UEs via the relay. The UE or user equipment may also be referred to herein as a Radio Transmit / Receive Unit (WTRU). PC5-S messages can then be exchanged between the terminal WTRUs.

[0005] Using a Layer 3 U2U trunk, each terminal WTRU can establish a PC5 link with the trunk. The trunk can forward messages to the terminal WTRU. PC5-S messages can be exchanged between the terminal WTRU and / or the trunk.

[0006] With Layer 3 U2U relaying, when using IP based data connection, after a PC5 link is established with the relay, the relay can allocate an IP address for each terminal WTRU. This can also be based on a dynamic host configuration protocol (DHCP) mechanism and / or each terminal WTRU can allocate its own IP address and / or inform the relay. The relay can be based on a link local IP address allocation mechanism. The DHCP and / or link local IP address allocation will be determined during the security connection establishment between the terminal WTRU and / or U2U relay.

[0007] After a connection is established between two terminal WTRUs via a U2U relay, each terminal WTRU can continuously monitor the channel status of the PC5 link. When the link quality is below a certain threshold, the terminal WTRU can reselect a U2U relay for the connection between the two terminal WTRUs. For U2U relay reselection, a U2U relay discovery procedure can be used and / or a negotiated 5G ProSe U2U relay reselection procedure can be used. In the negotiated U2U relay reselection, one terminal WTRU initiates the U2U relay reselection procedure, the terminal WTRU can use the existing connection to negotiate a new U2U relay, and establish the communication via the reselected U2U relay before releasing the communication via the current 5G ProSe U2U relay. SUMMARY

[0008] One example solution described herein can include an Internet Protocol (IP) address allocation process for multi-hop U2U connection. In a U2U relay, a relay WTRU can be authorized as a U2U relay supporting multi-hop relay and / or configured with parameters for serving the relay WTRU. This can include an IP address pool for allocating IP addresses with PC5 connection to the relay WTRU and an allocated DHCP service group ID.

[0009] In an example, a relay WTRU can establish a PC5 connection with a terminal WTRU for end-to-end (e2e) routing, allocate an IP address under the allocated IP address pool to the terminal WTRU, and / or establish a PC5 connection with other relay WTRUs for e2e routing and / or the relay WTRUs share their allocated IP address pool information and DHCP service group ID.

[0010] In an example, a dynamic host conversion protocol (DHCP) service group ID can be defined to guarantee the uniqueness of IP addresses allocated by relay WTRUs belonging to the same DHCP service group. By comparing the DHCP service group IDs of relay WTRUs in e2e routing, the possibility of IP address conflict can be determined. To avoid potential conflict of allocated IP addresses, relays belonging to different DHCP service groups can not be selected together for e2e routing.

[0011] In an example, when receiving a DNS query for a terminal WTRU, a relay WTRU can request a domain name system (DNS) query from other relay WTRU(s) and / or receive IP address information of the terminal WTRU from another relay WTRU. When receiving IP packets through the established PC5 connection, based on the saved IP address pool information, the relay WTRU can select an appropriate relay WTRU and / or forward the IP packets to the selected relay WTRU. BRIEF DESCRIPTION OF DRAWINGS

[0012] Figure 1A FIG. 1 is a system diagram illustrating an example communications system in which one or more disclosed embodiments can be implemented.

[0013] Figure 1B FIG. 2 is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that can be used within the communications system shown in FIG. 1 and / or FIG. 2, according to an embodiment. Figure 1A

[0014] Figure 1C FIG. 3 is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that can be used within the communications system shown in FIG. 1 and / or FIG. 2, according to an embodiment. Figure 1A

[0015] Figure 1D FIG. 4 is a system diagram illustrating another example RAN and another example CN that can be used within the communications system shown in FIG. 1 and / or FIG. 2, according to an embodiment. Figure 1A

[0016] Figure 2 An example IP address allocation procedure based on a configured IP address pool for multi-hop relaying is depicted.

[0017] Figure 3 An example IP address allocation procedure to resolve IP address conflict for multi-hop relaying is depicted. DETAILED DESCRIPTION

[0018] Figure 1A ​​​is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments can be implemented. The communications system 100 can be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 can enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 can employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word DFT-Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM (OFDM), filter bank multicarrier (FBMC), and / or the like.

[0019] As shown in Figure 1A The communications system 100 can include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104 / 113, a CN 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it will be appreciated 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. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which can be referred to as a “station” and / or a “STA”)

[0020] The communications system 100 can also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b can be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or the other networks 112. By way of example, the base stations 114a, 114b can be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a gNB, a NR Node B, a site controller, an access point (AP), a wireless router, and so on. The base stations 114a, 114b can be in communication with the WTRUs 102a, 102b, 102c, 102d and can facilitate the management of resources used by the WTRUs 102a, 102b, 102c, 102d. The base stations 114a, 114b can be part of one or more RANs such as the RAN 104 / 113, which can also include other base stations and / or network elements, not shown, such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc.

[0021] The base station 114a can be part of the RAN 104 / 113, which also can include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or the base station 114b can be configured to transmit and / or receive wireless signals on one or more carrier frequencies. These frequencies can be referred to as carriers, which can be utilized by base stations 114a, 114b to communicate with WTRUs 102a, 102b, 102c, 102d. As used herein a carrier can be a BCCH or a CCCH. Carriers can be assigned, for example, in an FDD, TDD, or mixed mode. Carriers can be assigned in a licensed or unlicensed spectrum. Carriers can be assigned in the frequency domain with the intention to group carriers closely together, for example modulated data, control channels, reference signals, etc. The location of carriers in the time domain can be fixed, for example, a fixed location in a frame, subframe, slot, symbol, etc. The location of carriers in the time domain can be dynamic, for example, carriers can be moved in the time domain. The location of carriers in the frequency domain can be fixed, for example, a fixed location in a system bandwidth, a fixed location in a component carrier, etc. The location of carriers in the frequency domain can be dynamic, for example, carriers can be moved in the frequency domain. The location of carriers in the time and / or frequency domain can be dynamic, for example, carriers can be moved in the time and / or frequency domain. The location of carriers in the time and / or frequency domain can be fixed, for example, a fixed location in a system bandwidth, a fixed location in a component carrier, etc. The location of carriers in the time and / or frequency domain can be dynamic, for example, carriers can be moved in the time and / or frequency domain. The location of carriers in the time and / or frequency domain can be fixed, for example, a fixed location in a system bandwidth, a fixed location in a component carrier, etc. The location of carriers in the time and / or frequency domain can be dynamic, for example, carriers can be moved in the time and / or frequency domain. The location of carriers in the time and / or frequency domain can be fixed, for example, a fixed location in a system bandwidth, a fixed location in a component carrier, etc. The location of carriers in the time and / or frequency domain can be dynamic, for example, carriers can be moved in the time and / or frequency domain.

[0022] The base stations 114a, 114b can communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an 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.). The air interface 116 can be established using any suitable radio access technology (RAT).

[0023] More specifically, as described above, the communications 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, and the like. For example, the base station 114a and the WTRUs 102a, 102b, 102c in the RAN 104 / 113 can implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish the air interface 115 / 116 / 117 using wideband CDMA (WCDMA). WCDMA can include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed Downlink (DL) Packet Access (HSDPA) and / or High-Speed UL Packet Access (HSUPA).

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

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

[0026] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement multiple radio access technologies. For example, the base station 114a and WTRUs 102a, 102b, 102c can implement LTE radio access and NR radio access together, for instance to establish the air interface 116 using Dual Connectivity (DC) principles. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c can be characterized by multiple

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

[0028] Figure 1A The base station 114b in FIG. 13 can be a wireless router, Home eNode B, Home Node B, or access point, for example, and can utilize any suitable RAT for facilitating wireless connectivity access. In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d can implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. As shown in FIG. 13, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b can not be required to access the Internet 110 via the CN 106 / 115. Figure 1A

[0029] ​The RAN 104 / 113 can be in communication with the CN 106 / 115, which can be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data can have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 / 115 can provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in FIG. 1C, the RAN 104 / 113 and / or the CN 106 / 115 can be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which can be utilizing a NR radio technology, the CN 106 / 115 can also be in communication with another RAN (not shown) that employs a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology. Figure 1A Although not shown in FIG. 1C, it is understood that the RAN 104 / 113 and / or the CN 106 / 115 can be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which can be utilizing a NR radio technology, the CN 106 / 115 can also be in communication with another RAN (not shown) that employs a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0030] The CN 106 / 115 can also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or the other networks 112. The PSTN 108 can include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 can include a global system of interconnected computer networks and devices that use the Transmission Control Protocol (TCP) Internet Protocol (IP) suite to communicate with one another. The networks 112 can include wired and / or wireless communications networks owned and / or operated by other service providers. For example, the networks 112 can include another CN connected to one or more RANs, which can employ the same RAT as the RAN 104 / 113 or a different RAT.

[0031] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 can include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, 102d can include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRUs 102a, 102b, 102c, 102d can include a transceiver Figure 1AThe WTRU 102c, as shown in FIG. 1C, can be configured to communicate with the base stations 114a, which can employ a cellular-based radio technology, and the base station 114b, which can employ an IEEE 802 radio technology.

[0032] Figure 1B is a system diagram of an example WTRU 102. As shown in Figure 1B As shown in FIG. 1C, the WTRU 102 can include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138, among others. It will be appreciated that the WTRU 102 can include any sub-combination of the above-referenced features.

[0033] The processor 118 can be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 can perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to the transceiver 120, which can be coupled to the transmit / receive element 122. While Figure 1B Although the processor 118 and the transceiver 120 are depicted in the

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

[0035] Although Figure 1BThe transmit / receive element 122 can be configured to transmit signals to, and receive signals from, a base station (e.g., the base station 1 14a, 1 14b, or 1 14c) over the air interface 1 16. For example, in one embodiment, the transmit / receive element 122 can be configured to transmit and receive RF signals and / or microwave signals, including any combination of download and upload Internet Protocol packets, according to the techniques described herein. In an embodiment, the transmit / receive element 122 can be configured to transmit and receive signals to and from one or more base stations (e.g., the base stations 1 14a, 1 14b, and 1 14c), and / or the nodes 1 16a, 1 16b, and 1 16c, of the core network 130. In this case, the transmit / receive element 122 can utilize transmit / receive on different frequencies for each of the base stations 1 14a, 1 14b, and 1 14c. The transmit / receive element 122 can be configured to communicate signals to and from the WTRU 102 over the air interface 1 16 using wireless communication techniques. The WTRU 102 can include multiple transmit / receive elements 122 (e.g., a diversity antenna system). In an embodiment, the transmit / receive element 122 can be an antenna, a front-end unit, or any combination thereof. In an embodiment, the transmit / receive element 122 can be configured to transmit wireless signals to, and receive wireless signals from, a base station 1 14a, 1 14b, or 1 14c using multiple antennas. The transmit / receive element 122 can be an example of a single-node communication or a multi-node communication. Each of the transmit / receive elements 122 can utilize a single antenna to transmit and receive signals. The transmit / receive element 122 can be an example of a single-node communication. The transmit / receive element 122 can utilize multiple antennas to transmit and receive signals. The transmit / receive element 122 can be an example of a multi-node communication.

[0036] The transceiver 120 can be configured to modulate information to be transmitted by the transmit / receive element 122 and to demodulate information received by the transmit / receive element 122. As noted above, the WTRU 102 can have multi-mode capabilities. Thus, the transceiver 120 can include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11, for example.

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

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

[0039] The processor 118 can also be coupled to the GPS chipset 136, which can be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 can receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 can acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0040] The processor 118 can further be coupled to other peripherals 138, which can include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 can include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a virtual reality and / or an augmented reality (VR / A R) device, an activity tracker, and the like. The peripherals 138 can include one or more sensors, which can be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0041] The WTRU 102 can include a full duplex radio for which transmission and reception of some or all signals associated with the air interface between the WTRU 102 and a network access device (e.g., base station 114a, 114b) can be concurrent and / or simultaneous. The full duplex radio can include an interference management unit to reduce and / or eliminate substantially self-interference occurring during concurrent transmission and reception. In an embodiment, the WTRU 102 can include a half duplex radio for which transmission and reception of some or all signals associated with the air interface between the WTRU 102 and network access device are time divided. For example, in a half duplex scheme involving a time-division duplex (TDD) mode, transmission and reception can be done at different times for the WTRU 102 and network access device.

[0042] Figure 1Cis a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As described above, the RAN 104 can be in communication with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 can also be in communication with the CN 106.

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

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

[0045] Figure 1C The CN 106 shown in Figure 1 can include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements can be owned and / or operated by an entity other than the CN operator.

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

[0047] ​The SGW 164 can be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 can generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 can perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

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

[0049] The CN 106 can also serve as a gateway for the WTRUs 102a, 102b, 102c to access the PSTN 108, the Internet 110, and / or the other networks 112. The PSTN 108 can include circuit-switched

[0050] Although WTRUs 102a, 102b, 102c are described as communicating with the RAN 104, it is understood that the WTRUs 102a, 102b, 102c can also communicate with other wireless devices, such as other WTRUs 102a, 102b, 102c, and the like. Figures 1A-1D

[0051] In representative embodiments, another network 112 can be a WLAN.

[0052] ​A WLAN in Infrastructure Basic Service 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 access or an interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic in to and / or out of the BSS. Traffic to STAs that originates from outside the BSS can arrive through the AP and can be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS can be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS can be sent through the AP, for example, where the source STA can send traffic to the AP and the AP can deliver the traffic to the destination STA. The traffic between STAs within a BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be sent between (e.g., directly between) source and destination STAs without sending the traffic through the AP. In certain representative embodiments, the peer-to-peer traffic can be sent using a direct link setup (DLS). In certain representative embodiments, the DLS can use an 802.11e DLS or an 802.11z tunneled DLS (TDLS). A WLAN using Independent BSS (IBSS) mode can not have an AP, and all STAs in an IBSS, (e.g., an ad-hoc group of STAs) can communicate directly with each other without using a central AP.

[0053] When using an 802.11 ac infrastructure mode of operation or similar modes of operation, an AP can transmit beacons on a fixed channel, such as a primary channel. The primary channel can be a fixed width (e.g., a 20 MHz wide bandwidth), or can be a dynamically set width via signaling. The primary channel can be the operating channel of the BSS, and can be used by STAs to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access with collision avoidance (CSMA / CA) can be implemented, for example, in 802.11 systems. For CSMA / CA, all STAs, including the AP (e.g., every STA) can listen to the primary channel. If a particular STA hears / detects and / or determines that the primary channel is busy, the particular STA can back off. Only one STA can transmit at any given time in a given BSS.

[0054] High Throughput (HT) STAs can use 40 MHz wide channels for communication, for example, via combining adjacent or nonadjacent 20 MHz channels into the 40 MHz wide channel.

[0055] Very High Throughput (VHT) STAs can support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. 40 MHz and / or 80 MHz channels can be formed by combining contiguous 20 MHz channels. 160 MHz channels can be formed by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, data can be passed through a segment parser after channel encoding, which can divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing can be done on each stream separately. The streams can be mapped on to the two 80 MHz channels, and the data can be transmitted by a transmitting STA. At the receiver of the receiving STA, the above-described operation for the 80+80 configuration can be reversed, and the combined data can be sent to the Medium Access Control (MAC).

[0056] 802.11af and 802.11ah support sub-1 GHz modes of operation. Channel operating bandwidths and carriers in 802.11af and 802.11ah are reduced relative to those used in 802.11η and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah can support Meter Type Control / Machine-Type Communications, such as MTC devices in a macro coverage area. MTC devices can have certain capabilities, for example, including limited functionality that supports (e.g., only supports) certain and / or limited bandwidth. MTC devices can include a battery that has a battery life above a threshold (e.g., that maintains a very long battery life).

[0057] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11η, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as the primary channel. The bandwidth of the primary channel can be equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA that supports the smallest bandwidth operating mode among all STAs operating in the BSS. Using 802.11ah as an example, for a STA (e.g., MTC type device) that supports (e.g., only supports) 1 MHz mode, the primary channel bandwidth can be 1 MHz, even if other STAs in the AP and BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy with a transmission to the AP (e.g., by a STA that only supports 1 MHz operating mode), the entire available frequency band can be considered busy, even if most of the frequency band remains idle and can be available.

[0058] In the United States, the available frequency bands for 802.11ah can be from 902 MHz to 928 MHz. In Korea, the available frequency bands can be from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands can be from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11ah can be from 6 MHz to 26 MHz, depending on the country code.

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

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

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

[0062] The gNBs 180a, 180b, 180c can be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In the standalone configuration, the WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, the WTRUs 102a, 102b, 102c can utilize one or more gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, the WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In the non-standalone configuration, the WTRUs 102a, 102b, 102c can communicate / connect with gNBs 180a, 180b, 180c while also communicating / connecting with another RAN, such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c can implement DC principles to simultaneously communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c. In the non-standalone configuration, eNode-Bs 160a, 160b, 160c can serve as the mobility anchor point for WTRUs 102a, 102b, 102c while gNBs 180a, 180b, 180c can provide additional coverage and / or throughput to serving WTRUs 102a, 102b, 102c.

[0063] Each of the gNBs 180a, 180b, 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b, and the like. As shown, the gNBs 180a, 180b, 180c can communicate with one another over an Xn interface. Figure 1D

[0064] Figure 1D ​The CN 115, as shown in FIG. 10B, can include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While the foregoing elements are depicted as part of the CN 115, it will be appreciated that any of these elements can be owned and / or operated by an entity other than the CN operator.

[0065] The AMF 182a, 182b can be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and can serve as a control node. For example, the AMF 182a, 182b can be responsible for authenticating WTRUs 102a, 102b, 102c, supporting for network slicing (e.g., handling different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, management of the WTRU 102a, 102b, 102c registration area, termination of NAS signaling, mobility management, and the like. The AMF 162 can utilize network slicing to customize CN support for the WTRU 102a, 102b, 102c based on the type of service or

[0066] The SMF 183a, 183b can be connected to AMF 182a, 182b in the CN 115 via an N11 interface. The SMF 183a, 183b can also be connected to the UPF 184a, 184b in the CN 115 via an N4 interface. The SMF 183a, 183b can select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b can perform other functions, such as managing and allocating WTRU IP address, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and the like.

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

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

[0069] In view of Figures 1A-1D and Figures 1A-1D corresponding description, one or more or all of the functions described herein for one or more of the WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMF 182a-ab, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device(s) described herein can be performed by one or more emulation devices (not shown). An emulation device can be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulation device can be used to test other devices and / or to emulate a network and / or WTRU functionality.

[0070] The one or more emulation devices can perform one or more, including all, functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, emulation devices can be used in a testing scenario in a testing laboratory and / or an undeployed (e.g., testing) wired and / or wireless communication network to implement testing of one or more components. The one or more emulation devices can be test equipment. The emulation devices can transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which can include one or more antennas).

[0071] The one or more emulation devices can perform one or more, including all, functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, emulation devices can be used in a testing scenario in a testing laboratory and / or an undeployed (e.g., testing) wired and / or wireless communication network to implement testing of one or more components. The one or more emulation devices can be test equipment. The emulation devices can transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which can include one or more antennas).

[0072] Within examples, the present disclosure provides potential enhancements to support multi-hop for U2N and / or U2U relaying. Multi-hop for U2N relaying can enable remote WTRUs to discover and / or communicate with U2N relays via one or more U2U relays. Multi-hop U2U relaying can enable terminal WTRUs to discover and communicate with each other via more than one U2U relay. Multi-hop capability can be considered critical for mission critical communications (e.g., emergency responders) and / or situations that typically require enhanced coverage (e.g., indoors).

[0073] For IP address allocation for multi-hop, when a U2U relay allocates an IP address, the IP address can be used to communicate with other WTRUs via the same U2U relay. An existing PC5 link with a U2U relay can be shared for communication with other terminal WTRUs. For multi-hop relaying, link sharing can be supported to provide backward compatibility and / or the same IP address can be used for shared links.

[0074] For IP-based collaborative communication, each terminal WTRU can retrieve the IP address of another terminal WTRU. In a single-hop relaying case, a relay WTRU can act as a DHCP server and / or provide IP address resolution services. For multi-hop relaying, each terminal WTRU can be served by a different relay WTRU and / or the IP address of each terminal WTRU can be allocated by a different relay WTRU.

[0075] For multi-hop relay connections, the IP address of another terminal WTRU at another relay WTRU can be collected. When link sharing is considered, the existing IP address assigned by a relay WTRU can be reused for a new connection for multi-hop connection. The IP addresses of terminal WTRUs assigned from different relays working as DHCP servers can collide because there is no coordination between relays regarding IP address assignment. When these WTRUs try to communicate with each other through relays, the IP addresses of WTRUs can collide with each other and / or IP address based data traffic forwarding can not work properly. For multi-hop relay connections, IP address assignment can be handled without IP address collision.

[0076] To support multi-hop relay resolving IP address collision, in some cases, terminal WTRUs can need to connect to each other via multi-hop relay even though there can be assigned IP address collision between terminal WTRUs. This can occur when considering allowing multi-hop relay with more number of hops. Based on mobility, a WTRU can move to a certain area that is a boundary of an IP address assignment service area for unique IP address assignment.

[0077] In this disclosure, a U2U relay WTRU (e.g., a U2U relay WTRU, a U2U relay, and / or a U2U relay) can mean a WTRU that is authorized to perform as a relay WTRU that forwards traffic between WTRUs.

[0078] A U2U relay discovery procedure (e.g., a U2U relay discovery procedure) is a procedure to discover a path to a target WTRU via relay WTRUs. Through the U2U relay discovery procedure, an initiating WTRU can get information of U2U relay(s) that can possibly reach a target WTRU. The initiating WTRU can select an appropriate end-to-end route to the target WTRU via relay WTRUs. For multi-hop support, in a discovery response, a U2U relay can inform whether the U2U relay supports multi-hop relay.

[0079] In some examples, a multi-hop U2U relay discovery procedure and / or a multi-hop candidate U2U relay discovery procedure can be performed by a terminal WTRU.

[0080] The multi-hop U2U relay discovery procedure can involve discovering an end-to-end path for a target WTRU to communicate via a path including a single and / or multiple relay WTRUs. For example, through a multi-hop U2U relay discovery procedure for a target WTRU, an initiating WTRU can obtain information from the U2U relay WTRU(s) about one or more paths to the target WTRU involving the U2U relay WTRU(s) and / or other U2U relay WTRUs in the path between the U2U relay WTRU(s) and / or the target WTRU. After performing the multi-hop U2U relay discovery procedure for the target WTRU, the initiating WTRU can select an appropriate end-to-end route between the initiating WTRU and the target WTRU including multi-hop relay WTRUs.

[0081] The multi-hop candidate U2U relay discovery procedure is used to discover an end-to-end path for a target U2U relay via a path through single-hop and / or multi-hop relay WTRUs. The multi-hop U2U relay discovery procedure can be performed by setting the target U2U relay WTRU information to the target WTRU information, thereby performing the multi-hop candidate U2U relay discovery procedure.

[0082] IP address allocation can be based on an allocated IP address range for L3 U2U relays supporting multi-hop relays.

[0083] When a WTRU can be authorized as a relay WTRU and / or support a DHCP server mechanism, the NW can configure an IP address pool to avoid conflicts between relay WTRUs acting as DHCP servers.

[0084] For IP routing between relay WTRUs for multi-hop connectivity, during PC5 connection establishment or during discovery, a relay WTRU can share its IP address range with other relay WTRUs. Additionally or alternatively, to avoid IP address conflict, the NW can additionally assign a DHCP service group ID. The DHCP service group ID can be assigned by the NW to each relay WTRU that is authorized to act as a relay WTRU and / or can work as a DHCP server for coordinating a distributed DHCP server mechanism. Based on geographical size, AMF’s service area, and / or SMF’s per service area size, a relay WTRU can be authorized to act as a U2U relay, configured to act as a DHCP server, assigned an IP address pool, and / or assigned a DHCP service group ID. The IP address pool of a relay WTRU can be unique and / or not overlap with other IP address pools within the DHCP service group ID. For example, when a new relay WTRU is authorized in the area and / or for a DHCP service group, if the new assigned IP address pool of the new relay WTRU can overlap with other authorized relay WTRUs, the new relay WTRU can be assigned an IP address pool of a different DHCP service group ID to avoid the overlap of IP address pools.

[0085] In some examples, when e2e routing via multi-hop relay connection is selected, relays belonging to different DHCP service groups can not be selected together to avoid IP address conflict.

[0086] Figure 2 An example IP address allocation procedure based on configured IP address pools for multi-hop relays is depicted.

[0087] At 202, WTRU1 and / or WTRU2 can be authorized as terminal WTRUs for multi-hop U2U relay service. WTRU1 and / or WTRU2 can be provided parameters for discovering other WTRUs and / or establishing connection with other WTRUs via multi-hop U2U relay service.

[0088] At 204, Relay 1, Relay 2, and / or Relay 3 can be authorized as relay WTRUs for multi-hop U2U relay service. Relay 1, Relay 2, and / or Relay 3 can be provided parameters for discovering other WTRUs and / or relay WTRUs and / or establishing connection with other WTRUs and / or relay WTRUs via multi-hop U2U relay service. The provided parameters can include parameters such as RSC (Relay Service Code(s)), PLMN list, and / or user information ID for the WTRU to apply, which are allowed at multi-hop relay connection.

[0089] When Relay 1, Relay 2, and / or Relay 3 can be authorized as relay WTRUs for the multi-hop U2U relay service, they can be provided with IP address pools that are used when the relay WTRU (e.g., as a DHCP server) allocates IP addresses to terminal WTRUs that have a PC5 connection with the relay WTRU. These provisions can be made to avoid IP address conflicts at the terminal WTRUs in the multi-hop relay connection.

[0090] For example, Relay 1 can receive configuration information that indicates a first IP address pool for allocating IP addresses for connections with Relay 1. The configuration information can also include an indication of a second IP address pool for allocating IP addresses for connections with Relay 2, and so on.

[0091] A DHCP service group ID can be assigned and / or provided by the network to each relay WTRU to indicate the DHCP service group that each relay WTRU belongs to. Each relay WTRU that belongs to the same DHCP service group ID can be assigned a unique IP address pool. The unique IP address pool does not overlap with the IP address pool of another relay WTRU within the DHCP service group ID.

[0092] At 206, when WTRU1 triggers to communicate with WTRU2 via the multi-hop relay service for a certain application service, WTRU1 can perform a multi-hop U2U relay discovery procedure to find an end-to-end route to WTRU2 via the multi-hop relay service.

[0093] At 208, WTRU1 can select an appropriate e2e route (e.g., the selected e2e route can be WTRU1, Relay 1, Relay 2, and / or WTRU2) that includes a multi-hop U2U relay for a new end-to-end connection to WTRU2. For example, the selection can be based on the discovery results (e.g., at block 206), link quality, number of hops of the e2e route, end-to-end latency of the e2e route, and / or consider the DHCP service group ID, and / or the like.

[0094] During the discovery procedure, the relay WTRU DHCP service group ID can be sent to the terminal WTRUs and other relay WTRUs. By comparing the DHCP service group IDs of the relay WTRUs in the e2e route, the likelihood of IP address conflicts can be determined. For e2e route selection, relay WTRUs that belong to the same DHCP service group ID can be selected to avoid IP address conflicts among the terminal WTRUs.

[0095] At 210, based on the selected e2e route (e.g., WTRU1, Relayl, Relay2, and / or WTRU2), WTRU1 can initiate a PC5 connection establishment and / or modification procedure to Relayl for e2e communication with WTRU2 via Relayl. If WTRU1 does not have a PC5 connection with Relayl, WTRU1 can send a direct connection request (DCR) to Relayl including the selected e2e route. If WTRU1 has an existing PC5 connection with Relayl, WTRU1 can send a link modification request to Relayl including, for example, the selected e2e route.

[0096] Thus, in an example, Relayl can receive an end-to-end route establishment request message from the first terminal WTRU. The end-to-end route establishment request message can indicate a second relay WTRU (e.g., Relay2) and a second terminal WTRU (e.g., WTRU2).

[0097] After sending the DCR and / or link modification request (LMR) to Relayl, a security association procedure can be performed between WTRU1 and / or Relayl as needed. After sending the DCR and / or LMR, WTRU1 can receive a DC accept and / or LM accept indication from Relayl for the requested e2e route (e.g., if the PC5 link establishment or modification for the e2e route is accepted). For example, Relayl can send an end-to-end route establishment response message to WTRU1 to establish an end-to-end route between WTRU1 and WTRU2 via Relayl and Relay2.

[0098] At step 212, Relayl can send a DC accept and / or LM accept to WTRU1 (e.g., after receiving a DC accept and / or LM accept for the requested e2e route from Relay2).

[0099] After establishing the PC5 connection with Relayl, WTRU1 can perform an IP address allocation procedure, for example, by obtaining an IP address from Relayl acting as a DHCP server. When an IP address is allocated to WTRU1, the IP address value can be within an IP address pool configured at Relayl (e.g., at block 204). For example, Relayl can allocate a first IP address in a first IP address pool (e.g., configured at Relayl) to WTRU1.

[0100] Relayl can store an association of the user information ID and / or the allocated IP address of WTRU1 for DNS lookup and / or IP traffic routing. Relayl can act as a DNS server for terminal WTRUs and / or relay WTRUs having a PC5 connection with Relayl. For example, Relayl can receive a lookup request from WTRU1.

[0101] At 212, after receiving the DCR and / or LMR for the e2e route from WTRU1, Relay 1 can trigger a new PC5 connection establishment and / or modification of an existing PC5 connection with the entity at the next hop (e.g., Relay 2) in the e2e route. The selected e2e route information can be included in the DCR and / or LMR.

[0102] For example, Relay 1 can send a request message to Relay 2 based on receiving the lookup request from WTRU1. The request message can indicate a request for a second IP address of WTRU2. The second IP address can be allocated from a second IP address pool (e.g., configured at Relay 2) that is different from a first IP address pool (e.g., configured at Relay 1).

[0103] After sending the DCR and / or LMR, Relay 1 can receive a DC accept and / or LM accept for the requested e2e route from Relay 2, e.g., if the PC5 link establishment and / or modification for the e2e route is accepted.

[0104] For example, after receiving the DC accept and / or LM accept for the requested e2e route from WTRU2 at step 214, Relay 2 can send the DC accept and / or LM accept to Relay 1.

[0105] During the PC5 link establishment and / or link modification procedure between Relay 1 and Relay 2, Relay 1 and / or Relay 2 can share the IP address pool and DHCP service group ID assigned for each relay WTRU. Additionally or alternatively, Relay 1 and / or Relay 2 can share other relay WTRUs that Relay 1 and / or Relay 2 have PC5 connection with that are assigned by the IP address pool and / or DHCP service group ID. In these cases, Relay 1 and / or Relay 2 can be aware of the IP address pool of other relay WTRUs and / or whether the other relay WTRUs can have already overlapped with the IP address allocation range. The IP address pool information of other relay WTRUs can be used to forward IP traffic to the correct relay WTRU when IP data is received from an end WTRU for forwarding to other end WTRUs in a multi-hop relay connection.

[0106] Additionally or alternatively, during step 204, Relay 1, Relay 2, and / or Relay 3 can be provided with IP address pools of relay WTRUs. These relay WTRUs can belong to the same DHCP service group ID. Relay 1 and / or Relay 2 can utilize this IP address pool information to forward IP traffic to the correct relay WTRU in a multi-hop relay connection.

[0107] Relay 1 and / or Relay 2 can share the association data of the user information ID and the allocated IP address of the terminal WTRU handled by each relay WTRU. This can be used later for DNS lookup and / or IP traffic routing of IP traffic via the relay WTRU.

[0108] Additionally or alternatively, Relay 1 and / or Relay 2 can share the association of the allocated IP address pool, the DHCP service group ID, the user information ID of each relay WTRU and / or the allocated IP address of the terminal WTRU. This information can be handled by each relay WTRU as a separate procedure at the existing PC5 connection between Relay 1 and / or Relay 2.

[0109] During PC5 connection establishment, Relay 1 and / or Relay 2 can store the ID of WTRU1 and / or the ID of WTRU2 and an indication of whether WTRU1 can attach to Relay 1 and / or whether WTRU2 can attach to Relay 2. Such information can be used later for DNS lookup to retrieve the IP address of the WTRU belonging to the relay WTRU.

[0110] At 214, after receiving the DCR or LMR for the e2e route from Relay 1, Relay 2 can trigger a new PC5 connection establishment or modification of an existing PC5 connection with the entity at the next hop in the e2e route (e.g., WTRU2). In the DCR and / or LMR, the selected e2e route information can be included.

[0111] After sending the DCR and / or LMR, Relay 2 can receive a DC accept and / or LM accept for the requested e2e route from WTRU2. WTRU2 can send the DC accept and / or LM accept to Relay 2 when accepting the requested PC5 link establishment and / or link modification for communicating with WTRU2 via the e2e route.

[0112] After establishing the PC5 connection with Relay 2, WTRU2 can perform an IP address allocation procedure, e.g., by getting an IP address from Relay 2 serving as a DHCP server. When an IP address can be allocated to WTRU2, the IP address value can be within the IP address pool configured at Relay 2 (e.g., during operation 204).

[0113] Relay 2 can store the association of the user information ID and / or the allocated IP address of WTRU2 for DNS lookup and / or IP traffic routing. Relay 2 can act as a DNS server for the terminal WTRU and / or relay WTRU having a PC5 connection with Relay 2.

[0114] At 216, WTRU1 can send a DNS query including the user info ID of WTRU2 to relay 1 after operation 210 to request the IP address of WTRU2.

[0115] At 218, if relay 1 does not have any IP address mapping for the requested WTRU (e.g., WTRU2) based on the user info ID, relay 1 can send a DNS query including the user info ID of WTRU2 as received in operation 216 to other relay WTRUs (e.g., relay 2) that have a PC5 connection with relay 1. When a relay WTRU with an association between the user info ID and / or assigned IP address receives a DNS query for a terminal WTRU, the relay WTRU can respond with the assigned IP address.

[0116] Relay 1 can decide to send the DNS query to relay 2 (e.g., at operation 212) based on the stored mapping between the user info of WTRU2 and / or relay 2.

[0117] Additionally or alternatively, relay 1 and / or relay 2 can share the assigned IP address pool, association of DHCP service group ID, user info ID of each relay WTRU, assigned IP address of terminal WTRUs handled by each relay WTRU at existing PC5 connections between relay 1 and / or relay 2 (e.g., during step 218 and / or another step as a separate procedure).

[0118] At 220, based on the IP address mapping received from other relay WTRUs and / or based on managed information about the IP address mapping to the user info ID requested (e.g., in step 216), relay 1 can respond to the DNS query of WTRU1 for the IP address of WTRU2.

[0119] At 222, based on the received IP address of WTRU2, WTRU1 can exchange IP traffic with WTRU2 via e2e routing. When IP packets are received between WTRU1 to WTRU2, relay 1 and relay 2 can forward the IP packets to relay 2 and / or relay 1 based on the information of IP address pool handled by the relay WTRUs (e.g., the IP address of WTRU1 can be at the IP address pool of relay 1 and / or the IP address of WTRU2 can be at the IP address pool of relay 2).

[0120] The present disclosure also provides an example configuration of dedicated DHCP server information for multi-hop relay connections. As another embodiment, in the case that a WTRU can be authorized as a relay WTRU for multi-hop relay service, the relay WTRU can be provided with a DHCP server address and / or associated relay WTRU information. The associated relay WTRU information can be communicated directly with the DHCP server.

[0121] When a terminal WTRU establishes a PC5 connection with a relay WTRU, the relay WTRU can inform the terminal WTRU of the DHCP server information. And after the PC5 connection is established, the terminal WTRU can exchange messages for the DHCP protocol and / or the relay WTRU forwards the protocol messages from the terminal WTRU to a relay WTRU that can be configured to be associated with the DHCP server.

[0122] Communication between U2U relays can be handled separately from communication between terminal WTRUs and / or U2U relays based on Layer 2 relays and / or Layer 3 relays.

[0123] For e2e routing (e.g., WTRU1, Relay1, Relay2, and WTRU2), WTRU1 can be assigned an IP address from Relay1. WTRU2 can be assigned an IP address from Relay2. WTRU1 and / or WTRU2 can communicate with each other based on the IP address of WTRU1 and / or WTRU2. When receiving an IP packet from WTRU1 to WTRU2, Relay1 can forward the IP packet to Relay2 based on the IP address of WTRU2. However, when Relay1 sends the IP packet to Relay2, the IP packet can be based on the IP address of Relay2, the IP address of Relay1, and / or based on the L2 ID of Relay2 and / or the L2 ID of Relay1.

[0124] For example, once an IP packet needs to be sent from Relay1 and / or Relay2. The packet can be sent based on the Layer 2 ID of Relay1, the L2 ID of the sender, and / or the Layer 2 ID of Relay2 as the receiver, without having the IP address of Relay1 and / or the IP address of Relay2.

[0125] When L2 ID can be used between relay WTRUs for IP packets belonging to WTRUs of the respective relay WTRUs, the relay WTRU can map the IP address of a sender terminal WTRU and / or the IP address of a receiver terminal WTRU to the relay WTRU managing the sender terminal WTRU and / or the relay WTRU handling the receiver terminal WTRU.

[0126] To map IP addresses and / or handle relaying of the IP addresses, the relay WTRUs can share their handled IP address information and / or WTRU lists with other relay WTRUs. The relay WTRUs can update each other when the lists can be updated similarly to step 218.

[0127] Examples described herein include solutions for multi-hop relaying to resolve IP address conflicts. During a discovery procedure or a PC5 connection establishment, each relay can share an IP address allocation range or an IP address allocation service group (e.g., a DHCP service group ID) it belongs to with other relays so that each relay will be able to know whether the IP address allocation range of other relays overlaps with its own IP address allocation range (e.g., based on the DHCP service group ID or based on the shared IP address allocation range).

[0128] After an end-to-end PC5 connection is established, when WTRU1 retrieves the IP address of WTRU2 via relay 1, relay 1 can query the IP address of WTRU2 from another relay (e.g., relay 2).

[0129] If relay WTRU1 knows that relay 2 has an overlapping IP address allocation range and / or belongs to a different DHCP service group ID (e.g., for IP addresses allocated by relay 2), relay 1 can provide a network address translation service (e.g., the service can change the IP address of WTRU2 by relay 2). Relay 1 can provide a network address translation service to the inner IP address of WTRU2 allocated by relay 1 and / or manage the mapping of the IP address of WTRU2 allocated by relay 2 and / or allocated by relay 1 internally (e.g., locally allocated).

[0130] WTRU1 and / or other WTRUs with a PC5 connection to relay 1 can be informed of the locally allocated IP address of WTRU2 when requested.

[0131] When an IP packet with a locally allocated IP address can be received, a relay WTRU can change the locally allocated IP address to a mapped IP address. For example, when an IP packet with a locally allocated IP address of WTRU2 as a destination IP address can be received, relay 1 can change the locally allocated IP address of WTRU2 to the IP address of WTRU2 allocated by relay 2 and / or forward the packet to relay 2.

[0132] Figure 3 An example IP address allocation procedure 300 to resolve IP address conflicts for multi-hop relaying is depicted.

[0133] At 302, WTRU1 and / or WTRU2 can be authorized as end WTRUs for the multi-hop U2U relay service and provided with parameters for discovering other WTRUs and establishing connections with other WTRUs via the multi-hop U2U relay service.

[0134] At 304, Relay 1, Relay 2, and / or Relay 3 can be authorized as relay WTRUs for the multi-hop U2U relay service. Relay 1, Relay 2, and / or Relay 3 can be provided with parameters for discovering other WTRUs and / or relay WTRUs and / or establishing connections with other WTRUs and / or relay WTRUs via the multi-hop U2U relay service. The provided parameters can include parameters such as RSC(s) (Relay Service Code(s)), PLMN list, and / or user info ID for the WTRU of the application, which are allowed at the multi-hop relay connection.

[0135] When Relay 1, Relay 2, and / or Relay 3 can be authorized as relay WTRUs for the multi-hop U2U relay service, they can be provided with an IP address pool. This IP address pool can be used by the relay WTRU (e.g., as a DHCP server) when assigning IP addresses to end WTRUs that have a PC5 connection with the relay WTRU.

[0136] A DHCP service group ID can be assigned and / or provided by the network to each relay WTRU to indicate the DHCP service group that each relay WTRU belongs to. Each relay WTRU that belongs to the same DHCP service group ID can be assigned a unique IP address pool. This unique IP address pool overlaps with the IP address pool of each other relay WTRU within the DHCP service group ID.

[0137] Here, Relay 1 can be assigned to DHCP service group ID_1 and Relay 2 can be assigned to DHCP service group ID_2. These designations indicate that Relay 1 and / or Relay 2 can have overlapping IP address pools.

[0138] At 306, when WTRU1 triggers communication with WTRU2 via the multi-hop relay service for a certain application service, WTRU1 can perform a multi-hop U2U relay discovery procedure to find an end-to-end route to WTRU2 via the multi-hop relay service.

[0139] During the discovery procedure, the DHCP service group ID of the relay WTRU can be known by the end WTRU and / or other relay WTRUs. For example, during the discovery procedure, Relay 1 and / or Relay 2 can know whether they can have overlapping IP address pools and / or whether they belong to different DHCP service groups.

[0140] At 308, WTRU1 can select an appropriate e2e route (e.g., the selected e2e route is WTRU1, Relay1, Relay2, and WTRU2). The route can include a multi-hop U2U relay for a new end-to-end connection to WTRU2, e.g., based on the discovery results at step 306, link quality, number of hops of the e2e route, end-to-end latency of the e2e route, and / or DHCP service group, etc.

[0141] At 310, based on the selected e2e route (e.g., WTRU1, Relay1, Relay2, and / or WTRU2), WTRU1 can initiate a PC5 connection establishment and / or modification procedure to Relay1 for e2e communication with WTRU2 via Relay1. If WTRU1 does not have a PC5 connection with Relay1, WTRU1 can send a DCR to Relay1 including the selected e2e route. If WTRU1 has an existing PC5 connection with Relay1, WTRU1 can send a link modification request to Relay1 including the selected e2e route.

[0142] After sending the DCR and / or LMR to Relay1, a security association procedure can be performed between WTRU1 and / or Relay1 as needed. After sending the DCR and / or LMR, WTRU1 can receive a DC accept and / or LM accept from Relay1 for the requested e2e route (e.g., if the PC5 link establishment or modification for the e2e route is accepted).

[0143] At step 312, Relay1 can send a DC accept and / or LM accept to WTRU1 (e.g., after receiving a DC accept and / or LM accept for the requested e2e route from Relay2).

[0144] After establishing the PC5 connection with Relay1, WTRU1 can perform an IP address allocation procedure, e.g., by getting an IP address from Relay1 serving as a DHCP server. When the IP address is allocated to WTRU1, the IP address value can be within the IP address pool configured at Relay1 during step 304. Relay1 can store an association of the user information ID and / or the allocated IP address of WTRU1 for DNS lookup and / or IP traffic routing usage. Relay1 can act as a DNS server for the end WTRU and / or relay WTRU that has a PC5 connection with Relay1.

[0145] At 312, after receiving the DCR and / or LMR for the e2e route from WTRU1, Relay1 can trigger a new PC5 connection establishment and / or modification of an existing PC5 connection with the entity at the next hop in the e2e route (e.g., Relay2). The selected e2e route information can be included in the DCR and / or LMR.

[0146] After sending the DCR to Relay 2, a security association procedure can be performed between Relay 1 and / or Relay 2 as needed. After sending the DCR and / or LMR, Relay 1 can receive a DC Accept and / or LM Accept from Relay 2 for the requested e2e route, e.g., if the PC5 link establishment and / or modification for the e2e route is accepted.

[0147] For example, at step 314, after receiving the DC Accept and / or LM Accept for the requested e2e route from WTRU2, Relay 2 can send the DC Accept and / or LM Accept to Relay 1. During the PC5 link establishment and / or link modification procedure between Relay 1 and / or Relay 2, Relay 1 and / or Relay 2 can share the assigned IP address pool and DHCP service group ID of each relay WTRU, so that Relay 1 and / or Relay 2 can be aware of the IP address pool of other relay WTRU and / or whether the other relay WTRU can have an overlapping IP address assignment range. For example, during step 312, Relay 1 and Relay 2 can indicate their overlapping IP address pool and / or whether they belong to different DHCP service groups.

[0148] Relay 1 and / or Relay 2 can share the association data of the assigned IP address and / or user information ID of the terminal WTRU handled by each relay WTRU. This can be used later for DNS lookup and / or IP traffic routing of IP traffic via the relay WTRU.

[0149] Additionally or alternatively, Relay 1 and / or Relay 2 can share the assigned IP address pool, the association of DHCP service group ID, user information ID of each relay WTRU, and / or the assigned IP address of the terminal WTRU, which are handled by each relay WTRU as a separate procedure at the existing PC5 connection between Relay 1 and / or Relay 2.

[0150] At 314, after receiving the DCR and / or LMR for the e2e route from Relay 1, Relay 2 can trigger a new PC5 connection establishment and / or modification of an existing PC5 connection with the entity at the next hop in the e2e route, e.g., WTRU2. The selected e2e route information can be included in the DCR and / or LMR.

[0151] After sending the DCR to WTRU2, a security association procedure can be performed between Relay 2 and / or WTRU2 as needed. After sending the DCR and / or LMR, Relay 2 can receive a DC Accept and / or LM Accept from WTRU2 for the requested e2e route. WTRU2 can send the DC Accept and / or LM Accept to Relay 2 when accepting the requested PC5 link establishment and / or link modification for communication with WTRU2 via the e2e route.

[0152] After establishing the PC5 connection with Relay 2, WTRU2 can perform an IP address allocation procedure, e.g., by obtaining an IP address from Relay 2 serving as a DHCP server. When the IP address is allocated to WTRU2, the IP address value can be within an IP address pool configured at Relay 2 during step 304.

[0153] Relay 2 can store an association of the user information ID and / or the allocated IP address of WTRU2 for DNS lookup and / or IP traffic routing. Relay 2 can act as a DNS server for terminal WTRUs and / or relay WTRUs having a PC5 connection with Relay 2.

[0154] At 316, WTRU1 can send a DNS query including the user information ID of WTRU2 to Relay 1 to request the IP address of WTRU2 (e.g., after step 310).

[0155] At 318, if Relay 1 does not have any IP address mapping for the requested WTRU (e.g., WTRU2) based on the user information ID, Relay 1 can send a DNS query including the user information ID of WTRU2 received in step 316 to other relay WTRUs (e.g., Relay 2) having a PC5 connection with Relay 1. When a relay WTRU having an association between the user information ID and the allocated IP address receives the DNS query for a terminal WTRU, the relay WTRU can respond with the allocated IP address.

[0156] Additionally or alternatively, Relay 1 and / or Relay 2 can share an association of allocated IP address pool, DHCP service group ID, user information ID, of each relay WTRU, allocated IP address of terminal WTRUs, handled by each relay WTRU at an existing PC5 connection between Relay 1 and / or Relay 2 during step 318 and / or another step as a separate procedure.

[0157] At 320, based on the IP address mapping received from another relay WTRU and / or based on the managed information about the IP address mapping of the user information ID requested in step 316, relay 1 can know that the IP address of WTRU2 can overlap with the IP address pool configured for relay 1.

[0158] At 322, for the IP address of a terminal WTRU assigned by a relay WTRU that can have a different DHCP service group ID than the assigned ID of relay 1 and / or that has overlapped with the IP address pool of relay 1, relay 1 can provide a network address translation service (e.g., change the IP address of the WTRU. The WTRU can be internal for WTRUs under the management of relay 1 and / or the IP address of the WTRU can be for a WTRU belonging to another relay).

[0159] For example, when relay 1 and / or relay 2 have overlapping IP address pools assigned by the NW, and / or relay 1 receives the IP address of WTRU2 from relay 2 as a response to a DNS query, relay 1 can change the IP address of WTRU2 assigned by relay 2 to an internal IP address of WTRU2 assigned by relay 1. Relay 1 can manage the mapping of the IP address of WTRU2 assigned by relay 2 and the IP address of WTRU2 internally assigned (e.g., locally assigned) by relay 1.

[0160] At 324, when relay 1 detects that the IP address of WTRU1 can overlap with the IP address pool of relay 2 (e.g., the IP address pool to which WTRU2 can attach), relay 1 can require relay 2 to assign a dedicated IP address for WTRU1 for communication with WTRUs attached to relay 2 (e.g., including WTRU2).

[0161] When relay 2 detects that the IP address of WTRU2 can overlap with the IP address pool of relay 1 (e.g., the IP address pool to which WTRU1 can attach), relay 2 can require relay 1 to assign a dedicated IP address for WTRU2 for communication with WTRUs attached to relay 1 (e.g., including WTRU1).

[0162] When a dedicated IP address for WTRU1 can be received from relay 2, relay 1 can store the IP address of WTRU1 assigned by relay 2 and use the IP address for IP address change when WTRU1 communicates with WTRUs attached to relay 2.

[0163] When relay 2 can receive a dedicated IP address for WTRU2 from relay 1, relay 2 can store the IP address assigned by relay 1 and / or use the IP address for IP address change when WTRU2 communicates with WTRUs attached to relay 1.

[0164] When relay 1 requests the dedicated IP address of WTRU 1 at relay 2, relay 1 can share the IP address of WTRU 1 allocated by relay 1. If the IP address allocated to WTRU 1 at relay 1 does not conflict with the IP addresses allocated to other WTRUs, relay 1 can allocate an IP address dedicated to WTRU 1 having the same value as the IP address allocated to WTRU 1 at relay 1.

[0165] When relay 2 requests the dedicated IP address of WTRU 2 at relay 1, relay 2 can share the IP address of WTRU 2 allocated by relay 2. If relay 1 does not conflict with the IP addresses allocated to other WTRUs, relay 1 can allocate an IP address dedicated to WTRU 2 having the same value as the IP address allocated to WTRU 2 at relay 2.

[0166] At 326, relay 1 can respond to the DNS query of WTRU 1 for the IP address of WTRU 2. If there is a locally allocated IP address of WTRU 2 in step 322, the address can be informed as a response to the DNS query of WTRU 1. When relay 1 has a dedicated IP address allocated to WTRU 2, the dedicated IP address can be a response to the DNS query of WTRU 1 for the IP address of WTRU 2.

[0167] At 328, based on the received IP address of WTRU 2, WTRU 1 can exchange IP traffic with WTRU 2 via e2e routing. To forward IP packets for e2e routing, a relay WTRU can act as a NAT server for IP packets destined to a terminal WTRU. The terminal WTRU can have an IP address allocated by the relay WTRU. The relay WTRU can have a different DHCP service group ID than the allocated ID of relay 1 and / or have an overlapping IP address pool of relay 1.

[0168] In an example, if an IP packet has a locally allocated IP address of WTRU 2 as a destination IP, the IP address of WTRU 2 at the IP packet can be changed to the IP address of WTRU 2 and / or the IP packet is forwarded to relay 2 based on the IP address pool information and / or managed mapping information of relay 2.

[0169] In an example, if an IP packet has an IP address of WTRU 2 allocated by relay 2 as a sender IP, the IP address at the IP packet can be changed to a locally allocated IP address of WTRU 2 and / or the IP packet is forwarded to a destination terminal WTRU based on the IP address pool information and / or managed mapping information of relay 2.

[0170] For a WTRU (e.g., WTRU1), relay 1 can change the IP address of WTRU1 to the private IP address assigned by relay 2 when there is a private IP address assigned by another relay (e.g., relay 2). This can occur for IP packets between WTRU1 and / or relay 2 to which WTRU (e.g., WTRU2) is attached.

[0171] As another example, during PC5 connection setup between relay 1 and / or relay 2 for e2e routing between WTRU1 and / or WTRU2, relay 1 and / or relay 2 can be aware of potential IP address conflict. Then, relay 1 and / or relay 2 can assign a private IP address for WTRU1 and / or WTRU2 at relay 1 and / or relay 2. And when requested by another relay, the assigned private IP address can be informed.

[0172] As another example, after relay 1 has the private IP address of WTRU1 assigned by relay 2 of DHCP service group ID 2, the private IP address of WTRU1 can be used for communication with relays to which other WTRUs under the same DHCP service group as relay 2 are attached. For example, when relay 1 receives a DNS query for WTRU1 from a relay (e.g., relay 2 and / or relay 3) of DHCP service group ID 2, relay 1 can respond with the private IP address of WTRU1 assigned by relay 2 as the IP address of WTRU1 for communication with WTRUs under the control of relays of DHCP service group ID 2.

Claims

1. A method performed by a first relay wireless transmit / receive unit (WTRU), the method comprising: Receive configuration information, the configuration information instructing a first Internet Protocol (IP) address pool to allocate IP addresses for connections to the first relay WTRU; The first terminal WTRU receives an end-to-end route establishment request message, wherein the end-to-end route establishment request message indicates the second relay WTRU and the second terminal WTRU; Send an end-to-end route establishment response message to the first terminal WTRU to establish an end-to-end route between the first terminal WTRU and the second terminal WTRU via the first relay WTRU and the second relay WTRU; Assign the first IP address from the first IP address pool to the first terminal WTRU; Receive a search request from the first terminal WTRU; as well as Based on the lookup request received from the first terminal WTRU, a request message is sent to the second relay WTRU, wherein the request message indicates a request for a second IP address of the second terminal WTRU, wherein the second IP address comes from a second IP address pool different from the first IP address pool.

2. The method according to claim 1, wherein, The configuration information includes an indication of the service group identifier (ID) associated with the first relay WTRU and the second relay WTRU.

3. The method according to claim 2, wherein, The first IP address pool is a first subset of the IP addresses associated with the service group ID, and the second IP address pool is a second subset of the IP addresses associated with the service group ID.

4. The method according to any one of claims 1 to 3, further comprising: Receive from the second trunk WTRU an instruction from the second IP address pool to allocate IP addresses for the connection with the second trunk WTRU; as well as Send an instruction to the second trunk WTRU for the first IP address pool to allocate IP addresses for the connection with the first trunk WTRU.

5. The method according to claim 4, further comprising: The second IP address pool is used to forward IP packets received from the first terminal WTRU to the second relay WTRU.

6. The method according to claim 4 or 5, further comprising: The second relay WTRU receives an indication of the second IP address of the second terminal WTRU.

7. The method according to any one of claims 1 to 3, wherein, The configuration information includes an indication of how the second IP address pool is used to allocate IP addresses for connections with the second relay WTRU.

8. The method according to any one of claims 1 to 7, further comprising: Send an instruction for the first IP address pool to the second relay WTRU.

9. The method according to claim 1, further comprising: Receive an indication of the service group identifier (ID) associated with the second trunk WTRU.

10. The method according to claim 9, wherein, The first IP address pool is a first subset of the IP addresses associated with the service group ID, and the second IP address pool is a second subset of the IP addresses associated with the service group ID.

11. A first relay wireless transmit / receive unit (WTRU), comprising: The processor is configured as follows: Receive configuration information, the configuration information instructing a first Internet Protocol (IP) address pool to allocate IP addresses for connections to the first relay WTRU; The first terminal WTRU receives an end-to-end route establishment request message, wherein the end-to-end route establishment request message indicates the second relay WTRU and the second terminal WTRU; Send an end-to-end route establishment response message to the first terminal WTRU to establish an end-to-end route between the first terminal WTRU and the second terminal WTRU via the first relay WTRU and the second relay WTRU; Assign the first IP address from the first IP address pool to the first terminal WTRU; Receive a search request from the first terminal WTRU; as well as Based on the lookup request received from the first terminal WTRU, a request message is sent to the second relay WTRU, wherein the request message indicates a request for a second IP address of the second terminal WTRU, wherein the second IP address comes from a second IP address pool different from the first IP address pool.

12. The first relay WTRU according to claim 11, wherein, The configuration information includes an indication of the service group identifier (ID) associated with the first relay WTRU and the second relay WTRU.

13. The first relay WTRU according to claim 12, wherein, The first IP address pool is a first subset of the IP addresses associated with the service group ID, and the second IP address pool is a second subset of the IP addresses associated with the service group ID.

14. The first relay WTRU according to any one of claims 11 to 13, wherein, The processor is also configured to: Receive from the second trunk WTRU an instruction from the second IP address pool to allocate IP addresses for the connection with the second trunk WTRU.

15. The first relay WTRU according to claim 14, wherein, The processor is also configured to: The second IP address pool is used to forward IP packets received from the first terminal WTRU to the second relay WTRU.

16. The first relay WTRU according to claim 14 or 15, wherein, The processor is also configured to: The second relay WTRU receives an indication of the second IP address of the second terminal WTRU.

17. The first relay WTRU according to any one of claims 11 to 13, wherein, The configuration information includes an indication of how the second IP address pool is used to allocate IP addresses for connections with the second relay WTRU.

18. The first relay WTRU according to claims 11 to 17, wherein, The processor is also configured to send an indication of the first IP address pool to the second relay WTRU.

19. The first relay WTRU according to claim 11, wherein, The processor is also configured to: Receive an indication of the service group identifier (ID) associated with the second trunk WTRU from the second trunk WTRU.

20. The first relay WTRU according to claim 1, wherein, The first IP address pool is a first subset of the IP addresses associated with the service group ID, and the second IP address pool is a second subset of the IP addresses associated with the service group ID.

Images