METHOD AND APPARATUS FOR PRIVACY HANDLING IN PROSe LAYER 2 UE TO NETWORK RELAY OPERATION

Abstract

A relay wireless transmit-receive unit (WTRU) is configured to communicate with a network and a remote WTRU, and to receive a link identifier update (LIU) request message that includes a new MSB of a new remote WTRU L2ID and a new secure identifier (ID). The relay WTRU generates a new relay WTRU L2ID and a new LSB of the new security ID. The relay WTRU sends a request for a new remote WTRU ID to the network, and receives the new remote WTRU ID associated with the new L2ID. And the relay WTRU sends the new remote WTRU ID and the LIU response message to the remote WTRU. The relay WTRU receives an acknowledgement message. Thereafter, the new remote WTRU ID is used for communication among the remote WTRU, the relay WTRU and the gNB.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 410,478, filed on September 27, 2022, which is incorporated herein by reference in its entirety. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] A more detailed understanding can be obtained from the following detailed description, which is given by way of example in conjunction with its accompanying drawings. As with the detailed description, the figures in such drawings are exemplary. Therefore, the drawings and detailed description should not be considered limiting, and other equally effective examples are possible and expected. In addition, like reference numerals ("ref.") in the accompanying drawings ("Figures") indicate similar elements, and wherein:

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

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

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

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

[0008] Figure 2 is a block diagram illustrating an architectural model for a Layer 2 WTRU to network relay;

[0009] Figure 3 is a diagram illustrating a user plane protocol stack for a layer 2 WTRU to network relay;

[0010] Figure 4 is a diagram illustrating a control plane protocol stack for a layer 2 WTRU to network relay;

[0011] Figure 5 is a signal flow diagram illustrating the signals followed for Layer 2 U2N remote WTRU connection establishment;

[0012] Figure 6 is a diagram illustrating a PC5 security key hierarchy;

[0013] Figure 7 is a signal flow diagram illustrating the signal flow for a link identifier update procedure;

[0014] Figure 8 is a signal flow diagram illustrating signal flow for a relay WTRU to request a new Remote UE ID from a gNB in ​​accordance with some embodiments;

[0015] Fig. 8A is a flow chart of an example relay WTRU procedure according to one embodiment;

[0016] Fig. 9 is a signal flow diagram illustrating signal flow for a remote WTRU to request a new remote UE ID from a gNB in ​​accordance with some embodiments;

[0017] Fig.10 is a signal flow diagram illustrating signal flow for a relay WTRU to trigger a privacy procedure and request a new Remote UE ID from a gNB in ​​accordance with some embodiments; and

[0018] Fig.11 is a signal flow diagram illustrating the signal flow for triggering a privacy procedure and configuration of a new remote UE ID from a gNB triggered by the gNB according to some embodiments. DETAILED DESCRIPTION

[0019] In the following specific embodiments, many specific details are set forth to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it should be understood that such embodiments and examples can be practiced without some or all of the specific details set forth herein. In other cases, well-known methods, procedures, components, and circuits are not described in detail to avoid blurring the following description. In addition, embodiments and examples not specifically described herein can be practiced in place of embodiments and other examples explicitly, implicitly, and / or inherently described, disclosed, or otherwise provided (collectively referred to as "provided") herein, or practiced in combination with these embodiments and examples.

[0020] Example Communication System

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

[0022] like Figure 1A As 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 UE 102a, 102b, 102c, 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to send and / or receive wireless signals and may include a user equipment (WTRU), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated process chain environment), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0023] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device that is configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNode B, a Home Node B, a Home eNode B, a gNB, an NR Node B, a site controller, an access point (AP), a wireless router, and the like. Although the base stations 114a, 114b are each depicted as a single element, it should be appreciated 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 (BSC), radio network controllers (RNC), relay nodes, etc. Base station 114a and / or base station 114b may be configured to send and / or receive wireless signals on one or more carrier frequencies (which may be referred to as cells (not shown)). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of a licensed spectrum and an 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. The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In 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 send and / or receive signals in a desired spatial direction.

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

[0026] More specifically, as noted above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 116. WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink Packet Access (HSDPA) and / or High Speed ​​Uplink 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) that may establish the air interface 116 using Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro).

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

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

[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., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), and GSM EDGE (GERAN).

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

[0032] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have 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 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not described in detail in the text and video, the CN 106 / 115 may be configured to provide voice, data, applications and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Figure 1AAlthough not shown in the figure, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

[0035] Figure 1B is a system diagram illustrating an example WTRU 102. Figure 1B As shown, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

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

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

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

[0039] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and to demodulate signals received by the transmit / receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. For example, the transceiver 120 may include multiple transceivers for enabling 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 and may receive user input data from a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, and a secure digital (SD) memory card, among others. In other embodiments, the processor 118 may access information from and store data in a memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

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

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

[0043] The processor 118 may also be coupled to other peripherals 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, module, FM radio unit, digital music player, media player, video game player module, Internet browser, virtual reality and / or augmented reality (VR / AR) device and activity tracker, etc. Peripheral device 138 may include one or more sensors, which may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, orientation sensor, proximity sensor, temperature sensor, time sensor; geolocation sensor; altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor and / or humidity sensor.

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

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

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

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

[0048] Figure 1C The illustrated CN 106 may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements is depicted as being 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 an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, and selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

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

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

[0052] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may be in communication with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired networks and / or wireless networks owned and / or operated by other service providers.

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

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

[0056] When using the 802.11ac infrastructure operation mode or a similar operation mode, the AP may send beacons on a fixed channel (such as a primary channel). The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a width dynamically set via signaling. The primary channel may be an operating channel of the BSS and may be used by the STA to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access / collision avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. For CSMA / CA, a STA (e.g., each STA) (including the AP) may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

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

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

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

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

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

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

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

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

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

