Methods for privacy protection using link modification operations during relay reselection

Abstract

To address how a first device and a second device may securely transmit information via a third device acting as a relay in wireless communication systems.SOLUTION: In a system, method, and / or device, there may be approaches for a wireless transmit receive unit (WTRU) to WTRU connections, utilizing more than one connection, selecting the connection, ensuring security and privacy, and using one or more relays. The WTRU may implement a method for privacy protection using link modification operations during relay reselection.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 457,061, filed April 4, 2023, the contents of which are incorporated herein by reference. [Background technology]

[0002] In a wireless communication system, there is a need to address how a first device and a second device may securely transmit information through a third device that acts as a relay. Summary of the Invention

[0003] In a system, method, and / or device, there may be techniques for wireless transmit receive unit (WTRU) to WTRU connections that utilize two or more connections, select a connection, ensure security and privacy, and use one or more repeaters. The WTRU may perform a method for privacy protection that uses link modification operations during repeater reselection. [Brief explanation of the drawings]

[0004] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which like reference numerals indicate similar elements and in which: [Figure 1A] 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1B is a system diagram illustrating an exemplary wireless transmit / receive unit (WTRU) that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 1C]1A is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 1D] 1B is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 2] 1 illustrates an example of 5G ProSe Layer 2 UE-to-UE relay reselection. [Figure 3] 10 illustrates an example of 5G ProSe UE-to-UE relay reselection with a new KNRP ID established using LMR / LMA. [Figure 4] 10 illustrates an example of 5G ProSe UE-to-UE Relay reselection with a new KNRP ID using LMR / LMA / LMAck. [Figure 5] 10 illustrates an example of 5G ProSe UE-to-UE relay reselection with coordinated early connection release for new KNRP ID establishment. [Figure 6] 10 illustrates an example of 5G ProSe UE-to-UE Relay reselection with KNRP ID state set to "refresh pending." [Figure 7] 1 illustrates an example of 5G ProSe UE-to-UE relay reselection security using an enhanced pre-key generation procedure. [Figure 8] An example of the method is illustrated below. DETAILED DESCRIPTION OF THE INVENTION

[0005] 1A is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. Communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messaging, broadcasts, etc., to multiple wireless users. 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 use 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 discrete Fourier transform spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multicarrier (FBMC), etc.

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

[0007] The communications 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 configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communications networks, such as the CN 106, 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 (eNB), a Home Node B, a Home eNode B, a next generation Node B (gNode B (gNB), etc.), a new radio (NR) Node B, a site controller, an access point (AP), a wireless router, etc. Although the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

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

[0009] 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).

[0010] More specifically, as noted above, the communications system 100 may be a multiple-access system, but may use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a and the WTRUs 102a, 102b, 102c of the RAN 104 may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 using wideband CDMA (WCDMA). WCDMA may include communications 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).

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

[0012] In one 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 NR.

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

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

[0015] 1A 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 a local area such as a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, etc. 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 one 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 femtocell. 1A, the base station 114b may have a direct connection to the Internet 110. Therefore, the base station 114b may not need to access the Internet 110 through the CN 106.

[0016] The RAN 104 may communicate with the CN 106, which may be any type of network configured to provide voice, data, application, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have various quality of service (QoS) requirements, such as different throughput, latency, error tolerance, reliability, data throughput, mobility, etc. The CN 106 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 shown in FIG. 1A , it will be understood that the RAN 104 and / or CN 106 may communicate directly or indirectly with other RANs that use the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may utilize NR radio technology, the CN 106 may also communicate with another RAN (not shown) employing GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

[0019] 1B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1B, 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 understood that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

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

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

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

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

[0024] The processor 118 of the WTRU 102 may be coupled to and may receive user-entered 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. Additionally, the processor 118 may access information from and store data in any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, etc. In other embodiments, the processor 118 may access information from and store data in memory that is not physically located on the WTRU 102, such as on a server or home computer (not shown).

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

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

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

[0028] The WTRU 102 may include a full-duplex radio where transmission and reception of some or all of the signals (e.g., associated with a particular subframe on both the UL (e.g., for transmission) and DL (e.g., for reception)) may be simultaneous and / or together. The full-duplex radio may include an interference management unit to reduce and or substantially eliminate self-interference through either hardware (e.g., a choke) or signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio where transmission and reception of some or all of the signals (e.g., associated with a particular subframe on either the UL (e.g., for transmission) or DL ​​(e.g., for reception)) may be simultaneous and / or together.

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

[0030] The RAN 104 may include eNodeBs 160a, 160b, and 160c, although it will be understood that the RAN 104 may include any number of eNodeBs while remaining consistent with an embodiment. The eNodeBs 160a, 160b, and 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In an embodiment, the eNodeBs 160a, 160b, and 160c may implement MIMO techniques. Thus, the eNodeB 160a may, for example, use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0031] Each of the eNodeBs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, etc. As shown in FIG. 1C, the eNodeBs 160a, 160b, 160c may communicate with one another via an X2 interface.

[0032] 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. Although the foregoing elements are depicted as part of the CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0033] The MME 162 may be connected to each of the eNodeBs 162a, 162b, 162c in the RAN 104 via an S1 interface and may function as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, activating / deactivating bearers, selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, 102c, etc. 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.

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

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

[0036] 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 landline communications devices. For example, the CN 106 may include or communicate 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 and / or wireless networks owned and / or operated by other service providers.

[0037] Although the WTRU is illustrated in FIGS. 1A-1D as a wireless terminal, it is contemplated that in certain representative embodiments, such a terminal may use a wired communication interface (e.g., temporarily or permanently) with the communication network.

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

[0039] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) of the BSS and one or more stations (STAs) associated with the AP. An AP may have access to or interface with a Distribution System (DS) or another type of wired / wireless network that carries traffic within and / or outside the BSS. Traffic originating outside the BSS and destined for a STA may arrive through the AP and be delivered to the STA. Traffic originating at a STA and destined for a destination outside the BSS may be sent to the AP to be delivered to the respective destination. Traffic between STAs within a BSS may be sent through the AP, for example, where the source STA may send traffic to the AP, which may deliver the traffic to the destination STA. Traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between (e.g., directly between) a source STA and a destination STA using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (e.g., all of the STAs) may communicate directly with each other. The IBSS mode of communication may be referred to herein as an "ad hoc" communication mode.

