WO2025072890A1 - Methods for ip address assignment handling for multihop u2u relay connection - Google Patents

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 assigning IP addresses for connection to the first relay WTRU. The first relay WTRU may receive an end-to-end route setup request message from a first end WTRU. The end-to-end route setup request message indicates a second relay WTRU and a second end WTRU. The first relay WTRU may send an end-to-end route setup response message to setup an end-to-end route between the first end WTRU and the second end WTRU via the first relay WTRU and the second relay WTRU. The first relay WTRU may assign a first IP address in the first IP address pool to the first end WTRU. The first relay WTRU may send a request message that indicates a request for a second IP address of the second end WTRU.

Description

METHODS FOR IP ADDRESS ASSIGNMENT HANDLING FOR MULTIHOP U2U RELAY CONNECTION

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001]This application claims priority to U.S. Provisional Application No. 63/586,102, filed September 28, 2023, and U.S. Provisional Application No. 63/586,104, filed September 28, 2023, the entirety of each of which is incorporated herein by reference.

BACKGROUND

[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 End WTRUs. For U2U Relay, 5G ProSe U2U Relay Discovery, and/or 5G ProSe Communication via U2U Relay may be defined. For 5G ProSe U2U Relay Discovery, both Model A and/or Model B discovery may be supported. Model A may use a single discovery protocol message (e.g., announcement), and Model B may use two discovery protocol messages (e.g., solicitation and/or response).

[0003] Discovery integrated into PC5 unicast link establishment procedure may also be supported. 5G ProSe Communication via U2U Relay may be possible with Layer2 U2U Relay and/or Layer3 U2U Relay. For Layer2 U2U Relay and/or Layer3 U2U Relay, 5G ProSe communication setup with discovery procedures and/or discovery integrated into PC5 unicast link establishment procedure may be defined.

[0004] With Layer2 U2U Relay, an end-to-end PC5 link may be established between the End UEs, via the Relay. A UE, or user equipment, may also be referred to herein as a wireless transmit/receive unit (WTRU). PC5-S messages may then be exchanged between End WTRUs.

[0005] With Layer3 U2U Relay, each End WTRU may establish a PC5 link with the Relay. The Relay may forward messages towards End WTRUs. PC5-S messages may be exchanged between End WTRUs and/or the Relay.

[0006] With Layer3 U2U Relay, when the IP based data connection is used, after PC5 link setup with Relay, each End WTRU may be assigned an IP address by the Relay. This may be further based on dynamic host configuration protocol (DHCP) mechanism and/or each End WTRU may assign its own IP address and/or inform the Relay. The Relay may be based on a link local IP address assignment mechanism. Whether the DHCP and/or link local IP address assignment will be determined during security connection setup between End WTRU and/or U2U Relay.

[0007] After connection setup between two End WTRUs via a U2U Relay, each End WTRU may keep monitoring the channel status of the PC5 link. When link quality goes below some threshold, the End WTRU may reselect U2U Relay for the connection between two End WTRUs. For U2U Relay reselection, U2U Relay discovery procedures may be used and/or the negotiated 5G ProSe U2U Relay reselection procedure may be used. In the negotiated U2U Relay reselection, one End WTRU initiates the U2U Relay reselection procedure, End WTRUs can negotiate a new U2U Relay using the existing connection and to establish the communication via the reselected U2U Relay prior to releasing the communication via the current 5G ProSe U2U Relay.

SUMMARY

[0008] One example solution described herein may comprise internet protocol (IP) address assignment handling for a multihop U2U connection. In a U2U relay, the relay WTRU may be authorized as U2U relay supporting multihop relay and/or configured parameters for serving relay WTRU. This may include an IP address pool for assigning IP address which has PC5 connection to relay WTRU and assigned DHCP service group ID.

[0009] In an example, a relay WTRU may establish PC5 connection with an End WTRU for an end-to-end (e2e) route, assign an IP address to the End WTRU which may be under the IP address pool assigned, and/or establish PC5 connection with other relay WTRU for a e2e route and/or relay WTRU share its assigned IP address pool information and DHCP service group ID. [0010] In examples, a dynamic host conversion protocol (DHCP) service group ID may be defined to guarantee the uniqueness of assigned IP address by relay WTRUs belonging to the same DHCP service group. By comparing DHCP service group ID of relay WTRUs in an e2e route, a possibility of IP address confliction may be determined. In order to avoid potential conflicts of assigned IP address, relays belonging to different DHCP service group may not be selected together for a e2e route.

[0011] In examples, when receiving DNS query for an End WTRU, the relay WTRU may request a domain name system (DNS) query to other relay WTRU(s) and/or receive IP address information of a End WTRU from another relay WTRU. When receiving an IP packet over the established PC5 connection, based on the saved IP address pool information, the relay WTRU may select a proper relay WTRU and/or forward the IP packet to the selected relay WTRU. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0013] FIG. 1 B is a system diagram illustrating an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0014] FIG. 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0015] FIG. 1 D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0016] FIG. 2 depicts an example IP address assignment procedure based on configured IP address pool for multihop relay.

[0017] FIG. 3 depicts an example IP address assignment procedure with resolution of IP address confliction for multihop relay.

DETAILED DESCRIPTION

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

[0019] As shown in FIG. 1A, the communications system 100 may 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, though 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 may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and/or a “STA”, may be configured to transmit and/or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a WTRU.

[0020] The communications systems 100 may also include a base station 114a and/or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106/115, the Internet 110, and/or the other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a gNB, a NR NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

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

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

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