[0066] Each of the gNBs 180a, 180b, 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in uplink (UL) and / or downlink (DL), support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards a user plane function (UPF) 184a, 184b, routing of control plane information towards an access and mobility management function (AMF) 182a, 182b, etc. As shown in FIG. Figure 1D As shown, gNBs 180a, 180b, and 180c may communicate with each other via an 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 a data network (DN) 185a, 185b. While each of the foregoing elements is depicted as part of the 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 WTRU 102a, 102b, 102c, support of network slicing (e.g., handling of different packet data unit (PDU) sessions with different requirements), selecting a specific SMF 183a, 183b, management of registration areas, termination of non-access stratum (NAS) signaling, mobility management, etc. The AMF 182a, 182b may use network slicing in order to customize CN support for the WTRU 102a, 102b, 102c based on the type of services utilized by the WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced mobile broadband (eMBB) access, and / or services for machine type communication (MTC) access, etc. The AMF a82a, 182b may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[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 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 notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

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

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

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

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

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

[0075] The examples provided herein do not limit the applicability of the subject matter to other wireless technologies, eg, using the same or different principles may be applicable.

[0076] As explained herein, a wireless transmit / receive unit (WTRU) may be an example of a user equipment (UE). Hence, the terms UE and WTRU may be used interchangeably herein.

[0077] Proximity Services (ProSe) and Privacy

[0078] Layer 2 WTRU to Network Relay

[0079] Layer 2 WTRU to Network Relay provides functionality to support connectivity to a network via Layer 2 remote WTRU forwarding via the AS (Access Stratum) layer. Figure 2 An architectural model for a layer 2 WTRU to network relay is shown. As can be seen, the remote WTRU communicates with the relay WTRU over a PC5 interface, and the relay WTRU communicates with the radio access network (RAN) over a Uu interface. Figure 3 The data plane protocol stack for a Layer 2 WTRU to network relay is shown, and Figure 4 The control plane protocol stack for a Layer 2 WTRU to network relay is shown.

[0080] After the PC5 session is established between the Layer 2 Remote WTRU 201 and the Layer 2 WTRU to Network Relay WTRU 203 , the Layer 2 WTRU to Network Relay forwards RRC signaling and traffic between the Layer 2 Remote WTRU 203 and the RAN 205 .

[0081] A PC5 link is uniquely identified by a PC5 link identifier during the lifetime of the link and the two communicating WTRUs are identified using a 24-bit Layer 2 UE ID. A packet on PC5 includes the Layer 2 UE IDs of the source WTRU and the target WTRU.

[0082] An adaptation layer is used on the remote WTRU 201, U2N relay and gNB to support L2 U2N relay. More details on this layer are provided below.

[0083] Sidelink Relay Adaptation Protocol

[0084] A new adaptation layer called Sidelink Relay Adaptation Protocol (SRAP) has been defined by RAN2 to support Layer 2 WTRU to Network (U2N) relay. The new SRAP sublayer is placed below the PDCP sublayer for both the control plane (CP) and the user plane (UP) at both the PC5 interface and the Uu interface.

[0085] Figure 5 1 is a signal flow diagram showing the signal flow for Layer 2 U2N Remote WTRU connection establishment as set forth in TS 38.300 v17.1.0 NR; General Description of NR and NG-RAN Phase 2; The U2N Relay WTRU is configured with the Remote UE ID by the gNB. The Remote WTRU obtains the Remote UE ID from the gNB via a Uu RRC message including: RRCSetup( Figure 5 Step 2), RRCReconfiguration( Figure 5 Step 6), RRCResume and RRCReestablishment

[0086] The Remote UE ID is included in both the PC5 SRAP header and the Uu SRAP header.

[0087] The gNB may update the Remote UE ID by transmitting the updated Remote ID via the RRCReconfiguration message. The gNB may perform the Remote UE ID update independently of the PC5 unicast link identifier update procedure.

[0088] The gNB configures the relay operation related configuration for the L2 U2N relay WTRU via an RRC reconfiguration message including sl-L2RelayUEConfig. sl-L2RelayUEConfig contains a list of remote WTRUs to be relayed via the associated relay WTRU and, for each WTRU, includes: (i) SL-DestinationIdentity, and (ii) SRAP configuration for use by that remote WTRU.

[0089] Even if the remote WTRU is out of coverage and connected to the network via the WTRU-to-network relay, the remote WTRU can still use the RRC protocol to talk to the gNB (e.g. Figure 4 (see ).

[0090] Privacy Policy

[0091] PC5 Security

[0092] A security context must be established for each unicast list. The security context includes K NRP-sess , NRPEK (if applicable), NRPIK, the selected confidentiality (if applicable) and integrity algorithms, and PDCP (Packet Data Convergence Protocol) counters used with each bearer. When a unicast link is rekeyed, the WTRU updates the security context associated with the unicast link. Once the unicast link is released, the WTRU deletes the security context associated with the unicast link.

[0093] Figure 6 The PC5 security key hierarchy is shown.

[0094] The different layers of the key are as follows:

[0095] (a) Long-term certificates: These are certificates that are provisioned into the WTRU and form a secure root for the PC5 unicast link. The certificates may include a symmetric key or a public / private key pair, depending on the specific use case. Authentication signaling is exchanged between the WTRUs to derive the K NRP .

[0096] (b)K NRP K: A 256-bit root key shared between two WTRUs communicating via a PC5 unicast link. NRP This can be refreshed by re-running authentication signaling using long-term credentials. The random number is exchanged between WTRUs and compared to K NRP Used together to generate K NRP-sess (Next level key). K may be maintained even when the WTRUs have no active unicast communication sessions between them. NRP ( Figure 6 601 in ). 32-bit K NRP ID is used to identify K NRP .

[0097] (c)K NRP-sess : This is the WTRU from K NRP A 256-bit key is derived and used to derive a key for protecting data transmission between WTRUs. NRP-sess (603) is derived for unicast links. During an active unicast communication session between WTRUs, K NRP-sess The actual keys used in the confidentiality and integrity algorithms are refreshed directly from K NRP-sess Export. 16 bit K NRP-sess ID Marking K NRP-

[0098] sess .

[0099] (d) NRPEK (605) and NRPIK (607): NRPC5 encryption key (NRPEK) and NR PC5 integrity key (NRPIK) are used in the selected confidentiality and integrity algorithms to protect PC5-S signaling, PC5 RRC signaling and PC5 user plane data respectively.

[0100] NRPEK and NRPIK are derived from K NRP-sess (603) derived, and each time K NRP-sess When changed, NRPEK and NRPIK are automatically refreshed.

[0101] Link Identifier Update Procedure

[0102] The Link Identifier Update (LIU) procedure has been defined during V2X R16 and reused in ProSe R17 / R18 to handle privacy and avoid WTRU tracking. At the same time, the LIU procedure enables the ID transmitted in the clear in the message header (MAC / PDCP) to be changed at the same time.

[0103] The ID needs to be changed during the same procedure run to ensure that there is no linkability, ie, if a new ID is transmitted together with the old ID, it is possible to link the new ID with the old ID and continue tracking the WTRU.

[0104] Figure 7 is a signal flow diagram illustrating the signal flows associated with a link identifier update procedure for Proximity Based Services (ProSe) in TS 23.304 v17.1.0 in a 5G System (5GS). Figure 7, at 700, a unicast link is established. Message 701 is a Link Identifier Update (LIU) Request that includes the changed Layer 2 ID for WTRU-1. In addition to the changed identifier, WTRU-1 also includes the new MSB (most significant byte) of the KNRP-sess ID in message 701. These bits are selected so that they uniquely identify the KNRP-sess at WTRU-1. The new MSB of the KNRP-sess ID is randomly selected.

[0105] After receiving message 701, WTRU-2 selects new LSBs (least significant bytes) of the KNRP-sess ID so that they uniquely identify the KNRP-sess at WTRU-2. The new LSBs of the KNRP-sess ID are randomly selected. WTRU-2 forms a new KNRP-sess ID based on the MSBs received from WTRU-1 and the LSBs selected by WTRU-2. WTRU-2 associates the new KNRP-sess ID with the updated Layer 2 ID and uses the new KNRP-sess ID when WTRU-2 uses the updated Layer 2 ID. At 702, WTRU-2 transmits a LIU Response message. In addition to its updated identifier, WTRU-2 also transmits the LSBs of the KNRP-sess ID to WTRU-1 in a Link Identifier Update Response message along with the received MSBs of the KNRP-sess ID and other identifiers received from UE-1.

[0106] After receiving the LIU Response message 702, WTRU-1 checks whether the returned MSBs of the KNRP-sess ID are the same as the MSBs it transmitted in the LIU Request message 701. If this check passes, WTRU-1 forms a new KNRP-sess ID (in message 701) based on the LSBs received from WTRU-2 and the MSBs selected by WTRU-1. WTRU-1 associates the new KNRP-sess ID with the updated Layer 2 ID and uses the new KNRP-sess ID when WTRU-1 uses the updated Layer 2 ID. WTRU-1 transmits a Link Identifier Update Ack message (message 703) to WTRU-2, which includes the LSBs of the KNRP-sess ID and the other identifiers received from WTRU-2. After receiving the LIU Ack message 703, WTRU-2 checks whether the returned LSBs of the KNRP-sess ID are the same as the LSBs transmitted in message 702.

[0107] At 704 and 705, after LIU is complete, the KNRP-sess ID is updated and used by WTRU-1 and WTRU-2 to locate the established security keys for PC5 RRC and UP ciphering and integrity.

[0108] Traceability / linkability threats

[0109] As specified in the section labeled Sidelink Relay Adaptation Protocol above, the serving gNB may perform remote UE ID update independently of the PC5 Link Identifier Update (LIU) procedure, i.e., using another procedure.

[0110] For the LIU procedure, all IDs carried in the header of the PC5 message need to be changed simultaneously to avoid linkability and privacy issues as specified in 3GPP TS 33.536v17.1.0 Security Aspects for Supporting Advanced Vehicle-to-Everything (V2X) Services. The LIU procedure for TS23.304v17.1.0 Proximity-based Services (ProSe) in the 5G System (5GS) allows all IDs to be updated during the same procedure running on two peer WTRUs via a three-way message exchange.

[0111] The introduction of the SRAP and Remote UE IDs specified in the PC5 message header introduces the possibility of traceability / linkability threats to the WTRU through potential eavesdropping of the Remote UE IDs exchanged in the clear. Therefore, it would be beneficial to mitigate such traceability / linkability threats due to the exchange of identifiers in the clear (e.g., in the SRAP header).

[0112] Implementation

[0113] The ProSe layer terminology is used throughout this document. This is merely exemplary, and it should be understood that the concepts expressed herein can be applied to similar application-specific layers, such as a ProSe-based V2X layer or a UAV Connected Everything (U2X) layer.

[0114] Various embodiments are presented in the following sections where the LIU procedure is triggered at the remote WTRU or at the U2N relay. Additionally, requesting a new remote UE ID from the gNB may be performed at the remote UE, the U2N relay WTRU, or both. Additionally, a change in the remote UE ID may be triggered at the gNB.

[0115] Identifier update triggered at the remote WTRU

[0116] The relay and possibly remote WTRU requests a new remote UE from the gNB during the LIU procedure ID

[0117] This embodiment supports the case where the remote WTRU triggers the LIU procedure and the relay WTRU (and possibly the remote WTRU) requests a new remote UE ID from the gNB during the LIU procedure (i.e., before the LIU procedure is completed).

[0118] Figure 8 is a signal flow diagram illustrating the signal flow for a remote WTRU and a relay WTRU to obtain a new remote UEID from a gNB according to some embodiments. Figure 8 The steps in are numbered 801 to 809 and correspond to the numbers in the following description.

[0119] (Step 801) A link identifier update procedure is triggered at the remote WTRU 820 (eg, a privacy timer expires or a trigger is received from the application layer). The remote WTRU generates a new ID (eg, a new source L2 ID and the MSB of a new KNRP-sess ID).

[0120] (Step 802) The remote WTRU 820 transmits a LIU request message to the relay WTRU 830 over an associated secure PC5 link. The current PC5 identifier is used to transmit the message, and the new ID is included in the message payload. The remote WTRU may include an indication for the relay WTRU to request a new remote UE ID from the gNB.

[0121] (Step 803) The relay WTRU 830 receives the LIU request message and also generates a new ID on its side (eg, a new target L2 ID and the LSB of the new KNRP-sess ID).

[0122] (Step 804) The relay WTRU 830 requests the gNB 840 to obtain an updated Remote UE ID associated with the Uu-SRAP and PC5-SRAP. The relay WTRU may transmit the request based on receipt of an indication in the LIU request message (message 802).

[0123] The relay WTRU retains the old Remote UE ID and the new Remote UE ID (i.e., the relay WTRU does not immediately replace the old Remote UE ID with the new value) because the old Remote UE ID may be used during a transient period before all UE IDs are updated. The relay WTRU may request a new Remote UE ID for the remote WTRU from the gNB using a SidelinkUEInformation message. The gNB may then configure the new Remote UE ID for the relay WTRU and for the remote WTRU using RRC signaling (e.g., RRC reconfiguration) messages transmitted to each WTRU. The relay WTRU 830 may provide the current Remote UE ID to the gNB 840 to allow the gNB to identify the Remote WTRU 820 that needs to be updated with the new Remote UE ID. The relay WTRU may indicate in its request to the gNB whether the gNB should configure the relay WTRU and / or the remote WTRU with the new Remote UE ID.

[0124] In more detail, the gNB generates a new remote UE ID (804.a) and transmits the remote UE ID to the relay WTRU (804.b) (and may also transmit the remote UE ID to the remote WTRU separately, 804.c). For example, in the case where the gNB has not configured the remote WTRU, the relay WTRU may provide the new remote UE ID to the remote WTRU in a PC5-RRC message (e.g., SidelinkReconfiguration message) (804d).

[0125] The gNB may keep using the current Remote UE ID until a message with a new Remote UE ID is received in the UL. Alternatively or in addition, the gNB may be configured with a timeout value for how long the current (old) Remote UE ID should be kept and monitored. This enables the gNB to forward packets in transit during the update procedure and avoid dropping packets.

[0126] The gNB may use a timer to periodically change the Remote UE ID. The gNB may restart this timer each time the Remote UE ID is updated (or the gNB may keep the old timer running and trigger the Remote UE ID Update procedure independently of the Remote UE ID Update triggered by the LIU procedure).

[0127] If the relay WTRU cannot obtain the new remote UE ID, the relay WTRU may transmit a LIU REJECT message with the cause value set to, for example, "Cannot obtain new remote UE ID".

[0128] (Step 805) Upon receiving the new Remote UE ID from the gNB (804.b), the Relay WTRU transmits a LIU Response message to the Remote WTRU, which includes the new Layer 2 ID of the Relay WTRU and the LSBs of the KNRP-sess ID. The Relay WTRU may include the new Remote UE ID (which it has received from the gNB in ​​804.b) in the LIU Response message to allow the Remote WTRU to verify whether the same Remote UE ID is also received at the Remote WTRU. Note that in Figure 8 In the process, all IDs in the current (already existing and established as being used) IDs (such as Remote WTRU L2 ID, Relay WTRU L2 ID and Security ID) are used in the message headers between devices (Remote WTRU, Relay WTRU, gNB) for message transmission until the new Remote WTRU ID is well established and accepted by the device.

[0129] (Step 806) If a new Remote UE ID is not received in steps 804c or 805, the remote WTRU may request a new Remote UE ID from the gNB (i.e., the same Remote UE ID that the relay WTRU received in step 804). RRC messages may be used to query the gNB, for example, a SidelinkUEInformation message, after which the gNB provides the ID in an RRCReconfiguration message.

[0130] The gNB transmits the new Remote UE ID to the Remote WTRU. The gNB keeps using the current Remote UE ID until a message with the new Remote UE ID is received in the UL. Alternatively or in addition, the gNB may be configured with a timeout value indicating the period for which the current (old) Remote UE ID should be kept and monitored.

[0131] Alternatively, step 806 may be omitted if the gNB or relay WTRU provides a new remote UE ID to the remote WTRU via RRC signaling (e.g., RRC reconfiguration) when requested by the relay WTRU in step 4 or via a LIU response message in step 805.

[0132] The remote WTRU may decide to query the gNB based on any of the following: (i) the remote WTRU may be configured (e.g., during U2N relay establishment or reconfiguration) such that whenever a LIU procedure is performed, it must be followed by a remote UE ID update request; (ii) the remote WTRU may decide whether to do so autonomously via specific implementation; (iii) depending on how long the remote UE ID has been in use since the last remote UE ID update (e.g., if it is recent, if it is very old, etc.).

[0133] (Step 807) Upon receiving the new Remote UE ID, the Remote WTRU completes the LIU procedure by transmitting a LIU Ack message to the Relay WTRU. If a new Remote UE ID is provided in the LIU Response from the Relay WTRU, the Remote WTRU may verify that the new Remote UE ID received from the gNB is the same as the Remote UE ID received from the Relay WTRU. If the Remote WTRU cannot obtain the new Remote UE ID, the Remote WTRU may decide to retry multiple times or terminate the PDU Session and the PC5 link to the Relay WTRU.

[0134] (Step 808) Upon receiving the LIU Ack message, the relay WTRU may transmit a message to the gNB indicating that the new Remote UE ID is ready to be used. The relay WTRU may indicate this to the gNB using a SidelinkUEInformation RRC message. Alternatively, the relay WTRU may indicate this implicitly by sending a data packet with the new Remote UE ID in the SRAP header. The indication of the readiness of the new Remote UE ID may be transmitted directly from the remote WTRU (e.g., the remote WTRU transmits Message 8 immediately after the LIU ACK).

[0135] (Step 809) At this point, the remote WTRU, relay WTRU and gNB begin using new IDs, including the new remote UE ID.

[0136] Fig. 8A is performed by a device such as Figure 8 Flowchart of an example procedure 850 performed by a WTRU relay 830 that illustrates the operations described in the signaling diagram of FIG. Fig. 8A , at 852, the relay WTRU receives a link identifier update (LIU) request message from the remote WTRU, the link identifier update (LIU) request message having a new remote WTRU layer 2 identifier (L2 ID) and a new MSB of a security identifier (ID). The new remote WTRU layer 2 identifier (L2 ID) and the new MSB of the security identifier (ID) may be referred to as first information.

[0137] exist Fig. 8A At 853, the relay WTRU generates information in response to the LIU request message, the information including a new relay WTRU L2 ID and a new LSB of a new security ID. The new relay WTRU L2 ID and the new LSB of the new security ID may be referred to as second information.

[0138] At 854, the relay WTRU sends a request for a new remote WTRU ID to the network, the request for a new remote WTRU ID including the current (already existing / established) remote WTRU ID. In one aspect, the relay sends the request for a new remote WTRU ID using a SidelinkUEInformation message.

[0139] At 854b, the relay WTRU receives a new Remote WTRU ID from the network, the new Remote WTRU ID being associated with a new Remote L2 ID, a new Relay L2 ID, and new MSBs / LSBs of a new Security ID. In one aspect, the relay WTRU receives the new Remote WTRU ID in a message to configure the Remote WTRU with the new Remote WTRU ID. At 854d, the relay WTRU sends the new Remote WTRU ID to the Remote WTRU. In one aspect, the relay WTRU sends the new Remote WTRU ID in a SidelinkReconfiguration message.

[0140] At 855, the relay WTRU sends a LIU response message to the remote WTRU, which includes the new relay L2ID and the new LSB of the new security ID. This may also be referred to as Fig. 8A Here, the relay WTRU uses the current remote WTRU L2 ID, the current relay L2 ID and the current security ID to send a LIU response message to the remote WTRU, the LIU response message including the new remote WTRU ID.

[0141] At 857, the relay WTRU receives an acknowledgement (ACK) message from the remote WTRU indicating an acknowledgement of the LIU response message at 855. Here, the relay WTRU receives the ACK message encapsulated in a header having the current remote WTRU L2 ID and the current relay L2 ID and the current security ID.

[0142] At 858, the relay WTRU sends a message to the network indicating to start using the new remote WTRU ID.

[0143] The relay WTRU has the new remote WTRU at 859. The relay WTRU may henceforth use the new WTRU L2ID and the new security ID to relay network to remote WTRU transmissions.

[0144] The remote WTRU requests a new remote UEID from the gNB

[0145] This embodiment enables the remote WTRU to request a new remote UE ID from the gNB and share the new remote UE ID with the relay WTRU during the LIU procedure (i.e., before the LIU procedure is completed).

[0146] Fig. 9 is a signal flow diagram illustrating an exemplary signal flow for such an embodiment. Fig. 9 The steps in are numbered 901 to 910 and correspond to the numbers in the following description.

[0147] (Step 901) A privacy procedure is triggered at the remote WTRU 920 (eg, a privacy timer expires or a trigger is received from the application layer). The remote WTRU generates a new ID (eg, a new source L2 ID and a new security ID).

[0148] (Step 902) The remote WTRU 920 transmits a request to the gNB 940 to obtain an updated Remote UE ID. An RRC message may be used to query the gNB, for example, a SidelinkUEInformation message, after which the gNB 940 provides the ID in an RRCReconfiguration message. The remote WTRU may indicate in its request to the gNB whether the gNB should also transmit the new Remote UE ID to the relay WTRU.

[0149] (Step 903) The gNB generates a new Remote UE ID and transmits it to the Remote UE ID (step 3a) and may also transmit it separately to the Relay WTRU (step 3b). The gNB remains using the current Remote UE ID until a message with the new Remote UE ID is received in the UL. Alternatively, the gNB may be configured with a timeout value for how long the current (old) Remote UE ID should be maintained and monitored (as defined in the sections marked as Relay and possibly Remote WTRU requesting a new Remote UE ID from the gNB during the LIU procedure at steps 804a and 804b). If the Remote WTRU 920 cannot obtain the new Remote UE ID, the Remote WTRU may decide to retry multiple times or terminate the PDU session and PC5 link to the Relay.

[0150] (Step 904) The remote WTRU 920 may configure a new remote UEID at the relay WTRU 930 using RRC signaling.

[0151] (Step 905) The remote WTRU transmits a LIU request message to the relay WTRU over the associated PC5 link. The current PC5 identifier is used to transmit the message, while the new ID is specified in the message payload. The new remote UE ID may be included in the LIU request payload along with other new identifiers.

[0152] (Step 906) The relay WTRU 930 receives the LIU request message and also generates new IDs on its side (eg, new target layer 2 ID and new security ID).

[0153] (Step 907) Once the relay WTRU 930 has received the new remote UE ID, the relay WTRU transmits a LIU response message to the remote WTRU 920, which includes the relay's new layer-2 ID and security ID.

[0154] (Step 908) The remote WTRU 920 completes the LIU procedure by transmitting a LIU Ack message to the relay WTRU 930.

[0155] (Step 909) The remote WTRU (or relay) may transmit a message to the gNB 940 indicating that the new Remote UE ID may start being used. A SidelinkUEInformation RRC message may be used to indicate this to the gNB. Alternatively, the relay WTRU may confirm the use of the new Remote UE ID by including the new Remote UE ID in the adaptation layer header with the data relayed from the remote WTRU.

[0156] (Step 910) At this point, the remote WTRU, relay WTRU and gNB begin using new IDs, including the new remote UE ID.

[0157] In the above alternative embodiment, the procedure may be modified as follows, transmitting a LIU request before requesting a new remote UE ID. In particular, the remote WTRU may transmit a LIU request message to the relay WTRU, which is an RRC message and may include associated relay WTRU information (e.g., a unique relay identifier), before transmitting a separate message to the gNB to request a new remote UE ID associated with the Uu-SRAP and PC5-SRAP from the gNB. Upon receiving the request from the remote WTRU, the gNB may generate a new remote UE ID while continuing to use the current remote UE ID until an explicit indication is received. The gNB may transmit the new remote UE ID to the remote WTRU and to the relay WTRU using RRC signaling (e.g., an RRC reconfiguration message). Upon receiving the new remote UE ID, the relay WTRU may transmit a LIU response message to the remote WTRU, which includes the relay WTRU's new Layer 2 ID and the new security ID, and the relay WTRU may include the new remote UE ID. The remote WTRU may transmit a LIU Ack message upon receiving the new remote UE ID and the LIU response message. Steps 9 to 10 can remain the same as Fig. 9 Same as in.

[0158] Identifier updates triggered by relays

[0159] The following embodiments and their alternatives described below support the following situation: the relay WTRU triggers the LIU procedure and the relay WTRU requests a new remote UE ID from the gNB during the LIU procedure (i.e., before the LIU procedure is completed).

[0160] Fig.10 is a signal flow diagram illustrating an exemplary signal flow for such an embodiment. Fig.10 The steps in are numbered 1001 to 1011 and correspond to the numbers in the following description.

[0161] (Step 1001) A privacy procedure is triggered (eg, a privacy timer expires) at the relay WTRU 1030. The relay generates a new PC5 ID (eg, a new source L2 ID and a new security ID).

[0162] (Step 1012) The relay WTRU 1030 requests an updated Remote UE ID associated with the Uu-SRAP and PC5-SRAP from the gNB 1040 using RRC signaling. When requesting a new Remote UE ID from the gNB, the relay WTRU may specify the current Remote UE ID so that the gNB can identify which Remote WTRU needs to be updated with the new Remote UE ID.

[0163] (Step 1003) gNB 1040 generates a new remote UE ID (such as Figure 8 804, 804a, 804b).

[0164] (Step 1004) The gNB transmits the new Remote UE ID to the relay WTRU 1030 and may include an indication requesting the relay WTRU to update the remote WTRU 1020. The gNB may also transmit the new Remote UE ID to the remote WTRU (1004a).

[0165] (Step 1005) If the relay WTRU has received an indication requesting it, the relay WTRU may transmit the new remote UE ID to the remote WTRU using RRC signaling.

[0166] (Step 1006) The relay WTRU transmits a LIU request message to the remote WTRU. The current PC5 identifier is used to transmit the message, while specifying the new PC5 ID in the message payload. The new remote UE ID may be included in the LIU request message payload if not already transmitted to the remote WTRU via RRC signaling, or in addition to RRC signaling. If the relay WTRU cannot obtain the new remote UE ID, the relay WTRU does not trigger the LIU procedure with the remote WTRU, and may decide to terminate the PC5 link, where the cause value is set to, for example, "unable to obtain new remote UE ID". Alternatively, the relay may transmit a new PC5 message, such as a link indication, to notify the remote WTRU about the failure to obtain the new remote UE ID, and the relay lets the remote WTRU decide whether the PC5 link should be terminated. Yet another alternative is to use a keepalive message to notify the remote WTRU about the failure to obtain the new remote UE ID.

[0167] (Step 1007) The remote WTRU receives the LIU Request message and also generates a new PC5 ID on its side (eg, new target L2 ID and new security ID). The remote WTRU keeps track of the new remote UE ID.

[0168] (Step 1008) The remote WTRU transmits a LIU Response message to the relay, which includes its new Layer 2 ID and new Security ID along with the new ID received on the LIU Request message.

[0169] (Step 1009) The relay WTRU completes the LIU procedure by transmitting a LIU Ack message to the remote WTRU.

[0170] (Step 1010) The relay WTRU may transmit a message to the gNB indicating that a new remote UE ID may be started to be used.

[0171] (Step 1011) At this point, the remote WTRU, relay WTRU and gNB start using new IDs, including the new remote UEID.

[0172] The remote / relay WTRU selects a procedure based on the remote / relay WTRU's RRC state

[0173] In one embodiment, the procedure for updating the remote UE ID at the remote WTRU and the relay WTRU may depend on the RRC state of the relay / remote WTRU. Specifically, this embodiment may be used to avoid the need to initiate an RRC connection establishment at the remote WTRU.

[0174] For example, if the Remote WTRU is in the RRC_CONNECTED state, it may use the above-described procedure whereby the Remote WTRU receives the Remote WTRU ID directly from the gNB in ​​the RRCReconfiguration message. On the other hand, if the Remote WTRU is in the RRC_IDLE / RRC_INACTIVE state, it may use the above-described procedure whereby the Remote WTRU receives the Remote UE ID directly from the Relay WTRU using PC5 RRC signaling (i.e., without Uu RRC signaling). This ensures that the Remote WTRU remains in the RRC_IDLE / RRC_INACTIVE state during the update procedure. In this case, the gNB may transmit an indication along with the new Remote UE ID that the new Remote UE ID is not to be transmitted by the gNB to the Remote WTRU.

[0175] In another alternative, how the remote WTRU initiates the procedure for obtaining a new remote UE ID may depend on the RRC state at the remote WTRU. For example, if the remote WTRU is in RRC_IDLE / RRC_INACTIVE state, it may initiate a connection establishment before initiating the remote UE ID update procedure. Alternatively, if the remote WTRU is in RRC_CONNECTED, it may use a different procedure to request a remote UE ID update.

[0176] Remote UEID update triggered on gNB

[0177] The following implementation scheme and its alternatives described below support the case where the gNB autonomously decides to update the Remote UE ID.

[0178] Fig.11 is a signal flow diagram illustrating an exemplary signal flow for such an embodiment. Fig.11 The steps in are numbered 1101 to 1105 and correspond to the numbers in the following description.

[0179] (Step 1101) gNB 1140 triggers a remote UE ID update procedure (e.g., in response to a timer expiration). The gNB generates a new remote UE ID.

[0180] (Step 1102) The gNB transmits the updated Remote UE ID associated with the Uu-SRAP and PC5-SRAP to the relay WTRU 1130 and indicates whether the relay WTRU should configure the remote WTRU 1120. The relay WTRU 1130 keeps track of the new Remote UE ID. If the gNB has indicated that the relay WTRU should configure the remote WTRU, the relay transmits the new Remote UE ID to the remote WTRU using RRC signaling. Alternatively, at step 3, the new Remote UE ID may be transmitted during the LIU procedure. If the gNB has indicated that the relay does not have to update the remote WTRU, the gNB transmits the new Remote UE ID to the remote WTRU using RRC signaling.

[0181] (Step 1103) The relay WTRU 1130 triggers the LIU privacy procedure with the remote WTRU. The relay WTRU transmits a LIU request message including its new PC5 ID to the remote WTRU 1120. The new remote UE ID may be included as a new ID in the LIU message. The remote WTRU transmits a LIU response message to the relay WTRU. The remote WTRU waits to receive the new remote UE ID before transmitting the LIU response message. The relay WTRU completes the LIU procedure by transmitting a LIU Ack message to the remote WTRU.

[0182] (Step 1104) The relay (or remote) WTRU may transmit a message to the gNB indicating that a new remote UE ID may be started to be used.

[0183] (Step 1105) At this point, the remote WTRU, relay and gNB begin using new IDs, including the new remote UE ID.

[0184] In the first alternative embodiment described above, the remote WTRU 1120 may trigger the LIU procedure with the relay WTRU 1130 (rather than the relay triggering the LIU procedure) at step 1103. The remote WTRU and the relay WTRU may negotiate which WTRU should trigger the LIU procedure during PC5 unicast link establishment.

[0185] In the second alternative embodiment described above, the gNB 1140 may transmit the new remote UE ID to the remote WTRU 1120 before transmitting the new remote UE ID to the relay WTRU 1130, i.e., steps 1102 and 1103 are swapped. In this case, the remote WTRU 1120 triggers the LIU procedure with the relay WTRU 1130. Once the LIU Ack message is transmitted / received, the remote WTRU or relay may inform the gNB to start using the new remote UE ID.

[0186] The gNB may transmit the new remote UE ID to the remote WTRU, and the remote WTRU triggers the LIU procedure with the relay WTRU and transmits the new remote UE ID to the relay WTRU using a LIU request or LIU Ack message or RRC signaling. Once the LIU Ack message is transmitted, the remote WTRU may notify the gNB to start using the new remote UE ID.

[0187] In a fourth alternative implementation, the gNB may update the Remote UE ID and transmit the updated Remote UE ID to the remote WTRU and to the relay WTRU. The remote WTRU and the relay WTRU may immediately start using the new Remote UE ID without triggering the LIU procedure. The LIU procedure may run as usual (triggered at the remote WTRU or relay WTRU), which simultaneously commands the change of the Remote UE ID, even if the gNB was previously updated independently of the LIU procedure.

[0188] Link identifier update triggered by a remote WTRU or relay WTRU using a preconfigured remote UE ID

[0189] In this embodiment, the relay WTRU or remote WTRU may obtain a set of remote UE IDs from the gNB during the RRC configuration procedure and then use a new remote UE ID from the set during subsequent LIU procedure runs.

[0190] In such an embodiment, the behavior at the remote WTRU may be as described in the following seven steps.

[0191] (Step 1) The Remote WTRU requests a Remote UE ID configuration from the gNB with an indication that multiple Remote UE IDs are requested (e.g. if privacy is required in the PC5 link). [Option 2] The message may include a privacy timer for when a new Remote UE ID should be used.

[0192] (Step 2) The remote WTRU receives a configuration message including a set of remote UE IDs (eg, in priority order). The WTRU stores the set of remote UE IDs and uses the first remote UE ID during communications through PC5.

[0193] (Step 3) Based on a privacy trigger (timer, application), the remote WTRU transmits a LIU request message to the relay WTRU, which includes a new remote UE ID from the remote UE ID set (e.g., the next one in the priority order) and other identifiers for the remote WTRU.

[0194] (Step 4) The remote WTRU receives a LIU response message from the relay WTRU accepting the change of the remote UE ID (including the new relay ID).

[0195] (Step 5) [Option 1b] The Remote WTRU transmits a request or indication message to the gNB to initiate the use of a new Remote UE ID (e.g., as selected at step 3). The selected new Remote UE ID is specified in the message.

[0196] (Step 6) [Option 1b] The remote WTRU may receive a response message from the gNB notifying the remote WTRU to start using a new remote UE ID.

[0197] (Step 7) The remote WTRU transmits a LIU Ack message confirming that the change of all IDs is complete.

[0198] In an embodiment utilizing a pre-configured Remote WTRU ID, the behavior at the relay WTRU may be as described in the following eight steps.

[0199] (Step 1) The relay WTRU obtains the configuration for the remote WTRU from the gNB, which configuration for the remote WTRU includes a set of remote UE IDs (as above).

[0200] (Step 2) The relay WTRU uses the first remote UE ID during communication through PC5 and Uu.

[0201] (Step 3) The relay WTRU receives a LIU request from the remote WTRU, which includes a new remote UE ID (and other IDs) from the set of remote UE IDs.

[0202] (Step 4) The relay WTRU verifies that the received Remote UE ID is the one specified in the set of Remote UE IDs obtained in step 1. If not, the relay WTRU may terminate the PC5 link or use the value as received on the LIU Request message.

[0203] (Step 5) [Option 1a] The relay may transmit a request or indication message to the gNB to initiate use of a new Remote UE ID (e.g., as received in step 3). The selected new Remote UE ID may be specified in the message.

[0204] (Step 6) [Option 1a] The relay WTRU may receive a response message from the gNB notifying the start of using the new remote UE ID.

[0205] (Step 7) The relay WTRU may transmit a LIU response to the remote WTRU accepting the change of the remote UE ID (including the new relay ID).

[0206] (Step 8) The relay WTRU receives a LIU Ack message from the remote WTRU confirming that the change of all IDs is complete.

[0207] In an implementation utilizing a pre-configured remote WTRU ID, the behavior at the gNB may be as described in the following three steps.

[0208] (Step 1) The gNB receives a request for configuration with an indication that multiple remote UE IDs are requested (e.g., if privacy is required in a PC5 link) from a remote WTRU (or relay WTRU). Alternatively, the request may include a timer for when to change the remote UE ID. The gNB may allocate multiple remote UE IDs and transmit the remote UE IDs to the remote WTRU (or relay WTRU) in a Configuration Response message (e.g., in priority order).

[0209] (Step 2) [Option 1a / 1b] The gNB receives a request or indication message from the relay WTRU (or remote WTRU) to initiate the use of a new Remote UE ID. The gNB starts monitoring traffic using the new Remote UE ID and stops using the current Remote UE ID (the gNB may use a timer to limit the use of the current / old Remote UE ID as described above).

[0210] (Step 3) [Option 1a / 1b] The gNB may transmit a response message to the relay WTRU (or remote WTRU) informing it to start using the new remote UE ID.

[0211] In addition to the above options 1a / 1b (which use messaging with the gNB), the following alternatives are proposed. These options allow implicit change of the Remote UE ID with the gNB by detecting the use of a new Remote UE ID used in UL traffic.

[0212] Option 2: The gNB may start a timer and start monitoring the use of a new Remote UE ID (e.g., the next one in the set) when the timer expires. In this case, neither the Remote WTRU nor the Relay WTRU needs to inform the gNB via messaging about the use of the new Remote UE ID (i.e., as in Option 1a / 1b).

[0213] Option 3: The gNB keeps using the current Remote UE ID until a message with a new Remote UE ID is received in the UL. With this option, the gNB does not need to start a timer as in Option 2 and monitor the Remote UE IDs (current and new) used in the UL.

[0214] Option 4: The list of new remote UE IDs is configured only on the remote WTRU (or only on the relay WTRU). In this case, the remote WTRU (or relay WTRU) transmits the new remote UE ID to the relay WTRU (or remote WTRU) when the LIU procedure is triggered using RRC signaling or LIU message.

[0215] in conclusion

[0216] Although features and elements are provided above in specific combinations, it will be understood by those of ordinary skill in the art that each feature or element may be used alone or in any combination with other features and elements. The present disclosure is not limited to the specific embodiments described in the present application, which are intended to be illustrative of various aspects. Many modifications and variations can be made without departing from the essence and scope of the present invention, as they will be apparent to those skilled in the art. Unless explicitly provided as such, any element, action or description used in the present application specification should not be understood as being essential or necessary to the present invention. According to the foregoing description, in addition to those listed herein, functionally equivalent methods and devices within the scope of the present disclosure will be apparent to those skilled in the art. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is limited only to the terms of the appended claims and the full range of equivalent forms of such entitled claims. It should be understood that the present disclosure is not limited to a specific method or system.

[0217] For simplicity, the foregoing embodiments are discussed with respect to terminology and structure of infrared capable devices (i.e., infrared transmitters and receivers). However, the embodiments discussed are not limited to these systems, but may be applied to other systems using other forms of electromagnetic waves or non-electromagnetic waves (such as sound waves).

[0218] It should also be understood that the terms used herein are for the purpose of describing specific embodiments only and are not intended to be limiting. As used herein, the term "video" or the term "image" may mean any of a snapshot, a single image, and / or a plurality of images displayed on a temporal basis. For example, when referred to herein, the term "user equipment" and its abbreviation "UE", the term "remote" and / or the term "head-mounted display" or its abbreviation "HMD" may mean or include (i) a wireless transmit and / or receive unit (WTRU); (ii) any of a plurality of embodiments of the WTRU; (iii) a wirelessly-enabled and / or wiredly-enabled (e.g., tetherable) device configured with (in particular) some or all of the structure and functionality of the WTRU; (iii) a wirelessly-enabled and / or wiredly-enabled device configured with less than all of the structure and functionality of the WTRU; or (iv), etc. This document refers to the following. Figures 1A to 1D Details of an example WTRU are provided that may represent any WTRU described herein. As another example, various disclosed embodiments herein above and below are described as utilizing a head mounted display. Those skilled in the art will recognize that devices other than head mounted displays may be utilized and that some or all of the embodiments of the present disclosure and various disclosed embodiments may be modified accordingly without undue experimentation. Examples of such other devices may include drones or other devices configured to stream information to provide an adapted reality experience.

[0219] In addition, the methods provided herein may be implemented in a computer program, software, or firmware incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (sent via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as built-in hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile disks (DVDs)). A processor associated with software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, MME, EPC, AMF, or any host computer.

[0220] Variations of the methods, devices, and systems provided above are possible without departing from the scope of the present invention. In view of the various embodiments that can be applied, it should be understood that the illustrated embodiments are merely examples and should not be considered to limit the scope of the following claims. For example, the embodiments provided herein include handheld devices that may include or be used with any suitable voltage source (such as a battery, etc.) that provides any suitable voltage.

[0221] In addition, in the embodiments provided above, processing platforms, computing systems, controllers and other devices including processors are indicated. These devices may include at least one central processing unit ("CPU") and memory. According to the practice of those skilled in the art of computer programming, references to the symbolic representations of actions and operations or instructions may be performed by various CPUs and memories. Such actions and operations or instructions may be referred to as being "executed", "computer executed" or "CPU executed".

[0222] Those of ordinary skill in the art will appreciate that the actions and symbolic representations of operations or instructions include manipulation of electrical signals by the CPU. The electrical system represents data bits, which may result in the ultimate transformation of electrical signals or reduction of electrical signals and the retention of data bits at memory locations in the memory system, thereby reconfiguring or otherwise changing the operation of the CPU and performing other processing of signals. The memory location that holds the data bits is a physical location that has specific electrical, magnetic, optical, or organic properties that correspond to or represent the data bits. It should be understood that the embodiments are not limited to the above-mentioned platforms or CPUs, and other platforms and CPUs may also support the provided methods.

[0223] The data bits may also be maintained on computer-readable media, including magnetic disks, optical disks, and any other volatile (e.g., random access memory ("RAM")) or non-volatile (e.g., read-only memory ("ROM")) mass storage system readable by the CPU. The computer-readable media may include cooperating or interconnected computer-readable media that reside solely on the processing system or distributed across multiple interconnected processing systems that may be local or remote relative to the processing system. It should be understood that the embodiments are not limited to the above-mentioned memories, and other platforms and memories may also support the provided methods.

[0224] In an exemplary embodiment, any of the operations, processes, etc. described herein may be implemented as computer-readable instructions stored on a computer-readable medium. The computer-readable instructions may be executed by a processor of a mobile unit, a network element, and / or any other computing device.

[0225] There is little difference between hardware implementation and software implementation of various aspects of the system. The use of hardware or software is usually (but not always, because in some contexts, the choice between hardware and software may become important) a design choice that represents a trade-off between cost and efficiency. There may be various media (e.g., hardware, software, and / or firmware) that can implement the processes and / or systems and / or other technologies described herein, and the preferred media may vary with the context of the deployment process and / or system and / or other technologies. For example, if the implementer determines that speed and accuracy are most important, the implementer may choose a media that is primarily hardware and / or firmware. If flexibility is most important, the implementer may choose a specific implementation that is primarily software. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.

[0226] The above specific embodiments have been listed various embodiments of devices and / or processes by using block diagrams, flow charts and / or examples. Where such block diagrams, flow charts and / or examples include one or more functions and / or operations, it will be understood by those skilled in the art that each function and / or operation within such block diagrams, flow charts or examples may be implemented individually and / or collectively by a wide range of hardware, software, firmware or almost any combination thereof. In embodiments, several parts of the subject matter described herein may be implemented via application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs) and / or other integrated formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein may be equivalently implemented in integrated circuits as a whole or in part as one or more computer programs running on one or more computers (e.g., one or more programs running on one or more computer systems), one or more programs running on one or more processors (e.g., one or more programs running on one or more microprocessors), firmware or almost any combination thereof, and according to the present disclosure, designing circuits and / or writing software and / or firmware codes will be completely within the technical scope of those skilled in the art. Furthermore, those skilled in the art will appreciate that the mechanisms of the subject matter described herein can be distributed as a program product in a variety of forms, and that the illustrative embodiments of the subject matter described herein apply regardless of the specific type of signal-bearing medium used to actually perform the distribution. Examples of signal-bearing media include, but are not limited to, the following: recordable type media (such as floppy disks, hard drives, CDs, DVDs, digital tapes, computer memory, etc.); and transmission type media (such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.)).

