Method and apparatus for wtru-to-wtru relay discovery security and privacy

Abstract

A method for UE to UE (U2U) relay discovery security is disclosed. The method may include providing a terminal UE with security profile for a direct discovery set and a U2U discovery message, and providing a U2U relay with security profile for a U2U discovery message. The security profile for the direct discovery set may include at least one of a ProSe restricted code, an associated key profile, and an indicator associated with a Relay Service Code (RSC) that indicates whether the RSC supports per ProSe direct discovery set protection. The method may include transmitting, by the end UE, a direct connection request (DCR) message to the U2U relay. The DCR message may include at least one of an RSC, and an end UE user information identification (ID), and a ProSe restricted code. The method may include transmitting, by the end UE, an indication for direct discovery set protection.

Description

[0001] This application is a divisional application of patent application No. 202480029178.0, filed on March 6, 2024, entitled "Method and apparatus for security and privacy discovery of WTRU-to-WTRU relay". Cross-reference to related applications

[0002] This application claims the benefit of U.S. Provisional Application 63 / 489,273, filed March 9, 2023, the contents of which are incorporated herein by reference. Background Technology

[0003] Proximity-based services (ProSe) can be provided to adjacent UEs. UEs can support the ProSe direct discovery process, which can be used to discover other nearby UEs. UEs can also support direct communication with another UE, for example, transmitting data directly to another UE without going through the infrastructure network.

[0004] The discovery process can be considered either open or restricted. In the case of open discovery, no explicit permission from the discovered UE is required. In the case of restricted discovery, there may be a requirement for explicit permission granted to the discovering UE to authorize the discovering UE to discover the discovered UE. This permission may be associated with, for example, a ProSe restricted code. The ProSe restricted code can be provided or configured in UEs that are authorized to use, provide, or discover other UEs using the same ProSe restricted code. Summary of the Invention

[0005] Proximity-based service (ProSe) can be provided to neighboring UEs. UEs can support the ProSe direct discovery process, which can be used to discover other nearby UEs. UEs can also support direct communication with another UE. UE-to-UE relays can relay traffic to and from end UEs. UE-to-UE relays broadcast discovery messages, which include their associated Relay Service Code (RSC), to facilitate the relay discovery process for end UEs. Discovery messages may include Direct Discovery Sets (DDS). DDS may contain information associated with one or more end UEs near the UE-to-UE relay. This may include a User Information Identifier (User Information ID) and a ProSe Restriction Code. Each RSC may have one or more ProSe Restriction Codes associated with it. The end UE's IP address / prefix information is associated with a unique ProSe Restriction Code and User Information ID pair.

[0006] Potential security requirements for UE-to-UE relay may include the protection of the UE's discovery messages and privacy-sensitive information during the UE-to-UE relay discovery process. Security keys can be used to protect messages during transmission. Both the relay and end UEs can be configured with security information associated with RSCs to ensure the security of the appropriate exchange and processing of relay messages. Only authorized end UEs can be configured with security information associated with a given ProSe restricted code. If the second end UE is authorized to perform restricted discovery using the same ProSe restricted code associated with the first end UE, then UE-to-UE relay may share the first end UE's IP address / prefix information only with the second end UE.

[0007] The end UE sends a protected DDS to the UE-to-UE relay, and the UE-to-UE relay includes the protected DDS in the discovery message. In one example, the end UE may run a timer to trigger the sending of an updated protected DDS to the UE-to-UE relay when the timer expires. In another example, the UE-to-UE relay may provide information about the next announcement timing, and then the end UE may send an updated protected DDS to the UE-to-UE relay during the next announcement timing. Attached Figure Description

[0008] The invention can be understood in more detail from the following description given by way of example in conjunction with the accompanying drawings, wherein like reference numerals denote like elements, and wherein: Figure 1A This is a system diagram illustrating an exemplary communication system that can implement one or more of the disclosed embodiments; Figure 1B This illustrates the possibility of implementation according to an embodiment. Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) used within the communication system shown; Figure 1C It is shown that, according to the embodiment, it is possible to Figure 1A System diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) used within the communication system shown; Figure 1D It is shown that, according to the embodiment, it is possible to Figure 1A A system diagram of another exemplary RAN and another exemplary CN used within the communication system shown; Figure 2 An example of UE-to-UE trunk connectivity is shown using the PC5 interface; Figure 3 This illustrates the UE-to-UE relay discovery process using Model A; Figure 4 An example of a relay message is shown, in which a single key set associated with the RSC is used to protect the message; Figure 5 An example of a relay message is shown, in which multiple key sets associated with the RSC are used to protect the message; Figure 6 An exemplary call flow is shown for the establishment of a direct link in a U2U trunk, which supports a model A U2U trunk discovery that uses multiple key sets and IP-shared privacy. Figure 7 An exemplary call flow is shown for the U2U trunk direct link modification process, which can support AU2U trunk discovery using multiple key sets and IP shared privacy. Figure 8 An exemplary call flow for U2U trunk DNS lookup using IP shared privacy is shown; Figure 9 An exemplary call flow is shown for a U2U trunk discovery process initiated by a U2U trunk using multiple key sets; Figure 10 An exemplary call flow is shown for a Model AU2U relay discovery process initiated by an end UE using multiple key sets; and Figure 11 An exemplary call flow is shown for a U2U trunk discovery process initiated by a U2U trunk using a delayed notification from the discovered UE. Detailed Implementation