[0040] When using the 802.11ac infrastructure mode of operation or a similar mode of operation, an AP may transmit 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 dynamically configured width. The primary channel may be the operating channel of the BSS, but may be used by STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. With CSMA / CA, STAs (e.g., all STAs), 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 in a given BSS at any given time.

[0041] High Throughput (HT) STAs may use 40 MHz wide channels for communication, which may be formed, for example, through a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels.

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

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

[0044] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as a primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be configured and / or limited by the STAs among all STAs operating in the BSS that support the minimum bandwidth operating mode. In an 802.11ah example, the primary channel can be 1 MHz wide for STAs (e.g., MTC-type devices) that support (e.g., only) 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) configuration can depend on the status of the primary channel. For example, if a STA (that only supports 1 MHz mode of operation) transmitting to an AP has a busy primary channel, all of the available frequency bands may be considered busy even if most of the available frequency bands are idle.

[0045] In the United States, the available frequency band that can be used by 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.

[0046] 1D is a system diagram illustrating the RAN 104 and the CN 106, according to one embodiment. As noted above, the RAN 104 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also communicate with the CN 106.

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

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

[0049] 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 without accessing another RAN (e.g., eNodeBs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize 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 unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate with and connect to gNBs 180a, 180b, 180c while also communicating with and connecting to another RAN, such as eNodeBs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNodeBs 160a, 160b, 160c may act as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0050] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support for network slicing, DC, interaction between NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a, 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D , the gNBs 180a, 180b, 180c may communicate with each other via an Xn interface.

[0051] 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While the foregoing elements are depicted as part of the CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0052] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface and may function as a control node. For example, the AMF 182a, 182b may be responsible for user authentication of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selection of a particular SMF 183a, 183b, management of registration areas, termination of non-access stratum (NAS) signaling, mobility management, etc. The network slicing may be used by the AMF 182a, 182b to customize the CN support for the WTRUs 102a, 102b, 102c based on the type of service utilizing the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, etc. The AMFs 182a, 182b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) employing other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0053] The SMFs 183a and 183b may be connected to the AMFs 182a and 182b in the CN 106 via an N11 interface. The SMFs 183a and 183b may also be connected to the UPFs 184a and 184b in the CN 106 via an N4 interface. The SMFs 183a and 183b may select and control the UPFs 184a and 184b and configure the routing of traffic through the UPFs 184a and 184b. The SMFs 183a and 183b may perform other functions, such as managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

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

[0055] The CN 106 may facilitate communication with other networks. For example, the CN 106 may include or communicate 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 and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to the local DNs 185a, 185b through the UPFs 184a, 184b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

[0056] 1A-1D and the corresponding description thereof, one or more or all of the functions described herein with respect to one or more of the WTRUs 102a-102d, base stations 114a-114b, eNodeBs 160a-160c, MME 162, SGW 164, PGW 166, gNBs 180a-180c, AMFs 182a-182b, UPFs 184a-184b, SMFs 183a-183b, DNs 185a-185b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation devices may be used to test other devices and / or simulate network and / or WTRU functions.

[0057] The emulation devices may be designed to perform one or more tests of other devices in a lab environment and / or an operator network environment. For example, one or more emulation devices may perform one or more or all functions while fully or partially running and / or deployed as part of a wired and / or wireless communication network to test other devices in the communication network. One or more emulation devices may perform one or more or all functions while temporarily running / deployed as part of a wired and / or wireless communication network. The emulation devices may be directly coupled to another device for the purpose of testing and / or conducting tests using over-the-air wireless communication.

[0058] One or more emulation devices may perform one or more functions, inclusive, while not running / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in test scenarios in a test lab and / or in an undeployed (e.g., test) wired and / or wireless communication network to perform testing of one or more components. One or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include, e.g., one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0059] As described herein, the following acronyms may be used: Break Before Make (BBM); Make Before Break (MBB); Direct Connection Request / Accept (DCR / DCA); (Root) Key NR ProSe (KNRP); Session Key NR PRoSe (KNRP-Sess); Link Modification Request / Accept (LMR / LMA); Least / Most Significant Byte (LSB / MSB); NR ProSe Encryption Key (NRPEK); NR ProSe Integrity Key (NRPIK); Relay Service Code (RSC); and / or UE-to-UE Relay (U2U Relay).

[0060] In general, a repeater may be any device, such as a WTRU, a UE, a base station, a virtualized device residing on another hardware, etc. Furthermore, as described herein, reference to an “end” WTRU may indicate that the WTRU is at one end (e.g., the first or second end in a simple relay scenario) of a communication link made available by at least one relay device (e.g., a relay WTRU). An L2 U2U repeater (re)selection procedure may involve two end WTRUs communicating through a first repeater, which then negotiate the selection of a second repeater via the first repeater (e.g., during a link modification procedure) before reconnecting via the second repeater. The end WTRU may decide to trigger a repeater reselection, for example, to seek a better repeater (e.g., providing better signal quality / performance).

[0061] FIG. 2 illustrates an example of an exemplary 5G ProSe Layer 2 (L2) UE-to-UE (U2U) (e.g., WTRU-to-WTRU) relay reselection.