[0227] Those skilled in the art will recognize that it is common in the art to describe devices and / or processes in the manner set forth herein, and thereafter use engineering practices to integrate such described devices and / or processes into a data processing system. That is, at least a portion of the devices and / or processes described herein can be integrated into a data processing system via a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system generally may include one or more of the following: a system unit housing; a video display device; a memory, such as a volatile memory and a non-volatile memory; a processor, such as a microprocessor and a digital signal processor; a computing entity, such as an operating system, a driver, a graphical user interface, and an application; one or more interactive devices, such as a touch pad or a screen; and / or a control system, including a feedback loop and a control motor (e.g., a feedback for sensing position and / or velocity, a control motor for moving and / or adjusting components and / or quantities). A typical data processing system may be implemented using any suitable commercially available components, such as those typically found in data computing / communication and / or network computing / communication systems.

[0228] The subject matter described herein sometimes illustrates different components included in or connected to different other components. It should be understood that such depicted architectures are merely examples, and in fact many other architectures that achieve the same functionality can be implemented. In a conceptual sense, any arrangement of components that achieve the same functionality is effectively "associated" so that the desired functionality can be achieved. Therefore, any two components that are combined to achieve a specific functionality in this article can be considered to be "associated" with each other so that the desired functionality is achieved, regardless of the architecture or intermediate components. Similarly, any two components so associated can also be considered to be "operably connected" or "operably coupled" to each other to achieve the desired functionality, and any two components that can be so associated can also be considered to be "operably couplable" to each other to achieve the desired functionality. Specific examples of operable coupling include, but are not limited to, components that can physically cooperate and / or physically interact and / or components that can wirelessly interact and / or wirelessly interact and / or components that can logically interact and / or components that can logically interact.

