Methods and apparatus for inter-WTRU relay discovery security and privacy

Abstract

This document discloses a method for security in inter-UE (U2U) relay discovery. [Solution] The method may include provisioning security material for direct discovery sets and U2U discovery messages to the end UE, and provisioning security material for U2U discovery messages to the U2U relay. The security material for direct discovery sets may include at least one of the following: ProSe restriction codes, associated key material, or indicators related to the relay service code (RSC) indicating whether the RSC supports protection for each ProSe direct discovery set. The method may include the end UE sending a Direct Connection Request (DCR) message to the U2U relay. The DCR message may include the RSC and at least one of the following: end UE user information identifier (ID), or ProSe restriction code.

Description

Technical Field

[0001] (Cross - Reference to Related Applications) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 489,273, filed Mar. 9, 2023, the content of which is incorporated herein by reference.

Background Art

[0002] Proximity - based services (ProSe) can be provided to UEs that are in proximity to each other. A UE can support a ProSe direct discovery procedure that can be used to discover other nearby UEs. A UE can also support direct communication with another UE, e.g., directly sending data to another UE without traversing an infrastructure network.

[0003] The discovery procedure can also be considered open or restricted. In the case of open discovery, no explicit permission from the discovered UE is required. In the case of restricted discovery, an explicit permission allowing the discovery - side UE to discover the discovered - side UE may need to be given to the discovery - side UE. This permission can be associated with, for example, a ProSe restriction code. The ProSe restriction code can be provisioned or configured in a UE that is permitted to use or provide or discover other UEs using the same ProSe restriction code.

Summary of the Invention

[0004] Proximity - based services (ProSe) services can be provided to UEs that are in proximity to each other. A UE can support a ProSe direct discovery procedure that can be used to discover other nearby UEs. A UE can also support direct communication with another UE. UE - to - UE relay can be capable of relaying traffic to and from end UEs. UE - to - UE relay broadcasts a discovery message including a relay service code (RSC) associated therewith to facilitate a relay discovery process for end UEs. Discovery messages may include a Direct Discovery Set (DDS). A DDS may include information relating to one or more end UEs in the vicinity of an inter-UE relay. This may include a user information identifier (user information ID) and a ProSe restriction code. Each RSC may have one or more associated ProSe restriction codes. End UE IP address / prefix information is associated with a unique pair of ProSe restriction code and user information ID.

[0005] Potential security requirements for UE-to-UE relay may include protecting UE discovery messages and private sensitive information during the UE-to-UE relay discovery procedure. Security keys may be used to protect messages during transmission. Both the relay and end UEs may provision security material associated with the RSC to properly exchange and handle the security of relay messages. Only authorized end UEs may provision security material associated with a given ProSe restriction code. If a second end UE is permitted to perform restricted discovery using the same ProSe restriction code associated with the first end UE, the UE-to-UE relay may only share the IP address / prefix information of the first end UE with the second end UE.

[0006] The end UE sends the protected DDS to the inter-UE relay, which includes the protected DDS in its discovery message. In one example, the end UE can run a timer to trigger the transmission of an updated protected DDS to the inter-UE relay when the timer expires. In another example, the inter-UE relay can provide information about the next notification opportunity, and the end UE can send an updated protected DDS to the inter-UE relay during the next notification opportunity. [Brief explanation of the drawing]

[0007] A more detailed understanding can be obtained from the following explanation, which is given as an example in conjunction with the attached drawings, where similar reference numbers in the drawings indicate similar elements. [Figure 1A] This is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] This is a system diagram illustrating an exemplary wireless transmit / receive unit (WTRU) that may be used in a communication system illustrated in Figure 1A, according to one embodiment. [Figure 1C] This is a system diagram illustrating an exemplary radio access network (RAN) and an exemplary core network (CN) that may be used in a communication system illustrated in Figure 1A according to one embodiment. [Figure 1D] This is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used in the communication system illustrated in Figure 1A according to one embodiment. [Figure 2] This example shows end-UE connectivity using inter-UE relay connectivity via the PC5 interface. [Figure 3] This shows the procedure for discovering relays between UEs in Model A. [Figure 4] This example shows a relay message where a single key set associated with RSC is used to protect the message. [Figure 5] This shows an example of a relay message where multiple key sets associated with RSC are used to protect the message. [Figure 6] This document provides an exemplary call flow for establishing a direct U2U relay link with support for Model A U2U relay discovery using multiple key sets and IP shared privacy. [Figure 7] This document provides an exemplary call flow for a U2U relay direct link modification procedure to enable support for Model A U2U relay discovery using multiple key sets and IP shared privacy. [Figure 8] This shows an example call flow for a U2U relay DNS query with IP sharing privacy. [Figure 9] U2U relay initiation model A using multiple key sets: This shows an exemplary call flow for the U2U relay discovery procedure. [Figure 10] This shows an exemplary call flow for an end-UE initiated model A U2U relay discovery procedure using multiple key sets. [Figure 11] Model A of U2U relay initiation with delayed notification of discovered end UE shows an exemplary call flow for the U2U relay discovery procedure. [Modes for carrying out the invention]

[0008] Figure 1A illustrates an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, message transmission, and broadcast to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through the 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 OFDM, and filter bank multicarrier (FBMC).

[0009] As shown in Figure 1A, the communication system 100 may include radio 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, but it will be understood that the disclosed embodiments intend any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a radio environment. For example, WTRU102a, 102b, 102c, and 102d, any of which may be referred to as stations (STAs), may be configured to transmit and / or receive radio signals and may include user equipment (UEs), mobile stations, fixed-line or mobile phone subscriber units, subscriber-based units, pagers, mobile phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain context), home electronic devices, and devices operating in commercial and / or industrial wireless networks. Any of WTRU102a, 102b, 102c, and 102d may interchangeably be referred to as UEs.

[0010] The communication system 100 may also include base stations 114a and / or base stations 114b. Each of the base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks such as CN 106, the Internet 110, and / or other networks 112. As an example, base stations 114a and 114b may be base transceiver stations (BTS), node B, e-node B (eNB), home node B, home e-node B, next-generation node B (g-node B (gNB), etc.), new radio (NR) node B, site controller, access point (AP), wireless router, etc. Although base stations 114a and 114b are each illustrated as single elements, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0011] Base station 114a may be part of RAN 104, which may also include other base stations such as a base station controller (BSC), a radio network controller (RNC), relay nodes, and / or network elements (not shown). 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 cells (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. Cells may provide coverage of radio services to a particular geographic area which may be relatively fixed or change over time. Cells may be further divided into cell sectors. For example, a 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.

[0012] Base stations 114a and 114b may communicate with one or more WTRUs 102a, 102b, 102c, and 102d via an air interface 116, which may be any suitable radio 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).