[0009] Figure 1A This diagram illustrates an example 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, and broadcasting to multiple wireless users. The communication system 100 enables multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail Unique Word Fourier Transform Extended OFDM (ZT-UW DTS-S-OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0010] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Any of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a station (STA)) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or MiFi devices, Internet of Things (IoT) devices, watches or other wearable devices, 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 industrial and / or automated processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of the wireless transmission / reception units 102a, 102b, 102c, and 102d may be interchangeably referred to as UEs.

[0011] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b can be any type of device configured to wirelessly connect to at least one of 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 examples, base stations 114a and 114b may be base transceiver stations (BTS), NodeBs, eNodeBs (eNBs), home NodeBs, home eNodeBs, next-generation NodeBs (e.g., gNodeBs (gNBs)), new radio (NR) NodeBs, site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are each depicted as a single element, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

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

[0013] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116, which can 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 can be established using any suitable radio access technology (RAT).

[0014] More specifically, as described above, the communication system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can use Wideband CDMA (WCDMA) to establish the air interface 116. WCDMA can include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​Uplink (UL) Packet Access (HSUPA).

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

[0016] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can use NR to establish air interface 116.

[0017] In one embodiment, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can, for instance, use a dual connectivity (DC) principle to implement both LTE and NR radio access together. Therefore, the air interface used by WTRUs 102a, 102b, and 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0018] In other embodiments, base station 114a and wireless transmission / reception units 102a, 102b, 102c may implement wireless technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., Global Microwave Access Interoperability (WiMAX)), CDMA 2000, CDMA 2000 1X, CDMA 2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0019] Figure 1ABase station 114b can be, for example, a wireless router, a home NodeB, a home eNodeB, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area such as a business premises, home, vehicle, campus, industrial facility, air corridor (e.g., for drone use), road, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA 2000, GSM, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b can have a direct connection to Internet 110. Therefore, base station 114b does not need to access Internet 110 via CN 106.

[0020] RAN 104 can communicate with CN 106, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. Data may have varying Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions (such as user authentication). Although in Figure 1A Although not shown, it should be understood that RAN 104 and / or CN 106 can communicate directly or indirectly with other RANs that use the same RAT as RAN 104 or a different RAT. For example, in addition to connecting to RAN 104, which can utilize NR radio technology, CN 106 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0021] CN 106 can also serve as a gateway for WTRUs 102a, 102b, 102c, and 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols, such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from 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, which may use the same RAT as RAN 104 or a different RAT.

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

[0023] Figure 1B This is a system diagram illustrating example WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keyboard 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 peripheral devices 138, etc. It is understood that WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

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

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

[0026] Although the transmitting / receiving element 122 is in Figure 1B While described as a single element, WTRU 102 may include any number of transmitting / receiving elements 122. More specifically, WTRU 102 may use MIMO technology. Therefore, in one embodiment, WTRU 102 may include two or more transmitting / receiving elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interface 116.

[0027] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 can have multimode capability. Therefore, transceiver 120 can include multiple transceivers to enable WTRU 102 to communicate via various RATs, such as NR and IEEE 802.11.

[0028] The processor 118 of WTRU 102 may be coupled to a speaker / microphone 124, a keyboard 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit) and may receive user input data therefrom. The processor 118 may also output user data to the speaker / microphone 124, keyboard 126, and / or display / touchpad 128. Additionally, the processor 118 may access information from any suitable type of memory and store data in said memory, such as non-removable memory 130 and / or removable memory 132. 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 user identification module (SIM) card, memory stick, secure digital storage (SD) card, etc. In other embodiments, the processor 118 may access information from memory that is not physically located on WTRU 102 and store data in said memory (e.g., located on a server or home computer (not shown)).

[0029] The processor 118 can receive power from the power supply 134 and can be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 can be any suitable device for powering 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.), solar cells, fuel cells, etc.

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

[0031] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or video), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors. These sensors may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, humidity sensors, etc.

[0032] WTRU 102 may include a full-duplex radio for which transmission and reception of some or all of the signals (e.g., signals associated with a specific subframe for UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit to reduce and / or substantially eliminate self-interference through hardware (e.g., chokes) or through signal processing by a processor (e.g., a separate processor (not shown) or processor 118). In one embodiment, WTRU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., signals associated with a specific subframe for UL (e.g., for transmission) or DL ​​(e.g., for reception)) may be concurrent and / or simultaneous.

[0033] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 may employ E-UTRA radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 may also communicate with CN 106.

[0034] RAN 104 may include eNode-Bs 160a, 160b, and 160c, but it should be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. eNode-Bs 160a, 160b, and 160c may each include one or more transceivers to communicate with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, for example, eNode-B 160a may use multiple antennas to transmit and / or receive radio signals from WTRU 102a.

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

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

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

[0038] The SGW 164 can connect to each of the eNode-Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 can typically route and forward user data packets to / from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions, such as anchoring the user plane during handover between eNode Bs, triggering paging when DL data is available to WTRUs 102a, 102B, and 102c, managing and storing the context of WTRUs 102a, 102B, and 102c, etc.

[0039] The SGW 164 can connect to the PGW 166, which can provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0040] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRU 102a, 102b, and 102c with access to a circuit-switched network (e.g., PSTN 108) to facilitate communication between WTRU 102a, 102b, and 102c and traditional landline communication equipment. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) or can communicate with an IP gateway that serves as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRU 102a, 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.