[0229] For substantially any plural and / or singular terms used herein, those skilled in the art may convert from the plural to the singular and / or from the singular to the plural as appropriate, depending on the context and / or application. For clarity, various singular / plural arrangements may be explicitly listed herein.

[0230] It will be understood by those skilled in the art that, in general, the terms used herein, and particularly in the appended claims (e.g., the bodies of the appended claims), are generally intended to be "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "comprising" should be interpreted as "including but not limited to," etc.). It will also be understood by those skilled in the art that if a specific number of an introduced claim recitation is intended, such intent will be explicitly recited in the claim, and in the absence of such recitation, no such intent is present. For example, where only one item is intended, the term "single" or similar language may be used. To aid understanding, the following appended claims and / or the description herein may include the use of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed as implying that any particular claim that includes such introduced claim recitation subject matter is limited to embodiments that include only one such recitation subject matter by the indefinite article "a" or "an" to introduce the claim recitation subject matter, even when the same claim includes the introductory phrases "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should be interpreted as meaning "at least one" or "one or more"). The same applies to the use of definite articles to introduce claim recitation subjects. Furthermore, even if a specific number of introduced claim recitation subjects is explicitly recited, one skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number (e.g., the bare recitation of "two recitation subjects" means at least two recitation subjects or two or more recitation subjects in the absence of other modifiers). Additionally, in those instances where a convention similar to “at least one of A, B, and C, etc.” is used, generally speaking, such construction is meant to be understood by one skilled in the art (e.g., “a system having at least one of A, B, and C” would include, but is not limited to, systems having A alone, B alone, C alone, both A and B, both A and C, both B and C, and / or both A, B, and C, etc.). In those instances where a convention similar to “at least one of A, B, or C, etc.” is used, generally speaking, such construction is meant to be understood by one skilled in the art (e.g., “a system having at least one of A, B, or C” would include, but is not limited to, systems having A alone, B alone, C alone, both A and B, both A and C, both B and C, and / or both A, B, and C, etc.). It should also be understood by those skilled in the art that, in fact, any separate words and / or phrases presenting two or more alternative terms, whether in the specification, claims or drawings, should be understood to contemplate the possibility of including one of the terms, any one of the terms, or both of the terms.For example, the phrase "A or B" will be understood to include the possibilities of "A" or "B" or "A and B." In addition, as used herein, the term "any of" followed by a listing of multiple items and / or multiple categories of items is intended to include "any of," "any combination," "any multiples," and / or "any combination of multiples" of the items and / or categories of items, either alone or in combination with other items and / or other categories of items. Furthermore, as used herein, the term "set" is intended to include any number of items, including zero. Additionally, as used herein, the term "quantity" is intended to include any number, including zero. And, as used herein, the term "plurality" is intended to be synonymous with "multiple."