[0062] As can be seen from the example of FIG. 2 , in a reselection procedure, there may be several devices involved, such as end WTRU1 251 (e.g., 5G ProSe-enabled or otherwise), Relay 1 252, Relay 2 253, and / or end WTRU2 254 (e.g., 5G ProSe-enabled or otherwise). Initially, at 201, there may be a connection setup between end WTRU1 and end WTRU2 via Relay 1. At 202, the end WTRUs may communicate (e.g., forward traffic, etc.) via Relay 1. At least one of the end WTRUs (e.g., end WTRU1) may decide to reselect a repeater (e.g., at 203). The end WTRU may then negotiate the selection of another repeater (e.g., Relay 2) via Relay 1. For example, at 204, end WTRU1 may send a link modification request message to a second end WTRU via Relay 1. At 205, end WTRU2 may be instructed, assisted, and / or may itself decide which relay WTRU (e.g., Relay 2) to switch to. At 206, end WTRU2 may send a link modification accept message to end WTRU2 via Relay 1. This link modification procedure (e.g., 204-206) may be performed before reconnecting the two end WTRUs via the new relay (e.g., Relay 2) at 207.

[0063] In some cases, there may be one or more security techniques related / associated with the L2 U2U repeater (re)selection procedure. In such cases, there may be new security keys established as part of the link modification procedure (e.g., FIG. 2). The new keys may be used to secure the connection between the end WTRUs via the second repeater.

[0064] The Key NR ProSe (KNRP) ID is a unique identifier of the Root Key KNRP shared between two WTRUs involved in direct communication. The KNRP and its associated KNRP ID value are not deleted after unicast link release. To prevent the privacy threat of an eavesdropper using the same KNRP ID between two WTRUs involved in direct communication to link two subsequent connections, a change of the KNRP ID can be performed during the link release procedure. A change of the KNRP ID can be performed unconditionally between two WTRUs as part of the link release procedure before the end WTRUs reconnect again.

[0065] A rekeying procedure may be used for an ongoing connection to ensure that a new session key, KNRP-SESS, and security keys, NR ProSe Encryption Key (NRPEK) and NR ProSe Integrity Key (NRPIK), are used. This procedure may also optionally be used to refresh KNRP.

[0066] The connection between the end WTRUs via the original L2 U2U Repeater may not be released prior to the setup of the new connection via the new L2 U2U Repeater. This occurs due to the fact that the release of the initial link with the original repeater reselection depends on whether the PC5 unicast link is still needed and on the WTRU execution, as well as the Make Before Break (MBB) principle underlying the repeater reselection procedure. The MBB principle stipulates that the current connection between the end WTRUs via the original L2 U2U Repeater should be maintained to allow a seamless transition of communications over the new connection via the new L2 U2U Repeater.

[0067] In general, it may be assumed that the end WTRU maintains the initial connection via the first U2U repeater while establishing a new connection via the second U2U repeater in an MBB manner. This may be required to minimize any potential interruption to ongoing communications during the U2U reselection procedure. Maintaining the initial connection means that mechanisms using link release as described herein cannot be applied in MBB scenarios.

[0068] If the end WTRU needs to prematurely release the initial connection (e.g., due to resource constraints), the end WTRU may not perform the link release procedure for the original connection via the first L2 U2U Repeater before reconnecting via the new L2 U2U Repeater, and / or the end WTRU may reuse the same KNRP ID via the new E2E connection. Therefore, it is necessary to address how to ensure that appropriate timing for link release of the initial connection before the start of the new connection setup is not specified in a potential break-before-make (BBM) scenario.

[0069] In both cases (e.g., MBB and BBM scenarios), an eavesdropper may be able to track end WTRUs that reuse the same KNRP ID. Therefore, as described herein, potential issues need to be addressed, such as how to ensure KNRP ID privacy protection during L2 U2U reselection.

[0070] As described herein, preparing new security keys using a connection through a first repeater during a link modification procedure provides the benefits of early security establishment for faster link setup through the new repeater and the availability of security keys to protect initial messages (e.g., Direct Connection Request (DCR)).

[0071] However, improving existing security procedures and / or reducing security-related logic in link modification procedures may be desirable to reduce the impact on existing implementations.

[0072] The establishment of new keys may also depend on the provisioned security policy, which needs to be taken into consideration for the provisioning of new security keys. Thus, there is a need to address how to establish new security keys (e.g., for a new connection via a second repeater) during a repeater reselection procedure while taking into consideration the provisioned security policy and potential impact (e.g., minimization) on existing procedures.

[0073] In one or more examples described herein (e.g., for KNRP ID privacy), there may be an L2 U2U reselection procedure in which a first end WTRU (End WTRU1) establishes a new KNRP ID with a second end WTRU (End WTRU2) using a link modification procedure or coordinated link release of the initial connection via a first relay (Relay1). End WTRU1 establishes a new connection with End WTRU2 via a second relay (Relay2) using the new KNRP ID. This approach enables privacy protection of the KNRP ID while the end WTRU establishes the new connection via Relay2 (e.g., mitigates the risk of an attacker being able to link the new KNRP ID with the old KNRP ID). In other words, this enables privacy of the new Key ID and ensures that it is protected during the linking procedure (e.g., as described herein). The approach described herein proposes to leverage and extend the link modification procedure that is mandatory for L2 U2U reselection to negotiate maintaining (MBB) or releasing (BBM) the initial connection prior to setting up a new connection. If MBB is selected, the end WTRU establishes a new KNRP ID as part of the link modification procedure. If BBM is selected, the end WTRU coordinates the link release procedure for the initial connection to establish a new KNRP ID prior to initiating the new connection setup. In this way, one problem that can be avoided is when an attacker may attempt to link an old key ID to a new key ID in order to track the WTRU.

[0074] In one or more examples described herein (e.g., for communication security), there may be an L2 U2U reselection security procedure in which a first end WTRU (end WTRU1) negotiates with a second WTRU (end WTRU2) using a link modification procedure via a first repeater (repeater 1) and / or performing an enhanced re-key procedure. End WTRU1 performs the enhanced re-key procedure with end WTRU2 to establish a new correlation ID and generate new keys used to secure the new connection via the second repeater (repeater 2). This approach improves the re-key procedure while enabling the preparation of security keys to protect the new connection setup, including the initial message (e.g., DCR).