[0024] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and/or 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 may implement a radio technology such as NR Radio Access , which may establish the air interface 116 using New Radio (NR).

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

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

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

[0029] The RAN 104/113 may be in communication with the CN 106/115, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have 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 may 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. 1A, it will be appreciated that the RAN 104/113 and/or the CN 106/115 may 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 may be utilizing a NR radio technology, the CN 106/115 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

[0032] FIG. 1 B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1 B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/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 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0033] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may 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 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. 1 B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0034] The transmit/receive element 122 may 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 may be an antenna configured to transmit and/or receive RF signals. In an embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and/or receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals. [0035] Although the transmit/receive element 122 is depicted in FIG. 1B as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0036] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may 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 may be coupled to, and may 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 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may 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 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

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

[0040] The processor 118 may further be coupled to other peripherals 138, which may 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 may 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 Augmented Reality (VR/AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors, the sensors may 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 may include a full duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for both the UL (e.g., for transmission) and downlink (e.g., for reception) may be concurrent and/or simultaneous. The full duplex radio may include an interference management unit 139 to reduce and or substantially eliminate self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, the WRTU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e.g., for transmission) or the downlink (e.g., for reception)).

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

[0043] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may 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 may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, and the like. As shown in FIG. 1C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0045] The CN 106 shown in FIG. 1C may 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 may be owned and/or operated by an entity other than the CN operator. [0046] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and/or WCDMA.

[0047] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring 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 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. [0049] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit- switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers. [0050] Although the WTRU is described in FIGS. 1A-1D as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (e.g., temporarily or permanently) wired communication interfaces with the communication network. [0051] In representative embodiments, the other network 112 may be a WLAN.

[0052] A WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have 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 may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. The traffic between STAs within a BSS may be considered and/or referred to as peer-to-peer traffic. The peer-to-peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802.11e DLS or an 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an “ad-hoc” mode of communication. [0053] When using the 802.11 ac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width via signaling. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) may be implemented, for example in in 802.11 systems. For CSMA/CA, the STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed/detected and/or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

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

[0056] Sub 1 GHz modes of operation are supported by 802.11 af and 802.11 ah. The channel operating bandwidths, and carriers, are reduced in 802.11af and 802.11 ah relative to those used in 802.11 n, and 802.11ac. 802.11af supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV White Space (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 Meter Type Control/Machine-Type Communications, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and/or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0057] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11 n, 802.11ac, 802.11af, and 802.11 ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and/or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and/or other channel bandwidth operating modes. Carrier sensing and/or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available. [0058] In the United States, the available frequency bands, which may be used by 802.11 ah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11 ah is 6 MHz to 26 MHz depending on the country code. [0059] FIG. 1 D is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As noted above, the RAN 113 may employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

[0060] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment.

The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 108b may utilize beamforming to transmit signals to and/or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, may 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 may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum while the remaining component carriers may be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and/or gNB 180c).

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

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

[0063] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, support 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 in FIG. 1 D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0064] The CN 115 shown in FIG. 1D may 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 each of the foregoing elements are depicted as part of the CN 115, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.

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

[0066] The SMF 183a, 183b may be connected to an AMF 182a, 182b in the ON 115 via an N11 interface. The SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 115 via an N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b may 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. A PDU session type may be IP-based, non-IP based, Ethernet-based, and the like.

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

[0068] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include, or may 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. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may 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 may be connected to a local Data Network (DN) 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0069] In view of Figures 1A-1 D, and the corresponding description of Figures 1A-1D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-ab, UPF 184a-b, SMF 183a-b, DN 185a-b, and/or any other device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and/or to simulate network and/or WTRU functions.

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

[0071]The one or more emulation devices may perform the one or more, including all, functions while not being implemented/deployed as part of a wired and/or wireless communication network. For example, the emulation devices may be utilized in a testing scenario in a testing laboratory and/or a non-deployed (e.g., testing) wired and/or wireless communication network in order to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and/or wireless communications via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and/or receive data.

[0072] Within examples, the present disclosure provides potential enhancements to support multihop for U2N, and/or U2U Relay. Multihop for U2N Relay may enable a remote WTRU to discover and/or communicate with a U2N Relay via one or more U2U relays. Multihop U2U Relay may enable End WTRUs to discover and communicate with each via more than one U2U Relay. The multihop capability may be deemed crucial for mission critical communications (e.g., first responders) and/or in general as needed to enhance coverage (e.g., indoors).

[0073] For IP address assignment for multihop, when a U2U Relay assigns an IP address, the IP address may be used for communication with other WTRUs via the same U2U Relay. An existing PC5 link with the U2U relay may be shared for communication with other End WTRUs. For multihop relay, link sharing may be supported for providing backward compatibility and/or same IP address may be used for the shared link.

[0074] For IP based co-communication, each End WTRU may retrieve an IP address of another END WTRU. In single-hop relay case, the relay WTRU may work as a DHCP server and/or provide IP address resolution service. For multihop relay, each End WTRU may be served by different relay WTRU and/or the IP address of each End WTRU may be assigned by different relay WTRU.

[0075] For multihop relay connection, the IP address of another End WTRU at the other relay WTRU may be gathered. When considering link sharing, existing IP addresses assigned by the relay WTRU may be reused for new connection for multihop connection. IP addresses of End WTRUs assigned from different relays working as DHCP servers may conflict because there is no coordination among the relays about IP address assignment. When those WTRUs try to communicate with each other through the relays, IP addresses of WTRUs may conflict with each other and/or data traffic forwarding based on IP address will not work properly. For multihop relay connection, IP address assignment may be handled without IP address confliction.