[0231] In addition, where features or aspects of the disclosure are described in terms of Markush groups, those skilled in the art will recognize that the disclosure is also described in terms of any individual member or subgroup of members of the Markush group.

[0232] As will be understood by those skilled in the art, for any and all purposes (such as in terms of providing a written description), all ranges disclosed herein also encompass any and all possible subranges and combinations of their subranges. Any listed range can be easily identified as fully describing and enabling the same range to be divided into at least equal halves, one-third, one-quarter, one-fifth, one-tenth, etc. As a non-limiting example, each range discussed herein can be easily divided into a lower third, a middle third, and an upper third, etc. As will be understood by those skilled in the art, all languages ​​such as "up to", "at least", "greater than", and "less than", etc. include the cited numbers and refer to the ranges that can be subsequently divided into subranges as described above. Finally, as will be understood by those skilled in the art, the range includes each individual number. Therefore, for example, a group with 1 to 3 units refers to a group with 1, 2, or 3 units. Similarly, a group with 1 to 5 units refers to a group with 1, 2, 3, 4, or 5 units, etc.

[0233] Furthermore, the claims should not be read as limited to the order or elements provided unless otherwise stated. Furthermore, the use of the term "means for..." in any claim is intended to invoke 35 U.S.C. § 112, 6 or parts-plus-function claim format, and any claim without the term "means for..." is not intended to be so.

