Wireless transmitting and receiving unit and implementation method thereof

Abstract

The present disclosure provides a wireless transmit receive unit (WTRU) and a method implemented thereby, the WTRU being configured to act as a relay between a first WTRU and a second WTRU, the WTRU comprising: a processor configured to: receive a link identifier update request from the first WTRU, wherein the link identifier update request indicates a request for a new Internet Protocol (IP) address, and the link identifier update request further comprises a request for updating the second WTRU with respect to the new IP address of the first WTRU; in response to the received link identifier updating request, determining the new IP address of the first WTRU; sending a relay update request to the second WTRU, wherein the relay update request indicates the new IP address determined for the first WTRU; and sending a link identifier update response to the first WTRU, wherein the link identifier update response indicates the new IP address determined for the first WTRU.

Description

[0001] This divisional application is a divisional application of the application with the filing date of February 12, 2021, application number 202180018287.9, and invention title "Security and Privacy Support for Direct Wireless Communication".

[0002] Cross-reference to related applications

[0003] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 976,205, filed on February 13, 2020, the entire disclosure of which is incorporated herein by reference. Background of the Invention

[0004] Mobile communication technologies are constantly evolving. The fifth generation can be referred to as 5G. Previous (conventional) generations of mobile communication technologies may include fourth generation (4G) or Long Term Evolution (LTE) technologies. Wireless Transmit / Receive Units (WTRUs) supporting 4G LTE or 5G may communicate directly with each other via unicast sidelink (e.g., including vehicle-to-everything or V2X links) and / or through relay WTRUs. Privacy and / or security issues may need to be addressed to facilitate communication between these WTRUs. Summary of the Invention

[0005] Systems, methods, and tools are described herein that provide privacy and / or security support for WTRU communication via sidelink. A WTRU (e.g., a source WTRU or S-WTRU) as described herein may include a processor configured to communicate with a first target WTRU (e.g., a T-WTRU) using a first Internet Protocol (IP) identifier (e.g., such as an IP address). The processor may be further configured to determine that the first IP identifier will change (e.g., based on the expiration of a timer), and transmit a message to a relay WTRU (e.g., an R-WTRU) requesting that the relay WTRU assign a second IP identifier to the WTRU. The WTRU may receive a response from the relay WTRU, where the response may include the second IP identifier assigned to the WTRU.

[0006] The source WTRU requesting the IP identifier change may also provide the relay WTRU with a list of target WTRUs (e.g., including the first target WTRU) that will be informed of the IP identifier change of the source WTRU. The source WTRU may authorize the relay WTRU to share the new IP identifier of the S-WTRU, for example, by providing the relay WTRU with a token that the relay WTRU may use to authenticate the target WTRU. The S-WTRU may also request that the relay WTRU change the IP identifier (e.g., IP address) of one or more of the target WTRUs and / or the relay WTRU provide the IP identifier of the target WTRU to the source WTRU.

[0007] The IP identifier change described herein can be achieved via corresponding unicast links (e.g., PC5 links) between the source WTRU and the relay WTRU and between the relay WTRU and the one or more target WTRUs. The IP identifier change can be achieved using one or more of a link identifier update (LIU) request message, an LIU response message, and / or an LIU confirmation message transmitted over the unicast link. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1A is a system diagram showing an exemplary communication system in which one or more of the disclosed embodiments can be implemented.

[0009] Figure 1B is a system diagram showing an exemplary wireless transmit / receive unit (WTRU) that can be used within the communication system shown in Figure 1A accordance with an embodiment.

[0010] Figure 1C is a system diagram showing an exemplary radio access network (RAN) and an exemplary core network (CN) that can be used within the communication system shown in Figure 1A accordance with an embodiment.

[0011] Figure 1D is a system diagram showing another exemplary RAN and another exemplary CN that can be used within the communication system shown in Figure 1A accordance with an embodiment.

[0012] Figure 2 is a diagram showing an example of performing IP routing via a WTRU to a WTRU repeater.

[0013] Figure 3 is a diagram showing an example of performing a link identifier update via a unicast link between two WTRUs.

[0014] Figure 4 is a diagram showing an exemplary operation associated with changing the IP address of a source WTRU (S-WTRU).

[0015] Figure 5 is a diagram showing an exemplary operation associated with changing the IP address of an S-WTRU, a relay WTRU (R-WTRU), and / or one or more target WTRUs (T-WTRUs).

[0016] Figure 6 is a diagram showing an example of triggering an IP address change from a relay WTRU.

[0017] Figure 7It is a diagram showing an exemplary protocol stack for an end-to-end PC5 unicast link.

[0018] Figure 8 It is a diagram showing exemplary operations associated with establishing an end-to-end PC5 unicast link.

[0019] Figure 9 It is a diagram showing exemplary operations associated with performing link identifier updates via an end-to-end PC5 unicast link.

[0020] Figure 10 It is a diagram showing exemplary operations associated with IP address sharing. DETAILED DESCRIPTION

[0021] Figure 1A It is a schematic diagram showing an exemplary communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multi-access system that provides content such as voice, data, video, messages, broadcasts, etc. to a plurality of wireless users. The communication system 100 may enable a plurality of wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero-tail unique word DFT-spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multicarrier (FBMC), etc.

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

[0023] The communication system 100 may also include base station 114a and / or 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 CN 106 / 115, Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be base transceiver stations (BTSs), Node Bs, evolved Node Bs, Home Node Bs, Home evolved Node Bs, gNBs, NR Node Bs, site controllers, access points (APs), wireless routers, etc. Although the base stations 114a, 114b are each depicted as a single element, it should be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0024] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of wireless services to a specific geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in an embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In an embodiment, 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 the desired spatial direction.

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

[0026] More specifically, as noted above, communication 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, etc. For example, base station 114a in RAN 104 / 113 and WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish air interfaces 115 / 116 / 117. 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).

[0027] 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 use Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-A Pro to establish the air interface 116.

[0028] 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 use New Radio (NR) to establish the air interface 116.

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

[0030] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., 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 Rate for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0031] Figure 1AThe base station 114b therein can be, for example, a wireless router, a home Node B, a home evolved Node B, or an access point, and can utilize any suitable RAT to facilitate wireless connections in a local area such as a commercial premise, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for drones), a road, etc. In an 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 pico cell or a femto cell. As Figure 1A shown, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.

[0032] The RAN 104 / 113 can communicate with the CN 106 / 115, which can be any type of network configured to provide voice, data, applications, and / or Internet protocol voice (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data can have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 can provide call control, billing services, location-based services, prepaid calls, Internet connections, video distribution, etc., and / or perform advanced security functions such as user authentication. Although not shown in Figure 1A it, it should be understood that the RAN 104 / 113 and / or the CN 106 / 115 can communicate directly or indirectly with other RANs that employ the same RAT or a different RAT as the RAN 104 / 113. For example, in addition to being connected to the RAN 104 / 113 that can utilize NR radio technology, the CN 106 / 115 can also communicate with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

[0035] Figure 1B is a system diagram showing an exemplary WTRU 102. As Figure 1B shown, the WTRU 102 may include a processor 118, a transceiver 120, transmit / receive elements 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, a non-removable memory 130, a removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138, among others. It should be understood that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

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

[0037] The transmit / receive element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via an 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 one embodiment, the transmit / receive element 122 can be a transmitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, the transmit / receive element 122 can be configured to transmit and / or receive RF and optical signals. It should be understood that the transmit / receive element 122 can be configured to transmit and / or receive any combination of wireless signals.

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

[0039] The transceiver 120 can be configured to modulate the signals to be transmitted by the transmit / receive element 122 and demodulate the signals received by the transmit / receive element 122. As noted above, the WTRU 102 can have multi-mode capabilities. For example, thus, the transceiver 120 can include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs (such as NR and IEEE 802.11).

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

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

[0042] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may receive location information via the air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that the WTRU 102 may obtain location information by any suitable location determination method while remaining consistent with the embodiments.

[0043] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software modules and / or hardware modules that provide additional features, functions, and / or wired or wireless connections. For example, the peripheral devices 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, Bluetooth® Modules, FM radio units, digital music players, media players, video game player modules, Internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral device 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geographical location sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

[0044] WTRU 102 may include a full-duplex radio, for which the transmission and reception of some or all signals (e.g., associated with specific subframes for 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 for reducing and / or substantially eliminating self-interference via signal processing performed by hardware (e.g., chokes) or via a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, WRTU 102 may include a half-duplex radio, for which the transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or downlink (e.g., for reception)).

[0045] Figure 1C FIG. is a system diagram of RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 may communicate with WTRU 102a, 102b, 102c via air interface 116 using E-UTRA radio technology. RAN 104 may also communicate with CN 106.

[0046] RAN 104 may include evolved Node Bs 160a, 160b, 160c, but it should be understood that RAN 104 may include any number of evolved Node Bs while remaining consistent with the embodiment. Each of evolved Node Bs 160a, 160b, 160c may include one or more transceivers for communicating with WTRU 102a, 102b, 102c via air interface 116. In an embodiment, evolved Node Bs 160a, 160b, 160c may implement MIMO technology. Thus, evolved Node B 160a, for example, may use multiple antennas to transmit wireless signals to and / or receive wireless signals from WTRU 102a.

[0047] Each of evolved Node Bs 160a, 160b, 160c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, etc. As Figure 1C shown, evolved Node Bs 160a, 160b, 160c may communicate with each other via the X2 interface.

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

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

[0050] The SGW 164 may be connected to each of the evolved Node 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 the user plane during handover between evolved Node Bs, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, etc.

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

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

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

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

[0055] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or from the BSS. Traffic originating outside the BSS and destined for an STA may reach the STA through the AP and may be delivered to the STA. Traffic originating from an STA and destined for a destination outside the BSS may be sent to the AP for delivery to the corresponding destination. Traffic between STAs within the BSS may be sent through the AP. For example, the source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between a source and a destination STA (e.g., directly between them) using direct link setup (DLS). In some representative embodiments, DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using independent BSS (IBSS) mode may not have an AP, and STAs within the IBSS or using the IBSS (e.g., all STAs) may communicate directly with each other. The IBSS communication mode may sometimes be referred to in this document as an "ad-hoc" communication mode.

[0056] When using the 802.11ac infrastructure operation mode or a similar operation mode, the AP may transmit beacons on a fixed channel, such as the primary channel. The primary channel may be of a fixed width (e.g., 20 MHz bandwidth) or a width dynamically set via signaling. The primary channel may be the operation channel of the BSS and may be used by the STA to establish a connection with the AP. In some representative embodiments, for example, Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) may be implemented in the 802.11 system. For CSMA / CA, the STA (e.g., each STA) (including the AP) may listen to the primary channel. If the primary channel is listened to / 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.