[0076] For supporting multihop relay with resolution of IP address confliction, in some cases, End WTRUs may need to connect each other via multihop relay even though the End WTRUs may have assigned IP address conflicts to others. This may happen when considering multihop relay with many hop counts allowed. Based on mobility, the WTRU may move to some area which is a boundary of IP Address assignment service area for unique IP address assignment. [0077] In the present disclosure, a U2U Relay WTRU (e.g., U2U Relay WTRU, U2U Relay, and/or U2U Relay) may mean a WTRU authorized to perform as a relay WTRU that forwards traffic between WTRUs.

[0078] The U2U Relay discovery procedure (e.g., U2U Relay discovery procedure) is to discover a path to a target WTRU via a relay WTRU. By U2U Relay discovery procedure, initiating WTRU may get information of U2U Relay(s) which may be reachable to the target WTRU. Initiating the WTRU may select a proper end-to-end route to the target WTRU via a Relay WTRU. For multihop supports, in the discovery response, the U2U Relay may inform whether the U2U Relay supports multihop relay or not.

[0079] In some examples, multihop U2U Relay discovery procedure and/or multihop candidate U2U Relay discovery procedure may be performed by an End WTRU.

[0080] Multihop U2U Relay discovery procedure may involve discovering an end-to-end path for a target WTRU to communicate via a path that includes a single and/or multiple relay WTRUs. Through a multihop U2U relay discovery procedure for a target WTRU, for example, an initiating WTRU may get information from U2U Relay WTRU(s) about the path(s) to the target WTRU involving the U2U relay WTRU(s) and/or other U2U relay WTRUs in the path between U2U Relay WTRU(s) and/or the target WTRU. After multihop U2U Relay discovery procedure for a target WTRU is performed, the initiating WTRU may select a proper end-to-end route between initiating WTRU and the target WTRU including multihop relay WTRUs.

[0081] Multihop candidate U2U Relay discovery procedure is to discover an end-to-end path for a target U2U Relay via path through single and/or multihop relay WTRUs. Multihop candidate U2U Relay discovery procedure can be performed by performing multihop the U2U Relay discovery procedure by setting target U2U relay WTRU information as target WTRU information.

[0082] IP address assignment may be based on configured IP address range for assignment for L3 U2U relay supporting multihop relay.

[0083] When a WTRU may be authorized as a relay WTRU and/or a supporting DHCP server mechanism, the NW may configure the IP address pool to avoid collision between relay WTRUs which behave as DHCP servers.

[0084] For IP routing between relay WTRUs for multihop connection, during PC5 connection setup or during discovery, relay WTRUs may share their range of IP addresses with other relay WTRUs. Additionally or alternatively, to avoid IP address conflicts, a DHCP service group ID may be additionally assigned by the NW. DHCP service group ID may be assigned by the NW to each relay WTRU which is authorized as a relay WTRU and/or may work as a DHCP server for a coordinated distributed DHCP server mechanism. Based on geographical size, service area of AMF, and/or per service area size of SMF, a relay WTRU may be authorized as a U2U relay, configured 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 may be unique and/or does not overlap with other IP address pools within the DHCP service group ID. When new relay WTRUs are authorized in the area and/or for a DHCP service group for example, if a newly assigned IP address pool of a new relay WTRU may overlap other authorized relay WTRUs, the new relay WTRU may be assigned an IP address pool of different DHCP service group IDs in order to avoid overlap of IP address pools.

[0085] In some examples, when an e2e route via multihop relay connection is selected, relays belonging to different DHCP service group may not be selected together to avoid IP address conflict.

[0086] FIG. 2 depicts an example IP address assignment procedure based on configured IP address pool for multihop relay.

[0087] At 202, WTRU1 and/or WTRU2 may be authorized for multihop U2U Relay service as End WTRU. WTRU1 and/or WTRU2 may be provisioned with parameters for discovery and/or connection setup with other WTRUs via multihop U2U Relay services.

[0088] At 204, Relayl , Relay2, and/or Relay3 may be authorized for multihop U2U Relay service as Relay WTRUs. Relayl , Relay2, and/or Relay3 may be provisioned with parameters for discovery and/or connection setup with other WTRUs and/or relay WTRUs via multihop U2U Relay services. The provisioned parameters may include parameters such as RSC (Relay service Code(s)), list of PLMN, and/or User Info ID of WTRU for application, which are allowed at multihop relay connection.

[0089] When Relayl , Relay2, and/or Relay3 may be authorized for multihop U2U Relay service as Relay WTRUs, they may be provisioned with an IP address pool used when relay WTRUs (e.g., as DHCP servers) assign IP addresses to the End WTRUs which have PC5 connection with relay WTRUs. These provisions may be made to avoid the conflict of IP address at End WTRUs in multihop relay connection.

[0090] For example, Relayl may receive configuration information indicating a first IP address pool for assigning IP addresses for connection to Relayl. The configuration information may also include an indication of a second IP address pool for assigning IP addresses for connection to Relay2, and so on.

[0091] A DHCP service group ID may be assigned and/or provisioned to each relay WTRU by network to indicate DHCP service group to which each relay WTRU belongs. Each relay WTRU belonging to the same DHCP service group ID may be assigned a unique IP address pool. The unique IP address pool does NOT overlap to another’s IP address pool within the DHCP service group ID.

[0092] At 206, when WTRU1 triggers to make communication with WTRU2 via multihop relay service for some application service, WTRU1 may perform multihop U2U relay discovery procedure to find end-to-end route to WTRU2 via multihop relay service.