[0013] More specifically, as described above, the communication system 100 may be a multiple access system, but may use one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA. For example, base stations 114a and WTRU 102a, 102b, and 102c of RAN 104 may implement radio technologies such as Universal Mobile Communications System (UMTS) Terrestrial Radio Access (UTRA), which can establish an air interface 116 using broadband CDMA (WCDMA). WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Advanced HSPA (HSPA+). HSPA may include High Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High Speed ​​Uplink (UL) Packet Access (HHSUPA).

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

[0015] In one embodiment, base stations 114a and WTRUs 102a, 102b, and 102c may implement radio technologies such as NR radio access, which may establish an air interface 116 using NR.

[0016] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Thus, 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).

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

[0018] 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 use by a drone, for example), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement 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 implement 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 (such as 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.

[0019] RAN104 may communicate with CN106, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU102a, 102b, 102c, and 102d. The data may have various Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements. CN106 may provide call control, billing services, mobile location-based services, prepaid calls, internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication. Although not shown in Figure 1A, it will be understood that RAN104 and / or CN106 may communicate directly or indirectly with other RANs using the same RAT or different RAT as RAN104. For example, in addition to being connected to RAN104 which may utilize NR radio technology, CN106 may also communicate with another RAN (not shown) by employing GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0020] CN106 may also function as a gateway to WTRU102a, 102b, 102c, and 102d for access to PSTN108, the Internet 110, and / or other networks 112. PSTN108 may include a circuit-switched telephone network providing conventional telephone services (POTS). The Internet 110 may include a global system of interconnected computer networks and devices, where 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. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs that may use the same RAT as RAN104 or a different RAT.

[0021] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multimode functionality (for example, WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different radio networks via different radio links). For example, WTRU 102c shown in Figure 1A may be configured to communicate with base station 114a, which may employ cellular-based radio technology, and base station 114b, which may employ IEEE 802 radio technology.

[0022] Figure 1B is a system diagram illustrating an exemplary WTRU 102. As shown in Figure 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 supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any partial combination of the aforementioned elements while maintaining consistency with one embodiment.

[0023] The processor 118 may be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), 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 functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120 which may be coupled to a transmit / receive element 122. Figure 1B illustrates the processor 118 and the transceiver 120 as separate components, but it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0024] The transmit / receive element 122 may be configured to transmit or receive signals to and 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 radio signals.

[0025] Although the transmit / receive element 122 is depicted as a single element in Figure 1B, 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 sending and receiving radio signals via the air interface 116.

[0026] The transceiver 120 may be configured to modulate the signal transmitted by the transmit / receive element 122 and demodulate the signal received by the transmit / receive element 122. As described above, the WTRU 102 may have multimode capabilities. Therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0027] The processor 118 of the WTRU102 may be coupled to 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) and may receive user input from these. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from any type of suitable memory, such as non-removable memory 130 and / or removable memory 132, and store data in such memory. 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. Removable memory 132 may include a subscriber identification module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from memory not physically located on the WTRU 102, such as on a server or home computer (not shown), and store data in that memory.

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

[0029] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or instead of, the information from the GPS chipset 136, the WTRU 102 may determine its location based on receiving location information from base stations (e.g., base stations 114a, 114b) via the air interface 116 and / or based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may acquire location information by any preferred location determination method while maintaining consistency with one embodiment.

[0030] The processor 118 may be further coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, 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 modulation (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, and the like. Peripherals 138 may include one or more sensors. The sensors may include one or more of the following: 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 barometer, a gesture sensor, a biometric sensor, a humidity sensor, and the like.

[0031] WTRU102 may include a full-duplex radio in which the transmission and reception of some or all of the signals (e.g., associated with specific subframes of 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 through signal processing either through hardware (e.g., chokes) or through a processor (e.g., via a separate processor (not shown) or processor 118). In one embodiment, WTRU102 may include a half-duplex radio for the transmission and reception of some or all of the signals (e.g., associated with specific subframes of either UL (e.g., for transmission) or DL ​​(e.g., for reception)).

[0032] Figure 1C is a system diagram illustrating RAN104 and CN106 according to one embodiment. As described above, RAN104 may employ E-UTRA radio technology to communicate with WTRU102a, 102b, and 102c via the air interface 116. RAN104 may also communicate with CN106.

[0033] RAN104 may include e-nodes B160a, 160b, and 160c, but it will be understood that RAN104 may include any number of e-nodes B while maintaining consistency with one embodiment. Each of e-nodes B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, e-nodes B160a, 160b, and 160c may implement MIMO technology. Thus, e-node B160a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU102a.

[0034] Each of the e-nodes B160a, 160b, and 160c may be associated with a specific cell (not shown) and may be configured to handle wireless resource management decisions, handover decisions, user scheduling in UL and / or DL, etc. As shown in Figure 1C, the e-nodes B160a, 160b, and 160c may communicate with each other via the X2 interface.

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

[0036] The MME162 can be connected to each of the e-nodes B162a, 162b, and 162c in RAN104 via the S1 interface and can function as a control node. For example, the MME162 may perform roles such as authenticating users of WTRU102a, 102b, and 102c, activating / deactivating bearers, and selecting a specific serving gateway during the initial attachment of WTRU102a, 102b, and 102c. The MME162 may provide control plane functionality for switching between RAN104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0037] The SGW164 can be connected to each of the e-nodes B160a, 160b, and 160c in RAN104 via the S1 interface. The SGW164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The SGW164 can perform other functions, such as anchoring the user plane during e-node B handovers, triggering paging when DL data is available to WTRU102a, 102b, and 102c, and managing and remembering the context of WTRU102a, 102b, and 102c.

[0038] SGW164 may be connected to PGW166, which may provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices.

[0039] CN106 can facilitate communication with other networks. For example, CN106 can provide WTRU102a, 102b, and 102c with access to a circuit-switched network such as PSTN108 to facilitate communication between WTRU102a, 102b, and 102c and conventional terrestrial line communication devices. For example, CN106 may include or communicate with an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that acts as an interface between CN106 and PSTN108. In addition, CN106 can provide WTRU102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0040] Although the WTRU is shown as a wireless terminal in Figures 1A to 1D, in certain representative embodiments, such a terminal is intended to be able to use a wired communication interface with a communication network (for example, temporarily or permanently).