[0041] Although WTRU is Figure 1A-1D While described as a wireless terminal, it is conceivable that in some representative embodiments, such a terminal may use a wired communication interface with a communication network (e.g., temporary or permanent).

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

[0043] A WLAN in Infrastructure Basic Services Set (BSS) mode can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can have access or interfaces to a distributed system (DS) or another type of wired / wireless network carrying traffic entering and / or leaving the BSS. Traffic originating outside the BSS destined for a STA can be delivered to the STA via the AP. Traffic originating from a STA destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a 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. This peer-to-peer traffic can be sent between the source and destination STAs (e.g., directly between the source and destination STAs) using a direct link setup (DLS). In some representative embodiments, the DLS can use 802.11e DLS or 802.11z tunneled DLS (TDLS). WLANs using Standalone BSS (IBSS) mode cannot have access points (APs), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as the "ad-hoc" communication mode in this document.

[0044] When using 802.11ac infrastructure operating mode or a similar operating mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of fixed width (e.g., a bandwidth of 20 MHz) or dynamically configured. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, such as in an 802.11 system, Carrier Sense Multiple Access (CSMA / CA) with collision avoidance can be implemented. For CSMA / CA, STAs including the AP (e.g., each STA) can listen on the primary channel. If the primary channel is listened to / detected and / or determined to be busy by a particular STA, that particular STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

[0045] High-throughput (HT) STAs can communicate using a 40 MHz wide channel, for example, by combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0046] 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 consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels, or by combining two non-consecutive 80 MHz channels; this can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data can pass through a segmented parser that divides the data into two streams. Each stream can be processed separately using Inverse Fast Fourier Transform (IFFT) and time-domain processing. The streams can be mapped onto the two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operation of the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0047] Operating modes below 1 GHz are supported by 802.11af and 802.11ah. The channel operating bandwidth and carrier in 802.11af and 802.11ah are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV whitespace (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support instrument-type control / machine-type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities including support for certain and / or limited bandwidths (e.g., only support). MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0048] WLAN systems that can support multiple channels and channel bandwidths (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as the primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA that supports the minimum bandwidth operating mode among all STAs operating in the BSS. In the 802.11ah example, for STAs that support (e.g., only support) the 1 MHz mode (e.g., MTC type devices), the primary channel can be 1 MHz wide even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, due to STAs (which only support the 1 MHz operating mode) transmitting to the AP, then the entire available band can be considered busy even if most of the available band remains idle.

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

[0050] Figure 1D This is a system diagram illustrating RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR wireless technology. RAN 104 can also communicate with CN 106.

[0051] RAN 104 may include gNBs 180a, 180b, and 180c; however, it should be understood that RAN 104 may include any number of gNBs while remaining consistent with the embodiments. Each of gNBs 180a, 180b, and 180c includes 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 implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, gNB 180a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In one embodiment, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c may implement Cooperative Multipoint (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0052] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with Scalable Digital Numerology (SDN). For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or Transmission Time Intervals (TTIs) of varying lengths or scalable lengths (e.g., containing different numbers of OFDM symbols and / or continuously varying lengths of absolute time).

[0053] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without needing to access other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can utilize one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate / connect with gNBs 180a, 180b, and 180c, and also with another RAN (such as eNode-Bs 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate essentially simultaneously with one or more gNBs 180a, 180b, and 180c, as well as one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, and 160c can serve as mobility anchors for WTRUs 102a, 102b, and 102c, while gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0054] 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 decisions, handover decisions, user scheduling in UL and / or DL, network fragmentation support, interoperability between DC, NR, and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, and routing of control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0055] Figure 1DThe CN 106 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and may include data networks (DN) 185a, 185b. While each of the foregoing elements is depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0056] AMF 182a and 182b can connect to one or more of gNB 180a, 180b, and 180c in RAN 104 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different Protocol Data Unit (PDU) sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating Non-Access Stratum (NAS) signaling, mobility management, and so on. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the type of service being used by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services relying on Ultra Reliable Low Latency (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, and services for MTC access. AMF 182a and 182b can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies (such as LTE, LTE-A, LTE-A Pro and / or non-3GPP access technologies (such as WiFi)).

[0057] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 106 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 106 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure them to route traffic through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating 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.

[0058] UPF 184a and 184b can connect to one or more of gNB 180a, 180b, and 180c in RAN 104 via the N3 interface. The N3 interface can provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices. UPF 184 and 184b can perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0059] CN 106 can facilitate communication with other networks. For example, CN 106 may include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) serving as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRUs 102a, 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. In one embodiment, WTRUs 102a, 102b, and 102c may be connected to DN 185a and 185b via the N3 interface to UPF 184a and 184b and the N6 interface between UPF 184a and 184b and local DN 185a and 185b.

[0060] Given Figure 1A-1D and Figure 1A-1D As described herein, one or more of the functions described with respect to one or more of the following can be performed by one or more emulation devices (not shown): WTRU 102a-d, base station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF184a-b, SMF 183a-b, DN 185a-b, and / or any other device described herein. An emulation device can be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device can be used to test other devices and / or simulate network and / or WTRU functions.

[0061] Simulation devices can be designed to perform one or more tests on other devices in laboratory and / or carrier network environments. For example, one or more simulation devices may perform one or more functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. The one or more simulation devices may perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices may be directly coupled to another device for testing purposes and / or may use over-the-air wireless communication to perform tests.