[0234] Suitable processors include, by way of example, a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), an application specific standard product (ASSP), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), and / or state machine.

[0235] The WTRU may be used in conjunction with a module, which may be implemented in hardware and / or software including: software defined radio (SDR) and other components such as a camera, a video camera module, a videophone, a speakerphone, a vibration device, a speaker, a microphone, a television transceiver, a hands-free headset, a keyboard, module, a frequency modulation (FM) radio unit, a near field communication (NFC) module, a liquid crystal display (LCD) display unit, an organic light emitting diode (OLED) display unit, a digital music player, a media player, a video game player module, an internet browser, and / or any wireless local area network (WLAN) or ultra-wideband (UWB) module.

[0236] Although various embodiments have been described in terms of a communication system, it is contemplated that the system may be implemented in software on a microprocessor / general purpose computer (not shown). In certain embodiments, one or more of the functions of the various components may be implemented in software controlling a general purpose computer.

[0237] Furthermore, while the invention has been illustrated and described herein with reference to specific embodiments, the invention is not intended to be limited to the details shown. Rather, various modifications may be made to the details within the scope and range of equivalents of the claims without departing from the invention.

Claims

1. A relay wireless transmit receive unit (WTRU), the relay wireless transmit receive unit (WTRU) configured to communicate with a network and a remote WTRU via respective air interfaces, the WTRU further configured to: receiving a link identifier update (LIU) request message having first information from the remote WTRU, the first information including a new most significant byte (MSB) of a new remote WTRU layer 2 identifier (L2 ID) and a new security identifier (ID); generating second information in response to the LIU request message, the second information comprising a new relay WTRU L2 ID and a new least significant byte (LSB) of the new security ID; sending a request for a new remote WTRU ID to the network, the request for a new remote WTRU ID including a current remote WTRU ID; receiving the new remote WTRU ID from the network, the new remote WTRU ID being associated with the first information and the second information; sending the new remote WTRU ID to the remote WTRU; sending a LIU response message to the remote WTRU, the LIU response message including the second information; receiving an acknowledgement (ACK) message from the remote WTRU indicating an acknowledgement of the LIU response message; and A message is sent to the network in response to the ACK message, wherein the message indicates to start using the new remote WTRU ID.