[0075] 3 illustrates an example of 5G ProSe U2U repeater reselection with KNRP ID privacy protection. As shown, there may be several devices involved in the reselection procedure, such as end WTRU1 351, repeater 1 352, repeater 2 353, and / or end WTRU2 354. While FIG. 3 presents an ordered sequence of actions / events, it is contemplated that one or more of these actions / events may be optional and / or one or more of these actions / events may occur / be performed in a different order than presented.

[0076] At 301, a connection for unicast communication between end WTRUs may be established via Repeater 1. End WTRU 2 may send a Protected Direct Security Mode (DSM) command including security parameters (e.g., a portion of the session key identifier, a nonce, a security algorithm / policy) to End WTRU 2. End WTRU 1 may send a Protected Direct Security Mode (DSM) Complete including security parameters (e.g., another portion of the session key identifier, a security policy, etc.) to End WTRU 2 in response.

[0077] At 302, there may be one or more messages (eg, data traffic, etc.) sent / received between end WTRUs via Relay 1.

[0078] In 303, end WTRU1 may decide to perform U2U repeater reselection with end WTRU2 based on another condition described herein, such as resource usage conditions, a configuration limiting simultaneous connections for the same service, and / or others described herein. End WTRU1 decides to generate a new KNRP ID with end WTRU2 based on the decision to maintain the current connection via Repeater 1. For example, end WTRU1 may decide to maintain the initial connection based on the availability of resources for the new connection. In another example, end WTRU1 may decide to maintain the initial connection based on a configuration parameter that controls the use of simultaneous connections (e.g., the maximum number of simultaneous connections allowed for a ProSe service or RSC). In other words, with respect to the decision to maintain the connection, after the decision to perform reselection, end WTRU1 may decide to generate a new Key ID, assuming that the current connection is maintained.

[0079] At 304, end WTRU1 may send a Link Modification Request (LMR) message to end WTRU2, which may include an instruction to maintain the initial connection prior to connection setup via Relay 2, the newly assigned MSB of the KNRP ID, and / or other parameters (e.g., a reselection instruction, identifiers of candidate relays including Relay 2). The newly assigned MSB of the KNRP ID associated with end WTRU2 uniquely identifies the KNRP at end WTRU1. End WTRU1 may include parameters for whether / when to release the initial connection after the new connection setup (e.g., release timer, maintain connection, release upon data communication over the new connection). In other words, the newly assigned MSB is for creating a new KNRP ID for the current key. When the LSB is received from end WTRU2 later in this process, end WTRU1 can create a new KNRP ID (e.g., for the current key) by combining the MSB and LSB, as described further herein.

[0080] At 305, end WTRU2 may select Relay 2 from the list of candidate relays. End WTRU2 may assign the LSBs of the KNRP ID associated with end WTRU1, which uniquely identifies the KNRP within end WTRU2. End WTRU2 may then combine the MSBs of the KNRP ID received from end WTRU1 with the LSBs of the KNRP ID to form a new KNRP ID to be used when reconnecting with end WTRU1. End WTRU2 replaces the old KNRP ID with the new KNRP ID. End WTRU2 may send a Link Modification Accept (LMA) message to end WTRU1 including the LSBs of the KNRP ID and / or other parameters (e.g., the identifier of the selected Relay 2). If the LMR does not include a release / maintenance indication, maintaining the initial connection may be assumed by default or may be left to the end WTRU to select (see, for example, the example illustrated in FIG. 4). End WTRU2 may assign the LSBs of the KNRP ID based on receiving the initial connection maintenance indication and / or the MSBs of the KNRP ID.

[0081] At 306, end WTRU1 may combine the MSB of the KNRP ID sent at 304 with the LSB of the KNRP ID received from end WTRU2 to form a new KNRP ID to be used when reconnecting with end WTRU2. End WTRU1 may replace the old KNRP ID with the new KNRP ID. End WTRU1 may send a DCR message containing the new KNRP ID to end WTRU2 via repeater 2 (e.g., a direct PC5 link with repeater 2 may have been previously set up or modified).

[0082] At 307, End WTRU1 and End WTRU2 may establish security for the connection between the End WTRUs via Repeater 2. The KNRP ID is used to find the corresponding KNRP that is used to derive session and security keys for securing the connection. In other words, the KNRP does not change, but the KNRP ID does (e.g., hence the need for new MSBs and LSBs).

[0083] At 308, end WTRU1 may receive a DCA from end WTRU2 completing the connection establishment. The end WTRU (e.g., end WTRU1 or end WTRU2) decides to continue maintaining the initial connection via repeater 1 or to perform a release of the initial connection based on the parameters described above (e.g., timers, data packets exchanged over the new connection).

[0084] 4 illustrates an example of 5G ProSe U2U repeater reselection with KNRP ID privacy protection based on initial PC5 connection release or maintenance negotiation prior to PC5 connection setup via a selected repeater. As shown, there may be several devices involved in the reselection procedure, such as end WTRU1 451, repeater 1 452, repeater 2 453, and / or end WTRU2 454. While FIG. 4 presents an ordered sequence of actions / events, it is contemplated that one or more of these actions / events may be optional and / or one or more of these actions / events may occur / be performed in an order different from that presented.

[0085] At 401, a connection for unicast communication between end WTRUs is established via Repeater 1.

[0086] At 402, there may be one or more messages (eg, data traffic, etc.) sent / received between end WTRUs via Relay 1.

[0087] At 403, end WTRU1 decides to perform U2U repeater reselection with end WTRU2.

[0088] At 404, end WTRU1 sends a Link Modification Request (LMR) message to end WTRU2, where the Link Modification Request message may include a release indication or a maintain (e.g., preference) indication and / or other parameters (e.g., reselection indication, identifiers of candidate relays, including relay 2). In some cases, the release indication is used to request release of the initial PC5 connection prior to setting up the connection via the selected relay. In some cases, the maintain indication is used to request maintenance of the initial PC5 connection during setting up the connection via the selected relay.