[0093] At 208, WTRU1 may select a proper e2e route (e.g., selected e2e route may be WTRU1 , Relayl , Relay2, and/or WTRU2) including multihop U2U relays for new end-to-end connection to WTRU2. For example, the selection may be based on the discovery result (e.g., at block 206), the link quality, number of hop of e2e routes, end-to-end delay of e2e routes, and/or considering DHCP service group ID, etc.

[0094] During the discovery procedure, the relay WTRUs DHCP service group ID may be sent to End WTRUs and other relay WTRUs. By comparing DHCP service group ID of relay WTRUs in an e2e route, a possibility of IP address confliction may be determined. For an e2e route selection, relay WTRUs belonging to the same DHCP service group ID may be selected in order to avoid IP address conflict between End WTRUs.

[0095] At 210, based on selected e2e route (e.g., WTRU1, Relayl , Relay2, and/or WTRU2), WTRU1 may initiate PC5 connection setup and/or modification procedure to Relayl for e2e communication with WTRU2 via Relayl . WTRU1 may send direct connection request (DCR) including selected e2e route to Relayl if WTRU1 has no PC5 connection with Relay! WTRU1 may send a link modification request, including, e.g., a selected e2e route, to Relayl if WTRU1 has an existing PC5 connection with Relayl .

[0096] Accordingly, in an example, Relayl may receive an end-to-end route setup request message from a first end WTRU. The end-to-end route setup request message may indicate a second relay WTRU (e.g., Relay2) and a second end WTRU (e.g., WTRU2).

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

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

[0099] After the PC5 connection setup with Relayl , WTRU1 may perform IP address assignment procedure, e.g., by getting an IP address from Relayl which works as a DHCP server. When an IP address is assigned to WTRU1, the IP address value may be within the IP address pool configured at Relayl (e.g., at block 204). For example, Relayl may assign a first IP address in the first IP address pool (e.g., configured at Relayl) to WTRU1.

[0100] Relayl may store an association of User Info ID and/or assigned IP addresses of WTRU1 for DNS lookup and/or IP traffic routing. Relayl may act as a DNS server to End WTRUs and/or Relay WTRUs having PC5 connection with Relayl . For example, Relayl may receive a lookup request from WTRU1.

[0101] At 212, after receiving DCR and/or LMR for a e2e route from WTRU1 , Relayl may trigger to new PC5 connection setup and/or modification of existing PC5 connection with an entity at next hop in the e2e route (e.g., Relay2). In DCR and/or LMR, selected e2e route information may be included.

[0102] For example, Relayl may sending a request message to Relay2 based on receipt of the lookup request from WTRU1 . The request message may indicate a request for a second IP address of WTRU2. The second IP address may be assigned from a second IP address pool (e.g., configured at Relay2) different than the first IP address pool (e.g., configured at Relayl). [0103] After sending DCR and/or LMR, Relayl may receive DC Accept and/or LM Accept for the requested e2e route from Relay2, e.g., if PC5 link setup and/or modification for the e2e route is accepted. [0104] Relay2 may send DC Accept and/or LM Accept to Relayl , e.g., after receiving DC Accept and/or LM Accept for the requested e2e route from WTRU2 at Step 214.

[0105] During PC5 link setup and/or link modification procedure between Relayl and Relay2, Relayl and/or Relay2 may share each relay WTRUs assigned IP address pool and DHCP service group ID. Additionally or alternatively, Relay 1 and/or Relay2 may share other relay WTRUs assigned by the IP address pool and/or DHCP service group ID which Relayl and/or Relay 2 have a PC5 connection. In these instances, Relayl and/or Relay2 may be aware of other relay WTRUs’ IP address pools and/or whether other Relay WTRUs may have overlapped the IP address assignment range. Other Relay WTRU’s IP address pool information may be used for IP traffic forwarding to correct relay WTRU when receiving IP data from End WTRU to forward other End WTRU in multihop relay connection.

[0106] Additionally or alternatively, during step 204, Relay 1, Relay2 and/or Relay3 may be provisioned with an IP address pool of relay WTRUs. These relay WTRUs may belong to the same DHCP service group ID. Relayl and/or Relay 2 may utilize this IP address pool information for IP traffic forwarding to the correct relay WTRU in a multihop relay connection. [0107] Relayl and/or Relay2 may share the data of association of user info ID and assigned IP addresses of End WTRUs handled by each relay WTRU. This may be used later for DNS lookup and/or IP traffic routing for IP traffic via relay WTRUs.

[0108] Additionally or alternatively, Relayl and/or Relay2 may share each Relay WTRU’s assigned IP address pool, DHCP service group ID, association of user info ID, and/or assigned IP address of End WTRUs. This information may be handled by each Relay WTRU at existing PC5 connection between Relayl and/or Relay2 as a separate procedure.

[0109] During PC5 connection setup, Relayl and/or Relay2 may store WTRUTs ID and/or WTRU2’s ID, as well as an indication of whether WTRU1 may be attached to Relayl and/or whether WTRU2 may be attached to Relay2. Such information may be used later for DNS lookup to retrieve IP address of the WTRU belonging to a relay WTRU.

[0110] At 214, after receiving DCR or LMR for an e2e route from Relayl , Relay2 may trigger to new PC5 connection setup or modification of existing PC5 connection with entity at next hop in the e2e route (e.g., WTRU2). In DCR and/or LMR, selected e2e route information may be included.