[0057] High Throughput (HT) STAs may communicate using a 40 MHz wide channel, e.g., via a combination of the primary 20 MHz channel and an adjacent or non - adjacent 20 MHz channel to form a 40 MHz wide channel.

[0058] Very High Throughput (VHT) STAs may support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. The 40 MHz and / or 80 MHz channels may be formed by combining consecutive 20 MHz channels. The 160 MHz channel may be formed by combining eight consecutive 20 MHz channels, or by combining two non - consecutive 80 MHz channels (which may be referred to as an 80 + 80 configuration). For the 80 + 80 configuration, after channel coding, the data may pass through a segment parser that may divide the data into two streams. The Inverse Fast Fourier Transform (IFFT) processing and time - domain processing may be performed separately on each stream. These streams may be mapped to two 80 MHz channels, and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations for the 80 + 80 configuration described above may be reversed, and the combined data may be sent to the Media Access Control (MAC).

[0059] 802.11af and 802.11ah support operation modes below 1 GHz. Compared to those used in 802.11n and 802.11ac, the channel operation bandwidth and carriers are reduced in 802.11af and 802.11ah. 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 communication, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, such as limited capabilities, including supporting (e.g., only supporting) certain bandwidths and / or limited bandwidths. MTC devices may include a battery with a battery life higher than a threshold (e.g., to maintain a very long battery life).

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

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

[0062] Figure 1D is a system diagram showing RAN 113 and CN 115 according to one embodiment. As noted above, RAN113 may communicate with WTRU 102a, 102b, 102c via air interface 116 using NR radio technology. RAN 113 may also communicate with CN115.

[0063] RAN 113 may include gNBs 180a, 180b, 180c, but it should be understood that while remaining consistent with the embodiments, RAN 113 may include any number of gNBs. Each of gNBs 180a, 180b, 180c may include one or more transceivers to communicate with WTRUs 102a, 102b, 102c via air interface 116. In an embodiment, 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 gNBs 180a, 180b, 180c. Thus, gNB 180a, for example, may use multiple antennas to transmit wireless signals to WTRU 102a and / or receive wireless signals from WTRU 102a. In an embodiment, gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In an embodiment, gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU 102a may receive a coordinated transmission from gNB 180a and gNB 180b (and / or gNB 180c).

[0064] WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with scalable parameter sets. For example, the OFDM symbol interval and / or the OFDM subcarrier interval may vary for different transmissions, different cells, and / or different parts of the radio transmission spectrum. WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using various or scalable length subframes or transmission time intervals (TTIs) (e.g., containing different numbers of OFDM symbols and / or continuously varying absolute time lengths).

[0065] gNBs 180a, 180b, 180c can be configured to communicate with WTRUs 102a, 102b, 102c in a stand-alone configuration and / or a non-stand-alone configuration. In the stand-alone configuration, WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c without accessing other RANs (e.g., such as evolved Node Bs 160a, 160b, 160c). In the stand-alone configuration, WTRUs 102a, 102b, 102c can use one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the stand-alone configuration, WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In the non-stand-alone configuration, WTRUs 102a, 102b, 102c can communicate or connect with gNBs 180a, 180b, 180c while also communicating or connecting with other RANs (such as evolved Node Bs 160a, 160b, 160c). For example, WTRUs 102a, 102b, 102c can implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more evolved Node Bs 160a, 160b, 160c substantially simultaneously. In the non-stand-alone configuration, evolved Node Bs 160a, 160b, 160c can be used as a mobility anchor for WTRUs 102a, 102b, 102c, and gNBs 180a, 180b, 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, 102c.

[0066] Each of 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 UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards user plane functions (UPFs) 184a, 184b, routing of control plane information towards access and mobility management functions (AMFs) 182a, 182b, etc. As Figure 1D shown, gNBs 180a, 180b, 180c can communicate with each other via the Xn interface.

[0067] Figure 1DThe illustrated CN 115 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 data networks (DN) 185a, 185b. Although each of the foregoing elements is depicted as part of CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0068] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selection of a particular SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, etc. The AMF 182a, 182b may use network slicing in order to customize CN support for the WTRUs 102a, 102b, 102c based on the type of service used by the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases such as services that rely on ultra-reliable low-latency (URLLC) access, services that rely on enhanced mobile broadband (eMBB) access, services for machine type communication (MTC) access, etc. The AMF 162 may provide control plane functions for handover 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.

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

[0070] UPF 184a and 184b can be connected to one or more of gNBs 180a, 180b, 180c in RAN 113 via the N3 interface. These gNBs can provide access to a packet switched network (such as the Internet 110) to WTRU 102a, 102b, 102c to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices. UPF 184a, 184b can perform other functions, such as routing and forwarding packets, implementing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, etc.

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

[0072] In view of Figures 1A to 1D and Figures 1A to 1D In view of the corresponding descriptions, one or more or all of the functions described herein with reference to one or more of the following can be performed by one or more emulation devices (not shown): WTRU102a-d, base stations 114a-b, evolved Node Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMF182a-b, UPF 184a-b, SMF 183a-b, DNs 185a-b, and / or any other devices described herein. The emulation device(s) can be one or more devices configured to mimic one or more or all of the functions described herein. For example, the emulation device(s) can be used to test other devices and / or simulate network and / or WTRU functions.

[0073] A simulation device can be designed to implement one or more tests of other devices in a laboratory environment and / or an operator network environment. For example, the one or more simulation devices can perform 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 to test other devices within the communication network. The one or more simulation devices can perform one or more functions or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device can be directly coupled to another device for testing purposes and / or can use over-the-air wireless communication to perform tests.

[0074] The one or more simulation devices can perform one or more (including all) functions while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test laboratory and / or a test scenario in a non-deployed (e.g., test) wired and / or wireless communication network to implement tests of one or more components. The one or more simulation devices can be test equipment. Direct RF coupling and / or wireless communication via an RF circuit (e.g., which can include one or more antennas) can be used by the simulation device to transmit and / or receive data.

[0075] Discovery and / or communication between peer WTRUs (e.g., device-to-device (D2D) discovery and communication) can be performed using Proximity Services (ProSe). Such services can allow for data transfer at high data transfer rates (e.g., streaming), provide local hotspots for Internet connectivity, etc. A WTRU-to-WTRU repeater can be used to support ProSe. Such a WTRU-to-WTRU repeater can include a WTRU configured to act / operate as a repeater between two or more peer WTRUs. WTRU-to-WTRU is used interchangeably with device-to-device or D2D in this document, and D2D is used interchangeably with sidelink and / or V2X in this document.

[0076] Figure 2Shows an example of a WTRU-to-WTRU repeater (e.g., ProSe 5G WTRU-to-WTRU repeater) configured to communicate with a source WTRU (e.g., WTRU-1 in the figure) and a destination WTRU (e.g., WTRU-2 in the figure) using IP routing. The source WTRU and / or the destination WTRU may be configured to establish a corresponding unicast L2 link (e.g., PC5 unicast link) with the WTRU-to-WTRU repeater, for example, by performing one or more of the actions shown as actions 1 to 5b (e.g., including advertisement-based WTRU-to-WTRU repeater discovery shown at 1a and 1b). The repeater may (e.g., during the establishment of the unicast L2 link) assign an IP identifier (e.g., IP address, IP prefix, etc.) to the source WTRU (and / or the destination WTRU), and may store the association of the user information of the source WTRU with the IP identifier assigned to the source WTRU in one or more DNS entries (e.g., the repeater may act as a DNS server for the source WTRU and / or the destination WTRU). The source WTRU may discover the ProSe service via the WTRU-to-WTRU repeater, for example, before or at the same time as communicating with the destination WTRU. The source WTRU may send (e.g., via the unicast link established with the repeater) a DNS query about the destination WTRU and / or the ProSe service at 6. The DNS query may include, for example, user information associated with the destination WTRU. In response to receiving the DNS query, the repeater may return, at 7, an IP identifier (e.g., IP address or prefix) associated with the destination WTRU or the ProSe service to the source WTRU, for example, via a DNS response message.