[0089] At 405, end WTRU2 selects relay 2 from the list of relay candidates. End WTRU2 decides to maintain the initial connection (e.g., based on end WTRU1 maintenance preferences, ProSe / RSC service configuration, and / or end WTRU2 resource usage) and allocates a new LSB of the KNRP ID associated with end WTRU1. End WTRU2 sends a Link Modification Accept (LMA) message to end WTRU1 that includes a maintenance instruction, the LSB of the KNRP ID, and other parameters (e.g., an identifier of the selected relay 2). End WTRU2 may include parameters for how to handle the maintained initial connection (e.g., timer-based release, etc.) once a new connection is set up, as described herein.

[0090] At 406, end WTRU1 accepts to maintain the initial PC5 connection. End WTRU1 assigns a new MSB of the KNRP ID and combines the new MSB and new LSB of the KNRP ID to form a new KNRP ID to be used when reconnecting with end WTRU2. End WTRU1 replaces the old KNRP ID with the new KNRP ID. End WTRU1 sends a Link Modify Ack message including the MSB of the KNRP ID to end WTRU2. End WTRU2 combines the new MSB and new LSB of the KNRP ID to form a new KNRP ID (e.g., the same as that formed by end WTRU1), which will be used when reconnecting with end WTRU1. End WTRU2 replaces the old KNRP ID with the new KNRP ID.

[0091] At 407, end WTRU1 sends a DCR message including the new KNRP ID to end WTRU2 via repeater 2.

[0092] At 408, End WTRU1 and End WTRU2 establish security for the connection between the End WTRUs via Repeater 2. The new KNRP ID is used to find the corresponding KRNP that is used to derive session and security keys to secure the connection.

[0093] At 409, end WTRU1 receives a DCA from end WTRU2 completing the connection establishment. The initial connection is maintained or released based on one or more of the parameters described herein (e.g., at 405 or elsewhere).

[0094] 5 illustrates an example of 5G ProSe U2U repeater reselection with KNRP ID privacy protection. As shown, there may be several devices involved in the reselection procedure, such as end WTRU1 551, repeater 1 552, repeater 2 553, and / or end WTRU2 554. While FIG. 5 presents an ordered sequence of actions / events, it is contemplated that one or more of these actions / events may be optional and / or one or more of these actions / events may occur / be performed in a different order than presented.

[0095] At 501, a connection for unicast communication between end WTRUs is established via Repeater 1.

[0096] At 502, there may be one or more messages (eg, data traffic, etc.) sent / received between end WTRUs via Relay 1.

[0097] At 503, end WTRU1 decides to perform U2U repeater reselection with end WTRU2 using coordinated release of the initial connection (e.g., before the new connection setup). For example, end WTRU1 may decide to release resources used up by the initial connection. In another example, WTRU1 may decide to release the initial connection based on configuration parameters that control the use of simultaneous connections (e.g., the maximum number of simultaneous connections allowed for ProSe service or RSC).

[0098] At 504, end WTRU1 sends a link modification request (LMR) message to end WTRU2 including an instruction requesting a coordinated release of the initial connection via Relay 1 and / or other parameters (e.g., a reselection instruction, identifiers of candidate relays including Relay 2). Based on the release instruction, end WTRU2 stops sending data packets and other link maintenance messages (e.g., keep-alives, link identifier updates) using the initial connection and starts a timer for expected receipt of a link release request from end WTRU1.

[0099] At 505, end WTRU2 sends a link modification accept (LMA) message to end WTRU1 including acceptance of the coordinated release of the initial connection via Relay 1 and other parameters (e.g., the identifier of the selected Relay 2). End WTRU1 stops sending data packets and / or other link maintenance messages (e.g., keep-alives, link identifier updates) as necessary. When end WTRU2 is expected to initiate the link release, end WTRU1 starts a timer for expected receipt of a link release request from end WTRU2.

[0100] At 506, end WTRU1 sends a link release request message including the new MSB of the KNRP ID to end WTRU2. Alternatively, end WTRU2 may send a link release request message on behalf of end WTRU1 after the LMA.

[0101] At 507, end WTRU2 sends a Link Release Response message including the LSBs of the KNRP ID to end WTRU1. End WTRU2 establishes a new KNRP ID combining the received MSBs with the LSBs of the KNRP ID.

[0102] 6 illustrates an example of 5G ProSe U2U repeater reselection with privacy protection of the KNRP ID based on a new state associated with the KNRP ID. As shown, there may be several devices involved in the reselection procedure, such as end WTRU1 651, repeater 1 652, repeater 2 653, and / or end WTRU2 654. While FIG. 6 presents an ordered sequence of actions / events, it is contemplated that one or more of these actions / events may be optional and / or one or more of these actions / events may occur / be performed in a different order than presented.

[0103] At 601, a connection for unicast communication between end WTRUs is established via Repeater 1.

[0104] At 602, there may be one or more messages (eg, data traffic, etc.) sent / received between end WTRUs via Relay 1.

[0105] At 603, end WTRU1 decides to perform U2U repeater reselection with end WTRU2.

[0106] At 604, end WTRU1 sends a Link Modification Request (LMR) message to end WTRU2, where the Link Modification Request message may include a release indication or a maintenance (e.g., preference) indication and / or other parameters (e.g., reselection indication, identifiers of candidate relays, including relay 2). In some cases, the release indication is used to request release of the initial PC5 connection prior to setting up a connection via the selected relay. In some cases, the maintenance indication is used to request maintenance of the initial PC5 connection during / after setting up a connection via the selected relay.

[0107] At 605, end WTRU2 selects relay 2 from the list of relay candidates. End WTRU2 decides to maintain the initial PC5 connection after completing the connection setup via the selected repeater. End WTRU2 associates a state with the KNRP ID associated with the End WTRU1 / End WTRU2 pair and sets it to "refresh pending". In some cases, the "refresh pending" state means that the KNRP ID cannot be reused during new PC5 link establishment (e.g., on a DCR message) and a new KNRP ID needs to be generated.

[0108] At 606, end WTRU2 sends a link modification accept (LMA) message to end WTRU1, which may include a maintain indication and / or other parameters (e.g., an identifier of the selected repeater 2). In some cases, the maintain preference takes precedence over release (e.g., break-before-make). For example, if one of the end WTRUs prefers to maintain the PC5 connection but the other prefers to release it, the PC5 connection is maintained. In some cases, maintain is assumed by default (e.g., if no indication is specified in the LMR).