[0111] After sending DCR and/or LMR, Relay2 may receive DC Accept and/or LM Accept for the requested e2e route from WTRU2. WTRU2 may send DC Accept and/or LM Accept to Relay2 when accepting the requested PC5 link setup and/or link modification for communication to WTRU2 via e2e route. [0112] After PC5 connection setup with Relay2, WTRU2 may perform IP address assignment procedure for example by getting IP address from Relay2 which works as a DHCP server. When an IP address may be assigned to WTRU2, the IP address value may be within the IP address pool configured at Relay2 (e.g., during operation 204).

[0113] Relay2 may store an association of User Info ID and/or assigned IP address of WTRU2 for use DNS lookup and/or IP traffic routing. Relay2 may act as a DNS server to End WTRUs and/or Relay WTRUs having PC5 connection with Relay2.

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

[0115] At 218, if Relayl does not have any IP address mapping for the requested WTRU (e.g., WTRU2) based on user info ID, Relayl may send DNS query including user info ID of WTRU2 as received in operation 216 to the other relay WTRUs having PC5 connection with Relayl (e.g., Relay2). When receiving DNS query for an End WTRU which relay WTRU has an association between user info ID and/or assigned IP address, the Relay WTRU may respond with the assigned IP address.

[0116] Relayl may decide to send DNS query to Relay2 based on the mapping between user info of WTRU2 and/or Relay2 as stored (e.g., at operation 212).

[0117] Additionally or alternatively, Relayl and/or Relay2 may share each Relay WTRU’s assigned IP address pool, DHCP service group ID, association of user info ID, assigned IP address of End WTRUs handled by each relay WTRU at existing PC5 connection between Relayl and/or Relay2 (e.g., during step 218 and/or another step as a separate procedure).

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

[0119] At 222, based on received IP address of WTRU2, WTRU1 may exchange IP traffic with WTRU2 via e2e route. When receiving IP packet between WTRU1 to WTRU2, Relayl and Relay2 may forward IP packet to Relay2 and/or Relayl based on information of IP address pool handled by the Relay WTRU (e.g., the IP address of WTRUI may be at the IP address pool of Relayl and/or the IP address of WTRU2 may be at IP address pool of Relay2).

[0120] The present disclosure further provides example configurations of dedicated DHCP server information for multihop relay connection. As another embodiment, where a WTRU may be authorized as a Relay WTRU for multihop relay service, the Relay WTRU may be provisioned with a DHCP server address and/or associated relay WTRU information. The associated relay WTRU information may direct communicate with DHCP server. [0121] When an End WTRU setup PC5 connection with Relay WTRU, Relay WTRU may inform the DHCP server information to the End WTRU. And after a PC5 connection setup, the End WTRU may exchange messages for DHCP protocol and/or relay WTRU forwards this protocol message from End WTRU to a relay WTRU which may be configured to be associated to the DHCP server.

[0122] Separately from the communication between an End WTRU and/or a U2U relay based on Layer 2 relay and/or based on Layer 3 relay, communication between U2U relay may be handled separately.

[0123] For the e2e route (e.g., WTRU1 , Realyl , Relay2, and WTRU2), the WTRU1 may be assigned an IP address from Relay 1. The WTRU2 may be assigned IP address from Relay2. WTRU1 and/or WTRU2 may communicate with each other based on IP address of WTRU1 and/or WTRU2. When receiving an IP packet from WTRU1 toward WTRU2, based on WTRU2’s IP address, Relayl may forward the IP packet to Relay2. But, when Relayl sends the IP packet to Relay2, the IP packet may be based on the IP address of Relay2, the IP address of Relayl , and/or based on the L2 ID of Relay2 and/or the L2 ID of Relayl .

[0124] For example, once an IP packet needs to be sent from Relayl and/or Relay2. The packet may be sent based on the Layer 2 ID of Relayl , sender’s L2 ID, and/or Layer 2 ID of Relay2 as receiver’s L2 ID without having an IP address of Relayl and/or IP address of Relay2. [0125] When L2 ID may be used between relay WTRUs for IP packet of WTRUs belonging to relay WTRUs, the relay WTRU may map an IP address of the sender End WTRU and/or IP address of receiver End WTRU to a relay WTRU admin sender End WTRU and/or a relay the WTRU handling receiver End WTRU.

[0126] In order to map an IP address and/or relay WTRU handling the IP address, the relay WTRU may share their handled IP address information and/or list of WTRUs with other relay WTRUs. The relay WTRUs may update each other when the list may be updated similarly to Step 218.

[0127] Examples described herein include solutions for multihop relay with resolution of IP address confliction. During discovery procedure or PC5 connection setup, relays may share IP address assignment range or its belonged IP address assignment service group e.g., DHCP service group ID with other relays so that relays will be able to aware whether the IP address assignment range of other relay is overlapped (e.g. based on DHCP service group ID or based on shared IP address assignment range.) with its own IP address assignment range. [0128] After end-to-end PC5 connection setup, when WTRU1 retrieves the IP address of WTRU2 via Relayl , Relayl may query IP address of WTRU2 from the other relay (e.g., Relay2).

[0129] If Relay WTRU1 is aware Relay2 has overlapped IP address assignment range and/or belongs to a different DHCP service group ID (e.g., for an IP address assigned by Relay2), Relayl may provide Network Address transition service, (e.g., which may change IP address of WTRU2 by Relay2). Relayl may provide Network Address transition service to the internal IP address of WTRU2 assigned by Relayl and/or manage the mapping of IP address of WTRU2 assigned by Relay2 and/or internally assigned (e.g., locally assigned) by Relayl.

[0130] Locally assigned IP addresses of WTRU2 may be informed to WTRU1 and/or other WTRUs having PC5 connection to Relayl when requested.