[0062] One or more simulation devices can perform one or more functions (including all functions) without being implemented / deployed as part of a wired and / or wireless communication network. For example, simulation devices can be used in test scenarios within a test laboratory and / or an undeployed (e.g., tested) wired and / or wireless communication network to perform testing of one or more components. One or more simulation devices can be test equipment. Simulation devices can transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0063] The following abbreviations and acronyms may be mentioned:

[0064] Proximity-based services (ProSe) can be provided to adjacent UEs. UEs can support the ProSe direct discovery process, which can be used to discover other UEs in their vicinity. UEs can also support direct communication with another UE, for example, transmitting data directly to another UE without going through the infrastructure network.

[0065] For ProSe direct discovery, two models can be considered, depending on the role the UE plays. In Model A, the UE can be classified as either an announcing UE or a monitoring UE based on its role: an announcing UE can announce / broadcast information that a monitoring UE can use to discover the announcing UE. In Model B, the UE can be classified as either a discovering UE or a discovered UE based on its role: a discovering UE can send a request containing information about its interest in discovery, and a discovered UE receiving the request can respond using some information related to the discovering UE's request. A discovered UE can be referred to as an announcing UE. A discovered UE can be referred to as a monitoring UE.

[0066] The discovery process can be considered either open or restricted. In open discovery, no explicit permission from the discovered UE is required. In restricted discovery, there may be a requirement for explicit permission granted to the discovering UE to authorize the discovering UE to discover the discovered UE. This permission may be associated with, for example, a ProSe restricted code. The ProSe restricted code can be provided or configured in a UE that is authorized to use, provide, or discover other UEs using the same ProSe restricted code. The ProSe restricted code may be associated, for example, with a ProSe service or ProSe application identifier (e.g., a ProSe application ID). The ProSe restricted code may be sent over the air by the notifying UE to announce its authorization for discovery purposes, thereby facilitating the discovery process.

[0067] UE-to-UE (U2U) relay is a UE that can relay services to and from other UEs. Figure 2 An example of UE connectivity using UE-to-UE relay connectivity via the PC5 interface is shown.

[0068] Figure 3 The U2U relay discovery process using Model A is illustrated. In (1), the U2U relay has discovered other nearby UEs. In (2), the U2U relay broadcasts a discovery announcement message. The Relay Service Code (RSC) can be used to identify the connectivity services provided by the U2U relay. The RSC can be pre-configured or provided in the U2U relay and in the authorized end UE. The RSC may contain, for example, associated security policies or information necessary for authentication and authorization between the end UE and the U2U relay. The U2U relay can broadcast a discovery / announcement message in which it announces its relay service capabilities by including the associated RSC in the message.

[0069] There may be situations where a terminal UE is interested in discovering another terminal UE authorized to use or provide a specific ProSe service, but the terminal UEs are not in close proximity. If the terminal UE is near a U2U relay, the U2U relay can facilitate the discovery process. The U2U relay can, for example, advertise information associated with a nearby terminal UE. The U2U relay discovery message may include, for example, information associated with a nearby terminal UE and the services that terminal UE is authorized to use / provide, such as the ProSe restriction code that the terminal UE is advertising. Simultaneously, the U2U relay may also include its own information (e.g., RSC) to support U2U relay discovery. Information supporting U2U relay discovery may include, for example, the U2U relay information ID and relay service code (RSC). The information associated with the terminal UE is called the Direct Discovery Set (DDS).

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

[0071] Potential security requirements for U2U relays may include protection of discovery messages during the UE-to-UE relay discovery process and privacy of sensitive information of the end UE. Security keys can be used to protect messages during transmission. Both the UE-to-UE relay and the end UE can be configured with security information associated with RSCs to properly exchange and process relay messages. However, only authorized end UEs can be configured with security information associated with a given ProSe restricted code.

[0072] The terms “security data,” “security key,” and “security key set” are used interchangeably herein to refer to one or more parameters used to protect or safeguard a message or part of a message. The terms “protected message” and “secure message” are used interchangeably herein to refer to a message protected / safeguarded with specific security data. The security data used for different messages may be different; therefore, they are referred to herein by using the association of security data with some or all of the information that the security data is protecting (e.g., security data associated with RSC).

[0073] Figure 4 An example of a relay message is shown, in which a single key set associated with the RSC is used to protect the message. The Message Integrity Code (MIC) 401 can be computed using an integrity key for message integrity protection. The portion of the message containing the UE-to-UE Relay Information ID 402 and the end UE information element 403 can be encrypted using a confidentiality key (here, the term "UE-to-UE Relay Information ID" refers to the UE-to-UE Relay user information ID). A UTC-based counter can be used in the integrity and confidentiality calculations to ensure the freshness of the protection and prevent replay attacks. The UTC-based counter used internally by the UE can be encoded as, for example, 32 most significant bits of the UTC time. Parameters sent by the notifying UE in the message can carry the four least significant bits (LSBs) 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] In one example, a single key set can be used to protect relay messages. When a single key set is associated with an RSC, a UE authorized to use the RSC can decrypt, tamper with, or replay any DDS transmitted using that RSC. For example, a first UE authorized to use a first ProSe service could eavesdrop on the contents of relay messages, including information from a second UE using a different ProSe service. This security issue can be mitigated by strengthening 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. This can be defined as part of the service deployment.