[0041] In a typical embodiment, the other network 112 may be a WLAN.

[0042] A WLAN in Infrastructure Basic Service Set (BSS) mode may have BSS access points (APs) and one or more stations (STAs) associated with the APs. An AP may have access to or interfaces 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 to an STA may reach and be delivered to the STA via the AP. Traffic originating from an STA to a destination outside the BSS may be sent to the AP to be delivered to its respective destination. Traffic between STAs within the BSS may be transmitted, for example, through the AP; a source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be transmitted between a source STA and a destination STA (for example, directly between them) using a Direct Link Setup (DLS). In certain representative embodiments, the DLS may be an 802.11e DLS or an 802.11z Tunneled DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have access points (APs), and STAs within or using IBSS (e.g., all STAs) can communicate directly with one another. The IBSS mode of communication may be referred to herein as the “ad hoc” communication mode.

[0043] When using the 802.11ac infrastructure operating mode or a similar operating mode, an AP may transmit beacons on a fixed channel, such as the primary channel. The primary channel may be of 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 may be used by an STA to establish a connection with the AP. In certain typical embodiments, carrier-sensing multiple access (CSMA / CA) with collision avoidance may be implemented, for example, in an 802.11 system. In the case of CSMA / CA, an STA, 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, that STA may be backed off. A single STA (e.g., only one station) may transmit at any given time in a given BSS.

[0044] A high-throughput (HT) STA may use a 40 MHz wide channel 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.

[0045] Very high throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining multiple consecutive 20 MHz channels. 160 MHz channels can be formed by combining eight consecutive 20 MHz channels, or by combining two non-consecutive 80 MHz channels, which may be referred to as an 80+80 configuration. In the 80+80 configuration, after channel coding, the data can pass through a segment parser that can split the data into two streams. Inverse fast Fourier transform (IFFT) processing and time-domain processing can be performed separately for each stream. The streams may be mapped to two 80 MHz channels, and the data can be transmitted by a transmitting STA. At the receiver of a receiving STA, the operation described above for the 80+80 configuration may be reversed, and the combined data may be transmitted to a media access control (MAC).

[0046] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports bandwidths of 5 MHz, 10 MHz, and 20 MHz in the TV white space (TVWS) spectrum, while 802.11ah supports bandwidths of 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz using the non-TVWS spectrum. According to a typical embodiment, 802.11ah may support meter-type control / machine-type communications (MTC), such as MTC devices in a macro coverage area. MTC devices may have limited capabilities, including support for certain capabilities, e.g., support for certain and / or limited bandwidths (e.g., support for these only). MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

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

[0048] 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.

[0049] Figure 1D is a system diagram showing RAN104 and CN106 according to one embodiment. As described above, RAN104 can communicate with WTRU102a, 102b, and 102c via the air interface 116 using NR radio technology. RAN104 can also communicate with CN106.

[0050] RAN104 may include gNB180a, 180b, and 180c, but it will be understood that RAN104 may include any number of gNBs while maintaining consistency with one embodiment. Each of gNB180a, 180b, and 180c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, gNB180a, 180b, and 180c may implement MIMO technology. For example, gNB180a and 108b may use beamforming to transmit signals to and / or receive signals from gNB180a, 180b, and 180c. Thus, gNB180a may, for example, use multiple antennas to transmit and / or receive radio signals to and from WTRU102a. In one embodiment, gNB180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB180a may transmit multiple component carriers to WTRU102a (not shown). A subset of these component carriers may be on the unauthorized spectrum, while the remaining component carriers may be on the authorized spectrum. In one embodiment, gNB180a, 180b, and 180c may implement coordinated multipoint (CoMP) technology. For example, WTRU102a may receive coordinated transmissions from gNB180a and gNB180b (and / or gNB180c).

[0051] WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using transmissions associated with scalable neurology. For example, OFDM symbol intervals and / or OFDM subcarrier intervals may vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using subframes or transmit time intervals (TTIs) of varying or scalable lengths (e.g., including varying numbers of OFDM symbols and / or varying durations of absolute time).

[0052] gNB180a, 180b, and 180c can be configured to communicate with WTRU102a, 102b, and 102c in standalone and / or non-standalone configurations. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c without accessing other RANs (e.g., e-nodes B160a, 160b, and 160c). In a standalone configuration, WTRU102a, 102b, and 102c can utilize one or more of gNB180a, 180b, and 180c as mobility anchor points. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using signals in unauthorized bands. In a non-standalone configuration, WTRU102a, 102b, and 102c can communicate with and connect to gNB180a, 180b, and 180c, while also communicating with and connecting to other RANs such as enodes B160a, 160b, and 160c. For example, WTRU102a, 102b, and 102c can implement DC principles for substantially simultaneous communication with one or more gNB180a, 180b, and 180c and one or more enodes B160a, 160b, and 160c. In a non-standalone configuration, e-nodes B160a, 160b, and 160c can function as mobility anchors for WTRU102a, 102b, and 102c, and gNB180a, 180b, and 180c can provide additional coverage and / or throughput to service WTRU102a, 102b, and 102c.

[0053] Each of the gNB180a, 180b, and 180c may be associated with a specific cell (not shown) and may be configured to handle wireless resource management decisions, handover decisions, user scheduling in UL and / or DL, support for network slices, interactions between DC, NR and E-UTRA, routing of user plane data to user plane functions (UPF) 184a and 184b, routing of control plane information to access and mobility management functions (AMF) 182a and 182b, and the like. As shown in Figure 1D, gNB180a, 180b, and 180c can communicate with each other via the Xn interface.

[0054] The CN106 shown in Figure 1D may include at least one AMF182a, 182b, at least one UPF184a, 184b, at least one Session Management Function (SMF)183a, 183b, and optionally a Data Network (DN)185a, 185b. Although the aforementioned elements are illustrated as part of CN106, it should be understood that any of these elements may be owned and / or operated by entities other than the CN operator.