[0077] For example, in response to receiving the IP address / prefix of the destination WTRU from the repeater, the source WTRU may transmit IP data or non-IP data encapsulated in an IP packet to the destination WTRU. The transmission of the IP data or the IP packet may utilize the unicast L2 link between the source WTRU and the repeater (e.g., at 8a) and the unicast L2 link between the repeater and the destination WTRU (e.g., at 8b). The WTRU-to-WTRU repeater may act as an IP router that forwards data packets from the source WTRU to the destination WTRU, and the unicast L2 link (e.g., each unicast L2 link associated with the ProSe service) may operate as an IP interface between the source WTRU and the destination WTRU.

[0078] Although Figure 2A source WTRU and a target WTRU communicating via a WTRU-to-WTRU repeater are shown, but there may be multiple WTRU-to-WTRU repeaters near the source WTRU, and the source WTRU may establish corresponding links with multiple repeaters and select one of the multiple repeaters to use for communicating with the target WTRU. This selection may be based on WTRU implementation. In an example, the source WTRU may send corresponding DNS queries to multiple repeaters and may select the first repeater that returns an affirmative response to the DNS query (e.g., a first response indicating the IP address of the target WTRU).

[0079] Link identifier updates may be performed for unicast links (e.g., associated with enhanced vehicle-to-everything (eV2X) communication). Identifiers such as application ID, application layer ID, source layer-2 (L2) ID, and / or IP address / prefix for a direct peer unicast mode for V2X or eV2X communication (e.g., via the PC5 reference point) may change over time (e.g., due to privacy reasons). For example, operations may be performed to update the identifier associated with the unicast link and / or exchange the identifier between the source WTRU and the target WTRU before the source WTRU and the target WTRU start using the identifier. In this way, service interruption between the source WTRU and the target WTRU may be prevented. Updating the identifier of the source WTRU may cause the target WTRU to change its corresponding identifier (e.g., if the unicast link between the source and the target is used for IP communication, the corresponding identifier such as L2 ID and / or IP address / prefix). As used herein, the application ID may correspond to an identifier of an application, and the application layer ID may correspond to an identifier assigned to the WTRU in association with the application (e.g., the application layer ID of the WTRU may be used by the application to identify the WTRU). Application and application layer may be used interchangeably herein.

[0080] Figure 3Illustrates exemplary operations associated with performing link identifier updates over a unicast link between two WTRUs. As shown, a first WTRU (e.g., WTRU-1) may transmit an identifier update request to a peer WTRU (e.g., WTRU-2). The request may specify an identifier of the first WTRU (e.g., a new L2 ID). The identifier (e.g., the new L2 ID) may be sent, for example, as a message payload (e.g., with security protection). The peer WTRU may respond with an identifier update response message that may specify an identifier of the peer WTRU (e.g., a new L2 ID). The initiating WTRU (e.g., WTRU-1) may confirm receipt of the identifier of the peer WTRU (e.g., the new L2 ID of the peer WTRU) by, for example, sending an identifier update ACK message. The first WTRU and the second WTRU may start using the identifiers (e.g., the new L2 IDs of the initiating WTRU and the peer WTRU) after the confirmation.

[0081] Link identifier update operations may be performed, for example, via a WTRU-to-WTRU repeater over a PC5 unicast link between a source WTRU (referred to herein as S-WTRU) and a relay WTRU (referred to herein as R-WTRU). The identifier(s) that may be updated may include, for example, L2 ID, IP address, IP prefix, etc. A change in an identifier such as an IP address change may disrupt end-to-end (E-to-E) communication, for example, because the S-WTRU and the target WTRU (referred to herein as T-WTRU) may use the IP address for communication. For example, a PC5 direct unicast link may not be established between the S-WTRU and the T-WTRU that communicate via IP. Accordingly, PC5 messages (e.g., link ID update messages) may not be exchanged between the S-WTRU and the T-WTRU. Examples are provided herein that describe how to inform the T-WTRU about an identifier change (e.g., an IP address change) of the S-WTRU. The IP address is used herein as an example to illustrate how identifier updates may be performed between peer WTRUs. However, it should be noted that the same or similar techniques may be used to update other types of identifiers.

[0082] The S-WTRU may communicate with multiple T-WTRUs using the same IP address and / or a PC5 unicast link (e.g., via a relay WTRU or R-WTRU). Multiple T-WTRUs may (e.g., each) send a DNS query request to find the S-WTRU (e.g., by specifying user information associated with the S-WTRU to the R-WTRU to query the IP address of the S-WTRU and obtaining the IP address of the S-WTRU from the R-WTRU) (e.g., to the R-WTRU). Packets (e.g., IP packets) received at the R-WTRU from different T-WTRUs may be forwarded to the S-WTRU via, for example, the same PC5 unicast link between the S-WTRU and the R-WTRU. Multiple T-WTRUs associated with the S-WTRU and / or R-WTRU may be informed of a change in the identifier of the S-WTRU (e.g., a new IP address), for example, to maintain uninterrupted communication with the S-WTRU.

[0083] Privacy settings (e.g., privacy requirements) associated with the WTRU link identifier may stipulate that the WTRUs involved in a link (e.g., a PC5 unicast link) change their identifiers simultaneously (e.g., at the same time). For example, the identifiers of the S-WTRU and the R-WTRU may be changed simultaneously by performing a link identifier update procedure between the S-WTRU and the R-WTRU. For IP-based communication, the S-WTRU, R-WTRU, and / or one or more T-WTRUs associated with the S-WTRU and / or R-WTRU may need to change their IP addresses (e.g., simultaneously) to preserve security and privacy. The change of the IP address of one or more T-WTRUs may be performed via a link identifier update operation performed through the corresponding PC5 unicast link between the one or more T-WTRUs and the R-WTRU.

[0084] S-WTRU to T-WTRU communication may occur via multiple (e.g., two) PC5 unicast links (e.g., between a first link between the S-WTRU and the R-WTRU and a second link between the R-WTRU and the T-WTRU). If the IP packets exchanged between the S-WTRU and the R-WTRU are encrypted (e.g., since the IP addresses within the IP packets may be inaccessible or invisible to others), there may be no privacy issues. However, the IP addresses within unencrypted IP packets (e.g., with only integrity protection) may be visible to others, and this may cause privacy issues. Changing the IP addresses (e.g., and / or other identifiers) on the S-WTRU and the R-WTRU rather than on the T-WTRU may cause privacy issues (e.g., if only integrity protection is provided without using encryption). Examples are provided herein that describe how to trigger, for example, simultaneously, the change of the IP addresses (and other identifiers) on one or more T-WTRUs.

[0085] An S-WTRU that obtains an IP address from an R-WTRU may not want its IP address to be shared with every requesting T-WTRU. The S-WTRU may prefer to only externalize its IP address to selected T-WTRUs. An example is provided herein describing how to inform an R-WTRU whether a T-WTRU is or may be authorized to obtain an IP address for the S-WTRU.

[0086] As used herein, a source WTRU (S-WTRU) and a target WTRU (T-WTRU) may correspond to a peer WTRU. An S-WTRU may be referred to interchangeably as, for example, an initiating WTRU, a source WTRU, or a peer WTRU. A T-WTRU may be referred to interchangeably as, for example, a responding WTRU, a target WTRU, or a peer WTRU. A WTRU-to-WTRU relay may be a WTRU configured to behave or operate as a relay between two peer WTRUs (e.g., an S-WTRU and a T-WTRU). A WTRU-to-WTRU relay may be referred to interchangeably as a relay WTRU and an R-WTRU.

[0087] A relay WTRU (e.g., an R-WTRU) may allocate (e.g., assign or change) an IP identifier (e.g., an IP address or an IP prefix) to other WTRUs (e.g., an S-WTRU and a T-WTRU). For example, the R-WTRU may identify the IP address or IP prefix and / or allocate it to the S-WTRU and / or the T-WTRU via a link identifier update response message. The R-WTRU may respond to queries regarding the IP address / prefix (e.g., a new IP address / prefix) of a peer WTRU communicating via the R-WTRU. The R-WTRU may not know which one or more T-WTRUs are communicating with the S-WTRU or which one or more T-WTRUs should be informed of the S-WTRU's IP identifier change (e.g., a new IP address assignment). The R-WTRU may be provided with information for identifying these T-WTRUs.

[0088] To preserve privacy and / or security, IP identifiers, such as the IP address of a WTRU, may be updated. The update may include one or more of the following: the S-WTRU and the R-WTRU may change their identifiers (e.g., including the IP address) and may inform the T-WTRU of the new IP identifier of the S-WTRU; the S-WTRU, the R-WTRU, and one or more T-WTRUs may change their identifiers (e.g., including the IP address) simultaneously (substantially simultaneously); the R-WTRU may trigger the identifier change, e.g., using the identifier update techniques described herein; a PC5 unicast link may be established between the S-WTRU and the T-WTRU via the user plane (e.g., via the PC5 link associated with the R-WTRU) to allow the S-WTRU and the T-WTRU to exchange their IP addresses and / or other identifiers; etc.

[0089] Before sharing the IP identifier (e.g., IP address) of a WTRU with other WTRUs (e.g., via a DNS query and / or response), the R-WTRU may obtain or be provided with authorization (e.g., by the S-WTRU). The R-WTRU may use a token for IP address sharing verification. For example, the token may be provided / configured on the R-WTRU or obtained from the S-WTRU (e.g., when the S-WTRU registers with the R-WTRU or when the R-WTRU receives a DNS request from the S-WTRU). The R-WTRU may receive the token from the T-WTRU in a DNS request, for example, and may use the token to verify whether the IP address of the S-WTRU may be shared with the T-WTRU. The tokens described herein may be authenticated or unauthenticated, e.g., for single use or multiple uses (e.g., the token may be reused). The token may represent a specific authentication policy (e.g., to be enforced at the R-WTRU) and may be provided to the S-WTRU and / or the T-WTRU (e.g., via the ProSe application).