[0075] In another example, multiple key sets can be used to protect relay messages. For instance, each ProSe service has an associated ProSe restricted code and security information. In this case, each individual Direct Discovery Set (DDS) can be protected using its own separate security information (e.g., the security information associated with the ProSe restricted code). The security information associated with the RSC can be used to encrypt U2U relay discovery messages.

[0076] Figure 5 An example of a relay message is shown, in which multiple key sets associated with the RSC are used to protect the message. In this example, each DDS (e.g., set #1501 and set #2502) can be protected using a specific key set associated with its corresponding ProSe restricted code.

[0077] A single key set approach allows for simpler deployment options and less impact on existing discovery / provisioning processes. This may be sufficient when using a dedicated RSC, or when additional protection per ProSe service is not required (e.g., when used with ProSe services related to public safety). A multiple key set approach can provide additional flexibility in RSC / ProSe service deployment, configuration options, and means of mitigating the aforementioned potential security / privacy risks. This approach may be sufficient when RSC is used by multiple commercial ProSe services. The coexistence of these approaches may be desirable to support different deployment scenarios and varying security requirements.

[0078] When using a multiple key set approach, even if a U2U trunk may be relaying traffic associated with a given ProSe restricted code, for example, if the U2U trunk is not authorized to use the ProSe service associated with that ProSe restricted code, the key set associated with that ProSe restricted code may not be available in the U2U trunk.

[0079] U2U trunks supporting protected DDS can support multiple key set methods. Support for protected DDS in a U2U trunk can be configured in the information associated with the RSC, meaning it can be based on each RSC. This allows RSCs supporting a single key set to coexist with RSCs supporting multiple key sets (e.g., supporting protected DDS). The U2U trunk can use the configuration information associated with the RSC to determine whether protected DDS is supported for that RSC, and then use information from the end UE to determine whether the specific DDS of the end UE to be advertised requires supported protection.

[0080] The end UE can send a protected DDS to the U2U relay in the discovery message. The U2U relay supporting protected DDS can extract the protected DDS from messages received from the end UE and include it in the discovery announcement message sent by the U2U relay. Since multiple end UEs can send discovery messages with protected DDS to the U2E relay, the relay can extract each received protected DDS and transparently append / add each extracted protected DDS to the discovery announcement message sent by the U2U relay.

[0081] A terminal UE already connected to a relay may not retransmit discovery messages with protected DDSs to the relay, as they may not be needed after the relay is discovered, and multiple transmissions could increase overhead and impact the UE's battery life. The U2U relay can store received protected DDSs for later transmission in discovery announcement messages. However, due to UTC-based replay protection, protected DDSs may become invalid after a period of time, after which they may be invalidated when received by the monitoring UE. The relay may then be unable to access newly generated protected DDSs and may fail to properly announce the presence of the terminal UE when needed.

[0082] In one example, when a U2U trunk connected to an end UE decides to notify previously discovered or currently connected end UEs, the U2U trunk may request a protected DDS from these end UEs. The U2U trunk may determine that the ProSe service used by the end UE is protected by a DDS based on the ProSe restriction code stored in the PC5 link context. If a protected DDS received from a previously discovered or currently connected UE is stored, the U2U trunk may verify its validity. If the protected DDS is invalid (e.g., based on UTC-time), the U2U trunk may send a request to obtain an updated protected DDS from the previously discovered or currently connected UE.

[0083] The protected DDS request message can be a newly defined PC5 signaling (PC5-S) message, or it can enhance an existing PC5-S message to include DDS-related information. A U2U trunk can send a PC5-S request message (including a ProSe restriction code) to the end UE requesting a protected DDS. The U2U trunk can receive a PC5-S response message from the end UE, which includes the protected DDS corresponding to the ProSe restriction code. The U2U trunk can then send a U2U trunk discovery announcement message including the received protected DDS.

[0084] In one example, the 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 to the U2U relay including the updated protected DDS.

[0085] In one example, when a U2U relay slave UE receives information including a protected DDS, the U2U relay can send a message to the slave UE including a time value for the next announcement timing. Then, during the next announcement timing, the slave UE can send an updated protected DDS to the U2U relay.

[0086] In one example, a U2U relay may include discovery scheduling assistance information in its discovery announcement message. This information may include details about the timing of the announcement. This could be, for example, a time offset (from the current time) until the next notification. It may also include, for example, configurations for periodic announcement timing, including start time, end time, and the periodicity of such timing.

[0087] Each RSC can have more than one ProSe service (e.g., ProSe restricted code) associated with it. The user information ID assigned to the end UE is unique only on a per-ProSe service basis; that is, the same user information ID can be assigned to different end UEs using different services. Different services can be associated with the same RSC. Therefore, more than one IP address can be associated with the same user information ID. Since the relay stores the user information ID and IP address / prefix information in a table to respond to DNS queries, when the relay receives a DNS query message including the user information ID, it finds the user information ID in the table and sends back a DNS response message including the corresponding IP address / prefix information. In this case, there can be more than one entry in the table associated with the same user information ID. To identify user information IDs received from and associated with different end UEs when receiving DNS query messages, the U2U relay can also use the ProSe restricted code associated with the service in addition to the user information ID. In other words, each unique pair of ProSe restricted code and user information ID can have its own IP address / prefix information.

[0088] A terminal UE connected to a U2U trunk can probe the trunk to obtain the IP address / prefix information of other terminal UEs based on its potential terminal UE user information ID (e.g., using DNS queries). This provides a means for malicious terminal UEs to circumvent authorization for restricted discovery and the ability to track whether a specific terminal UE is connected to the U2U trunk. To mitigate this risk, it is desirable to ensure that IP address / prefix information is shared only with authorized terminal UEs. In other words, it is desirable to ensure that the U2U trunk shares the IP address / prefix information of terminal UE A with terminal UE B only if terminal UE B is authorized to use the same ProSe restricted code to perform restricted discovery with terminal UE A, wherein the same ProSe restricted code comes from a unique ProSe restricted code and user information ID pair associated with the IP address / prefix information of interest.

[0089] In one example, during the link establishment process, the U2U relay can receive a Direct Connection Request (DCR) message from the first-end UE, including an RSC and a first ProSe restricted code. The U2U relay can store the ProSe restricted code in the context associated with the first-end UE (PC5 link, DNS entry). The U2U relay can send a Direct Connection Accept (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 if the second-end UE is authorized to perform restricted discovery using the first ProSe restricted code, the U2U relay will only share the first-end UE's IP address / prefix information with the second-end UE.

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

[0091] Figure 6 An exemplary call flow is shown for the establishment of a direct link in a U2U trunk, which supports a model A U2U trunk discovery that uses multiple key sets and IP-shared privacy. The terminal UE can be provided with security information associated with RSC and DDS (601, 602) by the DDNMF, PCF, or PKMF. The DDS security information may include the ProSe restriction code and associated key information. The U2U relay can be provided with security information associated with RSC (603) by the PCF or PKMF. The U2U relay and terminal UE can be configured with an indicator associated with RSC indicating whether the RSC supports protected DDS. This indicator can also indicate whether the use of protected DDS is mandatory for the RSC, for example, whether the RSC can operate without protected DDS.

[0092] The end UE can send a Direct Connection Request (DCR) message to the U2U trunk, including an RSC, the end UE user information ID, and a ProSe restriction code 604. The end UE can provide an indication of DDS protection. The end UE can provide the validity period value of the ProSe restriction code (e.g., based on the corresponding validity period value configured in the PCF / DDNMF within the end UE). The ProSe restriction code can be used by the U2U trunk to determine whether a particular end UE is protected by IP shared privacy and / or to enable the elimination of ambiguity in the end UE user information ID (when multiple entries exist).

[0093] Parameters in the DCR message (such as RSC, end UE user information ID, and ProSe restricted code) can be protected using security information associated with the RSC (e.g., for confidentiality, integrity, and replay protection). An indication supporting a protected DDS can be provided instead of the ProSe restricted code. This indication can be provided to avoid exposing specific ProSe restricted codes and / or unauthorized links between ProSe restricted codes and end UE user information IDs (e.g., if the identifier parameter is not confidentially protected in the DCR message). This indication can be used by the U2U relay to determine if the end UE can have at least one protected direct discovery set that will be announced by the U2U relay.

[0094] Upon receiving a DCR message that includes a ProSe restricted code / indication for DDS protection, a U2U trunk can verify whether the RSC supports the protected DDS 605 based on the aforementioned indicator.

[0095] The U2U relay and the end UE can establish the security of the PC5 link 606. The U2U relay can store the ProSe restricted code / indication for DDS protection together with the end UE user information ID in the PC5 link context 607. The U2U relay can send a Direct Connection Acceptance (DCA) message 608 to the end UE, which includes a time value for the U2U relay to announce the next opportunity for the protected DDS from the end UE.

[0096] Figure 7 An exemplary call flow is shown for the U2U trunk direct link modification process, which supports AU2U trunk discovery using multiple key sets and IP shared privacy.

[0097] The end UE may have a link established with U2U trunk 701. The end UE may send a Link Modification Request (LMR) message (including a ProSe restricted code) to U2U trunk 702 (e.g., to add another ProSe service for reusing an existing link, or, if an indication instead of a ProSe restricted code was provided during link establishment, to securely provide the ProSe restricted code without sending it in the DCR). As described above for the DCR case, the end UE may provide an indication of DDS protection and an validity period value. The provided ProSe restricted code can be used by the U2U trunk to determine whether a particular end UE is protected by IP shared privacy and / or to resolve ambiguity in the end UE's user information ID (when multiple entries exist).

[0098] LMR can be initiated by the terminal UE to activate DDS protection for the terminal UE and / or for a specific ProSe service protected by DDS (e.g., an existing ProSe service over a PC5 link is not DDS protected, and the terminal UE wants to activate it). LMR can also be initiated by the terminal UE to revoke a ProSe restricted code after a discovery update procedure, where the DDNMF revokes a previously assigned ProSe restricted code. In this case, an indication for revoking the ProSe restricted code may be included. If the DDNMF assigns a new code to the terminal UE to replace the old code, the LMR may include the old and new ProSe restricted code values, and a new validity period parameter.

[0099] Upon receiving a DCR message that includes a ProSe restricted code / indication for DDS protection, a U2U trunk can verify that the RSC supports protected DDS 703 based on the associated indicator.

[0100] The U2U trunk can store the ProSe restricted code / indicator used for DDS protection along with existing end-UE information in the PC5 link context 704. Optionally, the U2U trunk can remove or replace the ProSe restricted code if it is to be revoked or replaced (as described above). If all end-UE ProSe restricted codes (one or more) are removed and no other ProSe services are left for use, the U2U trunk can decide to release the direct link.

[0101] The U2U relay may send a Link Modification Acceptance (LMA) message 705 to the end UE, which includes a notification time value for the next opportunity for the U2U relay to notify the end UE of the protected DDS (e.g., if DDS protection against ProSe service used on that link has been activated). If the U2U relay revokes the last ProSe restriction code for the end UE, the U2U relay may include an indication to cancel any pending protected DDS timers.

[0102] U2U trunks can also invalidate stored ProSe restricted codes when the corresponding validity timer expires. If all end UE ProSe restricted codes have expired and no other ProSe services remain in use, the U2U trunk can decide to release the direct link with the end UEs.

[0103] Figure 8 An exemplary call flow for a U2U trunk DNS query employing IP shared privacy is shown.

[0104] End UE 1 can perform a direct link establishment procedure 801 with the U2U trunk. End UE 2 may (e.g., using a direct link establishment procedure) have already established a secure connection with the U2U trunk 802.

[0105] The U2U relay can receive a DNS query 803 from the end UE 2. The DNS query includes the end UE 1 user information ID and the ProSe restricted code used to discover the end UE 1.

[0106] The U2U relay can verify the existence of an entry 804 for the user information ID and received ProSe restriction code for UE 1. Multiple entries can exist for the same user information ID. The ProSe restriction code is used to select a specific entry (i.e., to retrieve a unique ProSe restriction code and user information ID pair). The validity timer for verifying the ProSe restriction code by the U2U relay has not expired. If the previous verification was successful, the U2U relay can send a DNS response 805 to UE 2, which includes the IP address / prefix information of UE 1.

[0107] Figure 9An exemplary call flow is shown for a U2U trunk discovery process initiated by a U2U trunk using multiple key sets.

[0108] UE 1 can perform a direct link establishment procedure 901 with the U2U relay. The U2U relay can decide to advertise connected or discovered UEs 902.

[0109] For each of the ProSe restricted codes stored for UE 1, the U2U relay may send a PC5 signaling message (PC5-S) request message (including the ProSe restricted code previously received from 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 enhanced to include the required new information; for example, a keep-alive message may be reused for a request for a protected DDS associated with a ProSe restricted code.

[0110] In one example, a U2U relay may send a PC5-S request message, which includes an indication requesting all applicable protected DDSs for all services (e.g., UE 1 is using several different ProSe services, which are protected by ProSe). In another example, a U2U relay may send a list of ProSe restricted codes.

[0111] End UE 1 can generate a secure PC5-S response message (e.g., a keep-alive message) that includes RSC and DDS 904 protected using Direct Discovery Security Data. End UE 1 can include one or more DDSs in the response message (e.g., if a list of ProSe restricted codes is requested). End UE 1 can use the PC5 link security context to protect the PC5-S message and send it to the U2U trunk.

[0112] U2U relays can handle PC5-S response message security and extract protected DDS. U2U relays can verify that the ProSe restricted code from the received protected DDS is valid (e.g., verifying that the validity timer has not expired based on the validity time value). U2U relays can send a U2U relay protected discovery message, including the RSC, U2U relay user information ID, and the protected DDS received from end UE 1, to end UE 2 905. U2U relays can protect the U2U relay discovery message with security data associated with the RSC.

[0113] Figure 10 An exemplary call flow is shown for a Model A U2U trunk discovery process initiated by an end UE using multiple key sets.

[0114] End UE 1 can perform a direct link establishment procedure 1001 with the U2U trunk. End UE 1 can decide to provide one or more protected DDS 1002 to the U2U trunk. This can be triggered based on the announcement time value provided by the U2U trunk as described above (e.g., in DCA or LMA).

[0115] End UE 1 can generate a U2U trunk discovery announcement message 1003, which includes an RSC, a U2U trunk user information ID, and one or more DDSs. Each U2U trunk discovery announcement message is protected using security information associated with its respective DDS. End UE 1 can use the security information associated with the RSC to protect the U2U trunk discovery message and send it to the U2U trunk. The destination L2ID can be set to the U2U trunk L2 ID discovered by end UE 1, or the default L2 ID of the traditional configuration can be used.

[0116] Optionally 1004, UE 1 can generate a secure PC5-S (unicast) request message (e.g., a keep-alive request message or a new PC5-S message can be defined), which includes an RSC and one or more DDSs. Each PC5-S request message is protected using security information associated with its respective DDS. UE 1 can use the PC5 link security context to protect the PC5-S message and send it to the U2U trunk.

[0117] U2U relay can handle U2U relay discovery / PC5-S request message security and extract the included protected DDS 1005.

[0118] The U2U relay can verify that the RSC supports the protected DDS and that the ProSe restricted code from the received protected DDS 1006 is valid. The U2U relay can verify that each received code matches the ProSe restricted code stored for terminal UE 1 and that it has not expired (e.g., based on the validity time value as described above).

[0119] In the case of replacing PC5S message 1004, the U2U relay can send a secure PC5-S response message (e.g., keep-alive response message, or a new PC5-S may be defined) to end UE 1, which includes the response status (e.g., success or failure) for announcing 1007. The response may include the relevant ProSe restriction code (one or more).

[0120] U2U trunks can send a U2U trunk protected discovery message, including the RSC, U2U trunk user information ID, and protected DDS received from end UE 1, to end UE 2 1008. U2U trunks can protect the U2U trunk discovery message with security data associated with the RSC.

[0121] Figure 11 An exemplary call flow is shown for a U2U trunk discovery process initiated by a U2U trunk using a delayed notification from the discovered UE.

[0122] End UE 1 may decide to send a discovery announcement message 1101 to the U2U relay. The end UE may monitor previous discovery announcement messages sent by the U2U relay to determine the timing of the U2U relay's next scheduling announcement. For example, the U2U relay may include discovery scheduling assistance information in the discovery announcement message to notify neighboring end UEs of the U2U relay's next announcement timing (e.g., expressed as a time offset / window relative to the current time or the discovery message transmission time). The end UE can use this information to schedule / synchronize its own discovery message transmissions to the relay in a timely manner, allowing the relay to include a protected DDS from the end UE in its next relay announcement message (e.g., near real-time, before the U2U relay's next transmission).

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

[0124] U2U trunks can process U2U trunk discovery / PC5-S request messages and extract protected DDS and validity time values ​​1103. U2U trunks can verify that RSC supports protected DDS.

[0125] U2U relays can schedule the next announcement for the protected DDS of end UE based on their own next scheduling announcement timing (e.g., implementation-based), and can take into account the received validity time value 1104. For example, if the time difference between the next scheduling announcement timings is greater than the validity time value (or if no validity time value is provided), the U2U relay can decide to immediately send the protected DDS of end UE 1 (or discard the current end UE 1 discovery message until a more appropriate / aligned relay announcement timing).

[0126] U2U relays can send a U2U relay protected discovery message 1105, which includes an RSC, the U2U relay user information ID, and the protected DDS received from UE 1 at the scheduling time. U2U relays can protect the U2U relay discovery message with the security data associated with the RSC.

[0127] In one example, the U2U trunk can be configured with security information associated with the RSC, and the end UE can be configured with security information associated with both the RSC and the DDS. The security information associated with the DDS can be associated with a ProSe restricted code. The U2U trunk and the end UE can be configured with an indicator associated with the RSC that indicates whether the RSC supports protected DDS.

[0128] In one example, a U2U relay can send a request message for a protected DDS to a connected end UE. 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. This message may also include a message type, the ProSe restriction code associated with the DDS, a UTC-based counter, a MIC, and the protected end UE information ID. In another example, the end UE can send a U2U relay discovery message including a protected DDS. The U2U relay can send a discovery announcement including the received protected DDS.

[0129] Although the features and elements have been 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. Furthermore, 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, 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-ROMs and digital multifunction discs (DVDs). The processor associated with the software can be used to implement a radio frequency transceiver used in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method implemented by a wireless transmit / receive unit (WTRU) acting as a user equipment (UE) to UE relay operation, the method comprising: A first message is received from a first-end UE, the first message including a first protected direct discovery set (DDS), wherein the first DDS includes at least the user information identifier (user information ID) of the first-end UE and the first protected DDS is protected with first security data associated with a first proximity service (ProSe) service; The second message is received from the second UE, the second message including a second protected direct discovery set (DDS), wherein the second protected DDS includes at least the second user information ID of the second UE and is protected by second security information associated with the second proximity service (ProSe) service; as well as The third broadcast message included: The third message includes the first protected DDS, the second protected DDS, and a relay service code (RSC) associated with the relay connectivity service provided by the WTRU; and The third message is protected using third security data associated with the RSC.

2. The method according to claim 1, wherein the first UE is configured with the first security data and the second UE is configured with the second security data.

3. The method according to claim 1, wherein the WTRU, the first end UE, and the second end UE are configured with the third security information.

4. The method of claim 1, further comprising, at the WTRU, verifying, based on a configured indication, that the relay connectivity service provided by the WTRU supports relay operation using a protected DDS.

5. The method of claim 4, wherein the configuration is configured by the network using RRC signaling.

6. The method of claim 4, wherein an indication of the configuration is provided in advance in the WTRU.

7. A wireless transmit / receive unit (WTRU) configured to implement UE-to-UE relay functionality, the WTRU comprising at least one processor and a transceiver, wherein the at least one processor and transceiver are configured to: A first message is received from a first-end UE, the first message including a first protected direct discovery set (DDS), wherein the first DDS includes at least the user information identifier (user information ID) of the first-end UE and the first protected DDS is protected with first security data associated with a first proximity service (ProSe) service; The second message is received from the second UE, the second message including a second protected direct discovery set (DDS), wherein the second protected DDS includes at least the second user information ID of the second UE and is protected by second security information associated with the second proximity service (ProSe) service; as well as The third broadcast message included: The third message includes the first protected DDS, the second protected DDS, and a relay service code (RSC) associated with the relay connectivity service provided by the WTRU; and The third message is protected using third security data associated with the RSC.

8. The WTRU of claim 7, wherein the first UE is configured with the first security data and the second UE is configured with the second security data.

9. The WTRU of claim 7, wherein the WTRU, the first end UE, and the second end UE are configured with the third security information.

10. The WTRU of claim 7, wherein the at least one processor and transceiver are further configured to verify, based on configuration indications, that the relay connectivity service provided by the WTRU supports relay operation using a protected DDS.

11. The WTRU of claim 10, wherein the configuration is configured by the network using RRC signaling.

12. The WTRU of claim 10, wherein an indication of the configuration is provided in advance in the WTRU.

Images