[0055] AMF182a and 182b can be connected to one or more gNB180a, 180b, and 180c in RAN104 via the N2 interface and can function as control nodes. For example, AMF182a and 182b may play roles such as user authentication for WTRU102a, 102b, and 102c, support for network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selection of specific SMF183a and 183b, management of registration areas, termination of non-accessible layer (NAS) signaling, and mobility management. Network slicing can be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of service utilizing WTRU102a, 102b, and 102c. For example, different network slices may be established for different use cases, such as services that rely on ultra-high reliability low latency (URLLC) access, services that rely on high-speed high-capacity (eMBB) access, and services for MTC access. AMF182a, 182b may provide control plane functionality for switching between RAN104 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.

[0056] 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 through UPF184a and 184b. SMF183a and 183b can perform other functions such as managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing DL data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0057] UPF184a and 184b may be connected via the N3 interface to one or more gNB180a, 180b, and 180c within RAN104, thereby providing WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices. UPF184 and 184b may perform other functions such as packet routing and forwarding, enforcement of user plane policies, support for multi-homed PDU sessions, processing of user plane QoS, buffering of DL packets, and providing mobility anchoring.

[0058] CN106 can facilitate communication with other networks. For example, CN106 may 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 WTRU102a, 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, WTRU102a, 102b, 102c may be connected to local DN185a, 185b via UPF184a, 184b through an N3 interface to UPF184a, 184b and an N6 interface between UPF184a, 184b and DN185a, 185b.

[0059] Considering Figures 1A-1D and the corresponding descriptions therein, one or more of the functions described herein with respect to one or more of the WTRU102a-d, base stations 114a-b, eNode-B160a-c, MME162, SGW164, PGW166, gNB180a-c, AMF182a-b, UPF184a-b, SMF183a-b, DN185a-b, and / or other devices described herein may be performed by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0060] Emulation devices may be designed to implement testing of one or more other devices in a laboratory and / or carrier network environment. For example, one or more emulation devices may perform one or more or all of their functions while fully or partially implemented and / or deployed as part of a wired and / or wireless network to test other devices in a communications network. One or more emulation devices may perform one or more or all of their functions while temporarily implemented / deployed as part of a wired and / or wireless network. Emulation devices may be directly coupled to another device for the purpose of testing and / or performing testing using over-the-air wireless communication.

[0061] One or more emulation devices may perform one or more functions, including all of the above, while not implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device may be used in a test laboratory test scenario, and / or in a wired and / or wireless communication network that is not deployed (e.g., for testing purposes), to implement 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 (e.g., which may include one or more antennas) may be used by the emulation device to transmit and / or receive data.

[0062] The following abbreviations and acronyms may be referenced.

[0063] [Table 1]

[0064] Proximity-based services (ProSe) services can be provided to UEs that are in close proximity to each other. UEs can support the ProSe direct discovery procedure, which they can use to discover other nearby UEs. UEs can also support direct communication with other UEs, for example, direct transmission of data to another UE without traversing the infrastructure network.

[0065] In the case of ProSe direct discovery, two models can be considered depending on the role performed by the UE. In Model A, UEs can be classified as either announcing UEs or monitoring UEs based on their role. Announcing UEs can announce / broadcast information that can be used by monitoring UEs to discover other notifying UEs. In Model B, UEs can be classified as either discovering UEs or discovered UEs based on their role. A discovering UE can send a request containing information about what it is interested in discovering, and a discovered UE receiving the request can respond with any information related to the discovering UE's request. A discovered UE is sometimes called an announcement UE. A discovering UE is sometimes called a monitoring UE.

[0066] Discovery procedures can also be considered open or restricted. In the case of open discovery, explicit permission from the discovered UE is not required. In the case of restricted discovery, explicit permission may need to be granted to the discovering UE, allowing the discovering UE to discover the discovered UE. This permission may be associated, for example, with a ProSe restriction code. A ProSe restriction code may be provisioned or configured in a UE authorized to use, provide, or discover other UEs using the same ProSe restriction code. A ProSe restriction code may be associated, for example, with a ProSe service or with ProSe application identification information (e.g., a ProSe app ID). A ProSe restriction code may be transmitted wirelessly by an informing UE to notify of its authorization for discovery purposes, thereby facilitating the discovery process.

[0067] U2U (Ultimatronic) relay is a UE that can relay traffic between an end UE and another UE. Figure 2 shows an example of end UE connectivity using U2U relay connectivity via a PC5 interface.

[0068] Figure 3 illustrates the U2U relay discovery procedure using Model A. In (1), the U2U relay discovers another nearby UE. In (2), the U2U relay broadcasts a discovery notification message. A relay service code (RSC) may be used to identify the connectivity service provided by the U2U relay. The RSC may be pre-configured or provisioned in the U2U relay and authorized end UEs. The RSC may have associated security policies or information necessary for authentication and authorization between the end UE and the U2U relay, for example. The U2U relay can broadcast a discovery / notification message, in which the U2U relay notifies of its relay service capability by including an associated RSC in the message.

[0069] An end UE may be interested in discovering another end UE authorized to use or provide a specific ProSe service, but the end UEs may not be in close proximity to each other. If an end UE is in close proximity to a U2U relay, the U2U relay may be able to facilitate the discovery process. The U2U relay can, for example, notify information associated with the adjacent end UE. A U2U relay discovery message may include, for example, information associated with the adjacent end UE and the services the end UE is authorized to use / provide, such as the ProSe restriction code that the end UE has announced. At the same time, the U2U relay may also include its own information, such as an RSC, to support U2U relay discovery. Information to support U2U relay discovery may include, for example, a U2U relay information ID and a relay service code (RSC). Information associated with an end UE is called a Direct Discovery Set (DDS).

[0070] The DDS may be located near a U2U relay and may contain information associated with the end UE that the U2U relay can communicate with. The DDS may contain a user information identifier (user information ID) and a ProSe restriction code associated with the end UE. The user information ID may be assigned to the end UE on a per-service basis. It may be unique for each end UE using the service and may be used to distinguish end UEs using the same service.

[0071] Potential security requirements for U2U relay may include the protection of sensitive information and privacy of the end UE during the inter-UE relay discovery procedure. Security keys may be used to protect messages during transmission. Both the inter-UE relay and the end UE may provision security materials associated with the RSC to properly exchange and process relay messages. However, only authorized end UEs may provision security materials associated with a given Prose restriction code.