[0131] When IP packets may be received with a locally assigned IP address, the Relay WTRU may change the locally assigned IP address to the mapped IP address. For example, when the IP packet may be received with a locally assigned IP address of WTRU2 as a destination IP address, Relayl may change the locally assigned IP address of WTRU2 into the IP address of WTRU2 assigned by Relay2 and/or forward the packet to the Relay2.

[0132] FIG. 3 depicts an example IP address assignment procedure 300 with resolution of IP address confliction for multihop relay.

[0133] At 302, WTRU1 and/or WTRU2 may be authorized for multihop U2U Relay service as End WTRU and are provisioned with parameters for discovery and connection setup with other WTRUs via multihop U2U Relay services.

[0134] At 304, Relayl , Relay2, and/or Relay3 may be authorized for multihop U2U Relay service as Relay WTRU. Relayl, Relay2, and/or Relay3 may be provisioned with parameters for discovery and/or connection setup with other WTRUs and/or relay WTRUs via multihop U2U Relay services. The provisioned parameter may include parameters such as RSC (Relay service Code(s)), list of PLMN, and/or User Info ID of WTRU for application, which is allowed at the multihop relay connection.

[0135] When Relayl , Relay2, and/or Relay3 may be authorized for multihop U2U Relay service as Relay WTRU, they may be provisioned with and IP address pool. The IP address pool may be used when relay WTRUs, (e.g., as DHCP servers) assign IP addresses to the End WTRUs which may have PC5 connection with relay WTRUs.

[0136] A DHCP service group ID may be assigned and/or provisioned to each Relay WTRU by the network to indicate DHCP service group which each relay WTRU belongs. Each Relay WTRU belonging to the same DHCP service group ID may be assigned with a unique IP address pool which overlaps to each other’s IP address pool within the DHCP service group ID. [0137] Here, Relay 1 may be assigned to a DHCP service group I D_1 and Relay2 may be assigned to a DHCP service group I D_2. These designation indicate that Relay 1 and/or Relay2 may have overlapped IP address pool.

[0138] At 306, when WTRU1 triggers communication with WTRU2 via multihop relay service for some application service, WTRU1 may perform multihop U2U relay discovery procedure to find end-to-end route to WTRU2 via multihop relay service.

[0139] During discovery procedure, relay WTRU’s DHCP service group ID may be known to End WTRUs and/or other Relay WTRUs. For example, during the discovery procedure, Relayl and/or Relay2 may be aware whether they may have overlapped IP address pool and/or whether they belong to different DHCP service groups.

[0140] At 308, WTRU1 may select a proper e2e route (e.g., selected e2e route is WTRU1 , Relayl , Relay2, and WTRU2). Routes may include multihop U2U relays for new end-to-end connection to WTRU2, e.g., based on discovery result at step 306, link quality, number of hop of e2e route, end-to-end delay of e2e route, and/or DHCP service group, etc.

[0141] At 310, based on selected e2e route (e.g., WTRU1, Relayl , Relay2, and/or WTRU2), WTRU1 may initiate PC5 connection setup and/or modification procedure to Relayl for e2e communication with WTRU2 via Relayl . The WTRU1 may send DCR including selected e2e route to Relayl if WTRU 1 has no PC5 connection with Relayl . The WTRU1 may send a link modification request including selected e2e route to Relayl if WTRU1 has an existing PC5 connection with Relayl .

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

[0143] Relayl may send DC Accept and/or LM Accept to WTRU1 , e.g., after receiving DC Accept and/or LM Accept for the requested e2e route from Relay2 at Step 312.

[0144] After PC5 connection setup with Relayl , WTRU1 may perform IP address assignment procedure for example by getting IP address from Relayl which works as DHCP server. When an IP address is assigned to WTRU1 , the IP address value may be within the IP address pool configured at Relayl during Step 304. Relayl may store an association of User Info ID and/or assigned IP address of WTRU1 for use in DNS lookup and/or IP traffic routing. Relayl may act as a DNS server to End WTRUs and/or Relay WTRUs having PC5 connection with Relayl . [0145] At 312, after receiving DCR and/or LMR for a e2e route from WTRU1 , Relayl may trigger to new PC5 connection setup and/or modification of existing PC5 connection with entity at next hop in the e2e route (e.g., Relay2). In DCR and/or LMR, selected e2e route information may be included.

[0146] After sending DCR to Relay2, security association procedure may be performed between Relayl and/or Relay2 if needed. After sending DCR and/or LMR, Relayl may receive DC Accept and/or LM Accept for the requested e2e route from Relay2, e.g., if PC5 link setup and/or modification for the e2e route is accepted.

[0147] Relay2 may send DC Accept and/or LM Accept to Relayl for example after receiving DC Accept and/or LM Accept for the requested e2e route from WTRU2 at Step 314. During PC5 link setup and/or link modification procedure between Relayl and/or Relay2, Relayl and/or Relay2 may share each Relay WTRU’s assigned IP address pool and DHCP service group ID so that Relayl and/or Relay2 may be aware of other relay WTRU’s IP address pool and/or whether other relay WTRUs may have overlapped IP addresses’ assignment range. For example, during Step 312, Relayl and Relay2 may indicate that they overlapped IP address pools and/or whether they belong to different DHCP service groups.

[0148] Relayl and/or Relay2 may share the data of association of user info ID and/or assigned IP addresses of End WTRUs handled by each relay WTRU. This may be used later for DNS lookup and/or IP traffic routing for IP traffic via relay WTRUs.

