Method for Privacy Protection Using Coordination of Initial Connection Release during Repeater Re-selection
The technique for WTRU to utilize multiple connections and repeaters with link correction during reselection addresses the need for secure and private information transmission in wireless communication systems, enhancing security and privacy.
Patent Information
- Application Number
- JP2024565972
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2023-04-04
- Filing Date
- 2024-04-04
- Publication Date
- 2025-07-30
AI Technical Summary
There is a need in wireless communication systems for a method to securely transmit information via a third device acting as a repeater while ensuring privacy and security.
A technique for a wireless transmit/receive unit (WTRU) to utilize multiple connections and employ repeaters, with a method for privacy protection through link correction operations during repeater reselection.
Ensures secure and private transmission of information by leveraging multiple connections and repeater reselection methods, enhancing security and privacy in wireless communication systems.
Smart Images

Figure 2025524328000001_ABST
Abstract
Description
Technical Field
[0001] (Cross - Reference to Related Applications) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 457,073, filed on April 4, 2023, the content of which is incorporated herein by reference.
Background Art
[0002] In a wireless communication system, there is a need to address a method by which a first device and a second device can securely transmit information via a third device that functions as a repeater.
Summary of the Invention
[0003] In a system, method, and / or device, there may be a technique for a connection from a wireless transmit receive unit (WTRU) to a WTRU that utilizes two or more connections, selects a connection, guarantees security and privacy, and uses one or more repeaters. The WTRU can execute a method for privacy protection that uses a link correction operation during repeater reselection.
Brief Description of the Drawings
[0004] A more detailed understanding can be obtained from the following description given by way of example in conjunction with the accompanying drawings, in which like reference numerals in the figures indicate like elements.
Figure 1A
Figure 1B
Figure 1C
Figure 1D
Figure 2
Figure 3
Figure 4
Figure 5
Figure 6
Figure 7
Figure 8
DETAILED DESCRIPTION OF THE INVENTION
[0005] FIG. 1A is a diagram illustrating an exemplary communication system 100 in which one or more of the 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 a plurality of wireless users. The communication system 100 may enable a plurality of 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 filter type OFDM, filter bank multicarrier (FBMC).
[0006] As shown in Figure 1A, communication system 100 can 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 the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may also be referred to as a station (STA), can be configured to transmit and / or receive wireless signals and can be a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscriber-based unit, a pager, a cellular 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 wristwatch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and application (e.g., telesurgery), 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 can also be referred to interchangeably as a UE.
[0007] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks such as CN 106, the Internet 110, and / or other network 112. By way of example, base stations 114a, 114b may be a base transceiver station (BTS), Node B, eNode B (eNB), home Node B, home eNode B, next generation Node B (gNode B), new radio (NR) Node B, site controller, access point (AP), wireless router, etc. Base stations 114a, 114b are each depicted as a single element, but it will be understood that base stations 114a, 114b may include any number of interconnected base stations and / or network elements.
[0008] Base station 114a may be part of RAN104, which may also include other base stations such as a base station controller (BSC), a radio network controller (RNC), a relay node, and / or network elements (not shown). Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals at one or more carrier frequencies that may be referred to as a cell (not shown). These frequencies may be in an authorized spectrum, an unlicensed spectrum, or a combination of an authorized spectrum and an unlicensed spectrum. A cell may provide wireless service coverage to a specific geographic area that may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers per sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.
[0009] Base stations 114a, 114b may communicate with one or more of WTRUs 102a, 102b, 102c, 102d via air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Air interface 116 may be established using any suitable radio access technology (RAT).
[0010] More specifically, as described above, the communication system 100 may be a multiple access system and may use one or more channel access methods such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base stations 114a and the WTRUs 102a, 102b, 102c of the RAN 104 may execute radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA) that can establish the air interface 116 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and / or High-Speed Uplink Packet Access (HSUPA).
[0011] In one embodiment, the base stations 114a and the WTRUs 102a, 102b, 102c may execute radio technologies 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 stations 114a and the WTRUs 102a, 102b, 102c may execute radio technologies such as NR radio access, which may establish the air interface 116 using NR.
[0013] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may execute multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, 102c may execute LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Accordingly, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by transmissions sent between multiple types of radio access technologies and / or multiple types of base stations (e.g., eNBs and gNBs).
[0014] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c may execute wireless 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), IS-95, IS-856, Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.
[0015] The base station 114b in FIG. 1A can be, for example, a wireless router, a home node B, a home eNode B, or an access point, and can utilize any suitable RAT to facilitate wireless connection in a local area such as an office, a home, a vehicle, a campus, an industrial facility, an aerial corridor (for example, for use by a drone), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d can execute a wireless 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 can execute a wireless technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d can utilize a cellular-based RAT (for example, WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a pico cell or a femto cell. As shown in FIG. 1A, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106.
[0016] RAN104 can communicate with CN106, which can be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of WTRU102a, 102b, 102c, 102d. The data can have various quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN106 can provide call control, billing services, mobile location-based services, prepaid calls, internet connectivity, video distribution, etc., and / or implement high-level security functions such as user authentication. Although not shown in Figure 1A, it will be understood that RAN104 and / or CN106 can communicate directly or indirectly with other RANs using the same or a different radio access technology (RAT) as RAN104. For example, in addition to being connected to RAN104 that can utilize New Radio (NR) radio technology, CN106 can also communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.
[0017] CN106 may also function as a gateway for WTRU102a, 102b, 102c, 102d to access the PSTN108, the Internet 110, and / or other networks 112. The PSTN108 may include a circuit-switched telephone network that provides a plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices, and these networks and devices 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 network 112 may include a wired communication network and / or a wireless communication network that is owned and / or operated by another service provider. For example, the network 112 may include another CN connected to one or more RANs that may use the same RAT as the RAN104 or a different RAT.
[0018] Some or all of the WTRU102a, 102b, 102c, 102d in the communication system 100 may include a multimode function (e.g., the WTRU102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). For example, the WTRU102c shown in Figure 1A may be configured to communicate with a base station 114a that may employ a cellular-based wireless technology and a base station 114b that may employ IEEE802 wireless technology.
[0019] Figure 1B is a system diagram illustrating an exemplary WTRU102. As shown in Figure 1B, the WTRU 102 can 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, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other peripheral devices 138. It will be understood that the WTRU 102 can include any partial combination of the foregoing elements while remaining consistent with one embodiment.
[0020] The processor 118 can be a general-purpose processor, a dedicated 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), any other type of integrated circuit (IC), a state machine, etc. The processor 118 can perform signal coding, data processing, power control, input / output processing, and / or any other function that enables the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to a transceiver 120 that can be coupled to a transmit / receive element 122. Although Figure 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.
[0021] The transmit / receive element 122 may be configured to transmit or receive signals to / from a base station (e.g., base station 114a) via 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, for example, IR signals, UV signals, or visible light signals. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF signals and optical 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] Although the transmit / receive element 122 is depicted in FIG. 1B as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via 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 a multimode function. 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 the speaker / microphone 124, keypad 126, and / or display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit), and may receive data input by a user therefrom. The processor 118 may also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad 128. Additionally, the processor 118 may access information from and store data in any suitable type of memory, such as the non-removable memory 130 and / or the removable memory 132. The non-removable memory 130 may include a random-access memory (RAM), read-only memory (ROM), hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, memory stick, secure digital (SD) memory card, etc. 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 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 power to other components in the WTRU 102. The power source 134 may be any suitable device for supplying power to the WTRU 102. For example, the power source 134 may include one or more dry cells (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.
[0026] 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 a base station (e.g., base stations 114a, 114b) via the air interface 116 and / or may determine its location based on the timing of signals received from two or more neighboring base stations. It will be understood that the WTRU 102 may obtain location information by any suitable location determination method while remaining consistent with one embodiment.
[0027] Processor 118 may further be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connections. For example, the peripheral devices 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, 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 / Augmented Reality (VR / AR) device, an activity tracker, etc. The peripheral devices 138 may include one or more sensors. The sensors may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor, etc.
[0028] The WTRU 102 may include a full-duplex radio in which some or all of the transmissions and receptions of signals (e.g., associated with specific subframes for both 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 for reducing and / or substantially eliminating self-interference either via hardware (e.g., a choke) or via signal processing through a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for some or all of the transmissions and receptions of signals (e.g., associated with a specific subframe for either UL (e.g., for transmission) or DL (e.g., for reception)).
[0029] Figure 1C is a system diagram illustrating RAN 104 and CN 106 according to one embodiment. As described above, the RAN 104 may employ E-UTRA radio technology to communicate with the WTRU 102a, 102b, 102c via the air interface 116. The RAN 104 may also communicate with the CN 106.
[0030] The RAN 104 may include eNodeBs 160a, 160b, 160c, although it will be understood that the RAN 104 may include any number of eNodeBs while remaining consistent with one embodiment. Each of the eNodeBs 160a, 160b, 160c may include one or more transceivers for communicating with the WTRU 102a, 102b, 102c via the air interface 116. In one embodiment, the eNodeBs 160a, 160b, 160c may implement MIMO technology. Thus, the eNodeB 160a may transmit a wireless signal to and / or receive a wireless signal from the WTRU 102a, for example, using multiple antennas.
[0031] Each of the eNodeBs 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decision-making, handover decision-making, user scheduling in the UL and / or DL, etc. As shown in Figure 1C, the eNodeBs 160a, 160b, and 160c can communicate with each other via the X2 interface.
[0032] The CN 106 shown in Figure 1C can 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 can be owned and / or operated by an entity other than the CN operator.
[0033] The MME 162 can be connected to each of the eNodeBs 162a, 162b, and 162c in the RAN 104 via the S1 interface and can function as a control node. For example, the MME 162 can perform roles such as authenticating the users of the WTRUs 102a, 102b, and 102c, activating / deactivating bearers, selecting a specific serving gateway during the initial attach of the WTRUs 102a, 102b, and 102c, etc. The MME 162 can provide control plane functions for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies such as GSM and / or WCDMA.
[0034] SGW164 can be connected to each of the eNodeBs 160a, 160b, and 160c in RAN104 via the S1 interface. SGW164 can generally route and transfer user data packets between the WTRUs 102a, 102b, and 102c. SGW164 can perform other functions such as the function of anchoring the user plane during handover between eNodeBs, the function of triggering paging when DL data is available to the WTRUs 102a, 102b, and 102c, and the function of managing and storing the context of the WTRUs 102a, 102b, and 102c.
[0035] SGW164 can be connected to PGW166, and PGW166 can provide access to a packet switched network such as the Internet 110 to the WTRUs 102a, 102b, and 102c to facilitate communication between the WTRUs 102a, 102b, and 102c and IP-enabled devices.
[0036] CN106 can facilitate communication with other networks. For example, CN106 can provide access to a circuit switched network such as PSTN108 to the WTRUs 102a, 102b, and 102c to facilitate communication between the WTRUs 102a, 102b, and 102c and legacy landline communication devices. For example, CN106 can include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that functions as an interface between CN106 and PSTN108. In addition, CN106 can provide the WTRUs 102a, 102b, and 102c with access to another network 112, which can include other wired and / or wireless networks owned and / or operated by other service providers.
[0037] The WTRU is described as a wireless terminal in FIGS. 1A - 1D, but in certain representative embodiments, it is contemplated that such a terminal can use (e.g., temporarily or permanently) a wired communication interface to the communication network.
[0038] In a representative embodiment, the other network 112 can be a WLAN.
[0039] A WLAN in infrastructure basic service set (BSS) mode can have an access point (AP) of the BSS and one or more stations (STAs) associated with the AP. The AP can have an access or interface to a distribution system (DS) or another type of wired / wireless network that carries traffic within and / or outside the BSS. Traffic to an STA originating outside the BSS can reach and be delivered to the STA through the AP. Traffic originating from an STA and going to a destination outside the BSS can be sent to the AP so as to be delivered to their respective destinations. Traffic between STAs within the BSS can be sent, for example, through the AP. The source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be sent between the source STA and the destination STA (e.g., directly between them) using direct link setup (DLS). In a particular representative embodiment, the DLS can use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (e.g., all of the STAs) can communicate directly with each other. The IBSS mode of communication can be referred to herein as the "ad hoc" communication mode.
[0040] When using an 802.11ac infrastructure operation mode or a similar operation mode, the AP may transmit beacons on a fixed channel such as the primary channel. The primary channel may have a fixed width (e.g., a 20 MHz bandwidth) or a dynamically set width. The primary channel may be the operating channel of the BSS, but can be used by the STA to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be performed, for example, in an 802.11 system. In the case of CSMA / CA, STAs including the AP (e.g., all STAs) 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. Only one STA (e.g., only one station) may transmit at any given time in a given BSS.
[0041] A High Throughput (HT) STA may use a 40 MHz wide channel for communication, and this 40 MHz wide channel may be formed, for example, through a combination of a primary 20 MHz channel and an adjacent or non - adjacent 20 MHz channel.
[0042] A Very High Throughput (VHT) STA can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. A 40 MHz and / or 80 MHz channel can be formed by combining a plurality of adjacent 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels or by combining two non-adjacent 80 MHz channels, which can be referred to as an 80+80 configuration. In the case of an 80+80 configuration, after channel encoding, the data can pass through a segment parser that can divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing can be performed separately for each stream. The streams can be mapped to two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration can be reversed, and the combined data can be sent to the Medium Access Control (MAC).
[0043] The sub-1GHz operating mode is supported by 802.11af and 802.11ah. The channel operating bandwidth and carrier frequency are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports bandwidths of 5MHz, 10MHz, and 20MHz in the TV White Space (TVWS) spectrum, and 802.11ah supports bandwidths of 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz using the non-TVWS spectrum. According to an exemplary embodiment, 802.11ah may support meter type control / machine type communications (MTC) such as MTC devices in a macro coverage area. The MTC device may have limited capabilities, including support for certain capabilities, e.g., support for certain and / or limited bandwidths (e.g., only these). The MTC device may include a battery having a battery life above a threshold (e.g., to maintain a very long battery life).
[0044] A WLAN system that supports a plurality of channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes 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 can be set and / or restricted by the STA among all STAs operating in the BSS that support the minimum bandwidth operation mode. In the example of 802.11ah, the primary channel can be 1 MHz wide for an STA (e.g., an MTC type device) that supports the 1 MHz mode (e.g., supports only this) even when the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operation modes. Carrier sensing and / or Network Allocation Vector (NAV) setting may depend on the status of the primary channel. For example, if the primary channel is busy by an STA transmitting to the AP (supporting only the 1 MHz operation mode), even if most of the available frequency band is idle, all of the available frequency band may be considered busy.
[0045] In the United States, the available frequency band that can be used by 802.11ah is 902 MHz to 928 MHz. In South Korea, the available frequency band is 917.5 MHz to 923.5 MHz. In Japan, the available frequency band is 916.5 MHz to 927.5 MHz. The total available bandwidth for 802.11ah is 6 MHz to 26 MHz depending on the country code.
[0046] FIG. 1D is a system diagram illustrating RAN 104 and CN 106 according to one embodiment. As described above, RAN 104 may employ NR radio technology to communicate with WTRUs 102a, 102b, 102c via air interface 116. RAN 104 may also communicate with CN 106.
[0047] RAN 104 may include gNBs 180a, 180b, and 180c, but it should be understood that RAN 104 may include any number of gNBs while remaining consistent with one embodiment. Each of gNBs 180a, 180b, and 180c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may perform MIMO technology. For example, gNBs 180a and 108b may use beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Thus, gNB 180a may transmit and / or receive radio signals to / from WTRU 102a using, for example, multiple antennas. In one embodiment, gNBs 180a, 180b, and 180c may perform carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to WTRU 102a (not shown). A subset of such component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c may perform Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmission from gNB 180a and gNB 180b (and / or gNB 180c).
[0048] WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable numerology. For example, the OFDM symbol interval and / or the OFDM subcarrier interval may vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., including various numbers of OFDM symbols and / or varying durations of absolute time of various lengths).
[0049] gNBs 180a, 180b, and 180c may be configured to communicate with WTRUs 102a, 102b, and 102c in a stand-alone configuration and / or a non-stand-alone configuration. In a stand-alone configuration, the WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNodeBs 160a, 160b, and 160c, etc.). In a stand-alone configuration, the WTRUs 102a, 102b, and 102c may utilize one or more of gNBs 180a, 180b, and 180c as mobility anchor points. In a stand-alone configuration, the WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c using signals in an unlicensed band. In a non-stand-alone configuration, the WTRUs 102a, 102b, and 102c may communicate with and connect to gNBs 180a, 180b, and 180c while also communicating with and connecting to another RAN such as eNodeBs 160a, 160b, and 160c. For example, the WTRUs 102a, 102b, and 102c may perform a DC principle for communicating with one or more gNBs 180a, 180b, and 180c and one or more eNodeBs 160a, 160b, and 160c substantially simultaneously. In a non-stand-alone configuration, the eNodeBs 160a, 160b, and 160c may function as mobility anchors for the WTRUs 102a, 102b, and 102c, and the gNBs 180a, 180b, and 180c may provide additional coverage and / or throughput for servicing the WTRUs 102a, 102b, and 102c.
[0050] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decision-making, handover decision-making, user scheduling in 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, gNBs 180a, 180b, and 180c can communicate with each other via the Xn interface.
[0051] As shown in FIG. 1D, CN 106 can include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and optionally data networks (DNs) 185a, 185b. Although the foregoing elements are depicted as part of CN 106, it will be understood that any of these elements can be owned and / or operated by entities other than the CN operator.
[0052] AMF 182a and 182b can be connected to one or more of gNBs 180a, 180b, and 180c in RAN 104 via the N2 interface and can function as control nodes. For example, AMF 182a and 182b can perform roles such as user authentication of WTRUs 102a, 102b, and 102c, support for network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selection of specific SMFs 183a and 183b, management of the registration area, termination of non-access stratum (NAS) signaling, and mobility management. Network slicing can be used by AMF 182a and 182b to customize the CN support for WTRUs 102a, 102b, and 102c based on the type of services utilized by WTRUs 102a, 102b, and 102c. For example, different network slices can be established for different use cases such as services that rely on ultra-reliable low latency (URLLC) access, services that rely on enhanced massive mobile broadband (eMBB) access, services for MTC access, etc. AMF 182a and 182b can provide control plane functions for switching between RAN 104 and other RANs (not shown) that employ other radio technologies such as non-3GPP access technologies like LTE, LTE-A, LTE-A Pro, and / or WiFi.
[0053] SMF183a and 183b can be connected to AMF182a and 182b in CN106 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b in CN106 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b, and configure the routing of traffic passing through UPF184a and 184b. SMF183a and 183b can perform other functions such as the function of managing and allocating UE IP addresses, the function of managing PDU sessions, the function of implementing policies and controlling QoS, and the function of providing DL data notifications. The PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.
[0054] UPF184a and 184b can be connected to one or more of gNB180a, 180b, and 180c in RAN104 via the N3 interface, thereby providing access to a packet-switched network such as the Internet 110 to WTRU102a, 102b, and 102c to facilitate communication between WTRU102a, 102b, and 102c and IP-corresponding devices. UPF184 and 184b can perform other functions such as packet routing and forwarding, implementation of user plane policies, support for multi-home PDU sessions, processing of user plane QoS, buffering of DL packets, and provision of mobility anchoring.
[0055] CN106 can facilitate communication with other networks. For example, CN106 can include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that functions as an interface between CN106 and PSTN108. In addition, CN106 can provide access to other networks 112 for WTRU102a, 102b, 102c, and this other network can include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRU102a, 102b, 102c can be connected to local DN185a, 185b through UPF184a, 184b via an N3 interface to UPF184a, 184b and an N6 interface between UPF184a, 184b and DN185a, 185b.
[0056] In view of FIGS. 1A - 1D and the corresponding descriptions of FIGS. 1A - 1D, one or more of the functions described herein with respect to one or more of WTRU102a - 102d, base stations 114a - 114b, eNode Bs 160a - 160c, MME162, SGW164, PGW166, gNB180a - 180c, AMF182a - 182b, UPF184a - 184b, SMF183a - 183b, DN185a - 185b, and / or any other device described herein can be implemented by one or more emulation devices (not shown). An emulation device can be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulation device can be used to test other devices and / or simulate network and / or WTRU functionality.
[0057] An emulation device can be designed to perform one or more tests of other devices in a laboratory environment and / or an enterprise network environment. For example, one or more emulation devices can perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. One or more emulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation device can be directly coupled to another device for the purpose of testing and / or performing tests using over-the-air wireless communication.
[0058] One or more emulation devices can perform one or more functions, including all, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device can be utilized in a test scenario in a test laboratory and / or in a wired and / or wireless communication network that is not deployed (e.g., for testing) to perform tests of one or more components. One or more emulation devices can be test equipment. Direct RF coupling and / or wireless communication via an RF circuit (which can include one or more antennas) can be used by the emulation device 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 relay can be any device, such as a WTRU, a UE, a base station, a virtualized device existing on another hardware. Further, as described herein, a reference to an "end" WTRU can indicate that the WTRU is at one end of a communication link (e.g., the first or second end in a simple relay scenario) that can be utilized by at least one relay device (e.g., a relay WTRU). The L2 U2U relay (re)selection procedure can include two end WTRUs communicating via a first relay, and these end WTRUs then negotiate the selection of a second relay via the first relay (e.g., during a link modification procedure) before reconnecting via the second relay. An end WTRU can decide to trigger relay reselection, for example, to seek a better relay (e.g., one that provides better signal quality / performance).
[0061] Figure 2 illustrates an example of exemplary 5G ProSe layer 2 (L2) UE-to-UE (U2U) (e.g., WTRU-to-WTRU) repeater reselection.
[0062] As can be seen from the example of Figure 2, in the reselection procedure, there may be several devices involved, such as end WTRU1 251 (e.g., 5G ProSe compliant or otherwise), repeater 1 252, repeater 2 253, and / or end WTRU2 254 (e.g., 5G ProSe compliant or otherwise). Initially at 201, there may be a connection setup between end WTRU1 and end WTRU2 via repeater 1. At 202, the end WTRU can communicate via repeater 1 (e.g., traffic forwarding, etc.). At least one of the end WTRUs (e.g., end WTRU1) can decide to reselect a repeater (e.g., at 203). The end WTRU can then negotiate the selection of another repeater (e.g., repeater 2) via repeater 1. For example, at 204, end WTRU1 can send a link modification request message to the second end WTRU via repeater 1. At 205, end WTRU2 can be instructed, assist, and / or decide on the relay WTRU (e.g., repeater 2) to switch to. At 206, end WTRU2 can send a link modification acceptance message to end WTRU1 via repeater 1. This link modification procedure (e.g., 204 - 206) can be carried out before reconnecting the two end WTRUs via the new repeater (e.g., repeater 2) at 207.
[0063] [[ID=??]] In some cases, there may be one or more security techniques associated with / related to the L2 U2U repeater (re)selection procedure. In such cases, there may be a new security key established as part of the link modification procedure (e.g., Figure 2). The new key can 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. In order to prevent the privacy threat of an eavesdropper linking two subsequent connections using the same KNRP ID between two WTRUs involved in direct communication, a change of the KNRP ID can be carried out during the link release procedure. The change of the KNRP ID can be unconditionally carried out between the two WTRUs as part of the link release procedure before the end WTRU reconnects again.
[0065] A re-key generation procedure can be used for an ongoing connection to ensure that a new session key KNRP-SESS as well as the security keys NR ProSe encryption key (NRPEK) and NR ProSe integrity key (NRPIK) are used. This procedure may also optionally be used to refresh the KNRP.
[0066] The connection between end WTRUs via the original L2 U2U relay may not need to be released prior to the setup of a new set of connections via a new L2 U2U relay. This occurs due to the fact that the release of the initial link with original relay re-selection depends on whether the PC5 unicast link is still required and on the WTRU implementation, as well as due to the make-before-break (MBB) principle underlying the relay re-selection procedure. The MBB principle dictates that the current connection between end WTRUs via the original L2 U2U relay should be maintained to enable a seamless transition of communication via a new connection via a new L2 U2U relay.
[0067] Generally, it can be assumed that the end WTRU maintains an initial connection via a first U2U repeater while establishing a new connection via a second U2U repeater in an MBB manner. This may be required to minimize any potential disruption to ongoing communications during the U2U reselection procedure. Maintaining the initial connection means that mechanisms using link release as described herein may not be applicable in an MBB scenario.
[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, a way to ensure that the appropriate timing for link release of the initial connection before the start of a new connection setup is not specified in a potential break-before-make (BBM) scenario needs to be addressed.
[0069] In both cases (e.g., MBB scenario and BBM scenario), an eavesdropper may be able to track end WTRUs that reuse the same KNRP ID. Therefore, it is necessary to address potential issues such as how to ensure KNRP ID privacy protection during L2 U2U reselection as described herein.
[0070] As described herein, the preparation of a new security key using the connection via the first repeater during the link modification procedure provides the benefit of early security establishment for a faster link setup via the new repeater and the availability of a security key to protect the initial messages (e.g., Direct Connection Request (DCR)).
[0071] However, it may be desirable to improve existing security procedures and / or reduce security-related logic in link correction procedures in order to reduce the impact on existing implementations.
[0072] The establishment of a new key may also depend on a provisioned security policy that needs to be considered for the preparation of a new security key. Therefore, it is necessary to address how to establish a new security key during the repeater reselection procedure (e.g., for a new connection via a second repeater) while considering the potential impact (e.g., minimization) on the provisioned security policy and existing procedures.
[0073] In one or more examples described herein (e.g., for KNRP ID privacy), there may be an L2 U2U reselection procedure where a first end WTRU (end WTRU1) establishes a new KNRP ID with a second end WTRU (end WTRU2) using a link modification procedure or a coordinated link release for an initial connection via a first repeater (repeater 1). End WTRU1 establishes a new connection with end WTRU2 via a second repeater (repeater 2) using the new KNRP ID. This approach enables privacy protection of the KNRP ID (e.g., reduces the risk of linkability between the new and old KNRP IDs by an attacker) while the end WTRU establishes a new connection via repeater 2. Stated another way, this enables the privacy of the new key ID and ensures that it is protected during the link procedure (e.g., as described herein). The approach described herein proposes to utilize and extend a link modification procedure that is essential for L2 U2U reselection to negotiate the maintenance (MBB) or release (BBM) of the initial connection prior to the setup of the new connection. The end WTRU establishes a new KNRP ID as part of the link modification procedure if MBB is selected. The end WTRU coordinates the link release procedure for the initial connection to establish a new KNRP ID prior to the start of the new connection setup if BBM is selected. In this way, one problem that can be avoided is the case where an attacker may attempt to link an old key ID to a new key ID 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 implementing an extended re-key generation procedure. End WTRU1 implements an extended re-key generation procedure with end WTRU2 to establish a new correlation ID and generate a new key used to protect a new connection via a second repeater (repeater 2). This approach enables the preparation of security keys to protect a new connection setup that includes an initial message (e.g., DCR), while improving the key reset procedure.
[0075] Figure 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. Figure 3 presents a series of ordered actions / events, but one or more of these actions / events may be optional and / or one or more of these actions / events may occur / be implemented in an order different from that presented.
[0076] At 301, a connection for unicast communication between end WTRUs may be established via repeater 1. End WTRU2 may send a protected direct security mode (DSM) command to end WTRU2 that includes security parameters (e.g., a portion of the session key identifier, a nonce, a security algorithm / policy). In response, end WTRU1 may send a protected direct security mode (DSM) completion to end WTRU2 that includes security parameters (e.g., another portion of the session key identifier, a security policy, etc.).
[0077] At 302, there may be one or more messages (e.g., data traffic, etc.) sent / received between end WTRUs via repeater 1.
[0078] At 303, end WTRU1 can determine to perform U2U repeater reselection with end WTRU2 based on another condition described herein, such as resource usage conditions, a configuration that restricts simultaneous connections for the same service, and / or other things described herein. End WTRU1 can determine to generate a new KNRP ID with end WTRU2 based on a decision to maintain the current connection via repeater 1. For example, end WTRU1 can determine to maintain the initial connection based on the availability of resources for the new connection. In another example, end WTRU1 can determine to maintain 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 services or RSC). Put another way, with respect to the decision to maintain the connection, end WTRU1 can determine to generate a new key ID on the premise that the current connection is maintained after the decision to perform reselection.
[0079] At 304, the end WTRU1 can send a link modification request (LMR) message to the end WTRU2 that may include an indication for maintaining an initial connection prior to setting up a connection via the repeater 2, the newly assigned MSB of the KNRP ID, and / or other parameters (e.g., a reselection indication, an identifier of a repeater candidate including the repeater 2). The newly assigned MSB of the KNRP ID associated with the end WTRU2 uniquely identifies the KNRP at the end WTRU1. The end WTRU1 can include parameters as to whether / when to release the initial connection after the new connection setup (e.g., release a timer, maintain the connection, release during data communication via the new connection). Stated another way, the newly assigned MSB is for creating a new KNRP ID for the current key. When the LSB is received from the end WTRU2 later in this process, the end WTRU1 can create a new KNRP ID (e.g., of the current key) by combining the MSB and the LSB, as further described herein.
[0080] At 305, the end WTRU2 can select the repeater 2 from the list of repeater candidates. The end WTRU2 can assign the LSB of the KNRP ID associated with the end WTRU1 that uniquely identifies the KNRP within the end WTRU2. Then, the end WTRU2 can combine the MSB of the KNRP ID received from the end WTRU1 and the LSB of the KNRP ID to form a new KNRP ID to be used when reconnecting to the end WTRU1. The end WTRU2 replaces the old KNRP ID with the new KNRP ID. The end WTRU2 can send a Link Modification Acknowledgment (LMA) message containing the LSB of the KNRP ID and / or other parameters (e.g., the identifier of the selected repeater 2) to the end WTRU1. If the LMR does not include a release / maintain indication, the maintenance of the initial connection may be assumed by default or left to the end WTRU to select (see, e.g., the example illustrated in Figure 4). The end WTRU2 can assign the LSB of the KNRP ID based on receiving an initial connection maintenance indication and / or the MSB of the KNRP ID.
[0081] At 306, the end WTRU1 can combine the MSB of the KNRP ID sent at 304 and the LSB of the KNRP ID received from the end WTRU2 to form a new KNRP ID to be used when reconnecting to the end WTRU2. The end WTRU1 can replace the old KNRP ID with the new KNRP ID. The end WTRU1 can send a DCR message containing the new KNRP ID to the end WTRU2 via the repeater 2 (e.g., the direct PC5 link with the repeater 2 can be pre-setup or modified).
[0082] At 307, the end WTRU1 and the end WTRU2 can establish security for the connection between the end WTRUs via the repeater 2. The KNRP ID is used to find the corresponding KNRP that is used to derive the session key and the security key to protect the connection. In other words, the KNRP does not change, but the KNRP ID changes (e.g., thus the need for new MSB and LSB).
[0083] At 308, the end WTRU1 can receive a DCA from the end WTRU2 to complete the connection establishment. The end WTRU (e.g., end WTRU1 or end WTRU2) decides whether to continue maintaining the initial connection via the repeater 1 or to release the initial connection based on the parameters described above (e.g., timer, data packets exchanged via the new connection).
[0084] Figure 4 illustrates an example of 5G ProSe U2U repeater reselection with KNRP ID privacy protection based on the negotiation of initial PC5 connection release or maintenance before the PC5 connection setup via the selected repeater. As shown, there may be several devices involved in the reselection procedure, such as the end WTRU1 451, the repeater 1 452, the repeater 2 453, and / or the end WTRU2 454. Figure 4 presents a series of ordered actions / events, but 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 the end WTRUs is established via the repeater 1.
[0086] At 402, there may be one or more messages (e.g., data traffic, etc.) sent / received between the end WTRUs via the repeater 1.
[0087] At 403, the end WTRU1 determines to perform U2U repeater reselection with the end WTRU2.
[0088] At 404, the end WTRU1 sends a Link Modification Request (LMR) message to the end WTRU2, and the link modification request message can include a release instruction or a maintain (e.g., preference) instruction and / or other parameters (e.g., a reselection instruction, an identifier of a repeater candidate including repeater 2). In some cases, the release instruction is used to request the release of the initial PC5 connection prior to the setup of the connection via the selected repeater. In some cases, the maintain instruction is used to request the maintenance of the initial PC5 connection during the setup of the connection via the selected repeater.
[0089] At 405, the end WTRU2 selects repeater 2 from the list of repeater candidates. The end WTRU2 determines to maintain the initial connection (e.g., based on the end WTRU1 maintenance preference, the ProSe / RSC service configuration, and / or the end WTRU2 resource usage), and assigns a new LSB of the KNRP ID associated with the end WTRU1. The end WTRU2 sends a Link Modification Acceptance (LMA) message including a maintain instruction, the LSB of the KNRP ID, and other parameters (e.g., an identifier of the selected repeater 2) to the end WTRU1. The end WTRU2 can include parameters on how to handle the maintained initial connection (e.g., timer-based release, etc.) when the new connection is set up, as described herein.
[0090] At 406, the end WTRU1 accepts to maintain the initial PC5 connection. The end WTRU1 assigns a new MSB of the KNRP ID, combines the new MSB and the new LSB of the KNRP ID to form a new KNRP ID to be used when reconnecting with the end WTRU2. The end WTRU1 replaces the old KNRP ID with the new KNRP ID. The end WTRU1 sends a link correction Ack message including the MSB of the KNRP ID to the end WTRU2. The end WTRU2 combines the new MSB and the new LSB of the KNRP ID to form a new KNRP ID (e.g., the same as that formed by the end WTRU1), which is used when reconnecting with the end WTRU1. The end WTRU2 replaces the old KNRP ID with the new KNRP ID.
[0091] At 407, the end WTRU1 sends a DCR message including the new KNRP ID to the end WTRU2 via the repeater 2.
[0092] At 408, the end WTRU1 and the end WTRU2 establish security for the connection between the end WTRUs via the repeater 2. The new KNRP ID is used to find the corresponding KRNP used to derive the session key and the security key to protect the connection.
[0093] At 409, the end WTRU1 receives a DCA from the end WTRU2 to complete the connection establishment. The initial connection is maintained or released based on one or more of the parameters described herein (e.g., 405 or elsewhere).
[0094] Figure 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. Figure 5 presents a series of ordered actions / events, but 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.
[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 (e.g., data traffic, etc.) sent / received between end WTRUs via repeater 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 a new connection setup). For example, end WTRU1 can decide to release the resources exhausted by the initial connection. In another example, WTRU1 can 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 services or RSCs).
[0098] At 504, the end WTRU1 sends a Link Modification Request (LMR) message to the end WTRU2 that includes an indication requesting a coordinated release of the initial connection via the repeater 1 and / or other parameters (e.g., reselection indication, identifier of the repeater candidates including repeater 2). Based on the release indication, the end WTRU2 stops transmitting data packets and other link maintenance messages (e.g., keep-alive, link identifier update) using the initial connection and starts a timer for the expected reception of the link release request from the end WTRU1.
[0099] At 505, the end WTRU2 sends a Link Modification Acknowledgment (LMA) message to the end WTRU1 that includes an acceptance of the coordinated release of the initial connection via the repeater 1 and other parameters (e.g., identifier of the selected repeater 2). The end WTRU1 stops transmitting data packets and / or other link maintenance messages (e.g., keep-alive, link identifier update) as necessary. If it is expected that the end WTRU2 will initiate the link release, the end WTRU1 starts a timer for the expected reception of the link release request from the end WTRU2.
[0100] At 506, the end WTRU1 sends a link release request message to the end WTRU2 that includes the new MSB of the KNRP ID. Alternatively, after the LMA, the end WTRU2 can send the link release request message on behalf of the end WTRU1.
[0101] At 507, the end WTRU2 sends a link release response message to the end WTRU1 that includes the LSB of the KNRP ID. The end WTRU2 establishes a new KNRP ID by combining the received MSB with the LSB of the KNRP ID.
[0102] Figure 6 illustrates an example of 5G ProSe U2U repeater reselection with KNRP ID privacy protection 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. Figure 6 presents a series of ordered actions / events, but one or more of these actions / events may be optional and / or one or more of these actions / events are intended to occur / be performed in an order different from that 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 (e.g., data traffic, etc.) sent / received between end WTRUs via repeater 1.
[0105] At 603, end WTRU1 determines to perform U2U repeater reselection with end WTRU2.
[0106] At 604, end WTRU1 sends a Link Modification Request (LMR) message to end WTRU2, and the link modification request message can include a release instruction or a maintain (e.g., preference) instruction and / or other parameters (e.g., a reselection instruction, an identifier of a repeater candidate including repeater 2). In some cases, the release instruction is used to request the release of an initial PC5 connection prior to the setup of a connection via the selected repeater. In some cases, the maintain instruction is used to request the maintenance of an initial PC5 connection during / after the setup of a connection via the selected repeater.
[0107] At 605, the end WTRU2 selects Repeater 2 from the list of repeater candidates. After the setup of the connection via the selected repeater is completed, the end WTRU2 decides to maintain the first PC5 connection. The end WTRU2 associates the status with the KNRP ID associated with the end WTRU1 / end WTRU2 pair and sets it to "hold refresh". In some cases, the "hold refresh" status means that the KNRP ID cannot be reused during the establishment of a new PC5 link (e.g., on a DCR message), and a new KNRP ID needs to be generated.
[0108] At 606, the end WTRU2 sends a Link Modification Acceptance (LMA) message to the end WTRU1, which can include a maintenance instruction and / or other parameters (e.g., the identifier of the selected Repeater 2). In some cases, the choice of maintenance is prioritized over release (e.g., break before make). For example, if one of the end WTRUs prefers to maintain the PC5 connection while the other prefers to release it, the PC5 connection is maintained. In some cases, maintenance is assumed by default (e.g., when no instruction is specified in the LMR).
[0109] At 607, based on the received maintenance instruction, the end WTRU1 sets the KNRP ID status to "hold refresh". Since the KNRP ID status is set to "hold refresh", the end WTRU1 decides to set up a new PC5 connection via Repeater 2 without using the existing KNRP ID.
[0110] At 608, the end WTRU1 sends a DCR message to the end WTRU2 via Repeater 2, excluding the KNRP ID associated with the end WTRU1 / end WTRU2 pair even if a KNRP / KNRP ID exists. Generally, the DCR message can 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 status is set to “valid,” which means that the KNRP / KNRP ID can be used for session key derivation and the KNRP ID can be used for other PC5 connection establishments. Note that the example of FIG. 6 (as illustrated by this step) pertains to a scenario that requires a complete 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 that is used to derive the session key and security key to protect the connection.
[0113] At 611, End WTRU1 receives from End WTRU2 the DCA to complete the connection establishment.
[0114] FIG. 7 illustrates an example of 5G ProSe U-to-U repeater reselection security using 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 WTRU one 751, Repeater one 752, Repeater two 753, and / or End WTRU two 754. Although FIG. 7 presents a sequential series of actions / events, 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, as is intended.
[0115] At 701, a connection for unicast communication between the End WTRUs is established via Repeater 1.
[0116] At 702, there may be one or more messages (e.g., data traffic, etc.) sent / received between end WTRUs via repeater 1.
[0117] At 703, end WTRU1 determines to perform U2U repeater reselection with end WTRU2. End WTRU1 determines to perform pre - key generation for a new connection via 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 that includes the MSB of the correlation ID, a new connection pre - key generation indication, and / or other parameters (e.g., a reselection indication, an identifier of a repeater candidate including repeater 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 a new connection context associated with repeater 2, together with end WTRU1 information (e.g., user information ID, KNRP / KNRP ID) and / or repeater 2 information (e.g., repeater user information ID, L2 ID). End WTRU2 can send a link modification acceptance (LMA) message to end WTRU1 that includes an ack of the new connection pre - key generation, the correlation ID, and / or other parameters (e.g., an identifier of the selected repeater 2).
[0120] At 706 (e.g., 706a and 706b), the 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 the repeater 2, together with the end WTRU2 information and / or the repeater 2 information. The end WTRU1 sends a pre-key generation request message or a re-key generation request message including an instruction for generating a new key for a new connection to the end WTRU2 via the first repeater. The end WTRU1 includes the correlation ID and / or other re-key generation security parameters (e.g., security capabilities, nonces, MSB of the new KNRP-SESS ID) in the message.
[0121] At 707 (e.g., 707a and 707b), the end WTRU2 generates a new session (KNRP-SESS) and security keys (NRPEK and NRPIK) and stores the keys in the new connection context. The end WTRU2 sends a DSM command message including the correlation ID and the conventional re-key generation security parameters to the end WTRU1 via the repeater 1. The message is protected using the security context already established for the current connection (e.g., an instruction for activating new security using the new keys is not sent to the lower layer).
[0122] At 708, the end WTRU1 receives a DSM command message including the correlation ID and the conventional re-key generation security parameters from the end WTRU2. The end WTRU1 generates a new security key and stores it in the new connection context. The end WTRU1 sends a DSM completion message to the end WTRU2 via the first repeater.
[0123] At 709, the end WTRU2 sends a re-key generation response message to the end WTRU1 to confirm that the end WTRU2 is ready to use the new key in the connection via the second repeater.
[0124] At 710, the end WTRU1 sends, via the repeater 2, an integrity protected DCR message including a correlation ID to the end WTRU2. The message is protected using a new key associated from the new connection context. The authentication and security establishment procedures may be skipped via the new connection. The end WTRU2 finds a new connection security key based on the correlation ID. The end WTRU2 activates a security context for the new connection using the stored security key of the new connection. The end WTRU2 sends a fully protected DCA to the end WTRU1 using the security context. The end WTRU1 activates a security context for the new connection using the stored security key of the new connection placed together with the correlation ID.
[0125] In one example, there may be a (root) key NR ProSe (KNRP) privacy protection that uses link modification request / acceptance / Ack (LMR / LMA / LMAck) during the L2 U2U repeater reselection procedure. This procedure can establish a new KNRP ID during the link modification procedure, and the peer WTRU accepts the initial connection maintenance preference. The end WTRU1 establishes a new KNRP ID with the end WTRU2 during the U2U repeater reselection procedure via the first repeater and uses the new KNRP ID during the connection setup via the second repeater.
[0126] In this example, first, the end WTRU1 can decide to establish a new KNRP ID for the new connection during reselection based on the decision to maintain the current connection via the first repeater (e.g., based on ProSe service / RSC configuration, current resource usage).
[0127] End WTRU1 can send an LMR message containing an instruction for maintaining an initial connection before setting up a connection via a second repeater and the newly assigned MSB of the KNRP ID to End WTRU2 in order to notify End WTRU2 to update the current KNRP ID shared with End WTRU1.
[0128] End WTRU1 can receive an LMA message from End WTRU2 containing the new LSB of the KNRP ID.
[0129] End WTRU1 can combine the new MSB of the KNRP ID and 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 can send a DCR message containing the new KNRP ID to End WTRU2 via the second repeater.
[0132] End WTRU1 can receive a DCA message from End WTRU2 via the second repeater.
[0133] End WTRU1 can decide to initiate or maintain the release of the initial connection.
[0134] In one example, there may be a method for establishing a new KNRP ID during a link correction procedure, where the peer WTRU connection release is not accepted by the peer WTRU.
[0135] In this example, first, based on a decision to maintain the current connection via the first repeater (e.g., based on ProSe service / RSC configuration, current resource usage), End WTRU1 decides to establish a new KNRP ID for a new connection during reselection.
[0136] End WTRU1 can send an LMR message containing an indication for release of initial connection preference to End WTRU2 via a first repeater, before setting up a set of connections via a second repeater.
[0137] End WTRU1 can receive an LMA message from End WTRU2 containing the new LSB of the KNRP ID.
[0138] End WTRU1 can send an LMAck containing the new MSB of the KNRP ID to End WTRU2 via the first repeater.
[0139] End WTRU1 combines the new MSB of the KNRP ID and the new LSB of the KNRP ID.
[0140] End WTRU1 uses the new KNRP ID during setup of a new connection via the second repeater.
[0141] In one example (as further described herein), there may be a technique for KNRP ID privacy protection that uses coordination of initial connection release during an L2 U2U repeater reselection procedure. The new KNRP ID can be established by coordinating link release of the initial connection via the first repeater using a link modification procedure.
[0142] First, in this example, End WTRU1 can coordinate with End WTRU2 to release the current connection via the first repeater in order to establish a new KNRP ID before using it in the setup of a new connection via the second repeater.
[0143] End WTRU1 can determine to coordinate release of the current connection (e.g., based on ProSe service / RSC configuration, current resource usage) and establish a new KNRP ID for the new connection.
[0144] End WTRU1 can send an LMR message containing an instruction for the release of the initial connection to End WTRU2 via a first relay before setting up a new set of connections via a second relay.
[0145] End WTRU1 can receive an LMA message from End WTRU2 containing an affirmative response to the release of the initial link. It should be noted that LMR / LMA negotiates the release but does not actually trigger it.
[0146] End WTRU1 can send a link release request containing the newly assigned MSB of the KNRP ID to End WTRU2 via the first relay. It should be noted that the link release request actually triggers the release of the connection.
[0147] End WTRU1 can receive a link release response from End WTRU2 containing the new LSB of KNRP ID 1.
[0148] End WTRU1 can combine the new MSB of the KNRP ID and the new LSB of the KNRP ID and store the new KNRP ID by replacing the current KNRP ID.
[0149] End WTRU1 sends a DCR message containing the new KNRP ID to End WTRU2 via the second relay (when receiving a link release response message from End WTRU2).
[0150] In one example (as further described herein), there may be a technique for pre - key generation of a new connection procedure during the L2 U2U relay reselection procedure. A new security key can be generated during the relay reselection procedure via the initial connection via the first relay. The new key can be used for the security of the new connection via the second relay.
[0151] In this example, first, the end WTRU1 can negotiate the implementation of pre-key generation of the security key used to secure the connection via the second repeater during the U2U repeater reselection procedure via the first repeater.
[0152] Based on the security policy / configuration for the initial connection via the first repeater (e.g., a non-NULL integrity algorithm is in use), the end WTRU1 can determine to perform re-key generation extended as part of the U2U repeater reselection procedure.
[0153] The end WTRU1 can send an LMR message to the end WTRU2 via the first repeater, including an instruction to perform re-key generation extended to generate a new session key prior to setting up a new connection via the second repeater, the MSB of the newly assigned correlation ID, and a list of repeater identifiers.
[0154] The end WTRU1 can receive an LMA message from the end WTRU2, including an affirmative response to perform re-key generation extended, the identifier of the selected second repeater, and the LSB of the new correlation ID. The end WTRU1 combines the MSB and LSB of the correlation ID to form a correlation ID used to associate the initial connection with the (to-be-established) new connection.
[0155] The end WTRU1 can send a re-key generation request message to the end WTRU2 via the first repeater, including an instruction to generate a new key for the new connection, an identifier associated with the second repeater (e.g., any of user information ID, L2 ID, correlation ID), and other re-key generation security parameters (e.g., security capabilities, nonces, MSB of the new KNRP-SESS ID).
[0156] The end WTRU1 can receive a DSM command message from the end WTRU2, including the correlation ID and conventional re-key security parameters.
[0157] The end WTRU1 can generate a new session key with identifiers (KNRP-SESS and ID) for use with the new connection and new security keys (NRPEK and NRPIK).
[0158] The end WTRU1 can store, along with the existing KNRP ID, a new key for the new connection and an identifier associated with the second repeater.
[0159] The end WTRU1 can send a DSM completion message to the end WTRU2 via the first repeater.
[0160] The end WTRU1 can receive a re-key generation response message from the end WTRU2 to confirm that the end WTRU2 is ready to use the new key in the connection via the second repeater. The end WTRU1 (and the end WTRU2 save the security context for the initial connection via repeater 1).
[0161] The end WTRU1 can send a correlation ID within an integrity-protected DCR message for the end WTRU2 to find the new security keys and use those keys to establish new connection security.
[0162] Figure 8 illustrates an example of a reselection process. The second WTRU may receive a Link Modification Request (LMR) message from the first WTRU using the first relay, and the LMR message may include a new most significant byte (MSB) for a new key NR ProSe identifier (KNRP ID) of the current key. The second WTRU may send a Link Modification Acceptance (LMA) message to the first WTRU using the first relay, and the LMA message may include a new least significant byte (LSB) for the new KNRP ID of the current key. The second WTRU may form a new KNRP ID by combining the new MSB with the new LSB. The second WTRU may receive a Direct Connection Request (DCR) message from the first WTRU directly using the second relay, and the DCR message may include the new KNRP ID (e.g., formed by the first WTRU and matching the new KNRP ID formed by the second WTRU because both are creating the new KNRP ID using the same new LSB and new MSB). In one case, the second WTRU may receive a message from the first WTRU using the first relay via a first connection before receiving the LMR message, and the first connection is established based on an initial KNRP ID of the current key, and the initial KNRP ID is different from the new KNRP ID. In one case, the current key is the same in the first WTRU and the second WTRU. In one case, the initial KNRP ID of the current key is discarded when the new KNRP ID of the current key is generated. In one case, the second WTRU may assign the LSB based on an initial connection maintenance instruction by the LMR message.
[0163] In one example, a WTRU (e.g., communicating with another WTRU over one or more relays) can execute a method for a (re)selection process (e.g., regarding a relay). The WTRU can send a request message that can include an indication for including a new most significant byte (MSB) for the current key NR ProSE (KNRP). The WTRU can receive an acceptance message that includes a new least significant byte (LSB) of the current KNRP. The WTRU can 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 can receive a direct connection acceptance message. The request message may be a link modification request (LMR) message, and the acceptance message may be a link modification acceptance (LMA) message. The request message may include an indication for maintaining the current connection via a first relay. After the direct connection request message is received, the current connection can be released.
[0164] 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.
[0165] As described herein, the upper layer may refer to one or more layers in the protocol stack, or a particular sublayer within the protocol stack. This protocol stack may be composed of one or more layers within a WTRU or network node (e.g., eNB, gNB, other functional entities, etc.), where each layer may have one or more sublayers. Each layer / sublayer may perform one or more functions. Each layer / sublayer can 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. That is, they may be the 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. That is, they may be packet data convergence control (PDCP), radio link control (RLC), and / or media access control (MAC). For example, layer 3 may be composed of operations of the physical (PHY) layer type. The higher the layer number, the relatively higher the layer is with respect to other layers (e.g., layer 3 is higher than layer 1). In some cases, the foregoing examples may be referred to as the layer / sublayer itself regardless of the number of layers, and may be referred to as the upper layer as described herein. For example, the upper layer may refer to one or more of the following layers / sublayers from the topmost to the bottommost, i.e., the NAS layer, RRC layer, PDCP layer, RLC layer, MAC layer, and / or PHY layer. Any reference in this specification to the upper layer in relation to 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 to the upper layer in this specification may refer to a function or operation performed by one or more of the layers described in this specification.In some cases, references to upper layers in this specification may refer to information sent or received by one or more of the layers described in this specification. In some cases, references to upper layers in this specification may refer to configurations sent and / or received by one or more of the layers described in this specification.
[0166] Features and elements are described above in the context of specific combinations (e.g., embodiments, methods, examples, etc.), but one of ordinary skill in the art will understand that each feature or element can be used alone or in any combination with other features and elements. For example, as disclosed herein, there may be methods described in connection with figures for illustrative purposes, and one of ordinary skill in the art will understand that one or more features or elements from such methods can be used alone or in combination with one or more features from other methods described elsewhere. The symbol " / " (e.g., forward slash) may be used herein to represent "and / or"; for example, "A / B" may imply "A and / or B". As used herein, the terms "a" and "an" and similar phrases should be construed to mean "one or more" and "at least one". Similarly, any term ending with the suffix "(s)" should be construed to mean "one or more" and "at least one". The term "may" is construed to mean "may, for example" or to indicate that something "occurs" or "can occur". Additionally, the methods described herein can 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 (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, magnetic media such as read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, internal hard disks, and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor associated with software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.
Claims
1. A method performed by a second wireless transmit / receive unit (WTRU), comprising: Receiving, using a first repeater, a link modification request (LMR) message from a first WTRU, the LMR message including a new most significant byte (MSB) used for a new key NR ProSe identifier (KNRP ID) of a current key; Sending, using the first repeater, a link modification acceptance (LMA) message to the first WTRU, the LMA message including a new least significant byte (LSB) used for the new KNRP ID of the current key; Forming the new KNRP ID by combining the new MSB with the new LSB; Receiving, using a second repeater, a direct connection request (DCR) message from the first WTRU, the DCR message including the new KNRP ID.
2. The method of claim 1, further comprising receiving a message from the first WTRU using the first repeater via a first connection prior to receiving the LMR message, 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 in 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 generated.
5. The method of claim 1, further comprising allocating the LSB based on an initial connection maintenance indication by the LMR message.
6. A second wireless transmit / receive unit (WTRU), comprising: Means for receiving, using a first repeater, a link modification request (LMR) message from a first WTRU, the LMR message including a new most significant byte (MSB) used for a new key NR ProSe identifier (KNRP ID) of a current key; means for sending, using the first repeater, a link modification acceptance (LMA) message to the first WTRU, the LMA message including a new least significant byte (LSB) for the new KNRP ID of the current key; means for forming the new KNRP ID by combining the new MSB with the new LSB; a second wireless transmit / receive unit (WTRU) comprising means for receiving, using a second repeater, a direct connection request (DCR) message from the first WTRU, the DCR message including the new KNRP ID; [
7. ] The WTRU according to claim 6, further comprising means for receiving a message from the first WTRU using the first repeater via a first connection before receiving the LMR message, 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. [
8. ] The WTRU according to claim 6, wherein the current key is the same in the first WTRU and the second WTRU. [
9. ] The WTRU according to claim 6, wherein the initial KNRP ID of the current key is discarded when the new KNRP ID of the current key is generated. [
10. ] The WTRU according to claim 6, further comprising means for allocating the LSB based on an initial connection maintenance instruction by the LMR message.