[0072] The terms security material, security key, and security key set are used interchangeably herein to represent one or more parameters used to protect or safeguard a message or part of a message. The terms protected message and safeguarded message are used interchangeably herein to represent a message protected / safeguarded by a particular security material. Security materials for different messages may differ, and therefore they are represented herein by association between the security material and some or all of the information they protect, for example, by using RSC-related security material.

[0073] Figure 4 shows an example of a relay message in which a single key set associated with the RSC is used to protect the message. The Message Integrity Code (MIC) 401 can be calculated using the integrity key for message integrity protection. The portion of the message having the Inter-UE Relay Information ID 402 and the End-UE Information Element 403 can be encrypted using the secret key. (Here, the term Inter-UE Relay Information ID refers to the User Information ID of the Inter-UE Relay). UTC-based counters can be used in both integrity and confidentiality calculations to ensure the freshness of the protection and to protect against replay attacks. UTC-based counters used internally by the UE can be encoded, for example, as 32 most significant bits of UTC time. Parameters transmitted in the message by the notifying UE can carry the four least significant bits (LSB) of the UTC-based counter 404. This can be used by the monitoring UE when setting the value of the UTC-based counter to ensure that both UEs use the same value.

[0074] For example, a single keyset may be used to protect relay messages. If a single keyset is associated with an RSC, a UE authorized to use the RSC can decrypt, tamper with, or reconstruct any DDS transmitted with that RSC. For instance, a first UE authorized to use a first ProSe service could potentially eavesdrop on the contents of a relay message containing information about a second UE using a different ProSe service. This security issue can be mitigated by implementing security isolation between ProSe services (i.e., avoiding multiple ProSe services sharing a common RSC key). However, this may require configuring a dedicated RSC for a given ProSe service, which can be defined as part of a service deployment.

[0075] In another example, multiple key sets may be used to protect relay messages. For instance, each ProSe service has associated ProSe restriction codes and security materials. In this case, each individual direct discovery set (DDS) may be protected using its own individual security materials, such as ProSe restriction code-related security materials. RSC-related security materials may be used to encrypt U2U relay discovery messages.