2. The relay WTRU of claim 1 , wherein the relay WTRU sends a request for a new remote WTRU ID to the network, wherein the request for a new remote WTRU ID comprises a SidelinkUEInformation message.

3. The relay WTRU of claim 1, wherein the relay WTRU receives the new remote WTRU ID in a message from the network to configure the remote WTRU with the new remote WTRU ID.

4. The relay WTRU of claim 1 , wherein the relay WTRU sends the new remote WTRU ID to the remote WTRU using a SidelinkReconfiguration message.

5. The relay WTRU of claim 1, wherein the relay WTRU sends the LIU response message to the remote WTRU, wherein a LIU response message header includes the current remote WTRU ID, a current relay WTRU ID, and a current security ID.

6. The relay WTRU of claim 1, wherein the relay WTRU receives the ACK message with a first current ID and a second current ID and the current remote WTRU ID encapsulated in a header.

7. The relay WTRU of claim 1, further comprising the relay WTRU relaying a transmission from the network to the remote WTRU, the transmission comprising a message using the new remote WTRU ID, the new relay WTRU L2 ID, the new remote WTRU L2 ID, and the new security ID.

8. A method performed by a relay wireless transmit receive unit (WTRU), the relay wireless transmit receive unit (WTRU) being configured to communicate with a network and a remote WTRU via respective air interfaces, the method comprising: receiving a link identifier update (LIU) request message having first information from the remote WTRU, the first information including a new most significant byte (MSB) of a new remote WTRU layer 2 identifier (L2 ID) and a new security identifier (ID); generating second information in response to the LIU request message, the second information comprising a new relay WTRU L2 ID and a new least significant byte (LSB) of the new security ID; sending a request for a new remote WTRU ID to the network, the request for a new remote WTRU ID including a current remote WTRU ID; receiving the new remote WTRU ID from the network, the new remote WTRU ID being associated with the first information and the second information; sending the new remote WTRU ID to the remote WTRU; sending a LIU response message to the remote WTRU, the LIU response message including the second information; receiving an acknowledgement (ACK) message from the remote WTRU indicating an acknowledgement of the LIU response message; and A message is sent to the network in response to the ACK message, wherein the message indicates to start using the new remote WTRU ID.