[0109] At 607, End WTRU1 sets the KNRP ID state to "refresh pending" based on the received maintenance instruction. End WTRU1 decides to set up a new PC5 connection via Repeater 2 without using the existing KNRP ID, since the KNRP ID state is set to "refresh pending".

[0110] At 608, End WTRU1 sends a DCR message to End WTRU2 via Repeater 2, and does not include the KNRP ID associated with the End WTRU1 / End WTRU2 pair, even if a KNRP / KNRP ID exists. In general, the DCR message may include other parameters, such as target user information, security policy information, etc.

[0111] At 609, End WTRU1 and End WTRU2 authenticate each other via Repeater 2. A new KNRP / KNRP ID is derived. The existing KNRP ID is replaced with the newly derived value and its state is set to "valid", which means that the KNRP / KNRP ID can be used for session key derivation and that the KNRP ID can be used for other PC5 connection establishments. Note that the example in Figure 6 (e.g., as illustrated by this step) relates to a scenario that requires a full authentication procedure (e.g., new keys and new key IDs).

[0112] At 610, End WTRU1 and End WTRU2 establish security for the connection between the End WTRUs via Repeater 2. The KNRP ID is used to find the corresponding KRNP used to derive session and security keys to secure the connection.

[0113] At 611, end WTRU1 receives a DCA from end WTRU2 completing the connection establishment.

[0114] 7 illustrates an example of 5G ProSe U2U repeater reselection security with pre-key generation for a new connection with a second repeater. As shown, there may be several devices involved in the reselection procedure, such as end WTRU1 751, repeater 1 752, repeater 2 753, and / or end WTRU2 754. While FIG. 7 presents an ordered sequence of actions / events, it is contemplated that one or more of these actions / events may be optional and / or one or more of these actions / events may occur / be performed in a different order than presented.

[0115] At 701, a connection for unicast communication between end WTRUs is established via Repeater 1.

[0116] At 702, there may be one or more messages (eg, data traffic, etc.) sent / received between end WTRUs via Relay 1.

[0117] At 703, end WTRU1 decides to perform U2U repeater reselection with end WTRU2. End WTRU1 decides to perform pre-key generation for the new connection over the current connection based on the current connection security policy / configuration (e.g., signaling integrity is turned on). End WTRU1 assigns a new MSB of the correlation ID.

[0118] At 704, end WTRU1 sends a link modification request (LMR) message to end WTRU2 including the MSB of the correlation ID, a new connection pre-key generation instruction, and / or other parameters (e.g., a reselection instruction, identifiers of candidate relays including relay 2).

[0119] At 705 (e.g., 705a and 705b), end WTRU2 assigns the LSB of the correlation ID, combines the MSB and LSB of the correlation ID to form a new correlation ID, and stores the correlation ID in the new connection context associated with relay 2 along with end WTRU1 information (e.g., user info ID, KNRP / KNRP ID) and / or relay 2 information (e.g., relay user info ID, L2 ID). End WTRU2 may send a link modification accept (LMA) message to end WTRU1 including the new connection pre-key ack, correlation ID, and / or other parameters (e.g., the identifier of the selected relay 2).

[0120] At 706 (e.g., 706a and 706b), end WTRU1 combines the MSB and LSB to form a new correlation ID and stores the new correlation ID in a new connection context associated with relay 2 along with end WTRU2 information and / or relay 2 information. End WTRU1 sends a pre-key request message or a re-key request message to end WTRU2 via the first relay that includes instructions to generate new keys for the new connection. End WTRU1 includes the correlation ID and / or other re-key security parameters (e.g., security capabilities, nonce, MSB of the new KNRP-SESS ID) in the message.

[0121] At 707 (e.g., 707a and 707b), end WTRU2 generates new session (KNRP-SESS) and security keys (NRPEK and NRPIK) and stores the keys in the new connection context. End WTRU2 sends a DSM command message to end WTRU1 via repeater 1, including a correlation ID and conventional re-key security parameters. The message is protected using the security context already established for the current connection (e.g., no instructions are sent to lower layers to activate new security using new keys).

[0122] At 708, end WTRU1 receives a DSM command message from end WTRU2, including a correlation ID and conventional re-key security parameters. End WTRU1 generates new security keys and stores them in a new connection context. End WTRU1 sends a DSM complete message to end WTRU2 via the first repeater.

[0123] At 709, end WTRU2 sends a rekey response message to end WTRU1 confirming that end WTRU2 is ready to use the new key in the connection via the second repeater.

[0124] At 710, end WTRU1 sends an integrity-protected DCR message including the correlation ID to end WTRU2 via repeater 2. The message is protected using a new key associated from the new connection context. Authentication and security establishment procedures can be skipped over the new connection. End WTRU2 finds the new connection security key based on the correlation ID. End WTRU2 activates a security context for the new connection using the new connection's stored security key. End WTRU2 sends a fully protected DCA using the security context to end WTRU1. End WTRU1 activates a security context for the new connection using the new connection's stored security key located with the correlation ID.

[0125] In one example, there may be (Root) Key NR ProSe (KNRP) privacy protection using Link Modification Request / Accept / Ack (LMR / LMA / LMAck) during an L2 U2U repeater reselection procedure. This procedure may establish a new KNRP ID during the link modification procedure, and the peer WTRU accepts the initial connection maintenance preference. End WTRU1 establishes a new KNRP ID with end WTRU2 during the U2U repeater reselection procedure via the first repeater and uses the new KNRP ID during connection setup via the second repeater.

[0126] Initially, in this example, end WTRU1 may decide to establish a new KNRP ID for the new connection during reselection based on a decision to maintain the current connection via the first repeater (e.g., based on ProSe service / RSC configuration, current resource usage).