[0090] Authorization policies such as an authorization policy indicating that the S-WTRU does not require authorization can be distributed to the R-WTRU (e.g., via a ProSe application or other ProSe policy repository). Such a policy can allow the R-WTRU to act as a policy enforcement point (PEP) to grant or deny DNS queries from a particular WTRU or group of WTRUs without a special authorization mechanism (e.g., such as a token). The R-WTRU can authorize the sharing of the IP address of the S-WTRU (e.g., in the absence of receiving an authorization policy from the ProSe application). The R-WTRU can do so, for example, by verifying a first token received in a DNS request (e.g., from a T-WTRU) against a second token received from the S-WTRU. The R-WTRU can also query the S-WTRU for the token received from the T-WTRU (e.g., when the S-WTRU has not provided the R-WTRU with a token that the R-WTRU can use to verify the token from the T-WTRU).

[0091] The S-WTRU may desire to change its IP address (e.g., and / or other identifiers), for example, for privacy and / or security reasons. The new IP address of the S-WTRU can be informed to the T-WTRU that may be communicating with the S-WTRU via a PC5 unicast link (e.g., via the R-WTRU) in order to continue IP-based communication with the S-WTRU. The S-WTRU may be communicating with more than one T-WTRU via a PC5 unicast link. In such a case, the new IP address of the S-WTRU can be informed to more than one T-WTRU simultaneously (e.g., during the same program execution, using the same set of messages, etc.).

[0092] An S-WTRU desiring to change its IP address (or other identifier) can determine whether one or more T-WTRUs communicating with the S-WTRU should also change their IP address (and / or other identifier), for example, substantially simultaneously with the S-WTRU changing its IP address (and / or other identifier). Information related to these changes (e.g., whether one or more T-WTRUs should also change their IP address) can be provided to the S-WTRU by the application layer (or network) and / or can be provided on the S-WTRU according to an application ID (e.g., at the application layer). The S-WTRU can indicate to the R-WTRU whether one or more T-WTRUs should also change their IP address (and / or other identifier). For example, the S-WTRU can include an indication to the R-WTRU (e.g., a peer update indication) in a link identifier update request message, and can set the indication to inform the R-WTRU that the target WTRU identifier should be updated and that the new IP address of the S-WTRU should be informed to the target WTRU. The S-WTRU can also set the indication to inform the R-WTRU that the target WTRU identifier should not be updated and that the new IP address of the S-WTRU should be informed to the target WTRU. The S-WTRU can also set the indication to inform the R-WTRU that the target WTRU identifier should not be updated and that the new IP address of the S-WTRU should not be informed to the target WTRU.

[0093] Exemplary R-WTRU behavior in response to receiving a peer update indication as described herein is provided below. In the example, the peer update indication from the S-WTRU may be set to indicate that the peer WTRU ID should be updated and that the new IP address of the S-WTRU should be informed to the peer WTRU. In response, the R-WTRU may change the identifier of one or more (e.g., all) WTRUs (e.g., the S-WTRU and / or one or more T-WTRUs) involved in sidelink (e.g., PC5) communication with the S-WTRU and / or the R-WTRU. In the example, the peer update indication from the S-WTRU may be set to indicate that the peer WTRU ID should not be updated and that the new IP address of the S-WTRU should be informed to the peer WTRU. In response, the R-WTRU may change the identifier of the S-WTRU and / or the R-WTRU, and may inform one or more T-WTRUs of the new IP address of the S-WTRU. In these examples, the identifiers of not all WTRUs involved in WTRU-to-WTRU relay communication may be changed. In the example, the peer update indication from the S-WTRU may be set to indicate that the peer WTRU ID should not be updated and that the new IP address of the S-WTRU should not be informed to the peer WTRU. In response, the R-WTRU may complete the identifier update operation with the S-WTRU and may not inform the T-WTRUs of the new IP address of the S-WTRU. In these examples, the S-WTRU may inform the T-WTRUs of the new IP address of the S-WTRU, for example, via an end-to-end PC5 unicast link established between the S-WTRU and the T-WTRU.

[0094] Operations may be performed by one or more WTRUs to change the identifier (e.g., IP address) of the S-WTRU and / or the R-WTRU, and to inform the T-WTRU of the new identifier (e.g., IP address) of the S-WTRU. These operations may be performed, for example, based on a peer update indication (as described herein) from the S-WTRU indicating that the peer WTRU ID should not be updated and that the new identifier (e.g., IP address) of the S-WTRU should be informed to the peer WTRU. For example, the S-WTRU may be informed (e.g., via the application layer, timer expiration, etc.) that its IP address (e.g., and / or other identifiers such as IP prefix, application ID, L2 ID, etc.) will be changed according to a policy or rule to maintain privacy / security. The S-WTRU may trigger an identifier update procedure via a PC5 link established between the S-WTRU and the R-WTRU (e.g., the PC5 link may be associated with the IP address to be changed). The S-WTRU may request (e.g., as part of the PC5 link identifier update procedure) from the R-WTRU a new IP address / prefix (or other identifier), for example, if the R-WTRU is configured to allocate the IP address / prefix (or other identifier) of the S-WTRU.

[0095] Figure 4 Exemplary operations associated with changing the identifier (e.g., IP address) of the S-WTRU or the R-WTRU are shown. At 0, a first sidelink (e.g., a PC5 unicast link) may be established between the S-WTRU and the R-WTRU, and a second sidelink (e.g., a PC5 unicast link) may be established between the R-WTRU and the T-WTRU (e.g., corresponding PC5 links may be established between the R-WTRU and one or more T-WTRUs). The R-WTRU may be a relay WTRU associated with the S-WTRU and the T-WTRU (e.g., one or more T-WTRUs). The S-WTRU may discover the T-WTRU, for example, by sending a query request (e.g., a DNS query request) to the R-WTRU. The R-WTRU may respond to the query request (e.g., via a DNS response) and indicate (e.g., include) the identifier of the T-WTRU (e.g., the IP address of the T-WTRU) in the response. Query authorization (e.g., DNS query authorization) may be available to the R-WTRU to determine whether to disclose the identifier (e.g., IP address) of the T-WTRU to the S-WTRU (e.g., regardless of whether answering the DNS query from the S-WTRU). The R-WTRU may do so, for example, if the IP address of the T-WTRU is to be protected for privacy or security reasons. As Figure 4 shown, the roles of the S-WTRU and the T-WTRU may be reversed (e.g., the T-WTRU may discover the S-WTRU, etc.). Additional details regarding query authorization are provided below.

[0096] Figure 4 The S-WTRU and T-WTRU shown can exchange IP data, for example, via an R-WTRU (e.g., through the respective PC5 links with the S-WTRU and T-WTRU as described herein). The S-WTRU can send an indication (e.g., during link establishment) to the R-WTRU indicating that the link between the S-WTRU and the R-WTRU requires privacy. The R-WTRU can decide to accept or reject a direct communication request (e.g., from the S-WTRU) based on this indication. The R-WTRU can perform a similar action for one or more T-WTRUs. For example, the R-WTRU can decide not to accept a request for privacy protection from a T-WTRU (e.g., due to resource limitations). The R-WTRU can include an indication of privacy support when establishing a PC5 unicast link with the S-WTRU or T-WTRU.

[0097] Still referring to Figure 4 , at 1, the S-WTRU can trigger one or more link identifier update operations (e.g., as part of a link identifier update procedure), for example, based on an identifier update trigger (e.g., the trigger can be pre-configured). The S-WTRU can generate (e.g., automatically generate) a new L2 ID and can send a link identifier update request message to the R-WTRU. The message can include, for example, one or more of the following: the new L2 ID of the S-WTRU, an indication of the desired new IP address of the S-WTRU, T-WTRU information (e.g., a list of T-WTRU IP addresses, T-WTRU user information, etc.), a peer update indication (e.g., as described herein), and / or other identifiers that have been or will be updated (e.g., application ID, application layer ID of the S-WTRU, etc.). The S-WTRU can set its current IP address as deprecated (e.g., the S-WTRU can continue to use the IP address but should not start new communications with that IP address).

[0098] In response to receiving a request message from the S-WTRU, the R-WTRU may assign a new IP address to the S-WTRU and / or may save the new IP address of the S-WTRU (e.g., locally). The R-WTRU may assign (e.g., self-assign) a new L2ID and / or a new IP address to itself and may use such L2 ID and / or IP address to communicate with the S-WTRU over the PC5 link with the S-WTRU. The R-WTRU may retrieve T-WTRU information (e.g., T-WTRU records or entries) based on the T-WTRU information provided by the S-WTRU (e.g., T-WTRU user information and / or IP address). Such T-WTRU information may be stored locally by the R-WTRU, e.g., stored in a local table or database maintained by the R-WTRU.

[0099] The R-WTRU may verify the peer update indication provided by the S-WTRU. In an example (e.g., if the peer update indication indicates that the peer WTRU ID should not be updated), then at 2, the R-WTRU may send a message such as a PC5 relay update request message to the T-WTRU to inform the T-WTRU about the new identifier of the S-WTRU (e.g., the new IP address). The R-WTRU may include one or more of the following in the message: the old IP address of the S-WTRU, user information associated with the S-WTRU, the new IP address of the S-WTRU, and / or other identifiers associated with the S-WTRU (e.g., the application layer ID or application ID associated with the S-WTRU if previously received by the R-WTRU). If the peer update indication indicates that the peer WTRU ID should be updated, the R-WTRU may perform other operations. These operations are described in more detail below Figure 5 and are described in more detail below.