[0149] Additionally or alternatively, Relayl and/or Relay2 may share each Relay WTRU’s assigned IP address pool, DHCP service group ID, association of user info ID and/or assigned IP address of End WTRUs handled by each relay WTRU at existing PC5 connection between Relayl and/or Relay2 as a separate procedure.

[0150] At 314, after receiving DCR and/or LMR for an e2e route from Relayl , Relay2 may trigger to a new PC5 connection setup and/or modification of existing PC5 connection with entity at next hop in the e2e route (e.g., WTRU2). In DCR and/or LMR, selected e2e route information may be included.

[0151]After sending DCR to WTRU2, security association procedure may be performed between Relay2 and/or WTRU2, if needed. After sending DCR and/or LMR, Relay2 may receive DC Accept and/or LM Accept for the requested e2e route from WTRU2. WTRU2 may send DC Accept and/or LM Accept to Relay2 when accepting the requested PC5 link setup and/or link modification for communication to WTRU2 via e2e route.

[0152] After PC5 connection setup with Relay2, WTRU2 may perform IP address assignment procedure for example by getting IP address from Relay2 which works as DHCP server. When an IP address is assigned to WTRU2, the IP address value may be within the IP address pool configured at Relay2 during step 304.

[0153] Relay2 may store an association of User Info ID and/or assigned IP address of WTRU2 for use in DNS lookup and/or IP traffic routing. Relay2 may act as a DNS server to End WTRUs and/or Relay WTRUs having PC5 connection with Relay2.

[0154] At 316, WTRU1 may send a DNS query including user info ID of WTRU2 to Relayl to request IP address of WTRU2 (e.g., after Step 310).

[0155] At 318, if Relayl does not have any IP address mapping for the requested WTRU (e.g., WTRU2) based on user info ID, Relayl may send a DNS query including user info ID of WTRU2 as received in Step 316 to the other relay WTRUs having PC5 connection with Relayl , e.g., Relay2. When receiving a DNS query for an End WTRU which relay WTRU has an association between user info ID and assigned IP address, the Relay WTRU may respond with the assigned IP address.

[0156] Additionally or alternatively, Relayl and/or Relay2 may share each relay WTRU’s assigned IP address pool, DHCP service group ID, association of user info ID, assigned IP address of End WTRUs handled by each relay WTRU at an existing PC5 connection between Relayl and/or Relay2 during Step 318 and/or another step as a separate procedure.

[0157] At 320, based on the received IP address mapping from another relay WTRU and/or based on managed information about the IP address mapping to user Info ID as requested in Step 316, Relayl may be aware the IP address of WTRU2 may overlap to an IP address pool configured to Relayl .

[0158] At 322, For IP address of an End WTRU assigned by a relay WTRU which may have different DHCP service group IDs from RelayTs assigned ID and/or which have overlapped an IP address pool of Relayl , Relayl may provide a Network Address transition service

(e.g., change an IP address of a WTRU. This WTRU may be used for WTRUs internally under Relayl and/or an IP address of a WTRU may be used for WTRUs belonging to another Relay.) [0159] For example, when Relayl and/or Relay2 have overlapped IP address pools assigned by the NW, and/or Relayl received an IP address of WTRU2 as a response to a DNS query from Relay 2, Relayl may change the IP address of WTRU2 assigned by Relay2 to the internal IP address of WTRU2 assigned by Relayl . Relayl may manage the mapping of the IP address of WTRU2 assigned by Relay2 and IP address of WTRU2 internally assigned (e.g., locally assigned ) by Relayl .

[0160] At 324, when Relayl detects WTRUTs IP address may overlap to the IP address pool of Relay2 (e.g., which WTRU2 may be attached to), Relayl may ask Relay2 to assign a dedicated IP address of WTRU1 to be used for communication with WTRUs (e.g., including WTRU2) attached to Relay2.

[0161] When Relay2 detects WTRU2’s IP address may overlap to the IP address pool of Relayl (e.g., which WTRU1 may be attached to), Relay2 may ask Relayl to assign a dedicated IP address of WTRU2 to be used for communication with WTRUs (e.g., including WTRU1) attached to Relayl .

[0162] When a dedicated IP address for WTRU1 may be received from Relay2, Relayl may store the IP address for WTRU1 assigned by Relay2 and use the IP address for IP address change when WTRU1 communicate with the WTRUs attached to Relay2.

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

[0164] When Relayl asks a dedicated IP address of WTRU1 at Relay2, Relayl may share the IP address of WTRU1 assigned by Relayl . Relay2 may assign an IP address dedicated for WTRU1 which has same value to IP address assigned to WTRU1 at Relayl if it does not conflict to IP address assigned to other WTRU.

[0165] When Relay2 asks a dedicated IP address of WTRU2 at Relayl , Relay2 may share the IP address of WTRU2 assigned by Relay2. Relayl may assign an IP address dedicated for WTRU2 which has the same value to the IP address assigned to WTRU2 at Relay2 if Relayl does not conflict to IP address assigned to other WTRU.

[0166] At 326, Relayl may respond to a DNS query of WTRU 1 for IP address of WTRU2. If there is a locally assigned IP address of WTRU2 in step 322, the address may be informed as a response to a DNS query of WTRU 1. When Relayl has a dedicated IP address assigned to WTRU2, the dedicated IP address may be responded to a DNS query of WTRU1 for an IP address of WTRU2.

[0167] At 328, based on received IP address of WTRU2, WTRU1 may exchange IP traffic with WTRU2 via e2e route. For forwarding IP packet for e2e route, a Relay WTRU may work as a NAT server for an IP packet to an End WTRU. The End WTRU may have IP addresses assigned by a relay WTRU. The Relay WTRU may have different DHCP service group IDs from RelayTs assigned ID and/or which have an overlapped IP address pool of Relayl .