9. The method of claim 8, wherein sending a request for a new remote WTRUID to the network comprises sending a SidelinkUEInformation message to the network.

10. The method of claim 8, wherein receiving the new remote WTRU ID from the network comprises receiving the new remote WTRU ID in a message from the network to configure the remote WTRU with the new remote WTRU ID.

11. The method of claim 8, wherein sending the new remote WTRU ID to the remote WTRU comprises sending a SidelinkReconfiguration message to the remote WTRU.

12. The method of claim 8, wherein sending a LIU response message to the remote WTRU comprises sending the LIU response message with a LIU response message header, the LIU response message header including the current remote WTRU ID, the current relay WTRU ID, and a current security ID.

13. The method of claim 8, wherein receiving an acknowledgement (ACK) message from the remote WTRU indicating an acknowledgement of the LIU response message comprises receiving the ACK message encapsulated in a header having a current identifier and a current security identifier for the remote WTRU and the relay WTRU.

14. The method according to claim 8, further comprising: A transmission from the network to the remote WTRU is relayed via the relay WTRU, wherein the transmission includes a message using the new remote WTRU ID, the new relay WTRU L2 ID, and the new security ID.

15. A non-transitory computer-readable storage medium comprising instructions that, when executed by a processor, perform a method comprising: receiving a link identifier update (LIU) request message from a remote WTRU having first information including a new remote WTRU layer 2 identifier (L2 ID) and a new most significant byte (MSB) of a new security identifier (ID); generating second information in response to the LIU request message, the second information comprising a new relay WTRU L2 ID and a new least significant byte (LSB) of the new security ID; sending a request for a new remote WTRU ID to the network, the request for the new remote WTRU ID including the current remote WTRU ID; receiving the new remote WTRU ID from the network, the new remote WTRU ID being associated with the first information and the second information; sending the new remote WTRU ID to the remote WTRU; sending a LIU response message to the remote WTRU, the LIU response message including the second information; receiving an acknowledgement (ACK) message from the remote WTRU indicating an acknowledgement of the LIU response message; and A message is sent to the network in response to the ACK message, wherein the message indicates to start using the new remote WTRU ID.

16. The non-transitory computer-readable storage medium of claim 15, wherein sending a request for a new remote WTRU ID to the network comprises sending a SidelinkUEInformation message to the network.

17. The non-transitory computer-readable storage medium of claim 15, wherein receiving the new remote WTRU ID from the network comprises receiving the new remote WTRU ID from the network in a message to configure the remote WTRU with the new remote WTRU ID. [Figure 8, step 854b] 18. The non-transitory computer-readable storage medium of claim 15, wherein sending the new remote WTRU ID to the remote WTRU comprises sending a SidelinkReconfiguration message to the remote WTRU.

19. The non-transitory computer-readable storage medium of claim 15, wherein sending a LIU response message to the remote WTRU comprises sending the LIU response message with a LIU response message header, the LIU response message header comprising the current remote WTRU ID, a current relay WTRU ID, and a current security ID.

20. The non-transitory computer-readable storage medium of claim 15, wherein receiving an acknowledgement (ACK) message from the remote WTRU indicating an acknowledgement of the LIU response message comprises receiving the ACK message encapsulated in a header having a current identifier and a current security identifier for the remote WTRU and the relay WTRU.

Images