[0100] The T-WTRU may receive a PC5 message from the R-WTRU, retrieve (e.g., locate) information about the S-WTRU (e.g., stored records or entries) (e.g., based on user information and / or the old IP address of the S-WTRU), and / or save the new IP address of the S-WTRU (e.g., in addition to the old IP address of the S-WTRU). The T-WTRU may be able to continue receiving IP data such as packets that were sent before the S-WTRU received its new IP address using its old IP address. The T-WTRU may do so, for example, until the T-WTRU receives an IP packet that includes the new IP address of the S-WTRU. At this point, the T-WTRU may start using the new IP address of the S-WTRU (e.g., the T-WTRU may release or delete the old IP address of the S-WTRU). At 3, the T-WTRU may send a PC5 relay update response message to the R-WTRU and may include parameters such as the user information of the S-WTRU, the old and / or new IP addresses of the S-WTRU, etc. (e.g., to confirm the receipt of those parameters).

[0101] At 4, the R-WTRU may send a link identifier update response message to the S-WTRU. The response message may include, for example, one or more of the following: the new IP address of the S-WTRU, the new L2 ID of the R-WTRU, the new IP address of the R-WTRU, and / or other identifiers that the R-WTRU may have received from the T-WTRU.

[0102] For example, when (e.g., at) sending a PC5 relay update request message to the T-WTRU at 2, the R-WTRU may start a timer. The R-WTRU may use this timer to avoid waiting indefinitely for a response from the T-WTRU before replying to the S-WTRU's request. If the timer expires (e.g., before the T-WTRU responds), then the R-WTRU may reply to the S-WTRU and may provide the new IP address assigned to the S-WTRU. The R-WTRU may provide a status code indicating whether the IP address change of the S-WTRU has been successfully informed to the T-WTRU (e.g., in the link identifier update response message sent to the S-WTRU) (e.g., the status code may indicate success or failure).

[0103] Before responding to the S-WTRU, the R-WTRU may wait for a response from the T-WTRU or the expiration of a timer (e.g., if more than one T-WTRU is specified in the query request by the S-WTRU at 1). The R-WTRU may provide a list of T-WTRUs (e.g., including T-WTRU user information and / or IP addresses) to the S-WTRU (e.g., if at least one T-WTRU does not respond before the timer expires). The list may indicate to the S-WTRU whether the T-WTRU has or has not successfully updated with respect to the new IP address of the S-WTRU. For a T-WTRU that has not successfully updated the new IP address of the S-WTRU, the R-WTRU may set the status code described herein to failure.

[0104] The S-WTRU may save its new identifier (e.g., L2 ID, IP address, etc.) and / or the new identifier of the R-WTRU (e.g., L2 ID, IP address, etc.). At 5, the S-WTRU may send an acknowledgement (ACK) message (e.g., a link identifier update ACK message) to the R-WTRU and may include in the ACK message the new identifier (e.g., the new IP address) received in the identifier update response message. At 6, the S-WTRU and the R-WTRU may start using their new identifiers (e.g., L2 ID) for sidelink (e.g., PC5) communication. The S-WTRU may start using its new IP address (or IP prefix) to exchange IP data with the T-WTRU (e.g., a T-WTRU that has been successfully informed about the new IP address of the S-WTRU).

[0105] Adding an indication of the new IP address in the link identifier update request message and / or adding the newly allocated IP address in the link identifier update response message can be applicable to direct sidelink (e.g., PC5) communication, such as when the S-WTRU and the T-WTRU communicate directly with each other via the PC5 link without involving the R-WTRU (e.g., the T-WTRU can allocate an IP address to the S-WTRU, in which case the T-WTRU can act as a DHCP server for the S-WTRU). In these cases, the S-WTRU can obtain a new identifier (e.g., a new IP address, IP prefix, etc.) from the T-WTRU via one or more link identifier update operations (e.g., as part of a link identifier update procedure). In an example, the S-WTRU can act as a DHCP server (e.g., for one or more T-WTRUs), and can initiate one or more link identifier update operations (e.g., as part of a link identifier update procedure) for one or more T-WTRUs. In those examples, the S-WTRU can assign a new IP address to one or more of the T-WTRUs, and can specify the new IP address in the link identifier update request message.

[0106] In Figure 4 In the example shown, the R-WTRU can send the new IP address to the S-WTRU before updating the IP address of the S-WTRU with respect to the T-WTRU. For example, before updating the IP address of the S-WTRU with respect to the T-WTRU, the R-WTRU can wait to receive an ACK message (e.g., sent at 5) from the S-WTRU. The S-WTRU can start an IP change timer (e.g., when sending an identifier update request to the R-WTRU or when receiving an identifier update response from the R-WTRU), and can continue to use its old IP address until it receives an IP packet from the T-WTRU with the new IP address or until the IP change timer expires (e.g., whichever occurs earlier). The S-WTRU can (e.g., if the S-WTRU is associated with more than one T-WTRU) start using its new IP address with those T-WTRUs that have started using the new IP address of the S-WTRU, and can continue to use its old IP address with those T-WTRUs that have not yet started using the new IP address of the S-WTRU. The S-WTRU can start an IP change timer as described herein for each T-WTRU (e.g., can create one such timer for each T-WTRU).

[0107] In Figure 4In the example shown, the messages exchanged between WTRUs can be messages associated with existing WTRU functions (e.g., the messages can be associated with an existing PC5 link identifier updater), or they can be new messages (e.g., new PC5 messages) introduced to allow the S-WTRU to request a new IP address from the R-WTRU (or T-WTRU) without triggering a change in other identifiers (e.g., L2 ID, security identifier, etc.). For example, the S-WTRU, R-WTRU, and / or T-WTRU can exchange PC5 messages with link IP address request parameters and / or link IP address response parameters (e.g., link IP address update request / response messages). Such link IP address request parameters can include, for example, a list of T-WTRU user information and / or associated IP addresses (e.g., if the T-WTRU is to be informed about the S-WTRU's IP address). Link IP address response parameters can include, for example, one or more of the following: the new IP address / IP prefix of the S-WTRU, a status code (e.g., informing the T-WTRU about the success / failure of the IP address change), and / or the user information and / or IP address of the T-WTRU for which the S-WTRU's new IP address has not been successfully updated.

[0108] In Figure 4 In the example shown, the S-WTRU can obtain a new IP address from another entity (e.g., other than the R-WTRU), and the S-WTRU can specify that new IP address on the link identifier update request message sent at 1 (e.g., instead of indicating that a new IP address will be assigned to the S-WTRU). In these cases, the R-WTRU can track (e.g., save) the S-WTRU's new IP address.

[0109] The identifiers (e.g., IP addresses) of multiple (e.g., all) WTRUs involved in sidelink (e.g., PC5) communication such as the S-WTRU, R-WTRU, and one or more T-WTRUs can be changed. For example, if the S-WTRU indicates in a peer update message, for example, that the peer WTRU identifier should be updated and the S-WTRU's new identifier (e.g., IP address) should be informed to the peer WTRU, then the identifiers (e.g., IP addresses) of those peer WTRUs can also be changed. Peer WTRUs (e.g., the S-WTRU, R-WTRU, and / or one or more T-WTRUs that know the S-WTRU's old IP address) can update their identifiers, such as IP addresses and / or other identifiers, for privacy reasons. Link identifier updates can be performed between the S-WTRU and the R-WTRU and / or between the R-WTRU and one or more T-WTRUs.

[0110] Figure 5Illustrates exemplary operations associated with changing the IP addresses of an S-WTRU, an R-WTRU, and one or more T-WTRUs. Although the examples are described in the context of IP address change, they are also applicable to updating other types of identifiers (e.g., IP prefix, L2 ID, etc.). As shown, at 0, a first sidelink (e.g., a PC5 unicast link) may be established between the S-WTRU and the R-WTRU, and a second sidelink (e.g., a PC5 unicast link) may be established between the R-WTRU and the T-WTRU (e.g., corresponding PC5 links may be established between the R-WTRU and one or more T-WTRUs). The R-WTRU may be a relay WTRU associated with the S-WTRU and the T-WTRU (e.g., one or more T-WTRUs). The S-WTRU may discover the T-WTRU, for example, by sending a query request (e.g., a DNS query request including user information of the T-WTRU) to the R-WTRU, and the R-WTRU may send a response (e.g., a DNS response) indicating (e.g., including) the IP address of the T-WTRU to the R-WTRU. IP data may be exchanged between the S-WTRU and the T-WTRU, for example, via the R-WTRU (e.g., through the PC5 link as described herein).

[0111] At 1, the S-WTRU may be informed (e.g., via the application layer, timer-based expiration, etc.) that its IP address and / or other identifier (e.g., application layer ID, L2 ID, etc.) will change. In response, the S-WTRU may trigger one or more link identifier update operations (e.g., as part of a link identifier update procedure). For example, the S-WTRU may generate (e.g., automatically generate) a new L2 ID and may send a link identifier update request message to the R-WTRU. The message may include, for example, one or more of the following: the new L2 ID of the S-WTRU, an indication that a new IP address will be assigned or allocated to the S-WTRU, T-WTRU information (e.g., a list of T-WTRU IP addresses, T-WTRU user information, etc.), and / or a peer update indication (e.g., as described herein).