[0127] End WTRU1 may send an LMR message to end WTRU2 via the first repeater, including an instruction to maintain the initial connection before setting up the connection via the second repeater, and the newly assigned MSB of the KNRP ID, to notify end WTRU2 to update the current KNRP ID shared with end WTRU1.

[0128] End WTRU1 may receive an LMA message from end WTRU2 that includes the new LSBs of the KNRP ID.

[0129] End WTRU1 can combine the new MSB of the KNRP ID with the new LSB of the KNRP ID.

[0130] End WTRU1 can store the new KNRP ID by replacing the current KNRP ID.

[0131] End WTRU1 may send a DCR message including the new KNRP ID to end WTRU2 via the second repeater.

[0132] End WTRU1 may receive the DCA message from end WTRU2 via the second relay.

[0133] End WTRU1 may decide to initiate the release of the initial connection or to maintain it.

[0134] In one example, there may be a way to establish a new KNRP ID during a link modification procedure, where a peer WTRU connection release is not accepted by the peer WTRU.

[0135] In this example, initially, end WTRU1 decides to establish a new KNRP ID for the new connection during reselection based on a decision to maintain the current connection via the first repeater (e.g., based on ProSe service / RSC configuration, current resource usage).

[0136] End WTRU1 may send an LMR message including an instruction for initial connection preference release to end WTRU2 via the first relay prior to connection setup via the second relay.

[0137] End WTRU1 may receive an LMA message from end WTRU2 that includes the new LSBs of the KNRP ID.

[0138] End WTRU1 may send an LMAck containing the new MSBs of the KNRP ID to end WTRU2 via the first repeater.

[0139] End WTRU1 combines the new MSB of the KNRP ID with the new LSB of the KNRP ID.

[0140] End WTRU1 uses the new KNRP ID during the setup of the new connection through the second repeater.

[0141] In one example (as described further herein), there may be an approach for KNRP ID privacy protection using coordinated initial connection release during an L2 U2U relay reselection procedure. A new KNRP ID may be established by coordinating link release of the initial connection through the first relay using a link modification procedure.

[0142] First, in this example, end WTRU1 may coordinate with end WTRU2 the release of the current connection via the first repeater in order to establish a new KNRP ID before using it in setting up a new connection via the second repeater.

[0143] End WTRU1 may decide (eg, based on ProSe service / RSC configuration, current resource usage) to coordinate the release of the current connection and establish a new KNRP ID for the new connection.

[0144] End WTRU1 may send an LMR message to end WTRU2 via the first relay, including an instruction for release of the initial connection prior to setup of the new connection via the second relay.

[0145] End WTRU1 may receive an LMA message from end WTRU2 containing an acknowledgment for the release of the initial link. Note that the LMR / LMA negotiates the release but does not actually trigger the release.

[0146] End WTRU1 may send a link release request including the newly assigned MSB of the KNRP ID to end WTRU2 via the first repeater. Note that the link release request actually triggers the release of the connection.

[0147] End WTRU1 may receive a link release response from end WTRU2 that includes new LSBs of KNRP ID 1.

[0148] End WTRU1 can combine the new MSB of the KNRP ID with the new LSB of the KNRP ID and store the new KNRP ID by replacing the current KNRP ID.

[0149] End WTRU1 (upon receiving the link release response message from end WTRU2) sends a DCR message including the new KNRP ID to end WTRU2 via the second relay.

[0150] In one example (as described further herein), there may be an approach for pre-keying a new connection procedure during an L2 U2U repeater reselection procedure. A new security key may be generated during the repeater reselection procedure via the initial connection via the first repeater. The new key may be used for security of the new connection via the second repeater.

[0151] In this example, first, end WTRU1 may negotiate the implementation of pre-key generation of security keys to be used to secure the connection via the second repeater during the U2U repeater reselection procedure via the first repeater.

[0152] End WTRU1 may decide to perform enhanced re-keying as part of the U2U repeater reselection procedure based on the security policy / configuration for the initial connection via the first repeater (e.g., a non-NULL integrity algorithm is in use).

[0153] End WTRU1 may send an LMR message to end WTRU2 via the first repeater that includes instructions to perform an extended rekey to generate a new session key before setting up a new connection via the second repeater, the MSB of the newly assigned correlation ID, and a list of repeater identifiers.

[0154] End WTRU1 may receive an LMA message from end WTRU2 containing an acknowledgment to perform the extended re-keying, an identifier of the selected second repeater, and the LSBs of the new correlation ID. End WTRU1 combines the MSBs and LSBs of the correlation ID to form a correlation ID that is used to associate the initial connection with the new connection (to be established).

[0155] End WTRU1 may send a Rekey Request message to End WTRU2 via the first repeater, including instructions to generate a new key for the new connection, an identifier associated with the second repeater (e.g., any of User Info ID, L2 ID, Correlation ID), and other rekey security parameters (e.g., security capabilities, nonce, MSB of the new KNRP-SESS ID).

[0156] End WTRU1 may receive a DSM command message from end WTRU2 that includes a correlation ID and conventional re-key security parameters.

[0157] End WTRU1 may generate a new session key with identifiers (KNRP-SESS and ID) and new security keys (NRPEK and NRPIK) to be used with the new connection.

[0158] End WTRU1 may store the new key for the new connection along with the existing KNRP ID and the identifier associated with the second repeater.

[0159] End WTRU1 may send a DSM complete message to end WTRU2 via the first relay.

[0160] End WTRU1 may receive a re-key response message from end WTRU2 confirming that end WTRU2 is ready to use the new key in the connection via the second repeater. End WTRU1 (and end WTRU2) preserves the security context for the initial connection via repeater 1.

[0161] End WTRU1 may send the correlation ID in an integrity protected DCR message for end WTRU2 to discover new security keys and use them to establish a new connection security.