[0076] Figure 5 shows an example of a relay message in which multiple key sets associated with an RSC are used to protect the message. In this example, each DDS (e.g., set #1 501 and set #2 502) may be protected using its specific key set associated with its respective ProSe restriction code.

[0077] A single-keyset approach can enable simpler deployment options and have less impact on existing discovery / provisioning procedures. Therefore, it may be suitable when a dedicated RSC is used or when additional protection per ProSe service is not required (e.g., when used with public safety-related ProSe services). Multiple-keyset approaches can provide additional flexibility with respect to RSC / ProSe service deployment, configuration options, and means of mitigating the aforementioned potential security / privacy risks. This approach may be suitable when the RSC is used by multiple commercial ProSe services. The coexistence of these approaches may be desirable to support different deployment scenarios and fluctuating security requirements.

[0078] When employing a multiple keyset approach, even if a U2U relay may be relaying traffic associated with a given ProSe restriction code, if, for example, the U2U relay is not authorized to use the ProSe service associated with that ProSe restriction code, then the keyset associated with that ProSe restriction code may not be provisioned in the U2U relay.

[0079] A U2U relay supporting protected DDS can support multiple keyset techniques. Support for protected DDS by a U2U relay may be configured in the information associated with the RSC, i.e., on an RSC-by-RSC basis. This allows for the coexistence of RSCs that support a single key set and RSCs that support multiple key sets (e.g., those that support protected DDS). The U2U relay can use the configuration information associated with the RSC to determine whether protected DDS is supported for the RSC, and then use information from the end UE to determine whether the specific DDS of the advertised end UE requires supported protection.

[0080] An end UE can send protected DDS to a U2U relay in a discovery message. A U2U relay that supports protected DDS can extract the protected DDS from the message received from the end UE and include it in the discovery notification message that the U2U relay sends. Since multiple end UEs can send discovery messages with protected DDS to a U2E relay, the relay can extract each protected DDS received and transparently append all extracted protected DDS to the discovery notification message sent by the U2U relay.

[0081] End UEs already connected to a relay may not retransmit discovery messages with protected DDSs to the relay, as they may no longer be needed after the relay is discovered. Sending messages multiple times increases overhead and can affect the UE's battery life. U2U relays can store received protected DDSs for transmission in subsequent discovery notification messages. However, due to UTC time-based replay protection, protected DDSs may become invalid after a certain period and may then be invalidated when received by a monitoring end UE. Relays may not have access to newly generated protected DDSs and may not be able to properly announce the presence of end UEs when needed.

[0082] For example, if a U2U relay connected to an end UE decides to announce previously discovered or currently connected end UEs, the U2U relay can request a protected DDS from these end UEs. Based on the ProSe restriction code stored within the PC5 link context, the U2U relay can determine that the ProSe service used by the end UE is subject to DDS protection. If a protected DDS received from a previously discovered or currently connected UE is stored, the U2U relay can verify its validity. If the protected DDS is invalid (for example, based on UTC time), the U2U relay can send a request to obtain an updated protected DDS from the previously discovered or currently connected UE.

[0083] The protected DDS request message may be a newly defined PC5 signaling (PC5-S) message, or an existing PC5-S message may be extended to include DDS-related information. The U2U relay may send a PC5-S request message containing a ProSe restriction code requesting a protected DDS from the end UE. The U2U relay may receive a PC5-S response message from the end UE containing a protected DDS corresponding to the ProSe restriction code. The U2U relay may then send a U2U relay discovery notification message containing the received protected DDS.

[0084] In one example, an end UE can send a protected DDS based on a configured U2U relay discovery time value. The end UE can run a timer, and when the timer expires, the end UE can send a message containing the updated protected DDS to the U2U relay.

[0085] For example, when a U2U relay receives information from an end UE that includes a protected DDS, the U2U relay may send a message to the end UE that includes a time value for the next notification opportunity. The end UE may then send an updated protected DDS to the U2U relay during the next notification opportunity.

[0086] For example, a U2U relay may include discovery scheduling support information in its discovery notification message. This discovery scheduling support information may include information about notification opportunities. This could be, for example, a time offset (from the current time) until the next notification. This could include, for example, a configuration for periodic notification opportunities, including a start time, an end time, and the periodicity of such opportunities.

[0087] Each RSC can have multiple associated ProSe services (e.g., ProSe restriction codes). The user information ID assigned to an end UE is unique only for each ProSe service; that is, the same user information ID can be assigned to different end UEs using different services. Different services may be associated with the same RSC. As a result, one or more IP addresses may be associated with the same user information ID. The relay stores user information IDs and IP address / prefix information in a table so that it can respond to DNS queries. When it receives a DNS query message containing a user information ID, it finds the user information ID in the table and sends back a DNS response message containing the corresponding IP address / prefix information. In this case, one or more entries may exist in the table associated with the same user information ID. To identify user information IDs received from different end UEs and associated with different end UEs when receiving DNS query messages, the U2U relay can use ProSe restriction codes associated with services in addition to user information IDs. In other words, each unique pair of ProSe restriction code and user information ID may have its own IP address / prefix information.

[0088] An end UE connected to a U2U relay may probe the relay (e.g., using DNS queries) for the IP address / prefix information of other end UEs based on the end UE user information ID it may possess. This could provide a malicious end UE with a means to circumvent the authorization for limited discovery and ability to track whether a particular end UE is connected to a U2U relay. To mitigate this risk, it is desirable to ensure that IP address / prefix information is shared only with authorized end UEs. In other words, it is desirable to ensure that the U2U relay shares end UE A's IP address / prefix information with end UE B only if end UE B is authorized for limited discovery with end UE A, using the same ProSe restriction code from the unique pair of ProSe restriction code and user information ID associated with the IP address / prefix information in question.

[0089] For example, during the link establishment procedure, the U2U relay may receive a Direct Connection Request (DCR) message from the first end UE containing the RSC and the first ProSe restriction code. The U2U relay can store the ProSe restriction code in the context associated with the first end UE (PC5 link, DNS entry). The U2U relay can send a Direct Connection Acceptance (DCA) message to the first end UE acknowledging that "IP sharing protection" is enabled for the first end UE. By enabling "IP sharing protection," the U2U relay ensures that only the first end UE's IP address / prefix information is shared with the second end UE, provided that the second end UE is permitted to make discoveries restricted by the first ProSe restriction code.

[0090] During the DNS resolution process, the U2U relay can receive a DNS query message from the second end UE containing the second end UE user information ID and the second ProSe restriction code. The U2U relay can verify whether the second ProSe restriction code matches the first ProSe restriction code. Only if the second ProSe restriction code is the same as the first ProSe restriction code can the U2U relay send a DNS response message containing the first end UE's IP address / prefix information to the second end UE.

[0091] Figure 6 shows an exemplary call flow for a U2U relay direct link establishment procedure with support for Model A U2U relay discovery using multiple key sets and IP shared privacy.

[0092] The end UE may provision RSC-related security material and DDS-related security material by DDNMF, PCF, or PKMF (601, 602). The DDS security material may include ProSe restriction codes and associated key material. The U2U relay may provision RSC-related security material by PCF or PKMF (603). The U2U relay and the end UE may be configured with an indicator associated with the RSC that indicates whether the RSC supports a protected DDS. The indicator may also indicate whether the use of a protected DDS is essential for the RSC, for example, whether the RSC can operate without a protected DDS.

[0093] An end UE may send a Direct Connection Request (DCR) message containing the RSC, end UE user information ID, and ProSe restriction code to the U2U relay (604). The end UE may provide instructions for DDS protection. The end UE may provide an expiration time value for the ProSe restriction code (for example, based on the corresponding expiration time value configured by the PCF / DDNMF in the end UE). The ProSe restriction code may be used by the U2U relay to determine whether a particular end UE is subject to IP shared privacy protection and / or to enable deambiguation of the end UE user information ID (when multiple entries exist).

[0094] Parameters in a DCR message, such as RSC, end-UE user information ID, and ProSe restriction code, may be protected using RSC-related security materials (e.g., for confidentiality, integrity, and against replay). Instructions for protected DDS support may be provided instead of the ProSe restriction code. Instructions may be provided to avoid exposing a specific ProSe restriction code and / or an unauthorized linkage between the ProSe restriction code and the end-UE user information ID (e.g., if the identifier parameter is not confidential in the DCR message). Instructions may be used by a U2U relay to determine that the end-UE may have at least one protected direct discovery set to be announced by the U2U relay.

[0095] Upon receiving a DCR message containing a ProSe restriction code / instruction for DDS protection, the U2U relay can verify whether the RSC supports protected DDS based on the indicators described above (605).

[0096] The U2U relay and the end UE may establish security for the PC5 link (606). The U2U relay may store ProSe restriction codes / instructions for DDS protection in the PC5 link context along with the end UE user information ID (607). The U2U relay may send a Direct Connection Acceptance (DCA) message to the end UE that includes a time value for the next opportunity for U2U relay notification of a protected DDS from the end UE (608).

[0097] Figure 7 shows an exemplary call flow for a U2U relay direct link modification procedure to enable support for Model A U2U relay discovery using multiple key sets and IP shared privacy.

[0098] An end UE may have an established link with a U2U relay (701). An end UE may send a Link Modification Request (LMR) message containing a ProSe restriction code to the U2U relay (for example, to add another ProSe service that reuses an existing link, or to securely provide a ProSe restriction code if one was not sent in the DCR, for example, if instructions were provided during link establishment instead of the ProSe restriction code) (702). An end UE may provide instructions regarding DDS protection and validity time values, as described above for the case of the DCR. The provided ProSe restriction code may be used by the U2U relay to determine whether a particular end UE is subject to IP shared privacy protection and / or to enable deambiguation of the end UE user information ID (when multiple entries exist).

[0099] An LMR can be initiated by an end UE to activate DDS protection for the end UE and / or a specific ProSe service subject to DDS protection (for example, an existing ProSe service on a PC5 link is not subject to DDS protection, and the end UE wishes to activate it). An LMR may also be initiated by an end UE to revoke a ProSe limit code following a discovery update procedure, in which case the DDNMF revokes a previously assigned ProSe limit code. In this case, instructions for revoking the ProSe limit code may be included. If a new code is assigned by the DDNMF and the end UE replaces the old code, the LMR may include the old and new ProSe limit code values ​​and a new validity period parameter.

[0100] Upon receiving a DCR message containing a ProSe restriction code / instruction for DDS protection, the U2U relay can verify that the RSC supports protected DDS based on the associated indicator (703).

[0101] The U2U relay may store ProSe restriction codes / instructions for DDS protection in the PC5 link context along with existing end UE information (704). Alternatively, the U2U relay may remove or replace ProSe restriction codes if they should be revoked or replaced (as indicated above). The U2U relay may decide to release the direct link if all end UE ProSe restriction codes have been removed and no other ProSe services remain in use.

[0102] The U2U relay may send a Link Modification Acceptance (LMA) message to the end UE (for example, if DDS protection is activated for a ProSe service used on this link) that includes a notification time value for the next opportunity for notification by the U2U relay of protected DDS from the end UE (705). If the U2U relay has revoked the last ProSe limit code for the end UE, the U2U relay may include instructions to revoke any pending protected DDS timers.

[0103] The U2U relay may also invalidate stored ProSe limit codes when the corresponding validity timer expires. The U2U relay may decide to release the direct link to the end UE if all end UE ProSe limit codes have expired and no other ProSe services remain in use.

[0104] Figure 8 shows an example call flow for a U2U relay DNS query with IP shared privacy.

[0105] End UE 1 can perform a direct link establishment procedure with U2U relay 801. End UE 2 may have established a secure connection with U2U relay (802) (for example, by using the direct link establishment procedure).

[0106] The U2U relay can receive DNS queries from end UE 2 that include the end UE 1 user information ID and ProSe restriction code used to discover end UE 1 (803).

[0107] The U2U relay can verify that there is an entry for the end UE 1 user information ID and the received ProSe restriction code (804). Multiple entries may exist for the same user information ID. The ProSe restriction code is used to select a specific entry (i.e., to extract a unique pair of ProSe restriction code and user information ID). The U2U relay can verify that the validity timer for the ProSe restriction code has not expired. If the previous checks were successful, the U2U relay can send a DNS response to end UE 2 containing the IP address / prefix information of end UE 1 (805).

[0108] Figure 9 shows an exemplary call flow for the U2U relay discovery procedure of Model A U2U relay initiation using multiple key sets.

[0109] End UE 1 can perform the procedure for establishing a direct link with the U2U relay (901). The U2U relay may decide to announce the connected or discovered UE (902).

[0110] For each of the stored ProSe restriction codes for end UE 1, the U2U relay may send a PC5 signaling message (PC5-S) request message containing the ProSe restriction code previously received from end UE 1 to request the corresponding protected DDS (903). A new PC5-S signaling message may be defined, or an existing PC5 message may be extended to include the new information required, for example, a keep-alive message may be reused for a request for a protected DDS associated with a ProSe restriction code.

[0111] In one example, a U2U relay could send a PC5-S request message containing instructions to request all applicable protected DDS for all services (for example, End UE 1 uses several different ProSe services that require per-ProSe service protection). In another example, a U2U relay could send a list of ProSe restriction codes.

[0112] End UE 1 may generate a secure PC5-S response message (e.g., a keep-alive message) containing RSC and DDS protected using Direct Discovery Security Material 904. End UE 1 may include one or more DDS in the response message (e.g., if the request included a list of Prose restriction codes). End UE 1 may protect the PC5-S message using the PC5 Link Security Context and send it to the U2U relay.

[0113] The U2U relay can process PC5-S response message security and extract the protected DDS. The U2U relay can verify that the ProSe restriction code from the received protected DDS is valid (for example, verifying whether the validity timer has expired based on the validity time value). The U2U relay can send a U2U relay protection discovery message to end UE 2 (905) which includes the RSC, the U2U relay user information ID, and the protected DDS received from end UE 1. The U2U relay can protect the U2U relay discovery message using the security material associated with the RSC.

[0114] Figure 10 shows an exemplary call flow for an EndUE-Initiated Model A U2U Relay Discovery Model A procedure using multiple key sets.

[0115] End UE 1 can perform a procedure to establish a direct link with the U2U relay (1001). End UE 1 can decide to provide the U2U relay with one or more protected DDSs (1002). This may be triggered based on an announcement time value given by the U2U relay (e.g., in DCA or LMA) as described above.

[0116] End UE 1 can generate a U2U relay discovery notification message that includes an RSC, a U2U relay user information ID, and one or more DDSs, each of which is protected using its respective DDS-related security materials (1003). End UE 1 can protect the U2U relay discovery message using RSC-related security materials and send it to the U2U relay. The destination L2 ID may be set to the U2U relay L2 ID discovered by End UE 1, or a conventionally configured default L2 ID may be used.

[0117] Alternatively, in 1004, End UE 1 can generate secure PC5-S (unicast) request messages (e.g., keep-alive request messages or new PC5-S messages may be defined) that include an RSC and one or more DDSs, each protected using their respective DDS-related security materials. End UE 1 can protect the PC5-S message using the PC5 link security context and send it to the U2U relay.

[0118] The U2U relay can process the U2U relay discovery / PC5-S request message security and extract the contained protected DDS (1005).

[0119] U2U relay can verify that the RSC supports protected DDS and the validity of the ProSe restriction code from the received protected DDS (1006). The U2U relay can verify that each received code matches a stored ProSe limit code for end UE 1 and that it has not expired (for example, based on the validity time value described above).

[0120] In an alternative case to PC5-S message 1004, the U2U relay may send a secure PC5-S response message (e.g., a keep-alive response message, or a new PC5-S may be defined) to end UE 1 containing a response status for notification (e.g., success or failure) (1007). The response may include the relevant ProSe restriction code.

[0121] The U2U relay can send a U2U relay protection discovery message to end UE 2, which includes the RSC, the U2U relay user information ID, and the protected DDS received from end UE 1 (1008). The U2U relay can protect the U2U relay discovery message using the security material associated with the RSC.

[0122] Figure 11 shows an exemplary call flow for the U2U relay discovery procedure of Model A U2U relay initiation with delayed notification of discovered end UE.

[0123] End UE 1 may decide to send a discovery notification message to the U2U relay (1101). The End UE may monitor previous discovery notification messages sent by the U2U relay to determine the next scheduled notification opportunity for the U2U relay. For example, the U2U relay may include discovery scheduling assistance information in its discovery notification message to notify nearby (one or more) End UEs about the next notification opportunity by the U2U relay (represented, for example, as a time offset / window with respect to the current time or the time the discovery message was sent). The End UE may use this information to schedule / synchronize the sending of its own discovery message to the relay in a timely manner, enabling the relay to include a protected DDS from the End UE in its next relay notification message (for example, near real-time before the next transmission by the U2U relay).

[0124] End UE 1 can generate a U2U relay discovery notification message that includes the RSC, a U2U relay user information ID, and a DDS protected using direct discovery security material and an expiration time value (1102). The expiration time value may be set so as not to exceed the maximum range allowed by time-based replay protection. For example, the expiration time value may be set so as not to exceed the maximum time held by the UTC-based counter LSB (e.g., 2, 4, or 16 seconds).

[0125] The U2U relay can process the U2U relay discovery / PC5-S request message and extract the protected DDS and validity time value (1103). The U2U relay can verify that the RSC supports protected DDS.

[0126] The U2U relay may schedule the next notification for the end UE protected DDS according to its own next scheduled notification opportunity (for example, based on the implementation), taking into account the received validity time value (1104). For example, if the time difference between the next scheduled notification opportunities is greater than the validity time value (or if no validity time value is provided), the U2U relay may decide to immediately send the protected DDS for end UE 1 (or discard the current end UE 1 discovery message until a more appropriate / aligned relay notification opportunity).

[0127] The U2U relay can send a U2U relay protected discovery message at a scheduled time, which includes the RSC, the U2U relay user information ID, and the protected DDS received from end UE 1 (1105). The U2U relay can protect the U2U relay discovery message using security material associated with the RSC.

[0128] In one example, the U2U relay may consist of RSC-related security material, and the end UE may consist of RSC-related security material and DDS-related security material. The security material associated with the DDS may be associated with ProSe restriction code. The U2U relay and the end UE may be configured with an indicator associated with the RSC that indicates whether the RSC supports a protected DDS.

[0129] In one example, a U2U relay can send a request message to a connected end UE for a protected DDS. The request message may include a ProSe restriction code. The U2U relay can receive a response message from the connected end UE. The response message may include the requested protected DDS. The message may also include the message type, the ProSe restriction code associated with the DDS, a UTC-based counter, the MIC, and the protected end UE information ID. In another example, an end UE can send a U2U relay discovery message containing the protected DDS. The U2U relay can send a discovery notification containing the received protected DDS.

[0130] While the features and elements are described above in specific combinations, 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. In addition, the methods described herein can be implemented in computer programs, software, or firmware embedded in a computer-readable medium for execution by a computer or processor. Examples of computer-readable mediums include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital multipurpose 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 relaying between wireless transmitting / receiving units (WTRUs), wherein the method is Receiving a first message from a first end WTRU, wherein the first message includes a first protected direct discovery set (DDS), and the first protected DDS is protected using first security material associated with a proximity service (ProSe) service. Extracting the first protected DDS from the first message, Determining that the first protected DDS is effective, This includes sending a second message to a second end WTRU, The second message includes the first protected DDS and a relay service code (RSC) associated with the relay connection service provided by the WTRU relay, A method by which the second message is protected using a second security material associated with the RSC.

2. The method according to claim 1, wherein determining that the first protected DDS is valid is based on an effective time value configured in the inter-WTRU relay.

3. The method of claim 2, wherein determining that the first protected DDS is valid is based on an validity time value provided in the first message.

4. The method according to any one of claims 1 to 3, wherein the first end WTRU and the second end WTRU are provisioned with the first security material.

5. The method according to any one of claims 1 to 4, wherein the WTRU relay, the first end WTRU, and the second end WTRU are provisioned with the second security material.

6. The method according to any one of claims 1 to 5, further comprising transmitting a response to the first end UE to acknowledge the reception of the first protected DDS.

7. The method according to any one of claims 1 to 6, further comprising verifying that the relay connection service provided by the WTRU relay supports relay operation using a protected DDS.

8. The method according to any one of claims 1 to 7, further comprising sending a third message to a third end WTRU, wherein the third message is a PC5 signaling (PC5-S) secure request message, and the third message includes a request to a second protected DDS.

9. The method according to claim 8, further comprising receiving a fourth message from the third end WTRU, wherein the fourth message is a PC5 signaling (PC5-S) secure response message, and the fourth message includes the second protected DDS.

10. The method according to claim 8 or 9, wherein transmitting the third message to the third end WTRU is based on a notification period configured in the inter-WTRU relay.

11. A wireless transmit / receive unit (WTRU) for implementing a WTRU relay function, wherein the WTRU comprises at least one processor and a transceiver, and the at least one processor and transceiver are Receiving a first message from a first end WTRU, wherein the first message includes a first protected direct discovery set (DDS), and the first protected DDS is protected using first security material associated with a proximity service (ProSe) service. Extracting the first protected DDS from the first message, Determining that the first protected DDS is effective, The system is configured to transmit a second message to a second end WTRU, wherein the second message includes the first protected DDS and a relay service code (RSC) associated with the relay connection service provided by the inter-WTRU relay. The second message is protected using a second security material associated with the RSC in a wireless transmit / receive unit (WTRU).

12. The WTRU according to claim 11, wherein the determination that the first protected DDS is valid is based on an effective time value configured in the WTRU.

13. The WTRU according to claim 12, wherein the determination that the first protected DDS is active is based on an active time value provided in the first message.

14. The first end WTRU and the second end WTRU are provisioned with the first security material, as described in any one of claims 11 to 13.

15. The WTRU, the first end WTRU, and the second end WTRU are provisioned with the second security material, according to any one of claims 11 to 14.

16. The WTRU according to any one of claims 11 to 15, wherein the at least one processor and transceiver is further configured to transmit a response to the first end UE to acknowledge the reception of the first protected DDS.

17. The WTRU according to any one of claims 11 to 16, wherein the at least one processor and transceiver are further configured to verify that the relay connection service provided supports relay operation using a protected DDS.

18. The WTRU according to any one of claims 11 to 17, wherein the at least one processor and transceiver is further configured to transmit a third message to a third end WTRU, the third message being a PC5 signaling (PC5-S) secure request message, and the third message comprising a request to a second protected DDS.

19. The WTRU according to claim 18, wherein the at least one processor and transceiver is further configured to receive a fourth message from the third end WTRU, the fourth message being a PC5 signaling (PC5-S) secure response message, and the fourth message comprising the second protected DDS.

20. The WTRU according to any one of claims 18 or 19, wherein the at least one processor and transceiver are further configured to transmit the third message to the third end WTRU based on an announcement period configured in the WTRU.

Images