[0112] In response to receiving a link identifier update request from an S-WTRU, the R-WTRU may assign or allocate a new IP address to the S-WTRU and may, for example, save the IP address (e.g., locally), while still retaining the S-WTRU's current IP address. The R-WTRU may assign (e.g., self-assign) a new L2 ID and / or a new IP address of the R-WTRU to communicate with the S-WTRU via the PC5 link with the S-WTRU. The R-WTRU may retrieve information about the T-WTRU (e.g., from T-WTRU records or entries stored by the R-WTRU in a local table, for example). The R-WTRU may examine the peer update indication provided by the S-WTRU and determine whether the indication indicates that the peer WTRU ID should be updated. The R-WTRU may (e.g., if the indication is to update the peer WTRU ID) assign the new IP address to the T-WTRU and / or assign (e.g., self-assign) a new L2 ID and / or a new IP address of the R-WTRU to communicate with the T-WTRU via the PC5 link with the T-WTRU. The R-WTRU may repeat these operations for multiple (e.g., all) WTRUs and the PC5 links associated with those T-WTRUs (e.g., as specified by the S-WTRU in the update request message).

[0113] At 2, the R-WTRU may send a link identifier update request message to one or more T-WTRUs specified by the S-WTRU. Such a message may include, for example, one or more of the following: the new L2 ID of the R-WTRU, the new IP address of the R-WTRU, the new IP address of the T-WTRU, the old IP address of the S-WTRU, the user information of the S-WTRU, and / or the new IP address of the S-WTRU.

[0114] The T-WTRU may save the new IP address provided by the R-WTRU and / or may generate (e.g., automatically generate) a new L2 ID of the T-WTRU itself. The T-WTRU may retrieve information about the S-WTRU based on the old IP address of the S-WTRU and / or the user information of the S-WTRU (e.g., from T-WTRU records or entries stored by the T-WTRU). The T-WTRU may save the new IP address of the S-WTRU and / or other information related to the PC5 link between the S-WTRU and the T-WTRU provided by the R-WTRU (e.g., the new L2 ID, IP address, etc.). At 3, the T-WTRU may reply to the R-WTRU by sending a link identifier update response message. Such a message may include the new L2 ID of the T-WTRU and / or parameters received by the T-WTRU via the update request message sent by the R-WTRU at 2 (e.g., to confirm receipt of these parameters).

[0115] The R-WTRU may receive a response message (e.g., a link identifier update response message) from the T-WTRU (or T-WTRUs). The R-WTRU may save the new L2 ID indicated by the T-WTRU and send a link identifier update response message to the S-WTRU at 4. Such a message may include one or more of the following: the new IP address of the S-WTRU, the user information of the T-WTRU, the old IP address of the T-WTRU, the new IP address of the T-WTRU, the new L2 ID of the R-WTRU, and / or the new IP address of the R-WTRU.

[0116] Before sending the link identifier update response message to the S-WTRU, the R-WTRU may (e.g., if more than one T-WTRU was specified by the S-WTRU at step 1) wait to receive link identifier update response messages from one or more (e.g., all) of the T-WTRUs specified by the S-WTRU. Waiting for these T-WTRUs may be limited (e.g., controlled) by a timer, the expiration of which may indicate that the maximum waiting period for the T-WTRUs to respond has passed. For example, when (e.g., at) sending the link identifier update request message to the T-WTRU, the R-WTRU may start the timer. At the expiration of the timer, the R-WTRU may send the link identifier update response message described herein to the S-WTRU.

[0117] The S-WTRU may save its new IP address, the new IP address of the T-WTRU, and / or the new L2 ID and / or IP address of the R-WTRU. At 5, the S-WTRU may send a link identifier update ACK message to the R-WTRU. The ACK message may include, for example, the parameters received in the response message sent by the R-WTRU at 4 (e.g., to confirm receipt of those parameters).

[0118] At 6, the R-WTRU may send a link identifier update ACK message to one or more T-WTRUs. The ACK message may include, for example, the parameters received in the response message sent by the T-WTRU at 3. At 7, the S-WTRU, the R-WTRU, and / or one or more T-WTRUs may start using their new IP addresses for IP data exchange. For example, once data has been received using the new IP address (e.g., by one or more of the WTRUs), the old IP address of the WTRU may be released or deleted.

[0119] At Figure 5In the example shown, the S-WTRU may obtain a new IP address from another entity (e.g., in addition to the R-WTRU), and may specify this new IP address on the link identifier update request message sent at 1 (e.g., instead of indicating that the new IP address will be assigned to the S-WTRU). In these cases, the T-WTRU may perform its new IP address (e.g., obtained from another entity) on the link identifier update response message sent at 3 (e.g., without specifying the IP address on the link identifier update request message sent by the R-WTRU at 2). The R-WTRU may track (e.g., save) the new IP addresses of the S-WTRU and the T-WTRU (e.g., the R-WTRU does not assign new IP addresses to the S-WTRU and the T-WTRU).

[0120] The R-WTRU may trigger a change in the identifiers of other WTRUs including the S-WTRU and the T-WTRU. For example, the R-WTRU may assign a new identifier (e.g., a new IP address) to the S-WTRU. The R-WTRU may send the new IP address to the S-WTRU, for example, via one or more identifier update operations (e.g., as part of a link identifier update procedure). In these examples, the R-WTRU may send a link identifier update request message to the S-WTRU (e.g., instead of the S-WTRU sending to the R-WTRU). The S-WTRU may respond with a list of T-WTRUs that will be informed of the new IP address of the S-WTRU, and the R-WTRU may inform the T-WTRUs in this list about the new IP address of the S-WTRU. The R-WTRU may assign a new identifier (e.g., a new IP address) to the T-WTRU by similar operations (e.g., by reversing the roles of the S-WTRU and the T-WTRU).

[0121] A trigger to cause the R-WTRU to change its IP address (e.g., of an S-WTRU or T-WTRU) can be linked to a trigger to change other identifiers such as the application layer ID. For example, when the application layer ID is being changed, one or more (e.g., all) PC5 interfaces associated with the application layer ID on the R-WTRU can also be updated along with the associated IP address and L2 ID. The R-WTRU can initiate link identifier update operations (e.g., as part of a link identifier update procedure) on multiple PC5 links (e.g., simultaneously). These PC5 links can include, for example, a link to an S-WTRU and a link to a T-WTRU. The R-WTRU may not know which WTRUs are communicating with each other, so the R-WTRU can wait for the S-WTRU to transmit a list of T-WTRUs to the R-WTRU (e.g., included in a link identifier update response message from the S-WTRU). The R-WTRU can send the new IP addresses of the T-WTRUs back to the S-WTRU in a link identifier update ACK message (e.g., once the list of T-WTRUs is received). Multiple T-WTRUs can communicate with the S-WTRU, so before the R-WTRU sends a link identifier update ACK message to the S-WTRU (e.g., including the new IP addresses of multiple T-WTRUs), the R-WTRU can wait for a response from one or more (e.g., all) of the designated T-WTRUs after the R-WTRU triggers the change of the IP addresses of these T-WTRUs, or the R-WTRU can wait for the expiration of a timer. This can allow one or more (e.g., all) of the T-WTRUs to start receiving IP data using their new IP addresses.

[0122] Figure 6 Exemplary operations associated with an IP address change triggered by the R-WTRU are shown. At 0, a first sidelink (e.g., a PC5 unicast link) can be established between the S-WTRU and the R-WTRU, and a second sidelink (e.g., a PC5 unicast link) can be established between the R-WTRU and the T-WTRU (e.g., corresponding PC5 links can be established between the R-WTRU and one or more T-WTRUs). The S-WTRU can discover the T-WTRU, for example, by sending a DNS query request to the R-WTRU (e.g., including the user information of the T-WTRU). The R-WTRU can send, for example, a DNS response with the IP address of the T-WTRU. Then IP data can be exchanged between the S-WTRU and the T-WTRU through the R-WTRU and through the PC5 link.

[0123] The R-WTRU may be informed (e.g., via the application layer, timer-based expiration, etc.) that its IP address and / or other identifiers (e.g., application layer ID, L2 ID, etc.) will change. In response, the R-WTRU may trigger one or more link identifier update operations (e.g., as part of a link identifier update procedure). For example, the R-WTRU may generate (e.g., automatically generate) its own new L2 ID and / or new IP address, retrieve information about one or more peer WTRUs (e.g., S-WTRU and T-WTRU), and / or assign the new IP address to the peer WTRUs. At 1, the R-WTRU may send a link identifier update request message to the peer WTRUs (e.g., each of the peer WTRUs). Such a link identifier update request message may include, for example, the new IP address of the R-WTRU and / or the new IP address of the peer WTRUs.

[0124] At 2a, the S-WTRU may save the new IP address assigned by the R-WTRU and / or respond to the R-WTRU, e.g., by sending a link identifier update response message. The message may include, for example, the new IP address of the S-WTRU, user information associated with one or more T-WTRUs, and / or the IP addresses of one or more T-WTRUs. At 2b, the T-WTRU may (e.g., similar to the S-WTRU) save the new IP address assigned by the R-WTRU and / or respond to the R-WTRU, e.g., by sending a link identifier update response message. The message may include, for example, the new IP address of the T-WTRU and information about its peer (e.g., user information of the S-WTRU, the current IP address of the S-WTRU, etc.).

[0125] The R-WTRU may receive link identifier update response messages from its peer WTRUs (e.g., S-WTRU and T-WTRU). At 3, the R-WTRU may send (e.g., synchronize) a link identifier update ACK message to one or more (e.g., each) of the peer WTRUs. The ACK message sent to the S-WTRU may include, for example, user information associated with one or more T-WTRUs, the old IP addresses of one or more T-WTRUs, and / or the new IP addresses of one or more T-WTRUs, where the one or more T-WTRUs may include those described in association with 2 (e.g., as indicated on the link identifier update response message from the S-WTRU). Similar ACK messages may be sent to one or more T-WTRUs. Such ACK messages may include, for example, the old IP address of the S-WTRU, the new IP address of the S-WTRU, user information associated with the S-WTRU, etc.