[0162] FIG. 8 illustrates an example of a reselection process. A WTRU (e.g., communicating with another WTRU across one or more relays) may perform a method for a (re)selection process (e.g., with respect to a relay). The WTRU may send a request message, where the request message may include an instruction to include a new most significant byte (MSB) for the current Key NR ProSE (KNRP). The WTRU may receive an accept message, where the accept message includes a new least significant byte (LSB) of the current KNRP. The WTRU may send a direct connection request with a new KNRP ID, where the new KNRP ID is generated from combining the new MSB of the current KNRP and the new LSB of the current KNRP. The WTRU may receive a direct connection accept message. The request message may be a link modification request (LMR) message, and the accept message may be a link modification accept (LMA) message. The request message may include an instruction to maintain the current connection via the first relay. After the direct connection request message is received, the current connection may be released.

[0163] As described herein, the following acronyms may be used: Break Before Make (BBM); Make Before Break (MBB); Direct Connect Request / Accept (DCR / DCA); (Root) Key NR ProSe (KNRP); Session Key NR PRoSe (KNRP-Sess); Link Modification Request / Accept (LMR / LMA); Least / Most Significant Byte (LSB / MSB); NR ProSe Encryption Key (NRPEK); NR ProSe Integrity Key (NRPIK); Relay Service Code (RSC); and / or UE-to-UE Relay (U2U Relay).

[0164] As described herein, a higher layer may refer to one or more layers in a protocol stack or a particular sublayer within a protocol stack. This protocol stack may be composed of one or more layers within a WTRU or a network node (e.g., an eNB, a gNB, other functional entity, etc.), where each layer may have one or more sublayers. Each layer / sublayer may be responsible for one or more functions. Each layer / sublayer may communicate directly or indirectly with one or more of the other layers / sublayers. In some cases, these layers may be numbered, such as Layer 1, Layer 2, and Layer 3. For example, Layer 3 may be composed of one or more of the following: Non-Access Stratum (NAS), Internet Protocol (IP), and / or Radio Resource Control (RRC). For example, Layer 2 may be composed of one or more of the following: Packet Data Convergence Control (PDCP), Radio Link Control (RLC), and / or Medium Access Control (MAC). For example, Layer 3 may consist of a physical (PHY) layer type of operation. The higher the layer number, the higher the layer relative to other layers (e.g., Layer 3 is higher than Layer 1). In some cases, the foregoing may be referred to as layers / sublayers themselves, regardless of the number of layers, and may be referred to as upper layers as described herein. For example, upper layers may refer to one or more of the following layers / sublayers, from highest to lowest: NAS layer, RRC layer, PDCP layer, RLC layer, MAC layer, and / or PHY layer. Any reference herein to a higher layer associated with a process, device, or system will refer to a layer that is higher than the layer of the process, device, or system. In some cases, a reference herein to a higher layer may refer to a function or operation performed by one or more layers described herein. In some cases, a reference herein to a higher layer may refer to information sent or received by one or more layers described herein. In some cases, a reference herein to a higher layer may refer to configurations sent and / or received by one or more layers described herein.

[0165] Although features and elements are described above in particular combinations (e.g., embodiments, methods, examples, etc.), those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. For example, as disclosed herein, there may be a method described in connection with figures for illustrative purposes, and those skilled in the art will understand that one or more features or elements from this method can be used alone or in combination with one or more features from another method described elsewhere. The symbol " / " (e.g., a forward slash) may be used herein to represent "and / or," e.g., "A / B" may imply "A and / or B." As used herein, "a" and "an" and similar words should be interpreted as "one or more" and "at least one." Similarly, any term ending in the suffix "(s)" should be interpreted as "one or more" and "at least one." The term "may" should be interpreted as "may, for example," or to indicate that something "happens" or "could occur." Additionally, the methods described herein may be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and Digital Versatile Disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. 1. A method performed by a first wireless transmit / receive unit (WTRU), comprising: sending a link modification request (LMR) message to a second WTRU using the first relay, the LMR message including a new most significant byte (MSB) of a new key NR ProSe identifier (KNRP ID) of the current key; receiving a link modification accept (LMA) message from the second WTRU using the first repeater, the LMA message including a new least significant byte (LSB) of the new KNRP ID of the current key; forming the new KNRP ID by combining the new MSB with the new LSB; and sending a direct connection request (DCR) message to the second WTRU using a second relay, the DCR message including the new KNRP ID.

2. 2. The method of claim 1, wherein before sending the LMR message, sending a message to the second WTRU using the first relay over a first connection, the first connection being established based on an initial KNRP ID of the current key, the initial KNRP ID being different from the new KNRP ID.

3. The method of claim 1 , wherein the current key is the same at the first WTRU and the second WTRU.

4. The method of claim 1 , wherein the initial KNRP ID of the current key is discarded when the new KNRP ID of the current key is formed.

5. 2. The method of claim 1, further comprising: determining to maintain the initial connection of the first relay based on configuration parameters controlling usage of simultaneous connections, the configuration parameters including a maximum number of simultaneous connections allowed for ProSe service.

6. a first wireless transmit / receive unit (WTRU), means for sending a link modification request (LMR) message to a second WTRU using the first relay, the LMR message including a new most significant byte (MSB) of a new key NR ProSe identifier (KNRP ID) of the current key; means for receiving a link modification accept (LMA) message from the second WTRU using the first repeater, the LMA message including a new least significant byte (LSB) of the new KNRP ID of the current key; means for combining the new MSBs with the new LSBs to form the new KNRP ID; and means for sending a direct connection request (DCR) message to the second WTRU using a second relay, the DCR message including the new KNRP ID.

7. 7. The first WTRU of claim 6, wherein before sending the LMR message, the first WTRU sends a message to the second WTRU using the first relay via a first connection, the first connection being established based on an initial KNRP ID of the current key, and the initial KNRP ID being different from the new KNRP ID.

8. The first WTRU of claim 6 , wherein the current key is the same in the first WTRU and the second WTRU.

9. The first WTRU of claim 6 , wherein an initial KNRP ID for the current key is discarded when the new KNRP ID for the current key is formed.

10. 7. The first WTRU of claim 6, further comprising: determining to maintain the initial connection of the first relay based on configuration parameters controlling use of simultaneous connections, the configuration parameters including a maximum number of simultaneous connections allowed for ProSe services.

Images