[0168] In examples, if IP packet with locally assigned IP address of WTRU2 as a destination IP, the IP address of WTRU2 at the IP packet may be changed to an IP address of WTRU2 by Relay2 and/or the IP data is forwarded to Relay2 based on managed mapping information and/or the IP address pool information of Relay2. [0169] In examples, if IP packet with IP address of WTRU2 by Relay2 as sender IP, the IP address at the IP packet may be changed to locally assigned IP address of WTRU2 and/or the IP packet is forwarded to destination End WTRU based on managed mapping information and/or an IP address pool information of Relay2.

[0170] For a WTRU (e.g., WTRU1), when there is a dedicated IP address assigned by another relay (e.g., Relay2), Relayl may change the IP address of WTRU1 to the dedicated IP address assigned by Relay2. This may occur for the IP packet between WTRU1 and/or WTRUs (e.g., WTRU2) attached Relay2.

[0171] As another embodiment, during the PC5 connection setup between Relayl and/or Relay2 for an e2e route between WTRU1 and/or WTRU2, Relayl and/or Relay2 may be aware of potential IP address conflicts. Relayl and/or Relay2 may then assign dedicated IP addresses of WTRU1 and/or WTRU2 at Relayl and/or Relay2. And when requested by another Relay, the assigned dedicated IP address may be informed.

[0172]As another embodiment, after Relayl has a dedicated IP address of WTRU1 by Relay2 under DHCP service group ID is 2, the dedicated IP address of WTRU 1 may be used for communication with other WTRUs attached relays under same DHCP service group with Relay2. For example, when Relayl receives a DNS query for WTRU1 from relay (e.g., Relay2 and/or Relay3) under DHCP service group ID is 2, Relayl may respond with a dedicated IP address of WTRU1 assigned by Relay2 as an IP address of WTRU1 for communication with WTRUs under relays under DHCP service group ID is 2.

Claims

1. A method performed by a first relay Wireless Transmit/Receive Unit (WTRU), the method comprising: receiving configuration information indicating a first internet protocol (IP) address pool for assigning IP addresses for connection to the first relay WTRU; receiving an end-to-end route setup request message from a first end WTRU, wherein the end-to-end route setup request message indicates a second relay WTRU and a second end WTRU; sending an end-to-end route setup response message to the first end WTRU to setup an end-to-end route between the first end WTRU and the second end WTRU via the first relay WTRU and the second relay WTRU; assigning a first IP address in the first IP address pool to the first end WTRU; receiving a lookup request from the first end WTRU; and sending a request message to the second relay WTRU based on receipt of the lookup request from the first end WTRU, wherein the request message indicates a request for a second IP address of the second end WTRU, wherein the second IP address is from a second IP address pool different than the first IP address pool.

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

3. The method of claim 2, wherein the first IP address pool is a first subset of 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 of any of claims 1 to 3, further comprising: receiving, from the second relay WTRU, an indication of the second IP address pool for assigning IP addresses for connection to the second relay WTRU; and sending, to the second relay WTRU, an indication of the first IP address pool for assigning IP addresses for connection to the first relay WTRU.

5. The method of claim 4, further comprising: forwarding, using the second IP address pool, an IP packet received from the first end WTRU to the second relay WTRU.

6. The method of claim 4 or 5, further comprising: receiving, from the second relay WTRU, an indication of the second IP address of the second end WTRU.

7. The method of any of claims 1 to 3, wherein the configuration information includes an indication of the second IP address pool for assigning IP addresses for connection to the second relay WTRU.

8. The method of any of claims 1 to 7, further comprising sending an indication of the first IP address pool to the second relay WTRU.

9. The method of claim 1 , further comprising: receiving, from the second relay WTRU, an indication of a service group identifier (ID) associated with the second relay WTRU.

10. The method of claim 9, wherein the first IP address pool is a first subset of 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: a processor configured to: receive configuration information indicating a first internet protocol (IP) address pool for assigning IP addresses for connection to the first relay WTRU; receive an end-to-end route setup request message from a first end WTRU, wherein the end-to-end route setup request message indicates a second relay WTRU and a second end WTRU; send an end-to-end route setup response message to the first end WTRU to setup an end-to-end route between the first end WTRU and the second end WTRU via the first relay WTRU and the second relay WTRU; assign a first IP address in the first IP address pool to the first end WTRU; receive a lookup request from the first end WTRU; and send a request message to the second relay WTRU based on receipt of the lookup request from the first end WTRU, wherein the request message indicates a request for a second IP address of the second end WTRU, wherein the second IP address is from a second IP address pool different than the first IP address pool.

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

13. The first relay WTRU of claim 12, wherein the first IP address pool is a first subset of 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 of any of claims 11 to 13, wherein the processor is further configured to: receive, from the second relay WTRU, an indication of the second IP address pool for assigning IP addresses for connection to the second relay WTRU.

15. The first relay WTRU of claim 14, wherein the processor is further configured to: forward, using the second IP address pool, an IP packet received from the first end WTRU to the second relay WTRU.

16. The first relay WTRU of claim 14 or 15, wherein the processor is further configured to: receive, from the second relay WTRU, an indication of the second IP address of the second end WTRU.

17. The first relay WTRU of any of claims 11 to 13, wherein the configuration information includes an indication of the second IP address pool for assigning IP addresses for connection to the second relay WTRU.

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

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

20. The first relay WTRU of claim 1 , wherein the first IP address pool is a first subset of 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.