[0126] At 4, the S-WTRU and / or T-WTRU may start using its new IP address and the new IP address of its peer WTRU for IP data exchange. Even though Figure 6 The example shows a relay WTRU triggering an identifier change. The relay WTRU (e.g., R-WTRU) may also be configured not to trigger the change and may rely on one or more peer WTRUs to trigger the identifier change (e.g., via a link identifier updater).

[0127] At Figure 6 In the example shown, the S-WTRU and / or T-WTRU may obtain a new IP address from another entity (e.g., other than the R-WTRU). In those scenarios, the R-WTRU may not specify the new IP address of the S-WTRU or T-WTRU and may learn the address from a link identifier update response message sent by the S-WTRU or T-WTRU.

[0128] An end-to-end (E2E) sidelink (e.g., a PC5 unicast link) may be established between the S-WTRU and the T-WTRU, for example, above the IP layer. One or more of the following operations may be performed over this E2E link. These operations may be triggered, for example, by a peer update message in which the S-WTRU may indicate that the peer WTRU identifier should not be updated and that the new IP address of the S-WTRU should not be informed to the peer WTRU. The S-WTRU may use the E2E PC5 unicast link to directly inform the T-WTRU of the change.

[0129] Figure 7 An exemplary protocol stack for the E2E PC5 unicast link is shown. Even though the figure shows a MAC layer, an RLC layer, and a PDCP layer above the IP layer, the stack may or may not include these layers. For example, if there is no security protection on the PC5 unicast link between the S-WTRU / T-WTRU and the R-WTRU, and / or if the R-WTRU associated with the S-WTRU / T-WTRU is not trusted, the stack may include the MAC, RLC, and PDCP layers above the IP layer.

[0130] Figure 8Illustrates exemplary operations associated with establishing an E-to-E PC5 unicast link. As shown, at 1 and 2, the S-WTRU may retrieve the IP address of the T-WTRU via DNS queries and DNS responses. At 3, the S-WTRU may encapsulate a Direct Communication Request (DCR) message into an IP packet. The source IP address (e.g., for the S-WTRU) is shown as IPa in the figure, and the destination IP address (e.g., for the T-WTRU) is shown as IPb in the figure. The S-WTRU may send the DCR message (e.g., encapsulated within the IP packet) to the R-WTRU associated with the S-WTRU and the T-WTRU via the PC5 unicast link. The R-WTRU may forward the encapsulated DCR message to the T-WTRU, for example, based on IP routing over the unicast PC5 link with the T-WTRU. The S-WTRU and the T-WTRU may use, for example, the Generic Routing Encapsulation (GRE) protocol to encapsulate one or more PC5 signaling (PC5-S) messages. For example, information such as tunneling protocol capabilities / preferences (e.g., GRE, IP, etc.) may be provided to the R-WTRU during link establishment between the S-WTRU and the R-WTRU and / or between the T-WTRU and the R-WTRU. The R-WTRU may store the information locally (e.g., stored in a corresponding DNS record or entry). The tunneling protocol capabilities / preferences may be provided by the R-WTRU (e.g., in the DNS response) to a WTRU (e.g., the S-WTRU or the T-WTRU) that can perform peer WTRU discovery (e.g., via DNS queries). The WRTU may select a preferred tunneling protocol that can be supported by the peer WTRU.

[0131] As Figure 8 shown, at 4, the T-WTRU (e.g., after receiving the DCR message) may send a Direct Communication Accept (DCA) message (e.g., encapsulated into an IP packet) to the S-WTRU, at which point the S-WTRU and the T-WTRU may communicate via an E-to-E PC5 unicast link established over the IP layer between the S-WTRU and the T-WTRU. The E-to-E PC5 unicast link packets between the S-WTRU and the T-WTRU may be encapsulated into IP packets and forwarded by the R-WTRU. For example, if the PC5 links between the S-WTRU and the R-WTRU and between the R-WTRU and the T-WTRU are secured (e.g., in terms of confidentiality, integrity, and / or replay), the E-to-E PC5 link between the S-WTRU and the T-WTRU may not include a security protection layer (e.g., the security establishment operation may be skipped, or the S-WTRU and the T-WTRU may agree not to apply security protection).

[0132] Figure 9Shows an example of performing a link identifier (e.g., IP address) update using an E-to-E PC5 unicast link between an S-WTRU and a T-WTRU. At the operations 1 to 4 in Figure 9 can be similar (e.g., the same) to the operations 1 to 4 in Figure 8 . Therefore, the description of operations 1 to 4 will not be repeated here. At 5, the S-WTRU can trigger one or more link identifier update operations (e.g., as part of a link identifier update procedure) to update the link identifier (e.g., including the IP address) of the S-WTRU via the PC5 unicast link between the S-WTRU and the R-WTRU associated with the S-WTRU. The S-WTRU can indicate to the R-WTRU that a new IP address will be assigned to the S-WTRU and the old IP address of the S-WTRU will be retained (e.g., for at least a period of time). The S-WTRU can obtain a new IP address (e.g., IPc) from the R-WTRU (e.g., via the operations shown in Figure 9 ).

[0133] At 6, the S-WTRU can send a link identifier update request message to the T-WTRU via the established E-to-E PC5 unicast link. The message can be encapsulated into an IP packet, for example, with the destination IP address set to IPb and the source IP address set to IPa. The link identifier update request message can indicate the new IP address (e.g., IPc) and / or the old IP address (e.g., IPa) of the S-WTRU.

[0134] At 7, the T-WTRU can decide to change its own IP address and can trigger one or more link identifier update operations (e.g., as part of a link identifier update procedure) via the PC5 unicast link between the T-WTRU and the R-WTRU. The T-WTRU can obtain a new IP address (e.g., IPd) from the R-WTRU (e.g., during the update operation). The T-WTRU can indicate to the R-WTRU that the new IP address will be assigned to the T-WTRU and / or the old IP address of the T-WTRU will be retained (e.g., for at least a period of time).

[0135] At 8, the T-WTRU can send a link identifier update response message to the S-WTRU via the E-to-E PC5 unicast link. The message can be encapsulated into an IP packet, for example, with the destination IP address set to IPa and the source IP address set to IPb. If at 7, the T-WTRU obtains a new IP address (e.g., IPd), the link identifier update response can indicate the new IP address of the T-WTRU. The link identifier update response can also indicate the old IP address (e.g., IPb) of the T-WTRU.

[0136] At 9, the S-WTRU may send a link identifier update ACK message to the T-WTRU over an E-to-E PC5 unicast link. The message may be encapsulated, for example, in an IP packet with the destination IP set to IPb and the source IP address set to IPa. The link identifier update ACK message may indicate the new IP address of the T-WTRU (e.g., IPd) and / or the old IP address of the T-WTRU (e.g., IPb), as received, for example, in the link identifier update response message.

[0137] After 9, the S-WTRU and the T-WTRU may use their newly assigned IP addresses, e.g., IPc and IPd, and may stop using their old IP addresses (e.g., IPa and IPb). The relay WTRU may release or delete the old IP addresses (e.g., after an inactive period) and may maintain (e.g., store) the association with the new IP addresses.

[0138] The link identifier update request, response, and confirmation messages (e.g., transmitted at 6, 8, and 9, respectively) may be implemented, for example, using other types of PC5 signaling (e.g., such as one or more link modification messages or one or more link IP address update messages), as discussed herein.

[0139] The S-WTRU may indicate whether another WTRU (e.g., the relay WTRU) is authorized to share the S-WTRU's IP address (e.g., share the S-WTRU's IP address with one or more T-WTRUs). For example, the S-WTRU may indicate to the relay WTRU whether the relay WTRU may share the S-WTRU's IP address with other WTRUs without authorization from the S-WTRU. The S-WTRU may provide information to the relay WTRU to allow the relay WTRU to verify whether the requesting WTRU is authorized to receive the S-WTRU's IP address. For example, if the IP address of the T-WTRU is protected (e.g., for privacy reasons), it may also be necessary to first authorize the R-WTRU (e.g., via a DNS query authorization) before the R-WTRU can disclose the T-WTRU's IP address to the S-WTRU (e.g., in response to a DNS query from the S-WTRU).

[0140] A DNS token (e.g., a Query Authorization Token (DQAT)) may be provided to the S-WTRU (e.g., pre-provided). The token (e.g., DQAT) may be protected for confidentiality, integrity, and / or replay prevention (e.g., to prevent malicious retransmission of the token). The token may be for single use or reusable (e.g., for multiple uses). The validity of the token may be bounded by time, usage, and / or resource exhaustion (e.g., limited to certain T-WTRUs, certain number of times the token may be used, a certain time of day the token may be used, or a certain quantity of bytes the token may be used to transmit). Distribution of the token (e.g., DQAT) may be facilitated out-of-band or in-band, e.g., by the R-WTRU after or during a successful DNS query. The prior authorization (e.g., via an authorization token) as described herein may be authenticated or unauthenticated and may be provided by the S-WTRU or the T-WTRU.

[0141] Figure 10 Exemplary operations associated with authorized IP address sharing are shown. At 1, the S-WTRU may send an indication to the R-WTRU indicating that the R-WTRU requires authorization to share the S-WTRU's IP address. The S-WTRU may send a token (e.g., along with the authorization indication) to the relay WTRU for use in verifying queries regarding the S-WTRU's IP address. The S-WTRU may send the indication and / or token to the R-WTRU, e.g., during and / or upon establishment of the PC5 link with the R-WTRU. The S-WTRU may send an indication to the R-WTRU indicating that the R-WTRU does not require authorization to share the S-WTRU's IP address with other WTRUs. The default setting (e.g., if the S-WTRU does not provide an indication) may be that the R-WTRU requires authorization to share the S-WTRU's IP address.

[0142] The tokens as described herein may be authenticated. For example, the token may be valid only for certain R-WTRUs and / or for a certain usage of the R-WTRU associated with the token ID (e.g., similar to an airplane ticket that is valid only for the person on the ticket). The tokens as described herein may be unauthenticated. For example, the token may be valid for use by any R-WTRU and / or may be used subject to other conditions such as a limit on the number of uses (e.g., once, twice, N times, etc. within the current month). The relay WTRU may track the indication and / or token provided by the WTRU (e.g., S-WTRU or T-WTRU) along with, e.g., the WTRU's user information, IP address, and / or PC5 related information. One or more of the operations described herein with reference to the S-WTRU (e.g., between the S-WTRU and the R-WTRU) may also be performed for the T-WTRU (e.g., between the T-WTRU and the R-WTRU).

[0143] At 2, the relay WTRU may receive from the T-WTRU a DNS query message specifying user information associated with the S-WTRU (e.g., along with a token). The relay WTRU may scrape (e.g., look up) information about the S-WTRU in response to receiving the query message (e.g., based on the user information provided by the T-WTRU). The relay WTRU may determine, for example based on the scraped information, that the S-WTRU needs authorization (e.g., an indication that authorization is needed may have been received or set). The relay WTRU may verify the token received from the T-WTRU with a token received from and / or saved for the S-WTRU (e.g., if a token was received from the T-WTRU in the DNS query). If the tokens match, the relay WTRU may send a DNS response with the IP address of the S-WTRU to the T-WTRU. If the tokens do not match, the relay WTRU may not send a response to the T-WTRU, or may indicate to the T-WTRU that it is not authorized to receive the IP address of the S-WTRU.

[0144] At 3, the relay WTRU may send a PC5 message (e.g., a link authorization request) to the S-WTRU (e.g., if no token was received from the T-WTRU or no token has been provided by the S-WTRU), for example, requesting authorization to share the IP address of the S-WTRU with the T-WTRU. The link authorization request may include parameters such as the user information of the T-WTRU, the IP address of the T-WTRU, and / or the token received in the DNS query (e.g., if any).

[0145] At 4, the S-WTRU may receive the link authorization request and reply with a PC5 link authorization accept or reject message (e.g., with parameters such as the user information of the T-WTRU, etc.). The S-WTRU may also provide the relay WTRU with a token that the relay WTRU can use to determine whether to authorize future DNS queries regarding the S-WTRU. The S-WTRU may decide to grant or deny authorization based on policies set by the S-WTRU and / or the network, authorizations received from the application layer, etc.

[0146] If the R-WTRU is authorized (e.g., if the tokens from the S-WTRU and T-WTRU match, or if the S-WTRU accepts the authorization request), then at 5, the relay WTRU may send a DNS response with the IP address of the S-WTRU to the T-WTRU. If not authorized (e.g., if the tokens do not match, or if the S-WTRU rejects the authorization request), then the relay WTRU may not send a response to the T-WTRU, or may indicate to the T-WTRU that it is not authorized to receive the IP address of the S-WTRU. The R-WTRU may track the tokens provided by the S-WTRU and may send one or more tokens to the T-WTRU. The T-WTRU may use the tokens to send future query messages (e.g., DNS query messages) to discover the IP address of the S-WTRU.

[0147] One or more of the DNS messages described herein (e.g., DNS query messages) may be sent via the control plane. For example, if the S-WTRU and T-WTRU are configured to communicate via the R-WTRU as discussed herein, the user plane may not be protected for confidentiality (e.g., the messages may not be encrypted). In those cases, the IP address of the source WTRU may be used to track the source WTRU (e.g., because the IP address of the source WTRU may be sent to a malicious WTRU that uses the DNS query for the IP address of the source WTRU). In these cases, even if the source WTRU periodically changes its IP address, it may still be tracked by the malicious WTRU (e.g., by looking at the DNS messages sent by other WTRUs and / or the data traffic sent to / from the source WTRU).

[0148] To prevent the source WTRU from being tracked or otherwise compromised, the WTRU may be configured to send DNS messages via the control plane interface (e.g., as a PC5-S message). The application layer may interface with the lower layer (e.g., the ProSe layer) to send or receive DNS messages. The ProSe layer may send a PC5-S DNS message via the control plane, which may be protected for confidentiality (e.g., the message may be encrypted). The ProSe layer may deliver the received PC5-S DNS message to the application layer in a consistent manner. In this way, a malicious WTRU cannot learn the IP address of another WTRU by listening to DNS queries and / or response messages associated with other WTRUs.

[0149] One or more DNS messages (e.g., DNS query messages) described herein may be transmitted or received over a user plane bearer that can be protected by specific confidentiality protection. Different bearers and / or LCIDs may be used at the user plane interface. For example, a first bearer and / or LCID with confidentiality protection (e.g., encryption) may be used to transmit or receive DNS messages, and a second bearer and / or LCID (e.g., which may or may not be confidentiality protected) may be used to transmit or receive other data traffic (e.g., non-DNS traffic). Whether a bearer or LCID is confidentiality protected may be determined based on user plane security negotiation (e.g., during link establishment).

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

Claims

1. A wireless transmit / receive unit (WTRU) configured to act as a relay between a first WTRU and a second WTRU, the WTRU comprising: a processor configured to: receive a link identifier update request from the first WTRU, wherein the link identifier update request indicates a request for a new Internet Protocol (IP) address, and the link identifier update request further includes a request to update the second WTRU with the new IP address of the first WTRU; determine the new IP address of the first WTRU in response to receiving the link identifier update request; send a relay update request to the second WTRU, wherein the relay update request indicates the new IP address determined for the first WTRU; and send a link identifier update response to the first WTRU, wherein the link identifier update response indicates the new IP address determined for the first WTRU.

2. The WTRU according to claim 1, wherein the link identifier update request further includes identification information associated with the second WTRU, and wherein the processor is configured to send the relay update request to the second WTRU based on the identification information associated with the second WTRU.

3. The WTRU according to claim 2, wherein the identification information associated with the second WTRU includes at least one of an IP identifier of the second WTRU or application layer information associated with the second WTRU.

4. The WTRU according to claim 1, wherein before sending the link identifier update response to the first WTRU, the processor is further configured to receive from the second WTRU a message acknowledging receipt of the new IP address determined for the first WTRU.

5. The WTRU according to claim 1, wherein the processor is further configured to receive from the first WTRU a message acknowledging receipt of the new IP address determined for the first WTRU.

6. The WTRU according to claim 1, wherein the processor is further configured to receive an IP packet using the new IP address from the first WTRU, and wherein the processor is further configured to forward the IP packet to the second WTRU.

7. The WTRU according to claim 1, wherein the link identifier update request includes a token, and wherein the processor being configured to send the relay update request to the second WTRU includes the processor being configured to: receive a query from the second WTRU regarding the new IP address determined for the first WTRU; verify the query based on the token; and send the relay update request to the second WTRU in response to successfully verifying the query based on the token.

8. The WTRU according to claim 1, wherein the processor being configured to send the relay update request to the second WTRU includes the processor being configured to: Receive a query regarding the new IP address determined for the first WTRU from the second WTRU; And in response to receiving the query, send the relay update request to the second WTRU.

9. A method implemented by a WTRU configured to act as a relay between a first wireless transmit / receive unit (WTRU) and a second WTRU, the method comprising: Receive a link identifier update request from the first WTRU, wherein the link identifier update request indicates a request for a new Internet Protocol (IP) address, and the link identifier update request further includes a request to update the second WTRU with the new IP address of the first WTRU; In response to receiving the link identifier update request, determine the new IP address of the first WTRU; Send a relay update request to the second WTRU, wherein the relay update request indicates the new IP address determined for the first WTRU; And Send a link identifier update response to the first WTRU, wherein the link identifier update response indicates the new IP address determined for the first WTRU.

10. The method according to claim 9, wherein the link identifier update request further includes identification information associated with the second WTRU, the identification information including at least one of an IP identifier of the second WTRU or application layer information associated with the second WTRU, and wherein the relay update request is sent to the second WTRU based on the identification information associated with the second WTRU.

11. The method according to claim 9, further comprising receiving a message from the second WTRU confirming receipt of the new IP address determined for the first WTRU.

12. The method according to claim 9, further comprising receiving a message from the first WTRU confirming receipt of the new IP address determined for the first WTRU.

13. The method according to claim 9, further comprising receiving an IP packet using the new IP address from the first WTRU and forwarding the IP packet to the second WTRU.

14. The method according to claim 9, wherein the link identifier update request includes a token, and wherein sending the relay update request to the second WTRU includes: Receive a query regarding the new IP address determined for the first WTRU from the second WTRU; Verify the query based on the token; And In response to successfully verifying the query based on the token, send the relay update request to the second WTRU.

15. The method according to claim 9, wherein sending the relay update request to the second WTRU includes: Receive a query regarding the new IP address determined for the first WTRU from the second WTRU; And In response to receiving the query, send the relay update request to the second WTRU.

Images