System and method for supporting security in sidelink communications and positioning

Abstract

Techniques for supporting secure sidelink communication and secure sidelink positioning of user devices (UEs) are described. A server may configure each UE using a secret encryption key, a random value, and a derived encryption key. Two UEs may exchange their random values, and each may use its secret encryption key and the received random value to determine the derived encryption key already configured in the other UE. Here, two derived encryption keys known to both UEs can enable secure communication and positioning. In a degenerate case, a type B UE is configured using a derived encryption key, which can be determined by a type A UE configured using a random value and a secret encryption key. This technique can be extended to secure communication and positioning for groups of UEs.

Description

[Technical Field]

[0001] 1. Cross-reference of related applications This application claims the benefit of U.S. Patent Provisional Application No. 63 / 488,963, filed on March 7, 2023, entitled "SECURITY FOR SIDELINK POSITIONING," and of the application filed on March 6, 2024, entitled "SYSTEMS AND METHODS FOR SUPPORT OF SECURITY FOR SIDELINK COMMUNICATION AND POSITIONING." This invention claims the interests of U.S. Patent Application No. 18 / 597,512, both of which are incorporated herein by reference in their entirety.

[0002] 2. Areas of Disclosure This disclosure generally relates to the field of wireless communications, and more specifically to secure communications and positioning for one or more user devices (UEs) using sidelink signaling.

[0003] 3. Explanation of related technologies Wireless communication systems are widely deployed to provide a variety of telecommunications services, including telephone communication, video, data, messaging, positioning, and broadcasting. Typical wireless communication systems can utilize multiple access technologies that enable communication with multiple users by sharing available system resources (e.g., bandwidth, transmit power). Examples of such multiple access systems include fourth-generation (4G) systems such as Long-Term Evolution (LTE) systems, LTE-A systems, or LTE-A Pro systems, and fifth-generation (5G) systems, sometimes referred to as New Radio (NR) systems.

[0004] In mobile / cellular broadband networks, a receiving UE is used to receive radio frequency (RF) signals for positioning. In some cases, these RF signals, or "reference signals," are transmitted from other UEs using sidelink (SL) communication. The transmission and measurement of reference signals, as well as coordination and control for the measurement of other signals, may also be transmitted using SL signaling. Messages and signaling used for coordination and control may be susceptible to interception and / or impersonation by unauthorized entities. Therefore, means of securely protecting against such interception and / or impersonation may be desirable. [Overview of the project] [Means for solving the problem]

[0005] Techniques for supporting secure sidelink communication and secure sidelink positioning of user devices (UEs) are described. A server may configure each UE using a secret encryption key, a random value, and a derived encryption key. Two UEs may exchange their random values, and each may use its secret encryption key and the received random value to determine the derived encryption key already configured in the other UE. Here, two derived encryption keys known to both UEs can enable secure communication and positioning. In a degenerate case, a type B UE is configured using a derived encryption key, which can be determined by a type A UE configured using a random value and a secret encryption key. This technique can be extended to secure communication and positioning for groups of UEs.

[0006] An exemplary method for enabling secure sidelink communication between groups of user devices (UEs), performed by a server, the method may include determining a set of private encryption keys PK and a corresponding set of encryption key IDs Kid. The method may also include determining a random or partially random value RV for each UE in the group of UEs. The method may further include determining a set of derived encryption keys DK for each UE in the group of UEs based on the random or partially random value RV and the set of private encryption keys PK for each UE, and securely configuring each UE in the group of UEs using the random or partially random value RV for each UE, the set of derived encryption keys DK for each UE, one private encryption key from the set of private encryption keys PK, and one encryption key ID from the corresponding set of encryption key IDs Kid, where one encryption key ID corresponds to one private encryption key.

[0007] An exemplary method for supporting secure sidelink communication between groups of user devices (UEs), performed by a first UE of a group of UEs, the method may include securely receiving from a server a first random or partially random value RV1, a first set of derived cryptographic keys DK1, a first secret cryptographic key K1 of a set of secret cryptographic keys PK, and a first cryptographic key ID K1id, wherein the first cryptographic key ID K1id identifies the first secret cryptographic key K1; and transmitting the first random or partially random value RV1 and the first cryptographic key ID K1id in plain text to a second UE of the group of UEs. The method may also include receiving in plaintext a second random or partially random value RV2 and a second cryptographic key ID K2id from a second UE in a group of UEs, wherein the second cryptographic key ID K2id identifies the second secret cryptographic key K2 of a set of secret cryptographic keys PK configured in the second UE; determining at least one common cryptographic key based on a first set of derived cryptographic keys DK1, the first secret cryptographic key K1, the second random or partially random value RV2, and the second cryptographic key ID K2id; and supporting secure sidelink communication with the second UE based on at least one common cryptographic key.

[0008] An exemplary device for enabling secure sidelink communication between groups of user devices (UEs), the device comprising means for determining a set of private encryption keys PK and a corresponding set of encryption key IDs Kid; means for determining a random or partially random value RV for each UE in the group of UEs; means for determining a set of derived encryption keys DK for each UE in the group of UEs based on the random or partially random value RV and the set of private encryption keys PK for each UE; and means for securely configuring each UE in the group of UEs using the random or partially random value RV for each UE, the set of derived encryption key DKs for each UE, one private encryption key from the set of private encryption keys PK, and one encryption key ID from the corresponding set of encryption key IDs Kid, wherein one encryption key ID corresponds to one private encryption key.

[0009] An exemplary device for supporting secure sidelink communication between groups of user devices (UEs), performed by a first UE of a group of UEs, the device comprising means for securely receiving from a server a first random or partially random value RV1, a first set of derived cryptographic keys DK1, a first secret cryptographic key K1 of a set of secret cryptographic keys PK, and a first cryptographic key ID K1id, wherein the first cryptographic key ID K1id identifies the first secret cryptographic key K1; means for transmitting the first random or partially random value RV1 and the first cryptographic key ID K1id in plain text to a second UE of the group of UEs; and from the second UE of the group of UEs a second random or partially random value RV2 and a second cryptographic key ID K2id, wherein the second cryptographic key ID K2id identifies the second secret cryptographic key K2 of a set of secret cryptographic keys PK configured in the second UE. The system may include means for receiving a K2id in plain text, means for determining at least one common encryption key based on a first set of derived encryption keys DK1, a first secret encryption key K1, a second random or partially random value RV2, and a second encryption key ID K2id, and means for supporting secure sidelink communication with a second UE based on at least one common encryption key.

[0010] This summary is not intended to identify any major or essential features of the claimed subject matter, nor is it intended to be used alone to determine the scope of the claimed subject matter. The subject matter should be understood by referring to the entire specification of this disclosure, any or all of the drawings, and the appropriate parts of each claim. The above, along with other features and examples, is described in more detail below in the specification, claims, and accompanying drawings. [Brief explanation of the drawing]

[0011] [Figure 1] This diagram shows the architecture of a communication system, including several UEs, a Radio Access Network (RAN), and a 5G Core Network (5GC). [Figure 2] This diagram shows the architecture of the communication system for sidelink positioning. [Figure 3] This is a signal flow showing the signaling between the UE and the location server for side-link positioning supported by the network. [Figure 4] This block diagram shows one implementation of the structure of a sidelink positioning protocol message. [Figure 5] This is a block diagram showing one implementation of secure side-link communication according to one embodiment. [Figure 6] This is a signaling flow diagram illustrating how secure sidelink communication can be performed according to one embodiment. [Figure 7A] This is a signaling flow diagram illustrating how secure sidelink communication can be performed for a pair of UEs according to one embodiment. [Figure 7B] This is a signaling flow diagram illustrating how secure sidelink communication can be performed for a pair of UEs according to one embodiment. [Figure 8]This is a signaling flow diagram illustrating how secure sidelink communication can be performed for a group of UEs according to one embodiment. [Figure 9] This is a flowchart of a secure sidelink communication method executed by a server, according to one embodiment. [Figure 10] This is a flowchart of a method for secure sidelink communication performed by a UE, according to one embodiment. [Figure 11] This is a flowchart of a method for secure sidelink communication performed by a UE, according to one embodiment. [Figure 12] This is a block diagram of one embodiment of the UE that may be used in the embodiments described herein. [Figure 13] This is a block diagram of one embodiment of a computer system that may be used in the embodiments described herein. [Figure 14] This is a flowchart illustrating a method, according to one embodiment, for enabling secure sidelink communication between a first UE and a second UE, which is performed by a server. [Figure 15] This is a flowchart of a method for secure communication between a first UE and a second UE, as performed by a first UE, according to one embodiment. [Figure 16] This is a flowchart of a method for secure sidelink communication between a first UE and a second UE, as performed by a second UE, according to one embodiment. [Figure 17] This is a flowchart illustrating a method, according to one embodiment, for enabling secure sidelink communication between groups of UEs, executed by a server. [Figure 18] This is a flowchart illustrating a method for supporting secure sidelink communication between groups of UEs, performed by a first UE in a group of UEs, according to one embodiment.

[0012] In some exemplary implementations, similar reference numerals in various drawings refer to the same element. In addition, multiple instances of an element may be indicated by following the first digit of the element with a letter or hyphen and a second digit. For example, multiple instances of element 110 may be indicated as 110-1, 110-2, 110-3, etc., or as 110a, 110b, 110c, etc. When such an element is referred to using only the first digit, it should be understood to be any instance of that element (for example, element 110 in the previous example refers to elements 110-1, 110-2, and 110-3, or elements 110a, 110b, and 110c). [Modes for carrying out the invention]

[0013] Techniques and apparatus for supporting secure communication and positioning of UEs using sidelink signaling are described herein. The following description covers several implementations for the purpose of illustrating inventive aspects of various embodiments. However, it will be readily apparent to those skilled in the art that the teachings herein can be applied in numerous different ways. The implementations described include the Institute of Electrical and Electronics Engineers (IEEE) 802.15.4 standard for ultra-wideband (UWB), the IEEE 802.11 standard (including those identified as Wi-Fi® technology), the Bluetooth® standard, code division multiple access (CDMA), frequency division multiple access (FDMA), time division multiple access (TDMA), Global System for Mobile communications (GSM), General Packet Radio Service (GPRS), Enhanced Data GSM Environment (EDGE), Terrestrial Trunked Radio (TETRA), Wideband-CDMA (W-CDMA®), and Evolution Data Optimized (Evolution Data) technologies. Optimized (EV-DO), 1xEV-DO, EV-DO Rev A, EV-DO Rev B, High Rate Packet Data (HRPD), High Speed ​​Packet Access (HSPA), High Speed ​​Downlink Packet Access (HSDPA), High Speed ​​Uplink Packet Access (HSDPA)This can be implemented in any device, system, or network capable of transmitting and receiving radio frequency (RF) signals of any communication standard, such as Access (HSUPA), Evolved High Speed ​​Packet Access (HSPA+), Long Term Evolution (LTE), New Radio (NR), or Advanced Mobile Phone System (AMPS), or other known signals used for communication in wireless, cellular, or Internet of Things (IoT) networks, such as systems utilizing 3G, 4G, 5G, 6G technologies, or further implementations thereof.

[0014] As used herein, “RF signals” include electromagnetic waves that transport information through the space between a transmitter (or transmitting device) and a receiver (or receiving device). A transmitter used herein may transmit a single “RF signal” or multiple “RF signals” to a receiver. However, due to the propagation characteristics of RF signals through multiple channels or paths, a receiver may receive multiple “RF signals” corresponding to each transmitted RF signal.

[0015] In addition, unless otherwise specified, references to “reference signal,” “positioning reference signal,” and “reference signal for positioning” may be used to refer to signals used for positioning a user device (UE). As will be described in more detail herein, such signals may include any of various signal types, but are not necessarily limited to positioning reference signals (PRS) as defined in the relevant wireless standards.

[0016] Furthermore, unless otherwise specified, the term “positioning” as used herein may refer to absolute location determination, relative location determination, distance measurement, or a combination thereof. Such positioning may include and / or be based on timing, angle, phase, or power measurements, or a combination thereof (including RF sensing measurements), for the purpose of location services or sensing services.

[0017] The field of vehicle-to-everything (V2X) communication is rapidly expanding, with an increasing number of connected vehicles and infrastructure components communicating with each other. Sidelink positioning of a UE is supported by sending and receiving sidelink positioning messages from one or more UEs, including each UE's sidelink positioning capability and sidelink positioning resources, and by exchanging additional sidelink positioning messages used to determine location based on the sidelink positioning capability and sidelink positioning resources for each UE. In some embodiments, a UE may be associated with a vehicle and may be used to position the vehicle.

[0018] Sidelink positioning protocols can be used to support various forms of positioning, such as pairwise positioning, group operation, and network-supported sidelink positioning. For example, sidelink positioning can be achieved by sending sidelink positioning messages between UEs and / or between UEs and one or more location servers, according to the Sidelink Positioning Protocol (SLPP), Long-Term Evolution (LTE) Positioning Protocol (LPP), Secure User Plane Location (SUPL), or some combination of these protocols.

[0019] When using side-link positioning protocols, security concerns regarding side-link communications may exist. For example, in the case of V2X, even if robust security solutions are in place, an attacker owning a vehicle associated with a V2X UE could potentially hack the V2X UE's mobile device components (e.g., a V2X UE without a subscriber identification module (SIM) card) to obtain or impersonate the location data of other vehicles. Furthermore, location data can also be collected visually, such as through photographs and videos, and through vehicle license plate information (e.g., which could be used to identify specific vehicles and their users). Consequently, it may be important to implement appropriate safeguards to address these security concerns and ensure the privacy and security of V2X communications and location data.

[0020] While Sidelink positioning protocol location data can sometimes be less sensitive and may not require the same level of protection as other types of V2X communication data, there can still be significant benefits in supporting security for Sidelink positioning protocol and V2X communication. Firstly, implementing security measures for V2X, for example, can enable more secure transfer of other sensitive data such as driver-to-driver messages, user and vehicle global identification, vehicle and vehicle load descriptions, and / or planned vehicle routes. Furthermore, supporting security can improve the overall integrity of V2X communication by making it more difficult for attackers to inject false Sidelink positioning protocol location data or other misleading information into Sidelink positioning protocol sessions or other V2X sessions. As a result, supporting security can increase the reliability of Sidelink positioning protocol location data compared to scenarios where security measures are not implemented. Therefore, it may be beneficial to develop technical solutions to enhance the security of V2X communication and the Sidelink positioning protocol.

[0021] While V2X is frequently used herein as an example of a side-link communication and positioning application, it should be noted that the techniques described herein for supporting secure side-link communication and positioning may also be used for other applications such as IIoT or UEs communicating in peer-to-peer mode.

[0022] Current security solutions in V2X communication, such as public-key / certificate-based authentication / encryption and symmetric-key-based authentication / encryption between UEs, have limitations when applied to secure side-link positioning protocols. For example, public-key / certificate-based authentication / encryption can enable authentication of roadside units (RSUs) and special UEs (e.g., UEs associated with vehicles such as buses, trucks, and taxis) without relying on network support or SIM cards. However, this method can have several drawbacks, including the inability to authenticate other normal UEs (e.g., UEs associated with vehicles other than those special vehicles), high processing / latency requirements, scalability issues, reliance on persistent secret keys in RSUs and special UEs that can be insecure, and support for unicast side-link signaling but not for groupcast side-link signaling. These limitations may make the method less suitable for securing V2X communication and / or side-link positioning protocols.

[0023] On the other hand, a common secret key-based solution may offer several advantages, such as supporting authentication / encryption for all UEs, enabling groupcast / broadcast sidelink signaling, and reducing processing / latency compared to public / private keys. This type of solution may also be network or SIM card independent. However, there is a risk that a malicious UE could impersonate an authorized UE and obtain the key. This could lead to a legitimate UE unintentionally allowing an attacker to access key information, which could make a common secret key-based solution less suitable for protecting V2X communications and / or sidelink positioning protocols.

[0024] Various aspects of this specification generally relate to the field of wireless communications. Some aspects more specifically relate to secure sidelink communications for UE positioning. In some examples, UEs may be divided into two types, referred to herein as “Type A” and “Type B,” as will be described later herein. When performing secure sidelink communications, a server may provide a first set of key information to a Type B UE and a second set of key information to a Type A UE. A Type B UE may share / transmit with a Type A UE a portion of the first set of key information received from the server for encryption / authentication. A Type A UE may perform encryption / authentication with a Type B UE based on the second set of key information received from the server and a portion of the first set of key information received from a Type B UE. Based on the encryption / authentication (for example, both a Type B UE and a Type A UE each determine a common encryption key), a Type B UE and a Type A UE may perform sidelink communications in secure mode.

[0025] The technical solutions disclosed herein address the aforementioned challenges and limitations of existing solutions by providing a security solution that supports all coverage scenarios, authenticates UEs, encrypts all sidelink positioning messages and potentially other V2X messages, has low latency for authentication and encryption operations, has high capacity with scalability to potentially support thousands of UEs in a small area, and can prevent critical security key data from being obtained by attackers.

[0026] This description may refer, for example, to a sequence of actions to be performed by elements of a computing device. The various actions described herein may be performed by a specific circuit (e.g., an application-specific integrated circuit, ASIC), by program instructions being executed by one or more processors, or a combination of both. The sequence of actions described herein may be embodied in a non-temporary computer-readable medium that stores thereon the corresponding set of computer instructions that, at runtime, cause the relevant processors to perform the functions described herein. Thus, the various embodiments described herein may be embodied in several different forms, all of which fall within the scope of this disclosure, including the claimed subject matter.

[0027] As used herein, the terms “user equipment” (UE) and “base station” are not specific to any particular Radio Access Technology (RAT), and are not otherwise limited to such RATs, unless otherwise stated. Generally, such a UE may be any wireless communication device (e.g., a mobile phone, router, tablet computer, laptop computer, tracking device, Internet of Things (IoT) device, Industrial IoT (IIoT), in-vehicle UE, drone or aircraft UE) used to communicate over a wireless communication network and / or using side-link signaling. A UE may be mobile or (e.g., stationary at a given time) and may communicate with a Radio Access Network (RAN). For example, as used herein, a UE may be an infrastructure node such as an RSU, Positioning Reference Unit (PRU), etc. As used herein, the term "UE" may be interchangeably referred to as "Access Terminal" or "AT," "Mobile Device," "Client Device," "Wireless Device," "Subscriber Device," "Subscriber Terminal," "Subscriber Station," "User Terminal" or "UT," "Mobile Terminal," "Mobile Station," RSU, PRU, or variations thereof. Generally, a UE can communicate with the core network via the RAN, and through the core network, a UE may be connected to external networks such as the Internet and to other UEs. Of course, other mechanisms for connecting to the core network and / or the Internet are also possible for a UE, such as via a wired access network, a Wi-Fi network (e.g., based on IEEE 802.11), etc.

[0028] A base station may operate according to one of several RATs during communication with the UE, depending on the network in which it is deployed, and may be alternatively referred to as an access point (AP), network node, node B, advanced node B (eNB), general node B, g-node B (gNB), etc. In addition, in some systems, a base station may simply provide edge node signaling functionality, while in other systems, a base station may provide additional control and / or network management functionality.

[0029] A UE can be embodied by any of several types of devices, including, but not limited to, printed circuit (PC) cards, CompactFlash® devices, external or internal modems, wireless or wireline telephones, smartphones, tablets, tracking devices, and asset tags. A communication link from which a UE can send signals to a RAN is called an uplink channel (e.g., a reverse traffic channel, a reverse control channel, an access channel, etc.). A communication link from which a RAN can send signals to a UE is called a downlink channel or forward link channel (e.g., a paging channel, a control channel, a broadcast channel, a forward traffic channel, etc.). A communication link from which a UE can send signals to another UE is called a sidelink channel. As used herein, the term traffic channel (TCH) may refer to either an uplink / reverse traffic channel or a downlink / forward or sidelink traffic channel.

[0030] As used herein, the terms “cell” or “sector” may, depending on the context, refer to one of several cells of a base station or the base station itself. The term “cell” may refer to a logical communication entity used for communication with a base station (e.g., via a carrier) and may be associated with an identifier (e.g., a physical cell identifier (PCID), a virtual cell identifier (VCID)) to distinguish adjacent cells operating via the same or different carriers. In some examples, a carrier may support multiple cells, and different cells may be configured according to different protocol types (e.g., machine-type communication (MTC), narrowband Internet of Things (NB-IoT), enhanced mobile broadband (eMBB), or others) that may provide access to different types of devices. In some examples, the term “cell” may refer to a portion of the geographical coverage area (e.g., a sector) on which a logical entity operates.

[0031] Standardization of cellular systems, such as Fifth Generation (5G) or New Radio (NR) network systems, is underway in the 3rd Generation Partnership Project (3GPP®). For example, standardized RAT-dependent positioning systems include downlink (DL) positioning such as Enhanced Cell ID (E-CID) (using Received Signal Strength (RSS) and Round-Trip Time (RTT), and optionally using Angle of Arrival (AoA)), Observed Time Difference of Arrival (OTDOA), and Downlink Time Difference of Arrival (DL-TDOA), and uplink (UL) positioning such as Uplink Time Difference of Arrival (UL-TDOA) and Uplink Angle of Arrival (UL-AoA). Standardized RAT-independent positioning systems include Assisted Global Navigation Satellite Systems (A-GNSS) and other technologies such as Wireless Local Area Networks (WLAN), Bluetooth®, Terrestrial Beason Systems (TBS), and sensor-based positioning including barometric pressure sensors and motion sensors. In addition, hybrid positioning is standardized, including the use of multiple methods for positioning, such as A-GNSS+OTDOA hybrid positioning.

[0032] Standardization of Sidelink (SL) positioning (SLP) requires new solutions to define various aspects. For example, SLP standardization may require defining an SLP protocol (SLPP) to be used between UEs and between RSUs and UEs. Note that SLPP messages are also referred to herein as Sidelink positioning messages. In addition, it may be necessary to define support by location servers, such as location management functions (LMFs) and Secure User Plane Location (SUPL) location platforms (SUPL SLPs). Note that the term SLP is used herein for Sidelink positioning, and the term SUPL SLP is used herein for SUPL location platforms. Standardization of SL positioning may further require defining means to optimize SL group formation and modification for V2X (e.g., V2P (Vehicle-to-Pedestrian), V2I (Vehicle-to-Infrastructure), V2V (Vehicle-to-Vehicle)) to ensure that vehicles within an SL group are generally moving in the same direction and are close to one another. In addition, standardization of SL positioning may further require defining preferred procedures and message types for SLPP to enable the later addition of new positioning methods and new access types, as well as network or relay support for UEs that cannot directly exchange SL signaling.

[0033] Figure 1 shows an example of a communications system 100 including a first UE105A, a second UE105B, a radio access network (RAN) 135, here referred to as a fifth-generation (5G) next-generation (NG) RAN (NG-RAN), and a 5G core network (5GC) 140. The 5GC 140 and NG-RAN 135 may comprise, for example, a public land mobile network (PLMN). UE105A and UE105B may be referred to individually or collectively as UE105 in this specification. UE105 may be, for example, an IoT device, a location tracking device, a cellular phone, an in-vehicle UE, an on-board unit (OBU), or other similar type of device. UE105 may also be considered to function as an RSU or PRU. 5G networks are sometimes called New Radio (NR) networks, NG-RAN135 may be called 5G RAN or NR RAN, and 5GC140 may be called NG Core network (NGC). RAN135 may be another type of RAN, such as 3G RAN or 4G Long-Term Evolution (LTE) RAN. UE105B may be configured to transmit and / or receive signals to and from other similar entities in the communication system 100 and may be coupled to UE105A as well.The communication system 100 may utilize information from a constellation of satellite vehicles (SVs) 190 for several other local or regional SPSs, such as the Global Positioning System (GPS), Global Navigation Satellite System (GLONASS), Galileo, or Beidou (e.g., Global Navigation Satellite System (GNSS)), or the Indian Regional Navigational Satellite System (IRNSS), European Geostationary Navigation Overlay Service (EGNOS), or Wide Area Augmentation System (WAAS). Additional components of the communication system 100 are described below. The communication system 100 may include additional or alternative components.

[0034] As shown in Figure 1, NG-RAN135 includes NR node B (gNBs) 110a, 110b, and next generation eNode B (ng-eNB) 114, while 5GC140 includes Access and Mobility Management Function (AMF) 115, Session Management Function (SMF) 117, Location Management Function (LMF) 120, Gateway Mobile Location Center (GMLC) 125, User Plane Function (UPF) 118, and Secure User Plane Location (SUPL) Location Platform (SUPL SLP) 119. gNB110a, 110b, and ng-eNB114 are communicatively coupled to each other and configured to communicate wirelessly bidirectionally with UE105, and are communicatively coupled to AMF115 and UPF118 and configured to communicate bidirectionally with them, respectively. gNB110a, 110b, and ng-eNB114 are sometimes referred to as base stations (BSs). AMF115, SMF117, LMF120, and GMLC125 are communicatively coupled to each other, and GMLC125 is communicatively coupled to an external client 130. AMF115, SMF117, UPF118, and SUPL SLP119 are communicatively coupled to each other, and SUPL SLP119 is communicatively coupled to an external client 130. SMF117 may further function as an initial contact point for a Service Control Function (SCF) (not shown) that creates, controls, and deletes media sessions.Each of the base stations 110a, 110b, and 114 may support a macrocell (e.g., a high-power cellular base station) or a small cell (e.g., a low-power cellular base station), or each may be an access point (e.g., a short-range base station configured to communicate using short-range technologies such as WiFi, WiFi Direct (WiFi-D), Bluetooth®, Bluetooth® Low Energy (BLE), or Zigbee). One or more of the base stations 110a, 110b, and 114 may be configured to communicate with the UE 105 via multiple carriers. Each of the base stations 110a, 110b, and 114 may provide communication coverage to its respective geographical area, e.g., a cell. Each cell may be divided into multiple sectors depending on the base station antenna.

[0035] Figure 1 provides a generalized diagram of various components, any or all of which may be used as appropriate, and each of them may be duplicated or omitted as needed. Specifically, only two UEs 105 are illustrated, but many UEs (e.g., hundreds, thousands, millions, etc.) may be used within the communication system 100. Similarly, the communication system 100 may include more (or fewer) SVs (i.e., more or fewer than the four SVs 190 shown), gNBs 110a, 110b, ng-eNB 114, AMF 115, external clients 130, and / or other components. The shown connections connecting the various components in the communication system 100 may include additional (intermediate) components, direct or indirect physical and / or wireless connections, and / or additional networks, including data and signaling connections. Furthermore, components may be rearranged, combined, separated, replaced, and / or omitted depending on the desired function.

[0036] Figure 1 shows a 5G-based network, but similar network implementations and configurations may be used for other communication technologies such as 3G, Long-Term Evolution (LTE), and Future 6G. The implementations described herein (whether they are for 5G technology and / or for one or more other communication technologies and / or protocols) may be used to transmit (or broadcast) directional synchronization signals, receive and measure directional signals at a UE (e.g., UE105) or base stations 110a, 110b, 114, and / or provide location assistance to UE105 (via LMF120 or SUPL SLP119 or other location servers), and / or calculate the location of one or both of UE105 in location-enabled devices such as UE105, base stations 110a, 110b, LMF120, or SUPL SLP119 based on measurements received at UE105 or base stations 110a, 110b, 114 for such directionally transmitted signals. GMLC125, LMF120, AMF115, SMF117, UPF118, SUPL SLP119, ng-eNB(eNodeB)114, and gNB(gNodeBs)110a, 110b are examples and may be replaced by, or include, various other entities, including location server functions and / or base station functions, in various embodiments.

[0037] System 100 is wirelessly communicative in the sense that its components can communicate with each other directly or indirectly (at least sometimes using wireless connections) via, for example, base stations 110a, 110b, 114 and / or network 140 (and / or one or more other devices not shown, such as one or more other base transceiver stations). In the case of indirect communication, the communication may be modified during transmission from one entity to another, for example, to alter the header information of a data packet, to change the format, etc. UE 105 may include multiple UEs and may be a mobile wireless communication device, but may communicate wirelessly and via wired connections. UE 105 may be any of a variety of devices, such as a smartphone, tablet computer, or vehicle-based device, but these are merely examples, and other configurations of UEs may be used, as UE 105 is not required to be any of these configurations. Other UEs may include wearable devices (e.g., smartwatches, smart jewelry, smart glasses, or headsets). Further other UEs may be used, whether they currently exist or will be developed in the future. Furthermore, other wireless devices (whether mobile or not) may be implemented within System 100 and may communicate with each other and / or with UE 105, base stations 110a, 110b, 114, core network 140, and / or external clients 130. For example, such other devices may include IoT devices or IIoT devices, medical devices, home entertainment devices, and / or automation devices. The core network 140 may communicate with external clients 130 (e.g., computer systems) to enable external clients 130 to request and / or receive location information about UE 105 (e.g., via GMLC 125 or SUPL SLP 119).

[0038] The UE105 or other devices may be configured to communicate in various networks and / or for various purposes and / or using various technologies (e.g., 5G, Wi-Fi® communications, multiple frequencies for Wi-Fi communications, satellite positioning, one or more types of communications (e.g., GSM® (Global System for Mobiles), CDMA (Code Division Multiple Access), LTE (Long-Term Evolution), V2X (e.g., V2P (Vehicle-to-Pedestrian), V2I (Vehicle-to-Infrastructure), V2V (Vehicle-to-Vehicle), etc.), IEEE 802.11p, etc.)). V2X communications may be cellular (Cellular-V2X (C-V2X)) and / or Wi-Fi (e.g., DSRC (Dedicated Short-Range Connectivity)). System 100 can support operation on multiple carriers (waveform signals of different frequencies). A multi-carrier transmitter can transmit modulated signals simultaneously on multiple carriers. Each modulated signal may be a Code Division Multiple Access (CDMA) signal, a Time Division Multiple Access (TDMA) signal, an Orthogonal Frequency Division Multiple Access (OFDMA) signal, a Single-Carrier Frequency Division Multiple Access (SC-FDMA) signal, etc. Each modulated signal can be transmitted on a different carrier and can carry pilot, overhead information, data, etc.UE105s can communicate with each other via inter-UE sidelink (SL) communication by transmitting over one or more sidelink channels, such as the physical sidelink synchronization channel (PSSCH), physical sidelink broadcast channel (PSBCH), physical sidelink control channel (PSCCH), synchronization signal block (SSB), sidelink channel state information reference signal (SL-CSIRS), physical sidelink feedback channel (PSFCH), or sidelink sounding reference signal (SL-SRS).

[0039] The UE105 may include, and / or be referred to as, a device, mobile device, wireless device, mobile terminal, terminal, mobile station (MS), or Secure User Plane Location (SUPL) enabled terminal (SET), or by any other name. Furthermore, the UE105 may be compatible with cell phones, smartphones, laptops, tablets, PDAs, tracking devices, navigation devices, Internet of Things (IoT) devices, asset trackers, health monitors, security systems, smart city sensors, smart meters, wearable trackers, or any other portable or mobile devices. Generally, though not always, the UE105 may support wireless communications using one or more radio access technologies (RATs), such as Global System for Mobile communication (GSM), Code Division Multiple Access (CDMA), Wideband CDMA (WCDMA), LTE, High Rate Packet Data (HRPD), IEEE 802.11 WiFi (also known as Wi-Fi), Bluetooth (BT), Worldwide Interoperability for Microwave Access (WiMAX), and 5G New Radio (NR) (e.g., using NG-RAN135 and 5GC140). The UE105 may also support wireless communications using, for example, a Digital Subscriber Line (DSL) or a Wireless Local Area Network (WLAN) that can connect to other networks (e.g., the Internet) using packet cable.The use of one or more of these RATs may enable UE105 to communicate with an external client 130 (e.g., via an element of 5GC140 not shown in Figure 1, or possibly via GMLC125), and / or enable the external client 130 to receive location information about UE105 (e.g., via GMLC125 or SUPL SLP119).

[0040] Each UE105 may include a single entity, or it may include multiple entities, such as in a personal area network where the user may employ audio, video and / or data I / O (input / output) devices and / or body sensors and separate wireline or wireless modems. The estimated location of a UE, for example, UE105, may be called location, location estimate, location fix, fix, position, location estimate, or location fix, and may provide the location coordinates (e.g., latitude and longitude) of the UE, which may or may not include an elevation component (e.g., elevation above sea level, ground elevation or ground depth, floor level, or basement level). Alternatively, the location of a UE may be represented as a city location (e.g., as a postal address, or as the designation of some point or small area in a building, such as a specific room or floor). The location of a UE may be represented as an area or volume (defined either geodetically or in urban form) in which the UE is expected to be located with a certain probability or confidence level (e.g., 67%, 95%, etc.). The location of a UE may be represented, for example, as a relative location with distance and direction from a known location. The relative location may be represented as relative coordinates (e.g., X, Y (and Z) coordinates) defined with respect to some origin in the known location, which may be defined, for example, geodesically, from a city perspective, or by referring to a point, area, or volume shown on a map, floor plan, or building plan. In the descriptions contained herein, the use of the term location may include any of these variations unless otherwise indicated. When calculating the location of a UE, it is common to determine the local x, y, and possibly z coordinates, and then, if desired, convert the local coordinates to absolute coordinates (e.g., with respect to latitude, longitude, and altitude above or below mean sea level).

[0041] When sidelink positioning is used, the absolute (e.g., global) location or relative location of a UE may not always be obtained. Instead, a location result may be obtained for the UE that may include the range or distance between the UE and each of one or more other UEs, the direction from the UE to each of one or more other UEs, the location of the UE relative to the location of some other UE, the location of one or more other UEs relative to the location of the UE, the velocity of the UE, and / or the velocity of each of one or more other UEs. The velocity of the UE may be absolute (e.g., relative to the Earth) or relative to some other UE, in which case it may be called “relative velocity.” The relative velocity of UE B to another UE A may include a “radial velocity” component which may be equal to the rate of change of the range from UE A to UE B, and a “lateral velocity” component which may be perpendicular to the radial velocity component as seen from UE A, and may be equal to the rate of change of the angle in the direction from UE A to UE B multiplied by the range from UE A to UE B. In the descriptions contained herein, the use of the term “location results” (singular or plural) with respect to sidelink positioning of a UE or group of UEs may include any of these variations unless otherwise indicated.

[0042] UE105 may be configured to communicate with other entities using one or more of a variety of technologies. UE105 may be configured to indirectly connect to one or more communication networks via one or more device-to-device (D2D) peer-to-peer (P2P) links, which may be supported using sidelink signaling. D2D P2P links may be supported using any suitable D2D radio access technology (RAT), such as LTE Direct (LTE-D), WiFi Direct (WiFi-D), or Bluetooth. One or more of the groups of UEs utilizing D2D communication may be within the geographical coverage area of ​​a Transmission / Reception Point (TRP), such as one or more of gNB110a, 110b, and / or ng-eNB114. Other UEs within such a group may be outside such geographical coverage area or otherwise unable to receive transmissions from the base station. A group of UEs communicating via D2D communication may utilize a one-to-many (1:M) system in which each UE can transmit to other UEs in the group. A TRP can facilitate the scheduling of resources for D2D communication. In other cases, D2D communication may be performed between UEs without the involvement of a TRP. One or more of the groups of UEs utilizing D2D communication may be within the geographical coverage area of ​​a TRP. Other UEs in such a group may be outside such geographical coverage area or otherwise unable to receive transmissions from the base station. A group of UEs communicating via D2D communication (e.g., using side-link signaling) may utilize a one-to-many (1:M) system in which each UE can transmit to other UEs in the group. A TRP can facilitate the scheduling of resources for D2D communication (and side-link signaling). In other cases, D2D communication may be performed between UEs without the involvement of a TRP.

[0043] The base stations (BSs) in NG-RAN135 shown in Figure 1 include NR node B called gNB110a and 110b. The pair of gNB110a and 110b in NG-RAN135 may be connected to each other via one or more other gNBs. Access to the 5G network is provided to UE105 via wireless communication between the UE and one or more of gNB110a and 110b, and gNB110a and 110b may provide wireless communication access to 5GC140 for UEs using 5G. In Figure 1, it is assumed that the serving gNB for UE105A is gNB110b, while the serving gNB for UE105B is assumed to be gNB110a, but another gNB may act as a serving gNB when UE105 moves to a different location, or as a secondary gNB to give UE105 additional throughput and bandwidth, and UE105 may share the same serving gNB.

[0044] The base stations (BSs) within NG-RAN135 shown in Figure 1 may include ng-eNB114, also known as next-generation advanced node B. ng-eNB114 may, in some cases, connect to one or more of the gNB110a, 110b within NG-RAN135 via one or more other gNBs and / or one or more other ng-eNBs. ng-eNB114 may provide LTE wireless access and / or evolved LTE (eLTE) wireless access to UE105. One or more of the gNB110a, 110b and / or ng-eNB114 may be configured to function as positioning-only beacons, capable of transmitting signals to assist in determining the location of UE105 but unable to receive signals from UE105 or other UEs.

[0045] Each of the base stations 110a, 110b, and 114 may have one or more TRPs. For example, each sector within a base station cell may be supported by a TRP, but multiple TRPs may share one or more components (e.g., they may share a processor but have separate antennas). System 100 may include only macro TRPs, or system 100 may have different types of TRPs, e.g., macro, pico, and / or femto TRPs. A macro TRP may cover a relatively large geographic area (e.g., a radius of several kilometers) and may enable unrestricted access by UEs subscribing to the service. A pico TRP may cover a relatively small geographic area (e.g., a picocell) and may enable unrestricted access by UEs subscribing to the service. A femto TRP or home TRP may cover a relatively small geographic area (e.g., a femtocell that may have a radius of 20-50 meters) and may enable limited access by UEs associated with a femtocell (e.g., UEs for users in their homes or offices).

[0046] The communication system 100 supports NR and may support communication between one or more base stations 110a, 110b, 114 and a supported UE 105. The UEs may be distributed throughout the wireless communication system 100, and each UE may be stationary or mobile. As part of the communication, each of the base stations 110a, 110b, 114 and UE 105 may support transmitting reference signals for operation, including channel estimation, beam management and scheduling, and positioning of wireless devices within the coverage area of ​​one or more base stations.

[0047] For example, base stations 110a, 110b, and 114 may transmit one or more downlink reference signals for NR communication, including channel status information reference signal (CSI-RS) transmissions. Each CSI-RS transmission may be configured so that a particular UE 105 estimates the channel and reports channel quality information. The reported channel quality information may be used for scheduling or link adaptation at base stations 110a, 110b, and 114, or as part of mobility or beam management procedures for directional transmissions related to extended channel resources. Similarly, UE 105 may be configured to transmit uplink signals to one or more base stations 110a, 110b, and 114, and to transmit sidelink transmissions between UE 105s.

[0048] Base stations 110a, 110b, and 114 may transmit one or more additional downlink reference signals, including positioning reference signal (PRS) transmissions. PRS transmissions may be configured to have a particular UE 105 measure and report one or more reporting parameters (e.g., reporting quantities) associated with positioning and location information. PRS transmissions and reporting parameter feedback may support various location services (e.g., navigation systems, emergency communications). In some examples, the reporting parameters augment one or more additional location systems (such as Global Positioning System (GPS) technology) supported by the UE 105.

[0049] Base stations 110a, 110b, and 114 may configure PRS transmissions on one or more PRS resources in a channel. A PRS resource may span resource elements of multiple physical resource blocks (PRBs) within one or more OFDM symbols in a slot, depending on the number of ports configured. For example, a PRS resource may span one symbol in a slot and include one port for transmission. In any OFDM symbol, a PRS resource may occupy consecutive PRBs. In some examples, a PRS transmission may be mapped to consecutive OFDM symbols in a slot. In other examples, a PRS transmission may be mapped to scattered OFDM symbols in a slot. In addition, a PRS transmission may support frequency hopping within the PRBs of a channel.

[0050] One or more PRS resources may span several PRS resource sets according to the PRS resource configuration of base stations 110a, 110b, and 114. The structure of one or more PRS resources, PRS resource sets, and PRS resource configurations within a PRS transmission may be referred to as a multilevel resource configuration. For example, a multilevel PRS resource configuration of base stations 110a, 110b, and 114 may include multiple PRS resource sets, each of which may include a set of PRS resources (such as a set of four PRS resources).

[0051] UE105 may receive a PRS transmission through one or more PRS resources in its slots. UE105 may determine reporting parameters for at least some of the PRS resources included in the transmission. Reporting parameters for each PRS resource (which may include reporting quantities) may include one or more of the following: Time of Arrival (TOA), Reference Signal Time Difference (RSTD), Reference Signal Received Power (RSRP), angle, PRS identification number, Receive-to-Transmit Time Difference (UE Rx-Tx), Signal-to-Noise Ratio (SNR), or Reference Signal Received Quality (RSRQ).

[0052] Similarly, UE105 may be configured to transmit one or more additional uplink reference signals that can be received by base stations 110a, 110b, and 114 and used for positioning. For example, UE105 may transmit a sounding reference signal (SRS) for positioning. Base stations 110a, 110b, and 114, receiving the uplink reference signal from UE105, may perform positioning measurements such as time of arrival (TOA), and one or more of the receive-to-transmit time difference (Rx-Tx) of gNB or ng-eNB.

[0053] Embodiments of the wireless communication system 100 may include the use of downlink PRS transmission by base stations 110a, 110b, 114 or uplink SRS transmission by a UE, e.g., UE105A or UE105B, for UE location determination. In the case of downlink-based UE location determination, a location server, e.g., LMF 120 in 5GC, or an Extended Serving Mobile Location Center (E-SMLC) in EPC (sometimes referred to as location server 120) may be used to provide positioning assistance such as PRS-assisted data (AD) to the UE. In the case of uplink-based UE location determination, a location server 120 and / or a serving base station, e.g., gNB110a, may be used to provide positioning assistance such as SRS-assisted data to receiving entities such as base stations (e.g., gNB110a, 110b, and other UEs(s)). SRS-assisted data may include, for example, SRS transmission opportunities and other parameters, e.g., reference signal patterns, power if different from nominal values, repetition count, etc.

[0054] The UE's position estimate can be determined using a reference signal such as a PRS or SRS for positioning signals, or a measurement of other reference signals from one or more base stations 110a, 110b, 114 or the UE. Positioning methods such as Time-to-Arrival (TDOA), DL-to-Arrival (DL-TDOA), DL-to-Departure (DL AoD), and Extended Cell ID (ECID) are positioning methods that can be used to estimate the UE's position using reference signals from base stations. For example, DL-TDOA relies on measuring the reference signal time difference (RSTDs) between the downlink (DL) signal received from a base station for a reference cell and the DL signal received from one or more base stations for one or more neighboring cells. DL signals from which RSTSD can be obtained include, for example, cell-specific reference signals (CRS) and positioning reference signals (PRS) as defined in 3GPP Technical Specification (TS) 36.211 and TS 38.211.

[0055] Other positioning methods may use reference signals transmitted by the UE, including uplink-based positioning methods and downlink and uplink-based positioning methods. For example, uplink-based positioning methods may include, for example, UL Time Difference of Arrival (UL-TDOA), UL Angle of Arrival (UL AoA), and UL Relative Time of Arrival (UL-RTOA), while downlink-based and uplink-based positioning methods may include, for example, round-trip time (RTT) with one or more adjacent base stations.

[0056] In addition, sidelink-based positioning may be used in which UEs transmit and / or receive sidelink positioning reference signals that are measured and used for positioning. For example, UE 105 may communicate with each other through inter-UE sidelink (SL) communication by transmitting over one or more sidelink channels, such as the Physical Sidelink Synchronization Channel (PSSCH), Physical Sidelink Broadcast Channel (PSBCH), Physical Sidelink Control Channel (PSCCH), and Physical Sidelink Feedback Channel (PSFCH). Sidelink signals may include sidelink channel status information reference signals (SL-CSIRS), sidelink positioning reference signals (SL-PRS), and sidelink sounding reference signals (SL-SRS).

[0057] As mentioned above, Figure 1 shows a node configured to communicate according to the 5G communication protocol, but nodes configured to communicate according to other communication protocols, such as the LTE protocol or the IEEE 802.11x protocol, may be used. For example, in an Evolved Packet System (EPS) providing LTE wireless access to UE105, the RAN may include an Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN) which may include base stations including Evolved Node B (eNBs). The core network for the EPS may include an Evolved Packet Core (EPC). The EPS may also include E-UTRAN plus EPC, where in Figure 1, E-UTRAN corresponds to NG-RAN135 and EPC corresponds to 5GC140.

[0058] gNB110a, 110b, and ng-eNB114 may communicate with AMF115, which in turn communicates with LMF120 for positioning functions. AMF115 may support the mobility of UE105, including cell changes and handovers, and may be involved in signaling connections to UE105, and optionally supporting data and voice bearers for UE105. LMF120 may communicate directly or indirectly with UE105, or directly or indirectly with base stations 110a, 110b, and 114, for example, through wireless communication. The LMF120 may support the positioning of the UE105 when the UE105 accesses the NG-RAN135, and may support positioning procedures / methods such as Assisted GNSS (A-GNSS), Time of Arrival (TDOA) (e.g., Downlink (DL)TDOA or Uplink (UL)TDOA), Real Time Kinematic (RTK), Precise Point Positioning (PPP), Differential GNSS (DGNSS), Extended Cell ID (E-CID), Angle of Arrival (AoA), Angle of Departure (AoD), and / or other positioning methods. The LMF120 may process location service requests for the UE105 received, for example, from the AMF115 or the GMLC125. The LMF120 may be connected to the AMF115 and / or the GMLC125. The LMF120 may also be referred to by other names such as Location Manager (LM), Location Function (LF), Commercial LMF (CLMF), or Value Added LMF (VLMF).The nodes / systems implementing the LMF120 may, as an addition or alternative, implement other types of location support modules, such as an Enhanced Serving Mobile Location Center (E-SMLC) or a Secure User Plane Location (SUPL) Location Platform (SUPL SLP). At least part of the positioning functions (including the derivation of the UE's location) may be performed in the UE (e.g., using signals transmitted by wireless nodes such as gNB110a, 110b and / or ng-eNB114 and / or signal measurements taken by the UE for support data provided to the UE by the LMF120). At least part of the positioning functions (including the derivation of the UE's location) may, as an alternative, be performed in the LMF120 (e.g., using signal measurements taken by gNB110a, 110b and / or ng-eNB114). The AMF115 may act as a control node handling signaling between the UE105 and the core network 140, providing QoS (Quality of Service) flow and session management. The AMF115 may support the mobility of the UE105, including cell changes and handovers, and may be involved in supporting signaling connections to the UE105.

[0059] GMLC125 can support location requests for UE105 received from external client 130, and may forward such location requests to AMF115 for forwarding to LMF120 by AMF115, or it may forward the location requests directly to LMF120. The location response from LMF120 (including, for example, a location estimate for UE105) may be returned to GMLC125 either directly or via AMF115, and GMLC125 may then return the location response (including, for example, a location estimate) to external client 130. Although GMLC125 is shown connected to both AMF115 and LMF120, in some implementations only one of these connections may be supported by 5GC140.

[0060] The User Plane Function (UPF) 118 may support voice and data bearers for the UE 105 and may enable the UE 105 to access voice and data to other networks such as the Internet. The UPF 118 may be connected to the gNB 110 and ng-eNB 114. The functions of the UPF 118 may include the user plane portion of interconnection to data networks, external protocol data unit (PDU) session points, packet (e.g., Internet Protocol (IP)) routing and forwarding, packet inspection and policy rule enforcement, quality of service (QoS) handling for the user plane, downlink packet buffering, and triggering downlink data notification. The UPF 118 may be connected to the SUPL SLP 119 to enable support for positioning of the UE 105 using SUPL. The SUPL SLP 119 may further be connected to or accessible from an external client 130.

[0061] As shown in the diagram, the Session Management Function (SMF) 117 connects the AMF 115 and the UPF 118. The SMF 117 may have the ability to control both the local UPF and the central UPF within a PDU session. The SMF 117 may manage the establishment, modification, and release of PDU sessions for the UE 105, perform IP address allocation and management for the UE 105, act as a Dynamic Host Configuration Protocol (DHCP) server for the UE 105, and select and control the UPF 118 for the UE 105.

[0062] As further shown in Figure 1, the LMF120 may communicate with gNB110a, 110b, and / or ng-eNB114 using the New Radio Positioning Protocol A (NRPPa), which may be defined in 3GPP Technical Specification (TS) 38.455. NRPPa messages may be transmitted between gNB110a (or gNB110b) and the LMF120, and / or between ng-eNB114 and the LMF120 via the AMF115. As further shown in Figure 1, the LMF120 and UE105 may communicate using the LTE Positioning Protocol (LPP), which may be defined in 3GPP TS 37.355. Here, LPP messages may be transmitted between the UE105 and the LMF120 via the AMF115 for the UE105 and serving gNB110a, 110b, or serving ng-eNB114. For example, LPP messages can be transferred between LMF120 and AMF115 using a 5G service-based protocol, and between AMF115 and UE105 using a 5G Non-Access Stratum (NAS) protocol.

[0063] The LPP protocol may be used to support the positioning of UE105 using UE-assisted and / or UE-based positioning methods such as A-GNSS, RTK, TDOA, AoA, AoD, and / or E-CID. The NRPPa protocol may be used to support the positioning of UE105 using network-based positioning methods such as E-CID (e.g., when used with measurements obtained by gNB110a, 110b, or ng-eNB114), and / or the LMF120 may be used to obtain location-related information from gNB110a, 110b, and / or ng-eNB114, such as parameters defining the transmission of directional synchronization signals (SS) from gNB110a, 110b, and / or ng-eNB114. The LMF120 is shown in Figure 1 as being located within the core network 140, but may be outside the core network 140, for example, in the NG-RAN. For example, the LMF120 may be collateralized with or integrated with a gNB or TRP, or it may be located remotely from the gNB and / or TRP, and may be configured to communicate directly or indirectly with the gNB and / or TRP.

[0064] In UE-assisted positioning methods, a UE, e.g., UE105A or UE105B, may acquire location measurements and send them to a location server (e.g., LMF120) for the calculation of a location estimate for the UE. For example, location measurements may include one or more of the following for gNB110a, 110b, ng-eNB114, and / or WLAN APs: Received Signal Strength Indication (RSSI), Round Trip Signal Propagation Time (RTT), Reference Signal Time Difference (RSTD), Reference Signal Received Power (RSRP), and / or Reference Signal Received Quality (RSRQ), AoA, and AoD. Location measurements may also include, or alternatively, GNSS pseudodistance, code phase, and / or carrier phase measurements for SV190.

[0065] In UE-based positioning methods, a UE, for example, UE105A or UE105B, can acquire location measurements (which may be the same as or similar to location measurements for UE-assisted positioning methods, for example), and can calculate the location of the UE (with the help of support data received from a location server such as LMF120, or broadcast by gNB110a, 110b, ng-eNB114, or other base stations or APs).

[0066] In network-based positioning methods, one or more base stations (e.g., gNB110a, 110b, and / or ng-eNB114), sidelink UEs, or APs may acquire and / or receive location measurements (e.g., RSSI, RTT, RSRP, RSRQ, AoA, AoD, or Time of Arrival (ToA) measurements for signals transmitted by a UE, e.g., UE105A or UE105B). One or more base stations or APs may send measurements to a location server (e.g., LMF120) for the calculation of a location estimate for the UE.

[0067] Using NRPPa, the information provided to the LMF120 by gNB110a, 110b, and / or ng-eNB114 may include timing and configuration information for directional SS transmissions, as well as location coordinates. The LMF120 may provide some or all of this information to the UE105 as supporting data in LPP messages via NG-RAN135 and 5GC140.

[0068] An LPP message sent from the LMF120 to the UE105 can instruct the UE105 to do one of several things depending on the desired function. For example, an LPP message may include an instruction for the UE105 to acquire measurements for GNSS (or A-GNSS), WLAN, E-CID, and / or TDOA (or some other positioning method). In the case of E-CID, an LPP message may instruct the UE105 to acquire one or more measurements (e.g., beam ID, beamwidth, mean angle, RSRP, RSRQ measurements) of a directional signal transmitted within a particular cell supported by one or more of the gNB110a, 110b, and / or ng-eNB114 (or supported by some other type of base station such as an eNB or WiFi AP). UE105 may send the measured quantity back to LMF120 in an LPP message (for example, inside a 5G NAS message) via serving gNB110a (or serving ng-eNB114) and AMF115.

[0069] Positioning for UEs in a wireless network, such as the communication system 100 shown in Figure 1, generally uses a Uu interface for DL ​​PRS and / or UL SRS, i.e., a wireless interface between the UE and the wireless access network. Positioning for UEs may use a sidelink PRS (SL PRS), which may be a reference signal for a specific sidelink for positioning, or it may reuse a Uu SRS, such as UL SRS, which is sometimes called a sounding reference signal (SRSPos) for positioning, or other reference signals may be transmitted in the sidelink channel. Sidelink positioning can be extended by providing additional transmitting (or receiving) nodes. A sidelink UE, such as UE105B, with a known location may be used to support the location determination of a target UE, such as UE105, and the sidelink UE may be called an anchor node.

[0070] Using a sidelink positioning method, for example, UE105A may transmit a sidelink PRS or sidelink SRS that is received and measured by UE105B. In addition or alternatively, UE105B may transmit a sidelink PRS or sidelink SRS signal that is received and measured by UE105A. Measurements of the SL PRS or SL SRS signal may include Rx-Tx, TDOA, TOA, RSRP, RSRQ, and AoA. The SL positioning method may include SL RTT (also called ranging), SL AoA, and SL AoD. In some scenarios, a group of UEs (not shown in Figure 1) may support SL positioning. In this case, one UE in the group may transmit an SL PRS or SL SRS signal that can be measured by some or all of the other UEs in the group. Some or all other UEs within the group may also transmit SL PRS or SL SRS signals that can be measured by some or all other UEs within the group, different from the UE transmitting UL PRS or ULS SRS (for example, each UE transmits SL SRS or SL PRS at one or more times different from when other UEs in the group transmit SL PRS or SL SRS). Measurements taken by the UEs that are applicable to the transmission of SL PRS or SL SRS by a group of UEs may include Rx-Tx, TDOA, TOA, RSTD, AoA, RSRP, and RSRQ. Positioning methods supported by these measurements may include sidelink RTT (e.g., ranging), sidelink AoA, sidelink AoD, and sidelink TDOA (SL-TDOA). Based on the measurement and positioning method(s)(s), each UE may determine its own and / or other UEs' relative location and / or relative velocity, as well as / or absolute location and / or absolute velocity. For example, a UE's relative location may include the UE's location relative to one or more other UE locations within a group.

[0071] Sidelink positioning can be used for UE positioning independently of the core network (e.g., 5GC140) or serving PLMN. One exemplary implementation of sidelink positioning may be found in vehicle communication systems such as V2X, which can be used for safety-related applications such as safety warnings, traffic congestion (e.g., automated traffic control), and coordinated or automated vehicle steering. One aspect of sidelink positioning that may require a solution for standardization is the Sidelink Positioning Protocol (SLPP), which can be used between a UE and a location server, including between an RSU and a UE. SLPP may support sidelink positioning between a UE, RSU, and PRU with network access independence, for example. SLPP may provide support for sidelink positioning for pairs of UEs (e.g., ranging), groups of UEs (V2X), and UEs that are members of multiple different groups. For example, SLPP could provide support for various positioning techniques currently standardized for UE-based and UE-assisted support by a location server (e.g., LMF120), such as PRS RTT, AoA, Differential AoA (DAoA), AoD, and Differential AoD (DAoD), but could also enable support for other PRS and SRS-based positioning methods, as well as non-PRS methods such as RTK later on. By allowing the addition of new capabilities and methods later, SLPP could avoid the need to define a separate new positioning protocol different from SLPP. For example, additional positioning methods that may be included in SLPP later could include RTK, Wi-Fi, Ultra-Wideband (UWB), and BT positioning methods.

[0072] SLPP can initially enable direct side-link operation (where UEs communicate and coordinate positioning by exchanging SLPP messages using side-link signaling), and later can be extended to side-link operation via relays and operation via a network, where UEs can exchange SLPP messages via a network or via intermediate relay UEs. For example, this could be used to coordinate the positioning of two vehicles on a collision course at a corner where direct SL signaling between the two vehicles is not possible. Thus, SLPP may initially define support for SL PRS-based positioning in a general manner to simplify later extensions to support other positioning methods. For example, SLPP may define a general SLPP message similar to the general LPP message defined for LPP in 3GPP TS 37.355. Where feasible, SLPP may support distinct positioning methods (e.g., SL PRS RTT, SL PRS AoA, SL PRS AoD) using common procedures and common parameters. SLPP may define procedures that can be reused for multiple positioning methods, and is not limited to just one or a few positioning methods. SLPP messages can be forwarded and used by various entities, including UEs, RSUs, PRUs, and location servers such as LMFs and SUPL SLPs. Location server use (e.g., LMFs and SUPL SLPs) may forward SLPP messages within LPP messages to enable UE-assisted positioning by the LMF or SUPL SLP. Alternatively, location server use (e.g., LMFs and SUPL SLPs) may forward SLPP messages unrelated to LPP messages to enable UE-assisted positioning by the LMF or SUPL SLP. SLPP can further support relative (local) and global positioning.

[0073] As shown in Figure 1, Server 150 connects to UPF 118 (for example, via the Internet). As disclosed in detail below, Server 150 may have the ability to determine and provide security information for UE 105 to perform secure sidelink communication. In some embodiments, Server 150 may be configured to provide common security data and coordinate secure sidelink communication between UE 105.

[0074] Figure 2 shows, as an example, the architecture of a communication system 200 capable of network-supported and network-unsupported sidelink positioning. As shown in Figure 2, several UEs (e.g., UE105) may be combined within the same group 210 for sidelink positioning. Within group 210, there may be various subgroups of UEs. For example, group 210 of UEs may include a first subgroup 212 of UEs served by a first network (PLMN1 140a), a second subgroup 214 of UEs served by a second (different) network (PLMN2 140b), and a third subgroup 216 of UEs outside the coverage of any network and not served by any network. One or more of the network-serviced UEs, for example, UEs in subgroup 212 served by PLMN1 140a, or UEs in subgroup 214 served by PLMN2 140b, may include RSUs.

[0075] Location servers in a serving network, such as LMF1 120a or SUPL SLP1 119a in serving PLMN1 140a, and LMF2 120b or SUPL SLP2 119b in serving PLMN2 140b, can each support all UEs in groups served by the network (PLMN), such as subgroups 212 and 214. As illustrated, a location server can support UEs by sending and receiving SLPP messages to and from the UEs, where SLPP messages can be sent and received independently, or each can be sent and received embedded within a message for another protocol such as LPP, SUPL User Plane Location Protocol (ULP), or Supplemental Services Protocol (SSP). For example, LMF1 120a and LMF2 120b, while supporting UEs in subgroups 212 and 214 respectively, can each embed SLPP messages within LPP or SSP messages, or each can forward unembedded SLPP messages. Similarly, SUPL SLP1 119a and SUPL SLP2 119b, while supporting UEs in subgroups 212 and 214 respectively, can each embed SLPP messages within ULP message 1. In addition, UEs within each subgroup, and UEs in different subgroups, signal each other using unembedded SLPP messages.

[0076] Location server (e.g., LMF / SUPL SLP) support for a UE may not be visible to other UEs in the group. For example, location server support from PLMN1 140a for a UE in subgroup 212 may not be visible to UEs in subgroup 214, and may not be visible to out-of-coverage UEs in subgroup 216. The support provided to a UE by the location server may include determining or verifying the PRS configuration, and calculating the location results of the UEs, including UEs in supported and unsupported subgroups, if, for example, the location information of a UE in an unsupported subgroup is proven to the location server. For example, some implementations may use signaling between location servers in separate networks to provide more complete network support. As illustrated, LMF-LMF or SUPL SLP-SUPL SLP signaling may use SLPP or an extension of SLPP to enable more complete network support. ** ) can be used.

[0077] The SLPP message type can be aligned with LPP to allow LPP messages to contain SLPP messages, as indicated by the signaling between LMF1 120a and subgroup 212 UEs, and between LMF2 120b and subgroup 214 UEs. For example, SLPP may contain messages similar to LPP capability request and capability provision messages, which may be referred to as, for example, "capability and resource request" and "capability and resource provision" in SLPP. Capability and resource requests / provisions in SLPP may be limited to NR PRS or extended to LTE PRS, RTK, WiFi, BT, etc.

[0078] In another example, SLPP may include a message similar to LPP support data provision, which may be called "Positioning Signal Configuration Provision" in SLPP. Positioning Signal Configuration Provision in SLPP may include, for example, the PRS configuration, start time, duration, and end state to be transmitted by each UE and measured by other UEs, as well as one or more of the required measurement types, such as Rx-Tx, AoA, RSRP, TDOA, etc. In some implementations, Positioning Signal Configuration Provision in SLPP may be extended to define other types of signals, such as RTK signals to be measured, and WiFi signals to be transmitted and measured. Positioning Signal Configuration Provision in SLPP may include additional information, for example, to assist UEs in acquiring and measuring signals and determining transmission times.

[0079] In another example, an SLPP may include a message such as "Confirm Positioning Signal Configuration," which does not have a similar LPP message. In an SLPP, a Confirm Positioning Signal Configuration might, for example, confirm whether a positioning signal configuration is agreeable. If the positioning signal configuration is not (partially) agreeable, a different configuration may be offered as the positioning signal configuration. Because LPPs do not have similar messages, when a Confirm Positioning Signal Configuration (SLPP) message is embedded in an LPP message, a new LPP message type may be added to carry the SLPP message.

[0080] In another example, an SLPP may include a message similar to an LPP location information provision, which may be called a location information provision in an SLPP. By providing location information in an SLPP, PRS measurements and / or location results of other UEs may be provided to other UEs. Location information provision in an SLPP may be extended to other measurements, such as RTK, Wi-Fi, BT, etc.

[0081] In another example, an SLPP message may include the exact same SLPP message types defined for LPP, such as SLPP capability request, SLPP capability provision, SLPP support data request, SLPP support data provision, SLPP location information request, SLPP location information provision, SLPP error, and SLPP abort.

[0082] As shown in Figure 2, UEs within each subgroup and UEs within different subgroups can signal each other using SLPP. In addition, a location server (e.g., LMF or SUPL SLP) can serve UEs using SLPP, which is, for example, embedded in LPP or SSP, or transmitted unembedded. Thus, a first UE may receive a first SLPP message from a second UE and send a first SLPP message to the location server supporting the first UE. In response to the first SLPP message, the first UE may receive a second SLPP message from the location server and send a second SLPP message to the second UE.

[0083] Figure 3 is a signal flow 300 showing, as an example, signaling between UE105A, UE105B, 105C, and 105D and location server 302 for network-supported sidelink positioning, as described herein. UE105A, 105B, 105C, and 105D may belong to the same group, for example, the UE shown in Figure 1 and any of the UEs shown in subgroups 212 and 214 supported by the network in Figure 2. Location server 302 may be either LMF120 or SUPL SLP119 shown in Figure 1, or LMF120a or SUPL SLP119a shown in Figure 2.

[0084] As shown in Figure 3, in step 1, UE105A receives a first SLPP message from UE105B. The first SLPP message may be, for example, one of the message types described above. The first SLPP message may be transmitted based on SL multicast if the group includes three or more UEs, for example, as shown in Figure 3.

[0085] In stage 2, UE 105A sends a first SLPP message to location server 302, either embedded or not embedded within an LPP or SSP message.

[0086] In stage 3, UE 105A receives a second SLPP message from location server 302 in response to the first SLPP message in stage 2, either embedded or not embedded within the LPP or SSP message. The second SLPP message may contain one or more location results for at least one UE in the group. The location results, if present, may be location results for UE 105A or location results for another UE in the group.

[0087] In stage 4, UE105A may send a second SLPP message to one or more of UE105B, 105C, and 105D. The second SLPP message may be sent based on SL multicast if the group includes three or more UEs, for example, as shown in Figure 3.

[0088] Figure 4 is a block diagram 400 showing, as an example, one implementation of the structure of an SLPP message 410. As shown, the SLPP message 410 includes a header 412 which may include a session ID, transaction ID, sequence number (seq no), acknowledgment sequence number (ack seq no), etc. The SLPP message 410 allows one or more positioning methods or types. For example, the SLPP message 410 includes entries for positioning method / type 1 414, positioning method / type 2 416, and positioning method / type M 418. A positioning method may use one or more specific signal types (e.g., PRS, WiFi, GPS L1-L5) and support one method for determining location (e.g., PRS RTT). A positioning type may use one or more specific signal types and support multiple positioning methods (e.g., PRS RTT, AoA, AoD, TDOA). SLPP message 410 may be configured to support a positioning method or positioning type, or both a positioning method and a positioning type. As illustrated, each positioning method / type 414, 416, and 418 in SLPP message 410 includes parameters for each UE in the group, illustrated as identified by a member ID, e.g., UE1, UE2, ..., UEn. It is possible that not all UEs in the group support the same positioning method / type. Support for multiple positioning methods or types in SLPP message 410 may be advantageous because some UEs may support positioning using RTK and PRS, while others may only support RTK. However, in some implementations, SLPP message 410 may only support one positioning method or type (e.g., NR PRS).

[0089] As described above, solutions addressing security concerns for SLPP and / or V2X communications and the limitations of existing solutions may be desired. As disclosed in detail below, the solutions disclosed herein provide a security solution that supports all coverage scenarios, authenticates UEs, encrypts SLPP messages and potentially other V2X messages, has low latency for authentication and encryption operations, has high capacity with scalability to potentially support thousands of UEs in a small area, and can prevent critical security key data from being obtained by attackers.

[0090] Figure 5 is a block diagram showing one implementation of secure sidelink communication 500 for V2X or other applications according to one embodiment. As shown in Figure 5, secure sidelink communication 500 may be performed by a server 510 (e.g., server 150), a type B UE 520 (e.g., UE 105B), and a type A UE 530 (e.g., UE 105A). In some embodiments, secure sidelink communication 500 may be configured to perform secure sidelink positioning between the type B UE 520 and the type A UE 530 (e.g., encrypting sidelink positioning messages for performing sidelink positioning).

[0091] In some embodiments, server 510 may correspond to server 150 in Figure 1. For example, server 510 may be a server owned and managed by a national agency (e.g., the American Automobile Association), a government department, or a mobile network operator. In some embodiments, server 510 may be a server within Unified Data Management (UDM), a server within Home Subscriber Services (HSS), or a separate entity associated with the UDM or HSS. In some embodiments, server 510 may have the ability to determine and provide security information for type B UE 520 and type A UE 530 in order to perform secure side-link communication. As disclosed in detail below, server 510 may be configured to provide common security data and to coordinate secure side-link communication between type B UE 520 and type A UE 530.

[0092] It should be noted that Type A UE 530 and Type B UE 520 may be examples of UE 105 in Figures 1 and 3 and the UE shown in Figure 2. In some embodiments, Type A UE 530 and Type B UE 520 may have different functions and capabilities. For example, Type A UE 530 may be more secure than Type B UE 520 (e.g., more resilient to security attacks such as attempts to extract cryptographic key information from UE memory). For example, for V2X support, Type A UE 530 may correspond to a roadside unit (RSU) and / or a special vehicle (e.g., a bus, truck, or taxi) that coordinates the positioning of Type B UEs such as Type B UE 520, while Type B UE 520 may correspond to a UE located in or mounted on a vehicle that does not normally coordinate the positioning of other UEs. In other embodiments, Type A UE 530 and Type B UE 520 may be merely examples of the same type of UE (for example, both may be RSUs, or both may be UEs located within or mounted on a vehicle). In some embodiments, both Type B UE 520 and Type A UE 530 have 4G and / or 5G access with a Home Public Land Mobile Network (HPLMN).

[0093] In some embodiments, each of the Type B UE 520 and Type A UE 530 includes a mobile device (ME) that supports user device functions including wireless communication with the network and other UEs, and a V2X subscriber identification module (V2XSIM) integrated with the mobile device. In some embodiments, the V2XSIM (e.g., a universal SIM (USIM) or dual USIM) includes a unique global identification information (ID) and a unique secret cryptographic key K ueIt can store data. The internal software and hardware security of the V2XSIM (for example, with respect to resilience against malicious attempts to extract sensitive data from memory) may be equal to or better than that of a normal USIM. If the V2XSIM includes a USIM, the unique global ID may be the International Mobile Subscriber Identity (IMSI) and a unique secret cryptographic key K. ue This could be a 3GPP key. In some embodiments, the global ID may indicate the server to which the UE is associated (e.g., server 510).

[0094] In some embodiments, the V2XSIM may be integrated into the UE and may not be removable. For example, the V2XSIM may be a soft SIM. Additionally or alternatively, if the V2XSIM is removable, the V2XSIM or UE may be considered tampered with if the V2XSIM is removed or inserted.

[0095] In some embodiments, when performing secure sidelink communication 500, the Type A UE 530 and / or Type B UE 520 may periodically retrieve V2X security data from the server 510. For example, if the server 510 is a UDM server or an HSS server, and the V2XSIM in the Type A UE 530 and / or Type B UE 520 is a USIM, the secure sidelink communication 500 (or a portion of the secure sidelink communication 500) may be used to update security data on the V2XSIM of the Type A UE 530 and / or Type B UE 520.

[0096] Additionally or alternatively, if Server 510 is a non-3GPP server, mutual authentication and encryption may be employed when Type A UE 530 and / or Type B UE 520 access Server 510. Access to and authentication of Server 510 may use Transport Layer Security (TLS) with public / private server keys and certificates. For example, authentication of Type A UE 530 and / or Type B UE 520, and optionally Server 510, may use the UE's unique private encryption key K ue You can use (for example, using a pre-shared key (PSK)).

[0097] In some embodiments, the server 510 may perform a security check on the V2XSIM memory of the type A UE 530 and / or type B UE 520 using a cyclic redundancy check (CRC) stored in the server 510 to determine / verify whether the UE has been tampered with. Based on that determination, the server 510 may be configured to deactivate and reactivate the UE's support for V2X security. In some embodiments, a type A UE 530 and / or type B UE 520 with deactivated V2X security cannot use the sidelink positioning protocol in the secure mode disclosed herein.

[0098] As shown in Figure 5, when performing secure sidelink communication 500, server 510 may provide a first set of key information to type B UE 520 and a second set of key information to type A UE 530. Type B UE 520 may share / transmit a portion of the first set of key information received from server 510 for encryption / authentication with type A UE 530. Type A UE 530 may then perform encryption / authentication with type B UE 520 based on the second set of key information received from server 510 and a portion of the first set of key information received from type B UE 520. Based on the encryption / authentication (for example, both type B UE 520 and type A UE 530 determine a common encryption key), type B UE 520 and type A UE 530 may then perform sidelink communication in secure mode.

[0099] On the other hand, server 510 may determine a first set of key information and securely transmit the first set of key information to type B UE 520. For example, server 510 may determine a random or partially random value RV1 (e.g., RV1 may be a bit string containing 128, 256, or more bits), a secret encryption key K1 (e.g., K1 may be a bit string containing 128 or 256 bits), and the encryption key identifier K of the secret encryption key K1. 1id (For example, a numerical or alphanumeric value) can be selected. Server 510 may then encrypt RV1 using the secret encryption key K1 to generate a new encryption key K3, which may be called the derived encryption key (for example, here K3 may be a bit string containing 128 or 256 bits). Additionally or alternatively, before determining K3, Server 510 may determine the intermediate encryption key K2 by encrypting RV1 using the encryption key K1, and K3 may be determined by encrypting RV1 using the intermediate encryption key K2.

[0100] Server 510 then uses key K3 * To generate the secret cryptographic key K known to both server 510 and type B UE 520, ue1(For example, K3 can be encrypted using the secret encryption key stored in the V2X SIM of Type B UE 520 together with the global ID of Type B UE 520). Additionally or alternatively, K ue1 can also be some other data known to both the server 510 and the Type B UE 520. In some embodiments, on the server 510, K 1id and RV1 can be stored for later use if it is later detected that the security of the Type B UE 520 has been compromised and at that time.

[0101] In some embodiments, the first set of key information sent to the Type B UE 520 can include K 1id , RV1, and K3 * . For example, the first set of key information can be securely sent to the Type B UE 520 based on a secure connection between the Type B UE 520 and the server 510 established using, for example, the public - private key pair of the server 510.

[0102] In some embodiments, the encryption process disclosed herein can be performed based on a 128 - bit or 256 - bit Advanced Encryption Standard (AES) algorithm.

[0103] Upon receiving the first set of key information, the first set of key information can be stored in the volatile random access memory (RAM) of the Type B UE 520 (e.g., the RAM of the V2X SIM or ME of the Type B UE 520). The Type B UE 520 uses K3 * included in the first set of key information and K ue1K3 can be determined based on this. In some embodiments, the determined K3 may be stored in the RAM of the Type B UE 520 and used to support sidelink positioning protocol security (as disclosed in detail below). In some embodiments, the K3 stored in the Type B UE 520 may be deleted once it is no longer needed (for example, when the SL communication session using K3 ends).

[0104] On the other hand, server 510 may determine a second set of key information and securely send the second set of key information to type A UE 530. For example, server 510 may determine key K1 * To generate the secret cryptographic key K known to both server 510 and type A UE 530, ue2 K1 (for example, a secret cryptographic key known to server 510 and used to encrypt RV1 to generate K3) can be encrypted using (for example, a secret cryptographic key stored in the V2XSIM of type A UE 530 along with the global ID of type A UE 530). Additionally or alternatively, K ue2 This could also be some other data known to both Server 510 and Type A UE 530.

[0105] In some embodiments, the second set of key information is K 1id and K1 * This may include the following. The second set of key information may be securely sent to the type A UE 530 based on a secure connection established between the type A UE 530 and the server 510 using the public-private key pair of the server 510.

[0106] Upon receiving a second set of key information, the second set of key information may be stored in the RAM of the Type A UE 530 (e.g., the RAM of the V2XSIM or ME of the Type A UE 530). The Type A UE 530, for example using the processor of the V2XSIM of the Type A UE 530, can store the K1 contained in the second set of key information. *, and the K already known in Type A UE 530 ue2 Based on this, K1 can be determined. In some embodiments, the determined K1 may be stored for a short period (e.g., a few microseconds during the calculation after K3) and may only be stored in the V2XSIM processor for this short period.

[0107] In some embodiments, the Type B UE 520 is replaced with a Type A UE 530 for encryption and / or authentication. 1id And a portion of the first set of key information, including RV1, may be transmitted in plain text. Type A UE 530 determines the use of K1 to determine K3 from RV1, based on the same or similar mechanism used by server 510 to determine K3. 1id It is possible to use (for example, encrypt RV1 using K1).

[0108] At this point, both Type B UE 520 and Type A UE 530 may possess and store K3 (for example, stored in the RAM memory of the Type B UE 520 and Type A UE 530 mobile devices, respectively). The cryptographic key K3 may enable secure encrypted communication using sidelink signaling between Type B UE 520 and Type A UE 530 (e.g., transfer of SLPP messages). A new cryptographic key for performing sidelink communication in secure mode between Type B UE 520 and Type A UE 530 (e.g., encrypting SLPP messages) may be determined and shared between Type B UE 520 and Type A UE 530 (e.g., determined by either Type B UE 520 or Type A UE 530 and sent to the other Type A UE 530 or Type B UE 520 in an encrypted form using K3). After determining and transferring a new cryptographic key for performing secure mode sidelink communication, K3 may be deleted in both type B UE 520 and type A UE 530.

[0109] Additionally or alternatively, in some embodiments, K3 may be used directly to perform secure mode sidelink communication. For example, first, type B UE 520 sends an encrypted SLPP message using K3 to type A UE 530, and as described above, the unencrypted associated K in the header of the SLPP message allows type A UE 530 to determine K3. 1id And the RV1 value may be included (i.e., in clear text).

[0110] Therefore, sidelink communication can be performed in secure mode between a type B UE 520 and a type A UE 530 based on K3, or based on a new cryptographic key determined using K3 directly. In some embodiments, sidelink positioning of a type B UE 520 (e.g., based on a sidelink positioning session) can be performed between a type B UE 520 and a type A UE 530 based on secure mode sidelink communication.

[0111] Support for secure sidelink communication between a Type B UE 520 and a Type A UE 530 has so far been described for only one Type B UE 520 and one Type A UE 530. However, there may be many Type B UE 520s and many Type A UE 530s. In such a case, each Type B UE 520 has a unique secret cryptographic key K known only to the server 510 and that Type B UE 520. ue1 Each type B UE 520 may have a unique encryption key K3, and as described above, the server 510 may assign another unique encryption key K3 to it by selecting a unique random value RV1 for that type B UE 520, which is used by the server 510 to determine the unique encryption key K3. Similarly, each type A UE 530 may have a unique secret encryption key K known only to the server 510 and its type A UE 530. ue2 It may have a secret cryptographic key K1 and an associated key identifier K 1id This may be common to some or all of the Type A UE 530.

[0112] In some embodiments, secure mode sidelink communication may be performed between different associations of type B UE 520 and / or type A UE 530. For example, when secure mode sidelink communication is performed between two type A UEs (e.g., between two type A UE 530), one of the type A UEs may perform the role of a type B UE (e.g., type B UE 520) as disclosed herein. For example, a type A UE performing the role of type B UE 530 as described in Figure 5 may select a random or partially random RV1 value and determine a K3 value based on RV1 and K1 using the same or similar mechanism as disclosed above. The two type A UEs may then establish secure sidelink communication as described above for type B UE 520 and type A UE 530. Note that a different RV1 (e.g., a different random or partially random value RV1) may be used each time a type A UE determines K3.

[0113] In some embodiments, secure mode sidelink communication may be performed between a Type A UE and multiple Type B UEs (e.g., one Type A UE is securely associated with multiple Type B UEs using a group encryption key). When performing secure mode sidelink communication, a Type A UE may establish a UE group (e.g., for session-oriented sidelink positioning) and, based on the method relating to the description in Figure 5, transfer a common group encryption key to each Type B UE using the security association already established with each Type B UE. Sidelink positioning (e.g., SLPP) messages may then be groupcast (also called multicast) by any UE in the group to all other UEs in the group and encrypted using the common group encryption key. If the group is modified (e.g., by one or more UEs joining or leaving the group) and the Type A UE remains in the group, the Type A UE may send a new common group encryption key (e.g., as described above) to each Type B UE that will become part of the new group. In some embodiments, the transmission of a common group encryption key to each type B UE may be based on unicast. Alternatively or additionally, the common group encryption key may be transmitted to all type B UEs in a single groupcast message, where the common group encryption key may be included as a separate parameter for each type B UE and encrypted using a unique encryption key for that type B UE (e.g., a K3 key).

[0114] In some embodiments, secure mode sidelink communication may be performed between associations that do not include type A UEs (e.g., using only type B UEs). When performing secure mode sidelink communication, one of the type B UEs may retain the role of a type B UE and establish a security association with the other type B UEs acting as type A UEs, based on the method relating to the description in Figure 5. For example, server 510 may provide all type B UEs with a second set of key information. In some embodiments, key K1 used by server 510 to determine the second set of key information sent to a type B UE may be different from key K1 used to determine the second set of key information sent to a type A UE (e.g., it may be considered less secure). The type B UE retaining the role of a type B UE may then select a random or partially random RV1 value and determine the K3 key value based on the RV1 and K1 of the type B UEs, using the same or similar mechanism as disclosed above. A Type B UE can then establish secure sidelink communication with each Type B UE acting as a Type A UE, as described above for Type B UE 520 and Type A UE 530. In some embodiments, a new RV1, and therefore a new K3, may be used whenever a Type B UE needs to determine a K3 key to establish a secure association with another Type B UE acting as a Type A UE.

[0115] In some embodiments, secure mode sidelink communication may also be performed in sessionless mode for sidelink positioning. For example, Type A and Type B UEs may each broadcast an SLPP message to all other nearby UEs. The K1 key assigned to the Type B UE may be used for broadcasting, and these K1 keys assigned to the Type B UE are also sent (in encrypted form) to the Type A UE by the server 510. In this case, the Type A or Type B UE broadcasting the SLPP message selects a random or partially random RV1 value, determines the K3 key value based on the RV1 and K1 of the Type B UE in the same or similar mechanism as disclosed above, encrypts the SLPP message using the K3 key, and includes RV1 and K in the SLPP message. 1id The values ​​may be included in plain text. The receiving UE then receives RV1 and K as described above. 1id An SLPP message can be decrypted by behaving as a Type A UE that determines the K3 key using a value. In some embodiments, a UE may periodically (e.g., every few minutes or every few hours) determine a new K3 key value based on a new RV1 value and K1 key for a Type B UE. The UE may then use the new K3 key to encrypt the broadcasted sidelink positioning message, just described. This allows a receiving UE to decrypt the broadcast SLPP message, and thus each K3 key can effectively be unique to only one UE.

[0116] In some embodiments, a type A UE 530 may be configured by a server 510 using multiple secret encryption keys K1. In that case, the derived encryption key K3 determined by the server 510 for any type B UE 520 may be determined using any one of the multiple secret encryption keys K1. Encryption key identifier K 1idThe data is then configured in type B UE 520 by server 510 and subsequently forwarded to type A UE 530 along with a random value RV1 in type B UE 520, so that type A UE 530 knows which secret encryption key K1 configured in type A UE 530 should be used to determine the derived encryption key K3.

[0117] In some embodiments, a Type A UE (e.g., Type A UE 530) and / or a Type B UE (e.g., Type B UE 520) may employ any suitable existing internal encryption method to protect volatile and non-volatile stored content from attacker access. A Type A UE may be required to support a higher minimum level of memory protection than a Type B UE. If a Type A UE and / or a Type B UE or the corresponding V2XSIM detects any form of tampering or unauthorized access, all security data received from the server (e.g., Server 510) may be deleted. In some embodiments, the absence of security data may result in the deactivation of V2X security support in the UE. As described above, only the server (e.g., Server 510) can reactivate V2X security support in the UE by providing new security data to the UE. If a UE (e.g., Type A UE 530 and / or Type B UE 520) accesses a server (e.g., Server 510) without prior existing security data, the server may run diagnostic routines to check the internal UE and V2XSIM integrity.

[0118] In some embodiments, a UE (e.g., a Type A UE 530 or a Type B UE 520) may set an alarm indication in non-erasable memory (e.g., PROM) when potential tampering activity is detected. The non-erasable memory may be configured to have a capacity that includes multiple indications. If a server (e.g., server 510) detects a new indication of potential tampering activity that has not been previously observed, the UE and associated vehicle may be required to be physically checked by an authorized service center.

[0119] In some embodiments, key K3 may be exposed internally within one or more UEs (e.g., type A UE 530 and / or type B UE 520) only while it is being used to encrypt and decrypt sidelink positioning messages and / or possibly other messages. The duration of exposure may vary from less than one second (e.g., when K3 is replaced by another key for secure association between two UEs) to several minutes or hours (e.g., when the K3 key is used by a UE for sessionless sidelink positioning mode). Note that each K3 key may belong to or be assigned by only one UE. This helps limit the loss of security if the K3 key value is obtained by an attacker. If the server detects potential tampering in a type B UE, the server may send the K3 value of the type B UE to all relevant type A UEs. The relevant type A UEs may then use this K3 value to refuse secure association with the type B UE.

[0120] In some embodiments, the K1 key may not be exposed internally within the UE because it is only used during the calculation of the K3 key, which can take only a few microseconds. On the other hand, the associated (encrypted) K1 *The value may be exposed in volatile memory (e.g., RAM) and can be obtained by an attacker with physical access to the corresponding UE's mobile device or V2XSIM. The V2XSIM can then detect abnormal conditions (e.g., removal / insertion of V2XSIM, loss / addition of power), and if an abnormal condition is detected, K1 * Values ​​can be deleted. K1 * If the key is obtained from the UE, the attacker can use the UE's corresponding private key (e.g., K) to determine the corresponding K1 key. ue1 and / or K ue2 ) may still be required, which means using the private key to K1 * Decrypting this may require reprogramming the UE's V2XSIM. * To mitigate the possibility of obtaining the K1 key from the value, the K1 key and its associated K3 key may be modified / updated at least daily by the server (e.g., server 510) in the UEs (e.g., type A UE 530 and type B UE 520), depending on whether an attack is suspected.

[0121] In some embodiments, an attacker may bypass security by posing as a legitimate UE owner and directly hacking into the UE's mobile device to read and / or modify Sidelink positioning protocol location data. Alternatively, in some embodiments, the Sidelink positioning functionality in a Type B UE may malfunction. Therefore, to mitigate these situations, a Type A UE may monitor location results from Type B UEs and report to a server (e.g., Server 510) any Type B UEs that provide false results (e.g., exceeding some threshold) or have unexpected location results (e.g., a static location not on a highway). These Type B UEs may be identified and reported using their key-associated ID (e.g., RV1). The server may determine when a Type B UE poses a risk and report those Type B UEs to all relevant Type A UEs. The server may then deactivate V2X security support in the Type B UEs. Owners / users of these deactivated Type B UEs may then be required to visit a service center to have V2X security support reactivated.

[0122] Figure 6 is a signaling flow diagram showing how secure sidelink communication 600, similar to that described in Figure 5, may be performed according to one embodiment. As shown in Figure 6, secure sidelink communication 600 may be performed by Server 610 (e.g., corresponding to Server 510 in Figure 5), Type B UE 620 (e.g., corresponding to Type B UE 520 in Figure 5), and Type A UE 630 (e.g., corresponding to Type A UE 530 in Figure 5).

[0123] Secure sidelink communication 600 may be initiated in block 635, where server 610 may determine cryptographic key K3 based on a random or partially random value RV1 and a secret cryptographic key K1 known to or selected by server 610. In some embodiments, server 610 may select or determine RV1 as a random or partially random value in order to determine K3, and encrypt RV1 using K1. Additionally or alternatively, before determining K3, server 610 may determine an intermediate cryptographic key K2 by encrypting RV1 using K1, and K3 may be determined by encrypting RV1 using the intermediate key K2.

[0124] In block 645, server 610 has key K1 * , a first key ID K that corresponds to key K1 and identifies key K1 1id , and key K3 * It is possible to determine the key K1. * To generate this, the secret cryptographic key K known to be of type A UE 630 is used. ue1 K1 can be encrypted using (for example, a secret cryptographic key stored in the V2XSIM of type A UE 630 along with the global ID of type A UE 630). In some embodiments, server 610 may use K1 and K to indicate server 610. 1id It can be assigned to K. For example, K 1id This may include a pointer or instruction to both K1 and server 610. In some embodiments, on server 610, K 1id And RV1 may be stored for later use if it is detected that the security of type B UE 620 has been compromised. In some embodiments, server 610 stores key K3 * To generate the secret cryptographic key K known to be of type B UE 620, ue2 K3 can be encrypted using (for example, a secret encryption key stored in the V2XSIM of type B UE 620 along with the global ID of type B UE 620).

[0125] At arrow 650, server 610 and type B UE 620 may establish a secure connection, for example, using the public-private key pair of server 610, and server 610 is K 1id RV1 and K3 * Send the first set of key information, including the key, to the Type B UE 620.

[0126] At arrow 660, server 610 and type A UE 630 may establish a secure connection, for example, using the public-private key pair of server 610, and server 610 is K 1id and K1 * Send a second set of key information, including the key, to the Type A UE 630.

[0127] At arrow 670, type B UE 620 is K in clear text (also called plain text). 1id A portion of the first set of key information received from server 610, including RV1, may be sent to type A UE 630.

[0128] In block 675, type A UE 630 is the cryptographic key identifier K in 660. 1id Based on receiving the encryption key K1 (or key K1 * ) can be identified. Type A UE 630 then receives K1 from server 610 (for example, included in the second set of key information in 660). * K3 can be determined based on RV1 received from type B UE 620 (for example, included in part of the first set of key information in 670). For example, upon receiving a second set of key information, the second set of key information may be stored in the RAM of type A UE 630 (for example, the RAM of the V2XSIM or ME of type A UE 630). Type A UE 630 may use, for example, the processor of the V2XSIM of type A UE 630 to determine K1 included in the second set of key information * , and known as type A UE 630 K ue2Based on this, K1 can be determined. In some embodiments, the determined K1 may be stored for a short period (e.g., a few microseconds during the calculation after K3), and may only be stored in the V2XSIM processor or ME processor for this short period. The Type A UE 630 then determines K3 in block 635 based on the previously determined (and K received from the Type B UE 620) using the same mechanism as or similar to that used by one of the servers 610. 1id Based on K1 (identified by) and RV1 received from type B UE 620, K3 can be determined (for example, by encrypting RV1 using K1).

[0129] In block 685, type B UE 620 receives K3 from server 610. * Based on this, K3 (for example, included in the first set of key information in 650) can be determined. Upon receiving the first set of key information, the first set of key information may be stored in the volatile random access memory (RAM) of the type B UE 620 (for example, the RAM of the V2XSIM or ME of the type B UE 620). The type B UE 620 determines K3 included in the first set of key information * , and K already known in type B UE 620 ue1 Based on this, K3 can be determined. In some embodiments, the determined K3 may be stored in the RAM of the Type B UE 620 and used to support sidelink positioning protocol security (as disclosed in detail below). In some embodiments, the K3 stored in the Type B UE 620 may be deleted once it is no longer needed (for example, when the SL communication session using K3 ends).

[0130] In block 695, the Type A UE 630 and the Type B UE 620 may establish a secure connection based on the cryptographic key K3 and perform sidelink communication using the security association between the Type A UE 630 and the Type B UE 620 (for example, by exchanging SLPP messages encrypted using the cryptographic key K3). At this point, both the Type B UE 620 and the Type A UE 630 may possess and store K3 (for example, stored in the RAM memory of the mobile devices of the Type B UE 620 and the Type A UE 630, respectively). A new encryption key or key pair for performing sidelink communication in secure mode (for example, for encrypting sidelink positioning messages) may be determined based on K3 (for example, by encrypting using K3, or by transferring a new encryption key(s) encrypted using K3) and may be shared between a type B UE 620 and a type A UE 630 (for example, determined by one of the type B UE 620 or type A UE 630 and sent to the other type A UE 630 or type B UE 620). Once a new encryption key for performing sidelink communication in secure mode is determined, K3 may be deleted in both the type B UE 620 and the type A UE 630. As part of block 695, type A UE 630 and type B UE 620 may exchange SLPP messages to obtain location results (e.g., relative location, direction, and / or range for type A UE 630 and type B UE 620), each SLPP message being encrypted using a new cryptographic key(s) and optionally integrity protected.

[0131] Additionally or alternatively, in some embodiments, K3 may be used directly to perform secure mode sidelink communication. Type B UE 620 then uses the unencrypted associated K in the header of the SLPP message. 1id An encrypted SLPP message using K3, including the RV1 value, can be sent to a type A UE 630.

[0132] Therefore, sidelink communication may be performed in secure mode between a type B UE 620 and a type A UE 630 based on a new cryptographic key(s) determined based on or directly on K3. In some embodiments, sidelink positioning of the type B UE 620 and / or type A UE 630 (e.g., based on a sidelink positioning session) may be performed between the type B UE 620 and a type A UE 630 based on secure mode sidelink communication.

[0133] Security for sidelink positioning (e.g., SLPP) sessions may mean enabling UEs to exchange SLPP messages in such a way that messages cannot be read, modified, or impersonated by entities that are not part of the session. Such entities may include other UEs, as well as devices that are not 3GPP-compliant UEs. Another method to support this is described below, which relies on the use of a common secret cryptographic key among participating UEs, thereby substantially reducing latency and processing compared to methods that rely on public-private key pairs.

[0134] The derived cryptographic key method is described below for supporting secure sidelink communication and positioning, and is further shown in Figures 7A, 7B, and 8. In the derived cryptographic key method, each participating UEn has a secret cryptographic key K n (For example, including 128 or 1024 bits) and a random or partially random value RV n Each random value RV is pre-configured (for example, by a server such as server 150 in USIM or V2XSIM) using (for example, including 128 to 256 bits, some of which may indicate the creation date and / or validity period). n This can be unique for each UEn, and RV nA UEn can be authenticated as belonging to a UEn to another UEM using a public key-based certificate that authenticates it as belonging to a UEN that has the global identification information of the UEn. Each secret cryptographic key K n This can be unique for each UEn, or M distinct secret encryption keys PK1, PK2, PK3, ... PK M A common set of keys can be randomly selected, where M can be, for example, in the range of 1,000 to 1,000,000. In this case, several UEs may share the same secret key. For example, if the number of participating UEs is N, the number of distinct secret keys is M (where N > M), and each secret key is assigned to at least one UE, then the average number of UEs sharing the same secret key is N / M. When each UE has a unique secret key, it can be assumed that M is equal to N, and the set of M distinct secret keys is PK1, PK2, PK3, ..., PK M is, K n PK n It can be made to be equal to (1 ≤ n ≤ N).

[0135] Each UEn has its own secret encryption key K n The secret encryption key ID K is shown. IDn It is further constructed using, for example, K IDn This is a fixed set of secret encryption keys PK1, PK2, PK3, ...PK M The secret encryption key K n It is an index or pointer to the DK. Each UEn is one of the M derived cryptographic keys DK. n1 DK n2 DK n3 ,...DK nM It is further composed using a set of secret encryption keys PK1, PK2, PK3, ...PK MDetermined by a server that knows the fixed set (e.g., server 150, computer system 1300, Intelligent Transport System (ITS) server, or Sidelink Positioning Key Management Function (SLPKMF)). The derived encryption key can be determined by the server as follows. DK nm = Cipher m (PK m , RV n ) (1 ≤ n ≤ N, 1 ≤ m ≤ M) (Equation 1)

[0136] Here, Cipher m is an arbitrary encryption algorithm fixed for the secret encryption key PK m [[ID=]18]using the random value RV n to encrypt the secret encryption key PK m . For example, Cipher m can be an AES encryption algorithm that uses one or more known parameter values (e.g., a known counter value, etc.). Any UEn composed of the secret encryption key PK m is also configured to know the fixed encryption algorithm Cipher m . The derived encryption keys DK n1 , DK n2 , DK n3 ,... DK nM can each include the same number of bits (e.g., 128 bits). In some embodiments, the encryption algorithm Cipher m is the same for all of the M secret encryption keys PK m .

[0137] Periodically (e.g., daily, weekly, or monthly), the random value RV n , the M derived encryption keys DK n1 , DK n2 , DK n3 ,... DK nM , and optionally the secret encryption key K n and the secret encryption key ID KIDn However, for example, during the night when network bandwidth is abundant, each UE is handled by the server. n In this case, it can be replaced with a new set. Alternatively or additionally, the M derived cryptographic keys can be extended with additional derived cryptographic keys when additional secret cryptographic keys are added to the current M secret cryptographic keys.

[0138] Random or partially random value RV n UE n The set of derived cryptographic keys DK nm , secret encryption keys PK1, PK2, PK3, ...PK M Set of secret encryption keys K n Each UE using n Configuration and corresponding secret encryption key IDK IDn This can be performed by a server, for example, server 150. The configuration can be secure. For example, the server can establish a secure connection to the UEn, or the UE n This allows for the establishment of a secure connection to the server, where security is based on the server's public-private key pair, for example, using a Transport Layer Security (TLS) connection.

[0139] A pair of UEs and a group of UEs can establish a secure sidelink (e.g., SLPP) session using configured key information. In the case of a pair of UEs 1 and 2 (for example, UEs 1 and 2 may be UE 105 or UE 1200), the procedure for enabling a secure sidelink positioning session is shown in Figure 7A and is as follows, where the normal font in Figure 7A represents plain (unencrypted) text and the italic bold font represents encrypted text.

[0140] In step 1 of Figure 7A, UE 1 and UE 2 have their secret cryptographic key ID K ID1 and K ID2Then, optionally, swap those random values ​​RV1 and RV2 in the plaintext. One of the UEs (in this case UE 1) (for example, the secret encryption key ID K) ID1 and K ID2 , and / or based on some characteristics or relationships of random values ​​RV1 and RV2, or based on which of UE 1 and 2 discovered or was discovered by the other UE, it assumes the role of coordinator.

[0141] In stage 2, UE 1 transmits its random value RV1 (if not exchanged in stage 1) and instructions for the cryptographic operation Cipher 1 (which may include, for example, an encryption algorithm and / or a counter value and / or other values ​​(one or more)) to UE 2 in plaintext. UE 1 also transmits the first key component KC1 in ciphertext. KC1 may be a random bit sequence determined by UE 1 (for example, including 128 bits). The encryption of KC1 is performed using the K received in stage 1. ID2 However, the secret encryption key for UE 2 is PK x When demonstrating that this is the case, the derived cryptographic key DK configured in UE 1 1x The cryptographic operation uses Cipher 1.

[0142] In stage 3, UE 2, according to formula 1, obtains a random value RV1 from stage 1 or 2 and the secret cryptographic key PK of UE 2. x DK derived using 1x Determine the following, then perform the cryptographic operation Cipher 1 and the derived cryptographic key DK 1x Based on this, the first key component KC1 is deciphered and obtained.

[0143] In stage 4, UE 2 returns to UE 1 in plaintext its random value RV2 (if not exchanged in stage 1) and instructions for the cryptographic operation Cipher 2 (which may include, for example, an encryption algorithm and / or a counter value and / or other values ​​(one or more)). UE 2 also transmits the second key component KC2 in ciphertext. KC2 may be a random bit sequence determined by UE 2 (for example, including 128 bits). The encryption of KC2 is performed using the K received in stage 1. ID1 However, the secret encryption key for UE 1 is PK y When demonstrating this, the derived cryptographic key DK configured in UE 2 2y The cryptographic operation uses Cipher 2.

[0144] In stage 5, UE 1, according to formula 1, obtains a random value RV2 from stage 1 or 4 and the secret cryptographic key PK of UE 1. y DK derived using 2y Determine the following, and then the derived cryptographic key DK 2y Based on the cryptographic operation Cipher 2, the second key component KC2 is decrypted and obtained.

[0145] In stage 6, UEs 1 and 2 each determine a common encryption key and, optionally, a common integrity key by combining the first key component KC1 and the second key component KC2, respectively. For example, KC1 and KC2 may be combined using one or more of the following: concatenation, addition, exclusive OR, multiplication, interleaving, and truncation.

[0146] In stage 7, UE 1 and UE 2 exchange sidelink (e.g., SLPP) messages to encrypt the sidelink messages and optionally (e.g., use digital signatures) provide integrity protection for the sidelink messages by using a shared key(s) from stage 6 to perform sidelink positioning.

[0147] The messages used to transfer the key and encryption-related information in stages 1, 2, and 4 of Figure 12 may be messages used for UE discovery and / or to establish an SLPP session. For example, the UE discovery message may be used in stage 1 to exchange the key ID and optionally a random value, and / or the SLPP session creation request and SLPP session creation acceptance may be used in stages 2 and 4, respectively.

[0148] Any other UE (different from UE 1 and UE 2) capable of receiving and decrypting messages transmitted in stages 1, 2, and 4 will have a secret encryption key ID, K, because the other UE has only one secret encryption key and not two. ID1 and K ID2 Therefore, if the associated secret encryption keys K1 and K2 are different, it will be impossible to decrypt both the first key component KC1 transmitted in stage 2 and the second key component KC2 transmitted in stage 4. Secret encryption key ID, K ID1 and K ID2 If (and therefore the associated secret cryptographic keys K1 and K2) are the same, and if the other UE also has the same secret cryptographic key, then the other UE can decipher both the first key component KC1 and the second key component KC2, thereby determining the common encryption key and an optional common integrity protection key in step 6, which will enable the other UE to read, modify, and / or impersonate the sidelink message exchanged in step 7. For any given pair of UEs 1 and 2 and any given other UE, this probability (i.e., the probability that all three secret cryptographic keys match) is M -2 And when M=1000, it is 10 -6 And when M=1,000,000, it is 10 -12 And this is very low. However, to further reduce the probability, each UEn has its usual secret cryptographic key K n and associated key ID K * IDnDifferent from the secret encryption keys PK1, PK2, PK3, ...PK M The second secret encryption key K from the set * n It can be pre-configured using. In the procedure in Figure 7A, in step 2, UE 1 then, based on the fact that the two secret cryptographic key IDs exchanged in step 1 are the same, its second secret cryptographic key ID K * ID1 It can include this in plain text and send it to UE 2 in plain text. In step 4, UE 2 then receives the K received in step 2. * ID1 However, UE 1's second secret encryption key is PK z When demonstrating this, the derived cryptographic key DK is constructed in UE 2. 2z The second key component KC2 is encrypted using the cryptographic operation Cipher 2. In step 5, UE 1 encrypts the second secret cryptographic key PK of UE 1 using a random value RV2 from step 1 or step 4 and Equation 1. z DK derived using 2z Determine the following, and then the derived cryptographic key DK 2z Based on the cryptographic operation Cipher 2, the second key component KC2 is decrypted and obtained. This reduces the probability that another UE can obtain the common key(s) determined in stage 6.

[0149] When each participating UE is configured using the first and second secret encryption keys as described above, then any given pair of UEs 1 and 2 and any given other UEs that can receive and decrypt the message transmitted in steps 1, 2, and 4 of Figure 7A, the other UEs (A) use the same secret encryption key K used by UEs 1 and 2. * If it is constructed using 1 and K2, and if (B)UE 1 and 2 have the same first secret cryptographic key, then it is only possible to decrypt both the first key component KC1 transmitted in stage 2 and the second key component KC2 transmitted in stage 4. The probability of condition (B) is M -1The probability of condition (A) is (M * (M-1) / 2) -1 Therefore, the probability of both conditions occurring is approximately 2. * M -3 And when M=1000, 2 * 10 -9 And when M=1,000,000, 2 * 10 -18 This is extremely low.

[0150] The procedure shown in Figure 7A can be simplified by removing the transfer of the first and second key components KC1 and KC2 in steps 2 and 4. The simplified procedure is shown in Figure 7B.

[0151] In step 1 of Figure 7B, UE 1 has its secret encryption key ID (or, if UE 1 has two secret encryption keys, the first secret encryption key ID) K ID1 UE 1 sends the random value RV1 to UE 2 in plain text. UE 1 also sends one or more counters and / or random values, denoted as Counter1, to UE 2 (also in plain text). The counter(s) and / or random values ​​may later be used to determine one or more unique common encryption keys. For example, the counter(s) could be an integer value not previously used by UE 1, and the random value could be a random bit string having 64 to 256 bits.

[0152] In stage 2, UE 2 has its secret encryption key ID K ID2 And its random value RV2 is sent to UE 1 in plain text. UE 2 also sends one or more counters and / or random values ​​denoted as Counter2 to UE 1 (also in plain text). The counter(s) and / or random values ​​may be as described for UE 1 (but usually have different values). If UE 2 is configured with the first and second secret cryptographic keys as described above, and the secret cryptographic key ID K received from UE 1 in step 1. ID1The first secret encryption key of UE 2 is the secret encryption key ID K ID2 If the same, then in step 2, UE 2 will have the secret cryptographic key ID K of UE 2's first secret cryptographic key. ID2 Instead, the secret key ID K of UE 2's second secret encryption key. * ID2 Send this to UE1.

[0153] In stage 3, UE 1 uses the derived cryptographic key DK. 1x and DK 2y Determine. DK 1x This is already configured in UE 1, and the secret encryption key of UE 2 is PK x K ID2 (or K * ID2 When this indicates, the secret encryption key ID K received from UE 2 in stage 2 ID2 (or K * ID2 Identified from ). DK 2y The secret encryption key for UE 1 is PK y In this case, the random value RV2 received from UE 2 in step 2, and the secret encryption key PK of UE 1 are used. y Therefore, it is calculated by UE 1 using equation (1).

[0154] In stage 4, UE 2 uses the derived cryptographic key DK. 1x and DK 2y Determine the same thing. DK 2y This is already configured in UE 2, and the secret encryption key of UE 1 is PK y K ID1 When this is shown, the secret encryption key ID K received from UE 1 in stage 1 ID1 Identified by DK 1x This includes the random value RV1 received from UE 1 in stage 1, and the key ID K sent to UE 1 in stage 2. ID2 or K * ID2 The corresponding UE 2 secret encryption key PK x Therefore, it is calculated by UE 2 using equation (1).

[0155] In stage 5, UE 1 uses the derived cryptographic key DK. 1x and DK 2y The common encryption key and, optionally, the common integrity key are determined by combining the counter value(s) and / or random values ​​Counter1 (sent in Stage 1) and Counter2 (received in Stage 2) (determined in Stage 3). The combination may use one or more of the following methods: encryption, concatenation, addition, exclusive OR, multiplication, interleaving, and truncation. For example, if Counter1 and Counter2 each contain one random value and one counter, the two random values ​​may first be combined (e.g., by concatenation), and then the DK 1x It is encrypted using one of the counter values, and then DK 2y The data is then re-encrypted using other counter values, and the result is truncated, in some cases, to yield a key with 128 or 256 bits.

[0156] In stage 6, UE 2 uses the same derived cryptographic key DK. 1x and DK 2y The same common encryption key, and optionally the same common integrity key, is determined by combining the (determined in stage 4) with the counter value(s) and / or random values ​​Counter1 (received in stage 1) and Counter2 (transmitted in stage 2). The combination is the same as that performed by UE 1 in stage 5.

[0157] In stage 7, UE 1 and UE 2 exchange sidelink (e.g., SLPP) messages to encrypt the sidelink messages and optionally (e.g., use digital signatures) provide integrity protection for the sidelink messages by using one or more common keys from stages 5 and 6 to perform sidelink positioning.

[0158] The messages used to transfer the key and encryption-related information in stages 1 and 2 of Figure 7B may be messages used for UE discovery and / or to establish an SLPP session. For example, an SLPP session creation request message and an SLPP session creation acceptance message may be used in stages 1 and 2, respectively.

[0159] For a group of UEs 1, 2, 3, ..., r (r>2), the procedure shown in Figure 8 can be used to support secure SL positioning for the group of UEs, where the normal font in Figure 8 represents plain (unencrypted) text, and the italic bold font represents encrypted text. The UE preconfiguration assumptions previously described for Figures 7A and 7B also apply to Figure 8.

[0160] In step 1 of Figure 8, Coordinator UE 1 transmits its secret cryptographic key ID K (for example, via a single groupcast message or r-1 separate unicast messages). ID1 The random value RV1, and optionally (for example, when Figure 7B is used in step 3) one or more counters and / or random value Counter1, are sent in plain text to each of the other r-1 UEs.

[0161] In stage 2, each of the other r-1 UEs p (2 ≤ p ≤ r) has its own secret cryptographic key ID K IDp , that random value RV p , and optionally (for example, when Figure 7B is used in step 3) one or more counters and / or random value Counter p The following is sent to UE 1 in plain text. If UE p is configured with the first and second secret encryption keys as described above, and the secret encryption key ID K received from UE 1 in step 1 ID1 The secret key ID K of UE p's first secret key IDp If the same, then in step 2, UE p has the secret key ID K of UE p's first secret key.IDp Instead, the secret key ID K of UE p's second secret encryption key. * IDp Send this to UE1.

[0162] In step 3, Coordinator UE 1, together with each of the other r-1 UEs, performs either steps 2-6 in Figure 7A or steps 3-6 in Figure 7B, as previously described. In the case of Figure 7A, the message may be unicast as in the case of Figure 7A, or Coordinator UE 1 may groupcast the message to all r-1 other UEs in step 2 of Figure 7A. In the case of groupcasting, the message sent in step 2 of Figure 7A may include a random value RV1 (if not sent in step 1), instructions for the plaintext cryptographic operation Cipher 1, and a first key component KC1 included q times, where each inclusion of KC1 is a different derived cryptographic key DK 1s The cryptographic operation is encrypted using Cipher 1, and at least one other UE uses the secret encryption key PK in stage 2. s This shows that q is the number of different secret cryptographic key IDs shown by r-1 other UEs in step 2. Derived cryptographic key DK 1s The inclusion of KC1 encrypted using the cryptographic operation Cipher 1 also includes the private cryptographic key PK in plaintext. s It can be accompanied by a key ID, and as a result, the secret cryptographic key PK s Any UE constructed using this will know which of the KC1 encryptions needs to be decrypted.

[0163] In step 4 of Figure 8, Coordinator UE 1 uses the common key(s) determined for each of the other r-1 UEs in step 3 to send a common group key or pair of group keys, which will be used by all r UEs, in an encrypted form to each of the other r-1 UEs (e.g., using groupcast or unicast). For each UE p (2 ≤ p ≤ r) to which the common group key(s) is sent, UE 1, as part of step 3, encrypts the common group key(s) for UE 1 and p using the common key(s) determined by UE 1 and UE p. UE 1 may send the common group key(s) to the other r-1 UEs by groupcasting a single SLPP session start message (e.g., an SLPP session start message) containing the common group key(s) in an encrypted form to the other r-1 UEs.

[0164] In stage 5, a group of r UEs exchange SLPP messages to encrypt the SLPP messages and optionally perform sidelink positioning using a common group key(s) from stage 4 to provide integrity protection for the SLPP messages (e.g., using digital signatures).

[0165] The solutions for secure sidelink communication and secure sidelink positioning previously described with respect to Figures 5 and 6 can be considered a degenerate version of the derived cryptographic key method described with respect to Figures 7A, 7B, and 8, where a type B UE is constructed using a random value (RV1) and a derived cryptographic key (K3), and a type A UE is constructed using a secret cryptographic key (K1), and the derived cryptographic key for a type B UE can be determined using the secret cryptographic key and the random value, although the reverse (a type B UE configured as and acting as a type A UE, and a type A UE configured as and acting as a type B UE) may not be used.

[0166] Figure 9 is a flowchart of a method 900 for secure sidelink communication between a first UE (e.g., a Type B UE as described in Figures 5 and 6) and a second UE (e.g., a Type A UE as described in Figures 5 and 6), executed by a server, according to one embodiment. In some embodiments, the server may correspond to server 510 in Figure 5 and / or server 610 in Figure 6. The means / configurations for performing the functions illustrated in one or more of the blocks shown in Figure 9 may be performed by hardware and / or software components of a computer system, as described herein. Exemplary components of a computer system are shown in Figure 13 and described in more detail below.

[0167] In block 910, the function includes determining a first cryptographic key (e.g., cryptographic key K3 as described in Figures 5 and 6) using a random or partially random value (e.g., RV1 as described in Figures 5 and 6) and a first secret cryptographic key known to the server (e.g., K1 as described in Figures 5 and 6). In some embodiments, the server may select RV1 from a pool of random or partially random values ​​and encrypt RV1 using K1 known to K3. Additionally or alternatively, before determining K3, the server may determine an intermediate cryptographic key K2 by encrypting RV1 using K1, and K3 may be determined by encrypting K2.

[0168] The means for performing functions in block 910 may include a bus 1305 of a computer system 1300 as shown in Figure 13, a processor(s) 1310, a communication subsystem 1330, a memory 1335, and / or other components.

[0169] In block 920, the function is to use a second secret cryptographic key known to the first UE (e.g., K as described in Figures 5 and 6). ueB By encrypting the first encryption key using ), the second encryption key (for example, K3 as described in Figures 5 and 6) is obtained. * This includes determining whether the server is K3.* To generate the secret cryptographic key K known to type B UE, ueB K3 can be encrypted using (for example, a secret encryption key stored in the V2XSIM of a type B UE along with the global ID of a type B UE). Additionally or alternatively, K ueB This could also be some other data known to both the server and type B UE.

[0170] The means for performing functions in block 920 may include a bus 1305 of a computer system 1300 as shown in Figure 13, a processor(s) 1310, a communication subsystem 1330, a memory 1335, and / or other components.

[0171] In block 930, the function includes securely transmitting key information to the first UE, including a second cryptographic key and a random or partially random value and a key ID. In some embodiments, the first key information relating to the description in Figures 5 and 6 may be securely transmitted to the first UE. The key ID is the K relating to the description in Figures 5 and 6. 1id This can be supported. For example, the server can have K1 and K indicating the server in RV1. 1id It can be assigned to K. For example, K 1id This may include pointers or instructions to both K1 and the server. In some embodiments, on the server, K 1id This can be stored for later use if the security of a Type B UE is detected to be compromised. In some embodiments, the server uses K3 * To generate the secret cryptographic key K known to type B UE, ueB K3 can be encrypted using (for example, a secret encryption key stored in the V2XSIM of a type B UE along with the global ID of a type B UE). Additionally or alternatively, K ueB This could also be some other data known to both the server and the Type B UE. In some embodiments, the server and the Type B UE establish a secure connection, for example, using the server's public-private key pair. 1idRV1 and K3 * The first key information, including the above, can be securely transmitted to the Type B UE.

[0172] The means for performing functions in block 930 may include a bus 1305 of a computer system 1300 as shown in Figure 13, a processor(s) 1310, a communication subsystem 1330, a memory 1335, and / or other components.

[0173] In block 940, the function is to obtain a third secret key known to the second UE (K as described in Figures 5 and 6). ueA By encrypting the first secret key using ), a third cryptographic key (for example, K1 as described in Figures 5 and 6) is obtained. * This includes determining the key K1. * To generate the private key K known to type A UE, ueA K1 (for example, a secret key known to the server and used to encrypt RV1 in order to generate K3) can be encrypted using (for example, a secret key stored in a V2XSIM of type A UE along with a global ID of type A UE). Additionally or alternatively, K ueA This could also be some other data known to both the server and type A UE.

[0174] The means for performing the function in block 940 may include a bus 1305 of a computer system 1300 as shown in Figure 13, a processor(s) 1310, a communication subsystem 1330, a memory 1335, and / or other components.

[0175] In block 950, the function includes securely transmitting a third cryptographic key and key ID to a second UE. For example, the server and a type A UE establish a secure connection using, for example, the server's public-private key pair. 1id and K1 * Second key information, including the above, may be sent to a type A UE.

[0176] The means for performing functions in block 950 may include a bus 1305 of a computer system 1300 as shown in Figure 13, a processor(s) 1310, a communication subsystem 1330, a memory 1335, and / or other components.

[0177] In some embodiments, method 900 further includes updating the first secret key over a predetermined period of time.

[0178] In some embodiments, method 900 further includes transmitting a second cryptographic key and a first key ID to a second UE in response to detecting tampering with the first UE.

[0179] In some embodiments, method 900 further includes verifying a first or second UE to access a server based on performing a cyclic redundancy check (CRC) on the vehicle-to-everything (V2X) subscriber identification module (SIM) memory of the corresponding UE.

[0180] In some embodiments, in method 900, the first encryption key, the second encryption key, the third encryption key, or any combination thereof is determined based on a 128-bit AES algorithm.

[0181] In some embodiments, method 900 further includes receiving a notification from a second UE reporting an incorrect result in the sidelink positioning of the first UE, and considering the second UE ineligible to participate in the sidelink positioning.

[0182] Figure 10 is a flowchart of a method 1000 for secure sidelink communication between a first UE (e.g., a type B UE as described in Figures 5 and 6) and a second UE (e.g., a type A UE as described in Figures 5 and 6), performed by a type B UE, according to one embodiment. In some embodiments, the type B UE may correspond to the type B UE 520 in Figure 5 and / or the type B UE 620 in Figure 6. The means / configurations for performing the functions illustrated in one or more of the blocks shown in Figure 10 may be performed by hardware and / or software components of the UE, as described herein. Exemplary components of the UE are shown in Figure 12 and described in more detail below.

[0183] In block 1010, the function is to receive a first cryptographic key (for example, K3 in the description of Figures 5 and 6) from a server (for example, the server relating to Figures 5 and 6). * ), and receiving first key information including a random or partially random value and a key ID. In some embodiments, the first key information relating to the description in Figures 5 and 6 may be received by the first UE. The key ID is K relating to the description in Figures 5 and 6. 1id This can be supported. For example, the server can have K1 and K indicating the server in RV1. 1id It can be assigned to K. For example, K 1id This may include pointers or instructions to both K1 and the server. In some embodiments, on the server, K 1id This can be stored for later use if the security of a Type B UE is detected to be compromised. In some embodiments, the server uses K3 * To generate the private key K known to type B UE, ueB K3 can be encrypted using (for example, a secret key stored in a V2XSIM of type B UE along with a global ID of type B UE). Additionally or alternatively, K ueBThis could also be some other data known to both the server and the Type B UE. In some embodiments, the server and the Type B UE establish a secure connection, for example, using the server's public-private key pair. 1id RV1 and K3 * The first key information, including the above, can be securely transmitted to the Type B UE.

[0184] The means for performing the function in block 1010 may include the UE1200 bus 1205, one or more processors 1210, a wireless communication interface 1230, memory 1260, and / or other components as shown in Figure 12.

[0185] In block 1020, the function includes transmitting the first key information to the second UE. In some embodiments, as described above, the first key information in this specification is random or partially random values ​​RV1 and K 1id It may include.

[0186] The means for performing the function in block 1020 may include the UE1200 bus 1205, one or more processors 1210, a wireless communication interface 1230, memory 1260, and / or other components, as shown in Figure 12.

[0187] In block 1030, the function is to have a first cryptographic key and a first secret key known to the first UE (for example, K as described in Figures 5 and 6). ueB This includes determining a second cryptographic key (for example, cryptographic key K3 as described in Figures 5 and 6) using ).

[0188] The means for performing the function in block 1030 may include the UE1200 bus 1205, one or more processors 1210, a wireless communication interface 1230, memory 1260, and / or other components as shown in Figure 12.

[0189] In block 1040, the function includes performing secure communication with a second UE based on a second cryptographic key. For example, a first UE (e.g., a type B UE) and a second UE (e.g., a type A UE) may establish a secure connection based on cryptographic key K3 and perform sidelink communication using a security association between the first and second UEs. In some embodiments, a new cryptographic key for performing sidelink communication in secure mode (e.g., for encrypting sidelink positioning messages) may be determined based on K3 (e.g., by encrypting K3) and may be shared between the first and second UEs (e.g., determined by one of the first or second UEs and transmitted to the other of the second or first UEs).

[0190] The means for performing the function in block 1040 may include the UE1200 bus 1205, one or more processors 1210, a wireless communication interface 1230, memory 1260, and / or other components as shown in Figure 12.

[0191] In some embodiments, the second cryptographic key is stored in the volatile random access memory (RAM) of the first UE.

[0192] In some embodiments, secure communication includes sidelink positioning with a second UE, and method 1000 further includes removing a second cryptographic key from volatile RAM and obtaining a third cryptographic key (e.g., a new cryptographic key for performing sidelink communication in secure mode as described in Figures 5 and 6) determined based on the second cryptographic key for encrypting sidelink positioning messages for performing sidelink positioning with the second UE.

[0193] In some embodiments, when Method 1000 is performed between associations that do not include a Type A UE (e.g., only a Type B UE), as disclosed above, one of the Type B UEs may take on the role of a Type A UE. Method 1000 receives a fourth cryptographic key (e.g., another K1 as described in Figures 5 and 6) from the server. * ) receive the fourth encryption key and the fourth secret key known to the first UE (for example, K1 as described in Figures 5 and 6). * K corresponding to ueA Based on this, the server has a third secret key known to it (for example, K1 as described in Figures 5 and 6). * Method 1000 may further include determining the corresponding K1) and receiving second key information from a third UE (e.g., another type B UE relating to the description in Figures 5 and 6) which includes a second random or partially random value (e.g., another RV1 relating to the description in Figures 5 and 6), and a third secret key and a second key ID indicating a server. Method 1000 may further include determining a fifth cryptographic key (e.g., a new K3 relating to the description in Figures 5 and 6) based on the third secret key and the second random or partially random value contained in the second key information, and performing secure communication with the third UE based on the fifth cryptographic key.

[0194] In some embodiments, when method 1000 is executed in sessionless mode (e.g., when type A and type B UEs can broadcast sidelink positioning protocol messages to all nearby UEs), as disclosed above, method 1000 broadcasts a sidelink positioning message based on a first secret key, determines a fourth encryption key (e.g., new k3 related to the descriptions of FIGS. 5 and 6) using a second random or partially random value (e.g., new RV1 related to the descriptions of FIGS. 5 and 6) and the first secret key, encrypts the sidelink positioning message based on the fourth encryption key, and broadcasts an encrypted sidelink positioning message, wherein a header of the encrypted sidelink positioning message includes second key information including the second random or partially random value and a second key ID. The second key ID indicates the first secret key and the server.

[0195] In some embodiments, method 1000 further includes recording an instruction in a non-erasable memory in response to detecting an unauthorized access.

[0196] FIG. 11 is a flowchart of a method 1100 for secure sidelink communication between a first UE (e.g., type B UE related to the descriptions of FIGS. 5 and 6) and a second UE (e.g., type A UE related to the descriptions of FIGS. 5 and 6) executed by a type A UE according to an embodiment. In some embodiments, the type A UE may correspond to type A UE 530 of FIG. 5 and / or type A UE 630 of FIG. 6. The means / components for performing the functions illustrated in one or more of the blocks shown in FIG. 11 may be executed by hardware and / or software components of the UE, as described herein. Exemplary components of the UE are shown in FIG. 12 and will be described in more detail below.

[0197] In block 1110, the function includes receiving a first encryption key (e.g., K1 related to the descriptions of FIGS. 5 and 6) from a server (e.g., the server related to the descriptions of FIGS. 5 and 6). * )

[0198] The means for performing the function in block 1110 may include a bus 1205, a processor(s) 1210, a wireless communication interface 1230, a memory 1260, and / or other components of the UE 1200 as shown in FIG. 12.

[0199] In block 1120, the function includes determining a first secret key (e.g., K1 related to the descriptions of FIGS. 5 and 6) known to the server based on the first encryption key and a second secret key (e.g., K related to the descriptions of FIGS. 5 and 6) known to the second UE. ueA )

[0200] The means for performing the function in block 1120 may include a bus 1205, a processor(s) 1210, a wireless communication interface 1230, a memory 1260, and / or other components of the UE 1200 as shown in FIG. 12.

[0201] In block 1130, the function includes receiving first key information including a first random or partially random value (e.g., RV1 related to the descriptions of FIGS. 5 and 6) and a first key ID (e.g., K related to the descriptions of FIGS. 5 and 6) from the first UE. 1id )

[0202] The means for performing the function in block 1130 may include a bus 1205, a processor(s) 1210, a wireless communication interface 1230, a memory 1260, and / or other components of the UE 1200 as shown in FIG.​​​In block 1140, the function includes determining a second cryptographic key (for example, cryptographic key K3 as described in Figures 5 and 6) based on a first secret key and a first random or partially random value contained in the first key information.

[0204] The means for performing the function in block 1140 may include the UE1200 bus 1205, one or more processors 1210, a wireless communication interface 1230, memory 1260, and / or other components as shown in Figure 12.

[0205] In block 1150, the function includes performing secure communication with a first UE based on a second cryptographic key. For example, a first UE (e.g., a type B UE) and a second UE (e.g., a type A UE) may establish a secure connection based on cryptographic key K3 and perform sidelink communication using a security association between the first and second UEs. In some embodiments, a new cryptographic key for performing sidelink communication in secure mode (e.g., for encrypting sidelink positioning messages) may be determined based on K3 (e.g., by encrypting K3) and may be shared between the first and second UEs (e.g., determined by one of the first or second UEs and transmitted to the other of the second or first UEs).

[0206] The means for performing functions in block 1150 may include the UE1200 bus 1205, one or more processors 1210, a wireless communication interface 1230, memory 1260, and / or other components as shown in Figure 12.

[0207] In some embodiments, the determined first secret key is stored in the vehicle-to-everything (V2X) subscriber identification module (SIM) processor of the second UE.

[0208] In some embodiments, the first key ID indicates the first secret key (k1) and the server.

[0209] In some embodiments, secure communication includes sidelink positioning with a first UE, and method 1100 further includes removing a second cryptographic key from volatile RAM and obtaining a third cryptographic key determined based on the second cryptographic key in order to encrypt a sidelink positioning message for sidelink positioning with the second UE.

[0210] In some embodiments, when there is no first UE (e.g., a type B UE), one of the second UEs (e.g., a type A UE) may take on the role of a type B UE. For example, method 1100 receives a fourth cryptographic key (e.g., a new K3) from the server. * Method 1100 may further include receiving second key information, which includes a second random or partially random value, a third secret key, and a second key ID indicating a server. Method 1100 may further include transmitting the second key ID to the third UE, determining a fifth cryptographic key (e.g., a new K3) based on a fourth cryptographic key and a fourth secret key known to the second UE, and performing secure communication with the third UE based on the fifth cryptographic key.

[0211] In some embodiments, when performing sessionless mode, method 1100 may further include broadcasting a sidelink positioning message based on a first secret key (e.g., K1), determining a fourth cryptographic key (e.g., a new K3) using a second random or partially random value and the first secret key, and encrypting the sidelink positioning message based on the fourth cryptographic key. Method 1100 may further include broadcasting an encrypted sidelink positioning message, the header of the encrypted sidelink positioning message including a second key information including a second random or partially random value and a second key ID indicating the fourth secret key, as well as a server.

[0212] In some embodiments, method 1100 may further include recording instructions in non-erasable memory in response to the detection of unauthorized access.

[0213] Figure 12 is a block diagram of one embodiment of UE 1200, which may be used as described herein (for example, in relation to previously described figures) and may correspond to UE 105 in Figures 1-3, UE 520 and UE 530 in Figure 5, UE 620 and UE 630 in Figure 6, UE 1 or UE 2 in Figures 7A, 7B, and UE 3 or UEr in Figure 8. In some embodiments, for example, UE 1200 may comprise, for example, a mobile (e.g., movable / portable) device (e.g., a tablet, laptop, vehicle, etc.). It should be noted that Figure 12 is intended only to provide a generalized illustration of various components, and some or all of those components may be used as needed.

[0214] A UE1200 is shown having hardware elements that can be electrically coupled via bus 1205 (or otherwise may communicate as needed). The hardware elements may include, but are not limited to, one or more general-purpose processors (e.g., application processors), one or more dedicated processors (such as digital signal processor (DSP) chips, graphics acceleration processors, application-specific integrated circuits (ASICs)), and / or other processing structures or means, and may include a processor(s)1210. The processor(s)1210 may include one or more processing units that can be housed in a single integrated circuit (IC) or multiple ICs. As shown in Figure 12, some embodiments may have a separate DSP 1220 depending on the desired functionality. Location determination and / or other determinations based on wireless communication may be performed in the processor(s)1210 and / or the wireless communication interface 1230 (described below). The UE1200 may also include, but is not limited to, one or more input devices 1270, which may include one or more keyboards, touchscreens, touchpads, microphones, buttons, dials, switches, etc., and one or more output devices 1215, which may include one or more displays (e.g., touchscreens), light-emitting diodes (LEDs), speakers, etc.

[0215] The UE1200 may also include, but is not limited to, a wireless communication interface 1230 which may include a modem, network card, infrared communication device, wireless communication device, and / or chipset (such as a Bluetooth® device, IEEE 802.11 device, IEEE 802.15.4 device, Wi-Fi device, WiMAX device, WAN device, and / or various cellular devices), which can enable the UE1200 to communicate with other devices as described in the embodiments above. The wireless communication interface 1230 can enable data and signaling to be communicated (e.g., transmitted and received) with base stations of the network via, for example, eNBs, gNBs, ng-eNBs, access points, various base stations and / or other access node types, and / or other network components, computer systems, and / or any other electronic devices coupled to communicate with base stations, as described herein. Communication may be performed via one or more wireless communication antennas 1232 that transmit and / or receive wireless signals 1234. According to some embodiments, the wireless communication antenna(s) 1232 may include a plurality of individual antennas, an antenna array, or any combination thereof. The antenna(s) 1232 may be capable of transmitting and receiving wireless signals using beams (e.g., a Tx beam and an Rx beam). Beamforming may be performed using digital and / or analog beamforming techniques with their respective digital and / or analog circuit configurations. The wireless communication interface 1230 may include such circuit configurations.

[0216] Depending on the desired functionality, the wireless communication interface 1230 may include separate receivers and transmitters, or any combination of transceivers, transmitters, and / or receivers, for communication with base stations (e.g., ng-eNB and gNB) and other ground transceivers such as wireless devices and access points. The UE 1200 may communicate with different data networks, which may comprise various network types. For example, one such network type may include a wireless wide area network (WWAN), which could be a code division multiple access (CDMA) network, a time division multiple access (TDMA) network, a frequency division multiple access (FDMA) network, an orthogonal frequency division multiple access (OFDMA) network, a single-carrier frequency division multiple access (SC-FDMA) network, or a WiMAX (IEEE 802.16) network. The CDMA network may implement one or more radio access technologies (RATs), such as CDMA2000® and wideband code division multiple access (WCDMA). CDMA2000® includes the IS-95 standard, the IS-2000 standard, and / or the IS-856 standard. TDMA networks may implement the Global System for Mobile Communications (GSM), Digital Advanced Mobile Phone Systems (D-AMPS), or any other RAT. OFDMA networks may employ Long-Term Evolution (LTE), LTE Advanced, 5th Generation (5G) New Radio (NR), etc. 5G NR, LTE, LTE Advanced, GSM, and WCDMA are, 第3It is described in documents from the Generation Partnership Project (3GPP). CDMA2000® is described in documents from an organization called "3rd Generation Partnership Project 2" (3GPP2). 3GPP and 3GPP2 documents are publicly available. A wireless local area network (WLAN) may also be an IEEE 802.11x network, and a wireless personal area network (WPAN) may be a Bluetooth network, IEEE 802.15x, or any other type of network. The techniques described herein may also be used for any combination of WWAN, WLAN, and / or WPAN.

[0217] The UE1200 may further include one or more sensors 1240. The sensors 1240 may include, but are not limited to, one or more inertial sensors and / or other sensors (e.g., one or more accelerometers, one or more gyroscopes, one or more cameras, one or more magnetometers, one or more altimeters, one or more microphones, one or more proximity sensors, one or more light sensors, one or more barometers, etc.), some of which may be used to obtain positional measurements and / or other information.

[0218] Embodiments of the UE 1200 may further include a sensing unit 1250. The sensing unit 1250 may include hardware and / or software components capable of transmitting and / or receiving RF signals (e.g., RS) to detect one or more targets in the manner described herein. As shown, the sensing unit 1250 may include a stand-alone component connected to the bus 1205, or may be incorporated into another component (e.g., the wireless indication interface 1230). Further, the sensing unit 1250 may be communicatively coupled to an antenna 1232, which may be shared with the wireless communication interface 1230. Additionally or alternatively, the sensing unit 1250 may have its own antenna (not shown). In some embodiments, the sensing unit 1250 may be communicatively coupled to a plurality of antennas or an antenna array capable of transmitting and / or receiving RF signals via a directional beam.

[0219] Embodiments of UE1200 may also include a Global Navigation Satellite System (GNSS) receiver 1280 capable of receiving signals 1284 from one or more GNSS satellites using antenna 1282 (which may be the same as antenna 1232). Positioning based on GNSS signal measurements can be utilized to complement and / or incorporate the techniques described herein. The GNSS receiver 1280 can use conventional techniques to extract the position of UE1200 from GNSS satellites of GNSS systems such as the Global Positioning System (GPS), Galileo, GLONASS, the Quasi-Zenith Satellite System (QZSS) over Japan, the IRNSS over India, and the Beidou Navigation Satellite System (BDS) over China. Furthermore, the GNSS receiver 1280 can be used with a variety of augmentation systems (e.g., Satellite Based Augmentation Systems, SBAS) that are associated with, or otherwise designed to be used with, one or more global and / or regional navigation satellite systems, such as the Wide Area Augmentation System (WAAS), the European Geostationary Navigation Overlay Service (EGNOS), the Multi-functional Satellite Augmentation System (MSAS), and the Geo Augmented Navigation system (GAGAN).

[0220] Although the GNSS receiver 1280 is illustrated in Figure 12 as a separate component, it should be noted that embodiments are not limited in this way. As used herein, the term “GNSS receiver” may include hardware and / or software components configured to acquire GNSS measurements (measurements from GNSS satellites). In some embodiments, the GNSS receiver may thus comprise a measurement engine run (as software) by one or more processors, such as processor(s) 1210, DSP 1220, and / or a processor in a wireless communication interface 1230 (e.g., in a modem). The GNSS receiver may optionally also include a positioning engine, which can use GNSS measurements from the measurement engine to determine the position of the GNSS receiver using an Extended Kalman Filter (EKF), Weighted Least Squares (WLS), particle filter, etc. The positioning engine may also be run by one or more processors, such as processor(s) 1210 or DSP 1220.

[0221] The UE1200 may further include and / or communicate with memory 1260. Memory 1260 may include, but is not limited to, local storage and / or network-accessible storage, disk drives, drive arrays, optical storage devices, programmable, flash-updatable, and / or read-only memory (ROM) solid-state storage devices such as random-access memory and / or read-only memory. Such storage devices may be configured to implement any suitable data store, including, but is not limited to, various file systems, database structures, etc.

[0222] The memory 1260 of the UE1200 may also include software elements (not shown in Figure 12) including other code such as an operating system, device drivers, executable libraries, and / or one or more application programs, which may include computer programs provided by various embodiments as described herein and / or are designed to perform methods provided by other embodiments and / or constitute a system provided by other embodiments. As merely an example, one or more steps described with respect to the methods (one or more) discussed above may be executed as code and / or instructions in memory 1260 that are executable by the UE1200 (and / or a processor (one or more) 1210 or DSP 1220 within the UE1200). In some embodiments, such code and / or instructions may then be used to configure and / or adapt a general-purpose computer (or other device) to perform one or more operations according to the described methods.

[0223] Figure 13 is a block diagram of one embodiment of a computer system 1300, which may be used in whole or in part to provide the functionality of one or more components and / or devices as described in embodiments of this specification, including a server (e.g., a sensing server / SMF, a location server / LMF, etc.) that communicates with one or more base stations and / or one or more sensing nodes to coordinate RF sensing as described in embodiments of this specification. This may include, for example, computer servers, personal computers, personal electronic devices, etc. The computer system 1300 may correspond to or support any of the servers referred to herein, such as server 150 in Figure 1, server 510 in Figure 5, server 610 in Figure 6, or security-related information (e.g., security-related information described with respect to Figures 7A, 7B, and 8) that can constitute a UE. It should be noted that Figure 13 is intended only to provide a generalized illustration of various components, and any or all of those components may be used as needed. Thus, Figure 13 broadly illustrates how individual system elements may be implemented in a relatively separated or relatively more integrated manner. In addition, it should be noted that the components shown in Figure 13 may be localized in a single device and / or distributed among various networked devices that may be located in different geographical locations.

[0224] The computer system 1300 is shown including hardware elements that may be electrically coupled (or otherwise communicate as needed) via bus 1305. The hardware elements may include, but are not limited to, one or more general-purpose processors, one or more dedicated processors (such as a digital signal processing chip, a graphics acceleration processor), and / or other processing structures that may be configured to perform one or more of the methods described herein. The computer system 1300 may also include, but are not limited to, one or more input devices 1315, which may include a mouse, keyboard, camera, microphone, etc., and one or more output devices 1320, which may include, but are not limited to, a display device, printer, etc.

[0225] The computer system 1300 may further include (and / or communicate with) one or more non-temporary storage devices 1325, which may include, but not limited to, local storage and / or network-accessible storage, and / or, but not limited to, solid-state storage devices such as disk drives, drive arrays, optical storage devices, random-access memory (RAM), and / or read-only memory (ROM), which may be programmable, flash-updatable, etc. Such storage devices may be configured to implement any suitable data store, including, but not limited to, various file systems, database structures, etc. Such data stores may include one or more databases and / or other data structures used to store and manage messages and / or other information that will be sent to one or more devices via a hub, as described herein.

[0226] The computer system 1300 may also include a communications subsystem 1330, which may include wireless communications technology managed and controlled by a wireless communications interface 1333, as well as wired technologies (such as Ethernet, coaxial communications, and Universal Serial Bus (USB)). The wireless communications interface 1333 may include one or more wireless transceivers capable of sending and receiving wireless signals 1355 (e.g., signals via 5G NR or LTE) via one or more wireless antennas 1350. Thus, the communications subsystem 1330 may comprise a modem, a network card (wireless or wired), an infrared communications device, a wireless communications device, and / or a chipset, etc., which may enable the computer system 1300 to communicate with any device on each network, including user equipment (UEs), base stations, and / or other transmission / reception points (TRPs), and / or any other electronic devices described herein, in some or all of the communications networks described herein. Thus, the communications subsystem 1330 may be used to receive and transmit data as described in the embodiments described herein.

[0227] In many embodiments, the computer system 1300 further includes working memory 1335, which may include RAM devices or ROM devices, as described above. Software elements indicated as located within the working memory 1335 may include other code such as an operating system 1340, device drivers, executable libraries, and / or one or more applications 1345, which may include computer programs provided by various embodiments as described herein, and / or may be designed to perform methods provided by other embodiments and / or to configure systems provided by other embodiments. As mere examples, one or more steps described with respect to the methods (one or more) described above may be executed as code and / or instructions executable by a computer (and / or a processor in the computer), and in one embodiment, such code and / or instructions may then be used to configure and / or adapt a general-purpose computer (or other device) to perform one or more operations according to the methods described.

[0228] These instructions and / or sets of code may be stored on a non-temporary computer-readable storage medium, such as the storage device(s) 1325 described above. In some cases, the storage medium may be incorporated into a computer system, such as computer system 1300. In other embodiments, the storage medium may be separate from the computer system (e.g., a removable medium such as an optical disc) and / or provided in an installation package, so that the instructions / code stored thereon may be used to program, configure, and / or adapt a general-purpose computer. These instructions may take the form of executable code that can be executed by computer system 1300, and / or in the form of source and / or installable code, which, once compiled and / or installed on computer system 1300 (e.g., using any of the various commonly available compilers, installers, compression / decompression utilities, etc.), then take the form of executable code.

[0229] Figure 14 is a flowchart of a method 1400 that enables secure sidelink communication between a first user equipment (UE) and a second UE (e.g., UE 105), performed by a server (e.g., server 150), according to one embodiment. The means / configurations that perform the functions illustrated in one or more of the blocks shown in Figure 14 may be performed by hardware and / or software components of a computer system, as described herein. Exemplary components of a computer system are shown in Figure 13 and described in more detail above.

[0230] In block 1410, the function includes determining a random or partially random value RV1, a first cryptographic key K1, and a first cryptographic key identifier K1id, as illustrated with reference to Figure 5, for example.

[0231] The means for performing functions in block 1410 may include a bus 1305 of the computer system 1300, one or more processors 1310, a communication subsystem 1330, a memory 1335, and / or other components, as shown in Figure 13.

[0232] In block 1420, the function includes determining a second encryption key K3 based on encrypting a random or partially random value RV1 using a first encryption key K1, as illustrated with reference to Figure 5, for example.

[0233] The means for performing the function in block 1420 may include a bus 1305 of a computer system 1300 as shown in Figure 13, a processor(s) 1310, a communication subsystem 1330, a memory 1335, and / or other components.

[0234] In block 1430, the function includes securely transmitting a random or partially random value RV1, a first key identifier K1id, and a second cryptographic key K3 to a first UE, as described, for example, with respect to 650 in Figures 5 and 6.

[0235] The means for performing functions in block 1430 may include a bus 1305 of a computer system 1300, one or more processors 1310, a communication subsystem 1330, a memory 1335, and / or other components, as shown in Figure 13.

[0236] In block 1440, the function includes securely transmitting the first cryptographic key K1 and the first cryptographic key identifier K1id to the second UE, as described, for example, with respect to 660 in Figures 5 and 6.

[0237] The means for performing functions in block 1440 may include a bus 1305 of a computer system 1300, one or more processors 1310, a communication subsystem 1330, a memory 1335, and / or other components, as shown in Figure 13.

[0238] In some embodiments, determining a second encryption key K3 based on encrypting a random or partially random value RV1 using a first encryption key K1 includes determining an intermediate encryption key K2 based on encrypting a random or partially random value RV1 using the first encryption key K1, and determining a second encryption key K3 based on encrypting a random or partially random value RV1 using the intermediate encryption key K2, as described with respect to Figure 5, for example.

[0239] In some embodiments, securely transmitting the second encryption key K3 to the first UE is based on encrypting the second encryption key K3 using the first UE's secret encryption key Kue1, as illustrated, for example, with respect to Figure 5. * To determine the key K3 in the first UE * Sending and including

[0240] In some embodiments, securely transmitting the first encryption key K1 to a second UE is based on encrypting the first encryption key K1 using the second UE's secret encryption key Kue2, as illustrated, for example, with respect to Figure 5. * To determine the second UE and the key K1 * Sending and including

[0241] In some embodiments, the second encryption key is determined based on a 128-bit or 256-bit Advanced Encryption Standard (AES) algorithm.

[0242] Figure 15 is a flowchart of a method 1500 for secure communication between a first user device (UE) and a second UE (e.g., UE 105), as performed by the first user device (UE), according to one embodiment. The means / configurations for performing the functions illustrated in one or more of the blocks shown in Figure 15 may be performed by hardware and / or software components of the UE, as described herein. Exemplary components of the UE are shown in Figure 12, which are described in more detail above.

[0243] In block 1510, the function includes securely receiving a random or partially random value RV1, a first cryptographic key identifier K1id, and a second cryptographic key K3 from a server (e.g., server 150), as described with respect to 650 in Figures 5 and 6, for example.

[0244] The means for performing the function in block 1510 may include the UE1200 bus 1205, one or more processors 1210, a wireless communication interface 1230, memory 1260, and / or other components as shown in Figure 12.

[0245] In block 1520, the function includes sending a random or partially random value RV1 and a first cryptographic key identifier K1id in plaintext to a second UE, as described, for example, with respect to 670 in Figures 5 and 6, the random or partially random value RV1 and the first cryptographic key identifier K1id enabling the second UE to determine the second cryptographic key K3.

[0246] The means for performing the function in block 1520 may include the UE1200 bus 1205, one or more processors 1210, a wireless communication interface 1230, memory 1260, and / or other components as shown in Figure 12.

[0247] In block 1530, the function includes performing secure communication with a second UE based on a second cryptographic key K3, as described, for example, with respect to 695 in Figures 5 and 6.

[0248] The means for performing functions in block 1530 may include the UE1200 bus 1205, one or more processors 1210, a wireless communication interface 1230, memory 1260, and / or other components as shown in Figure 12.

[0249] In some embodiments, securely receiving the second cryptographic key K3 from the server is, for example, as described with respect to 685 in Figures 5 and 6, from the server to key K3 * Receiving and using the secret encryption key Kue1 of the first UE to key K3 * This includes determining the second encryption key K3 based on the decryption of the first key.

[0250] Figure 16 is a flowchart of a method 1600 for secure communication between a first UE and a second UE (e.g., UE 105), performed by a second user device (UE), according to one embodiment. The means / configurations for performing the functions illustrated in one or more of the blocks shown in Figure 16 may be performed by hardware and / or software components of the UE, as described herein. Exemplary components of the UE are shown in Figure 12, which are described in more detail above.

[0251] In block 1610, the function includes securely receiving a first cryptographic key K1 and a first cryptographic key identifier K1id from a server (e.g., server 150), as described, for example, with respect to 660 in Figures 5 and 6.

[0252] The means for performing the function in block 1610 may include the UE1200 bus 1205, one or more processors 1210, a wireless communication interface 1230, memory 1260, and / or other components as shown in Figure 12.

[0253] In block 1620, the function includes receiving a random or partially random value RV1 and a first cryptographic key identifier K1id in plaintext from a first UE, as described, for example, with respect to 670 in Figures 5 and 6.

[0254] The means for performing the function in block 1620 may include the UE1200 bus 1205, one or more processors 1210, a wireless communication interface 1230, memory 1260, and / or other components as shown in Figure 12.

[0255] In block 1630, the function includes identifying a first cryptographic key K1 based on a first cryptographic key identifier K1id, as described, for example, with respect to 675 in Figures 5 and 6.

[0256] The means for performing functions in block 1630 may include the UE1200 bus 1205, one or more processors 1210, a wireless communication interface 1230, memory 1260, and / or other components as shown in Figure 12.

[0257] In block 1640, the function includes determining a second encryption key K3 by encrypting a random or partially random value RV1 using a first encryption key K1, as described, for example, with respect to 675 in Figures 5 and 6.

[0258] The means for performing the function in block 1640 may include the UE1200 bus 1205, one or more processors 1210, a wireless communication interface 1230, memory 1260, and / or other components as shown in Figure 12.

[0259] In block 1650, the function includes performing secure communication with the first UE based on the second cryptographic key K3, as described, for example, with respect to 695 in Figures 5 and 6.

[0260] The means for performing functions in block 1650 may include the UE1200 bus 1205, one or more processors 1210, a wireless communication interface 1230, memory 1260, and / or other components as shown in Figure 12.

[0261] In some embodiments, securely receiving the first cryptographic key K1 from the server is done as described with respect to 675 in Figures 5 and 6, from the server to key K1 * Receiving, for example, using the secret encryption key Kue2 of the second UE to key K1 * This includes determining the first encryption key K1 based on decrypting the following.

[0262] In some embodiments, determining a second encryption key K3 based on encrypting a random or partially random value RV1 using a first encryption key K1 includes determining an intermediate encryption key K2 based on encrypting a random or partially random value RV1 using the first encryption key K1, and determining a second encryption key K3 based on encrypting a random or partially random value RV1 using the intermediate encryption key K2, as described with respect to Figure 5, for example.

[0263] Figure 17 is a flowchart of a method 1700, according to one embodiment, that enables secure sidelink communication between a group of user devices (e.g., UE 105) performed by a server (e.g., server 150). The means / configurations that perform the functions illustrated in one or more of the blocks shown in Figure 17 may be performed by hardware and / or software components of a computer system, as described herein. Exemplary components of a computer system are shown in Figure 13 and described in more detail above.

[0264] In block 1710, the function includes determining a set of secret cryptographic keys PK and a corresponding set of cryptographic key IDs Kid, as described, for example, with respect to the derived cryptographic key method described above.

[0265] The means for performing the function in block 1710 may include a bus 1305 of the computer system 1300 as shown in Figure 13, a processor(s) 1310, a communication subsystem 1330, a memory 1335, and / or other components.

[0266] In block 1720, the function includes determining a random or partially random value RV for each UE in a group of UEs, for example, as described above with respect to the method of derived cryptographic keys.

[0267] The means for performing the function in block 1720 may include a bus 1305 of a computer system 1300 as shown in Figure 13, a processor(s) 1310, a communication subsystem 1330, a memory 1335, and / or other components.

[0268] In block 1730, the function includes determining the derived set of cryptographic keys DK for each UE in a group of UEs based on a set of random or partially random values ​​RV and secret cryptographic keys PK for each UE, as described above with respect to the method of derived cryptographic keys.

[0269] The means for performing functions in block 1730 may include a bus 1305 of a computer system 1300, one or more processors 1310, a communication subsystem 1330, a memory 1335, and / or other components, as shown in Figure 13.

[0270] In block 1740, the function includes securely configuring each UE in a group of UEs using a random or partially random value RV for each UE, a set of derived cryptographic keys DK for each UE, one secret cryptographic key from a set of secret cryptographic keys PK, and one cryptographic key ID from a corresponding set of cryptographic key IDs Kid, as described with respect to the method of derived cryptographic keys above, where one cryptographic key ID corresponds, for example, to one secret cryptographic key.

[0271] The means for performing the function in block 1740 may include a bus 1305 of a computer system 1300 as shown in Figure 13, a processor(s) 1310, a communication subsystem 1330, a memory 1335, and / or other components.

[0272] In some embodiments, securely configuring each UE in a group of UEs using a random or partially random value RV for each UE, a set of derived cryptographic keys DK for each UE, one private cryptographic key from a set of private cryptographic keys PK, and one cryptographic key ID from a corresponding set of cryptographic key IDs Kid, involves configuring each UE in a group of UEs using a secure connection between each UE and a server, as described with respect to the derived cryptographic key method above, where the secure connection is based, for example, on a public-private key pair of the server.

[0273] In some embodiments, determining the set of derived cryptographic keys DK for each UE in a group of UEs based on a set of random or partially random values ​​RV and secret cryptographic keys PK for each UE includes determining each derived cryptographic key in the set of derived cryptographic keys DK by encrypting the random or partially random value RV using different secret cryptographic keys in the set of secret cryptographic keys PK, as described with respect to the derived cryptographic key method above, wherein the set of derived cryptographic keys DK and the set of secret cryptographic keys PK contain an equal number of cryptographic keys, and each secret cryptographic key in the set of secret cryptographic keys PK is used to determine one derived cryptographic key in the set of derived cryptographic keys DK.

[0274] In some embodiments, method 1700 further includes periodically determining a new random or partially random value RV and a new set of derived cryptographic keys DK for each UE in a group of UEs, as described, for example, with respect to the derived cryptographic key method above, and securely configuring each UE in the group of UEs with the new random or partially random value RV and the new set of derived cryptographic keys DK for each UE.

[0275] Figure 18 is a flowchart of a method 1800 that supports secure sidelink communication between groups of user equipment (UEs) (e.g., UE105), performed by a first UE of a group of user equipment (UEs), according to one embodiment. The means / configurations that perform the functions illustrated in one or more of the blocks shown in Figure 18 may be performed by hardware and / or software components of the UE, as described herein. Exemplary components of the UE are shown in Figure 12, which are described in more detail above.

[0276] In block 1810, the function includes securely receiving from a server (e.g., server 150) a first random or partially random value RV1, a first set of derived cryptographic keys DK1, a first secret cryptographic key K1 of a set of secret cryptographic keys PK, and a first cryptographic key ID K1id, for example, as described above with respect to the method of derived cryptographic keys, wherein the first cryptographic key ID K1id identifies the first secret cryptographic key K1.

[0277] The means for performing the function in block 1810 may include the UE1200 bus 1205, one or more processors 1210, a wireless communication interface 1230, memory 1260, and / or other components as shown in Figure 12.

[0278] In block 1820, the function includes sending a first random or partially random value RV1 and a first cryptographic key ID K1id in plaintext to a second UE of the group of UEs, as described, for example, with respect to stage 1 in Figure 7A and stage 1 in Figure 7B.

[0279] The means for performing the function in block 1820 may include the UE1200 bus 1205, one or more processors 1210, a wireless communication interface 1230, memory 1260, and / or other components as shown in Figure 12.

[0280] In block 1830, the function includes receiving a second random or partially random value RV2 and a second cryptographic key ID K2id in plaintext from a second UE of the group of UEs, as described, for example, with respect to stage 1 in Figure 7A and stage 2 in Figure 7B, where the second cryptographic key ID K2id identifies the second secret cryptographic key K2 of the set of secret cryptographic keys PK configured in the second UE.

[0281] The means for performing the function in block 1830 may include the UE1200 bus 1205, one or more processors 1210, a wireless communication interface 1230, memory 1260, and / or other components as shown in Figure 12.

[0282] In block 1840, the function includes determining at least one common cryptographic key based on a first set of derived cryptographic keys DK1, a first secret cryptographic key K1, a second random or partially random value RV2, and a second cryptographic key ID K2id, as described, for example, with respect to steps 5 and 6 in Figure 7A and steps 3 and 5 in Figure 7B.

[0283] The means for performing the function in block 1840 may include the UE1200 bus 1205, one or more processors 1210, a wireless communication interface 1230, memory 1260, and / or other components as shown in Figure 12.

[0284] In block 1850, the functionality includes supporting secure sidelink communication with a second UE based on at least one common cryptographic key, as described, for example, with respect to stage 7 in Figure 7A and stage 7 in Figure 7B.

[0285] The means for performing the function in block 1850 may include the UE1200 bus 1205, one or more processors 1210, a wireless communication interface 1230, memory 1260, and / or other components as shown in Figure 12.

[0286] In some embodiments, securely receiving a first random or partially random value RV1, a first set of derived cryptographic keys DK1, a first secret cryptographic key K1, and a first cryptographic key ID K1id from a server includes, for example, receiving the first random or partially random value RV1, a first set of derived cryptographic keys DK1, a first secret cryptographic key K1, and a first cryptographic key ID K1id using a secure connection between a first UE and a server, as described above with respect to the method of derived cryptographic keys, wherein the secure connection is based on the server's public-private key pair.

[0287] In some embodiments, as described, for example, with respect to the derived cryptographic key method described above, each derived cryptographic key DKm in a first set of derived cryptographic keys DK1 corresponds to a separate secret cryptographic key PKm in a set of secret cryptographic keys PK, and each derived cryptographic key DKm involves the encryption of a first random or partially random value RV1 using the corresponding separate secret cryptographic key PKm in the set of secret cryptographic keys PK, and the first set of derived cryptographic keys DK1 and the set of secret cryptographic keys PK contain an equal number of cryptographic keys, and each secret cryptographic key in the set of secret cryptographic keys PK is used to determine one derived cryptographic key in the set of derived cryptographic keys DK1.

[0288] In some embodiments, determining at least one common cryptographic key based on a first set of derived cryptographic keys DK1, a first secret cryptographic key K1, a second random or partially random value RV2, and a second cryptographic key ID K2id includes identifying a first derived cryptographic key in the first set of derived cryptographic keys DK1, wherein the first derived cryptographic key corresponds to a second secret cryptographic key K2 in the set of secret cryptographic keys PK, and the second secret cryptographic key K2 is identified by the second cryptographic key ID K2id; determining a second derived cryptographic key based on encrypting the second random or partially random value RV2 using the first secret cryptographic key K1, as described with respect to steps 5 and 6 in Figure 7A and steps 3 and 5 in Figure 7B; and determining at least one common cryptographic key based on the first derived cryptographic key and the second derived cryptographic key.

[0289] In some embodiments, determining at least one common cryptographic key based on a first derived cryptographic key and a second derived cryptographic key includes: transmitting a first key component to a second UE, wherein the first key component is encrypted using either the first derived cryptographic key or the second derived key; receiving a second key component from the second UE, wherein the second key component is encrypted using either the first derived cryptographic key or the other of the second derived key; decrypting the second key component using either the first derived cryptographic key or the other of the second derived key, as described with respect to steps 2, 4, 5, and 6 of Figure 7A, for example; and determining at least one common cryptographic key based on the first and second key components.

[0290] In some embodiments, Method 1800 further includes: transmitting a first random or partially random value RV1 and a first cryptographic key ID K1id in plaintext to each UE in a group of UEs, excluding the first and second UEs; receiving from each UE in the group of UEs in plaintext a unique random or partially random value RV and a cryptographic key ID Kid, wherein the cryptographic key ID Kid identifies the secret cryptographic key K of a set of secret cryptographic keys PK configured at each UE; determining at least one common cryptographic key for each UE based on a first set of derived cryptographic keys DK1, the first secret cryptographic key K1, the random or partially random value RV, and the cryptographic key ID Kid; transmitting at least one common group cryptographic key to each UE, for example, as described with reference to Figure 8, wherein at least one common group cryptographic key is encrypted using at least one common cryptographic key for each UE; and supporting secure sidelink communication of the group of UEs based on the at least one common group cryptographic key.

[0291] In some embodiments, supporting secure sidelink communication between a group of UEs based on at least one common group cryptographic key includes, for example, exchanging messages for the Sidelink Positioning Protocol (SLPP) with other UEs in the group, as described with respect to step 5 in Figure 8, where the SLPP messages are encrypted or integrity protected using at least one common group cryptographic key, or both.

[0292] It will be apparent to those skilled in the art that substantial modifications may be made according to specific requirements. For example, customized hardware may be used, and / or certain elements may be implemented in hardware, software (including portable software such as applets), or both. Furthermore, connectivity to other computing devices, such as network input / output devices, may be utilized.

[0293] Referring to the attached diagram, components that may contain memory may also contain non-temporary machine-readable media. As used herein, the terms “machine-readable media” and “computer-readable media” refer to any storage medium involved in providing data that enables a machine to operate in a particular manner. In the embodiments provided above, various machine-readable media may be involved in providing instructions / codes to a processor and / or other device(s) to execute. In addition or alternatively, machine-readable media may be used to store and / or carry such instructions / codes. In many implementations, computer-readable media are physical and / or tangible storage media. Such media may include, but are not limited to, non-volatile and volatile media, and can take many forms. Common forms of computer-readable media include, for example, magnetic and / or optical media, any other physical media having a pattern of holes, RAM, programmable ROM (PROM), erasable PROM (EPROM), FLASH-EPROM, any other memory chip or cartridge, or any other medium from which a computer can read instructions and / or code.

[0294] The methods, systems, and devices described herein are examples. Various embodiments may omit, substitute, or add various procedures or components as needed. For example, features described in relation to some embodiments may be combined in various other embodiments. Different aspects and elements of embodiments may be combined in the same way. Various components in the figures provided herein may be embodied in hardware and / or software. Furthermore, technology evolves, and therefore many elements are examples that do not limit the scope of this disclosure to their specific examples.

[0295] For reasons of common usage, it is sometimes convenient to refer to such signals as bits, information, values, elements, symbols, characters, variables, terms, numbers, numerical values, etc. However, it should be understood that all of these or similar terms are merely labels for convenience and should be associated with appropriate physical quantities. Unless otherwise specified, as is evident from the above description, descriptions throughout this specification using terms such as “process,” “calculate,” “compute,” “determine,” “verify,” “identify,” “associate,” “measure,” and “execute” should be understood to refer to actions or processes of specific devices such as dedicated computers or similar dedicated electronic computing devices. Therefore, in the context of this specification, dedicated computers or similar dedicated electronic computing devices are capable of manipulating or converting signals that are generally expressed as physical electronic, electrical, or magnetic quantities within the memory, registers, or other information storage devices, transmitting devices, or display devices of the dedicated computer or similar dedicated electronic computing device.

[0296] As used herein, the terms “and” and “or” may have a variety of meanings, which are expected to depend at least partially on the context in which such terms are used. Generally, when “or” is used to relate a list such as A, B, or C, it is intended to mean A, B, and C, as used here in an inclusive sense, and A, B, or C, as used here in an exclusive sense. In addition, as used herein, the term “one or more” may be used to represent any feature, structure, or characteristic in the singular, or any combination of features, structures, or characteristics. However, it should be noted that these are illustrative examples and the claimed subject matter is not limited to these examples. Furthermore, when the term “at least one of” is used to relate a list such as A, B, or C, it may be interpreted to mean any combination of A, B, and / or C, such as A, AB, AA, AAB, AABBCCC.

[0297] While several embodiments are described, various modifications, alternative configurations, and equivalents may be used without departing from the scope of this disclosure. For example, the elements described above may be merely components of a larger system in which other rules may take precedence over the applications of the various embodiments, or the applications of the various embodiments may be modified in a different way. Also, several steps may be taken before, during, or after the consideration of the elements described above. Therefore, the above description does not limit the scope of this disclosure.

[0298] In light of this description, embodiments may include combinations of different features. Examples of implementations are described in the following numbered clauses. Clause 1. An exemplary method for enabling secure sidelink communication between groups of user devices (UEs), performed by a server, comprising: determining a set of private encryption keys PK and a corresponding set of encryption key IDs Kid; determining a random or partially random value RV for each UE in the group of UEs; determining a set of derived encryption keys DK for each UE in the group of UEs based on the random or partially random value RV and the set of private encryption keys PK for each UE; and securely configuring each UE in the group of UEs using the random or partially random value RV for each UE, the set of derived encryption keys DK for each UE, one private encryption key from the set of private encryption keys PK, and one encryption key ID from the corresponding set of encryption key IDs Kid, wherein one encryption key ID corresponds to one private encryption key. Clause 2. The method described in Clause 1, which includes securely configuring each UE in a group of UEs using a random or partially random value RV for each UE, a set of derived cryptographic keys DK for each UE, one private cryptographic key from a set of private cryptographic keys PK, and one cryptographic key ID from a corresponding set of cryptographic key IDs Kid, and configuring each UE in a group of UEs using a secure connection between each UE and the server, wherein the secure connection is based on the public key-private key pair of the server. Clause 3. A method by which determining a set of derived cryptographic keys DK for each UE in a group of UEs, based on a set of random or partially random values ​​RV and private cryptographic keys PK for each UE, comprises determining each derived cryptographic key in the set of derived cryptographic keys DKs, based on encrypting a random or partially random value RV using a different private cryptographic key in the set of private cryptographic keys PK, wherein the set of derived cryptographic keys DKs and the set of private cryptographic keys PKs contain an equal number of cryptographic keys, and each private cryptographic key in the set of private cryptographic keys PKs is used to determine one derived cryptographic key in the set of derived cryptographic keys DKs. The method according to any one of the clauses 1 to 3, further comprising: periodically determining a new random or partially random value RV and a new set of derived cryptographic keys DK for each UE in a group of UEs; and securely configuring each UE in a group of UEs with the new random or partially random value RV and the new set of derived cryptographic keys DK for each UE. Clause 5. An exemplary method for supporting secure sidelink communication between groups of user equipment (UEs), performed by a first UE in a group of UEs, comprising: securely receiving from a server a first random or partially random value RV1, a first set of derived cryptographic keys DK1, a first secret cryptographic key K1 of a set of secret cryptographic keys PK, and a first cryptographic key ID K1id, wherein the first cryptographic key ID K1id identifies the first secret cryptographic key K1; transmitting the first random or partially random value RV1 and the first cryptographic key ID K1id in plain text to a second UE in the group of UEs; and receiving from the second UE in the group of UEs a second random or partially random value RV2 and a second cryptographic key ID K2id, wherein the second cryptographic key ID K2id identifies the second secret cryptographic key K2 of a set of secret cryptographic keys PK configured in the second UE. A method comprising: receiving a K2id in plain text; determining at least one common cryptographic key based on a first set of derived cryptographic keys DK1, a first secret cryptographic key K1, a second random or partially random value RV2, and a second cryptographic key ID K2id; and supporting secure sidelink communication with a second UE based on at least one common cryptographic key. Clause 6. A method of securely receiving from a server a first random or partially random value RV1, a first set of derived cryptographic keys DK1, a first private cryptographic key K1, and a first cryptographic key ID K1id, using a secure connection between a first UE and a server, wherein the secure connection is based on the server's public-private key pair, as described in Clause 5. Clause 7. The method according to Clause 5 or 6, wherein each derived cryptographic key DKm in a first set of derived cryptographic keys DK1 corresponds to a separate secret cryptographic key PKm in a set of secret cryptographic keys PK, and each derived cryptographic key DKm includes the encryption of a first random or partially random value RV1 using the corresponding separate secret cryptographic key PKm in the set of secret cryptographic keys PK, and the first set of derived cryptographic keys DK1 and the set of secret cryptographic keys PK contain an equal number of cryptographic keys, and each secret cryptographic key in the set of secret cryptographic keys PK is used to determine one derived cryptographic key in the set of derived cryptographic keys DK. Clause 8. The method of any one of Clauses 5 to 7, wherein determining at least one common cryptographic key based on a first set of derived cryptographic keys DK1, a first secret cryptographic key K1, a second random or partially random value RV2, and a second cryptographic key ID K2id includes identifying a first derived cryptographic key in the first set of derived cryptographic keys DK1, wherein the first derived cryptographic key corresponds to a second secret cryptographic key K2 in the set of secret cryptographic keys PK, and the second secret cryptographic key K2 is identified by the second cryptographic key ID K2id; determining a second derived cryptographic key based on encrypting the second random or partially random value RV2 using the first secret cryptographic key K1; and determining at least one common cryptographic key based on the first derived cryptographic key and the second derived cryptographic key. The method according to any one of the clauses 5 to 8, wherein determining at least one common cryptographic key based on a first derived cryptographic key and a second derived cryptographic key includes: transmitting a first key component to a second UE, the first key component being encrypted using either the first derived cryptographic key or the second derived key; receiving a second key component from the second UE, the second key component being encrypted using either the first derived cryptographic key or the other of the second derived key; decrypting the second key component using either the first derived cryptographic key or the other of the second derived key; and determining at least one common cryptographic key based on the first and second key components. Clause 10. The method of any one of Clauses 5 to 9, further comprising: transmitting a first random or partially random value RV1 and a first cryptographic key ID K1id in plaintext to each UE in a group of UEs, excluding the first and second UEs; receiving from each UE in a group of UEs in plaintext a unique random or partially random value RV and a cryptographic key ID Kid, wherein the cryptographic key ID Kid identifies the secret cryptographic key K of a set of secret cryptographic keys PK configured in each UE; determining at least one common cryptographic key for each UE based on a first set of derived cryptographic keys DK1, a first secret cryptographic key K1, a random or partially random value R, and the cryptographic key ID Kid; transmitting at least one common group cryptographic key to each UE, wherein at least one common group cryptographic key is encrypted using at least one common cryptographic key for each UE; and supporting secure sidelink communication of the group of UEs based on at least one common group cryptographic key. Clause 11. A method by which a group of UEs can support secure sidelink communication based on at least one common group cryptographic key, including exchanging messages for the Sidelink Positioning Protocol (SLPP) with other UEs, wherein the SLPP messages are encrypted or integrity protected using at least one common group cryptographic key, or both. Clause 12. A device for enabling secure sidelink communication between groups of user devices (UEs), comprising: means for determining a set of private encryption keys PK and a corresponding set of encryption key IDs Kid; means for determining a random or partially random value RV for each UE in the group of UEs; means for determining a set of derived encryption keys DK for each UE in the group of UEs based on the random or partially random value RV and the set of private encryption keys PK for each UE; and means for securely configuring each UE in the group of UEs using the random or partially random value RV for each UE, the set of derived encryption keys DK for each UE, one private encryption key from the set of private encryption keys PK, and one encryption key ID from the corresponding set of encryption key IDs Kid, wherein one encryption key ID corresponds to one private encryption key. Clause 13. The apparatus described in Clause 12, which securely configures each UE in a group of UEs using a secure connection between each UE and a server, where the secure connection is based on the server's public-private key pair. Clause 14. The apparatus according to Clause 12 or 13, wherein determining a set of derived cryptographic keys DK for each UE in a group of UEs, based on a set of random or partially random values ​​RV and private cryptographic keys PK for each UE, and determining each derived cryptographic key in the set of derived cryptographic keys DK, based on encrypting a random or partially random value RV using a different private cryptographic key in the set of private cryptographic keys PK, wherein the set of derived cryptographic keys DK and the set of private cryptographic keys PK contain an equal number of cryptographic keys, and each private cryptographic key in the set of private cryptographic keys PK is used to determine one derived cryptographic key in the set of derived cryptographic keys DK. The apparatus according to any one of Clauses 12 to 14, further comprising: means for periodically determining a new random or partially random value RV and a new set of derived cryptographic keys DK for each UE in a group of UEs; and means for securely configuring each UE in a group of UEs using the new random or partially random value RV and the new set of derived cryptographic keys DK for each UE. Clause 16. Device for supporting secure sidelink communication between groups of user equipment (UEs), performed by a first UE of a group of UEs, comprising: means for securely receiving from a server a first random or partially random value RV1, a first set of derived cryptographic keys DK1, a first secret cryptographic key K1 of a set of secret cryptographic keys PK, and a first cryptographic key ID K1id, wherein the first cryptographic key ID K1id identifies the first secret cryptographic key K1; means for transmitting the first random or partially random value RV1 and the first cryptographic key ID K1id in plain text to a second UE of the group of UEs; and means for transmitting from the second UE of the group of UEs a second random or partially random value RV2 and a second cryptographic key ID K2id, wherein the second cryptographic key ID K2id identifies the second secret cryptographic key K2 of a set of secret cryptographic keys PK configured in the second UE. An apparatus comprising: means for receiving a K2id in plain text; means for determining at least one common cryptographic key based on a first set of derived cryptographic keys DK1, a first secret cryptographic key K1, a second random or partially random value RV2, and a second cryptographic key ID K2id; and means for supporting secure sidelink communication with a second UE based on at least one common cryptographic key. Clause 17. A device that securely receives from a server a first random or partially random value RV1, a first set of derived cryptographic keys DK1, a first private cryptographic key K1, and a first cryptographic key ID K1id, using a secure connection between a first UE and a server, wherein the secure connection is based on the server's public-private key pair, as described in Clause 16. Clause 18. The apparatus according to Clause 16 or 17, wherein each derived cryptographic key DKm in a first set of derived cryptographic keys DK1 corresponds to a separate secret cryptographic key PKm in a set of secret cryptographic keys PK, and each derived cryptographic key DKm includes the encryption of a first random or partially random value RV1 using the corresponding separate secret cryptographic key PKm in the set of secret cryptographic keys PK, and the first set of derived cryptographic keys DK1 and the set of secret cryptographic keys PK include an equal number of cryptographic keys, and each secret cryptographic key in the set of secret cryptographic keys PK is used to determine one derived cryptographic key in the set of derived cryptographic keys DK1. Clause 19. The apparatus according to any one of Clauses 16 to 18, comprising: determining at least one common cryptographic key based on a first set of derived cryptographic keys DK1, a first secret cryptographic key K1, a second random or partially random value RV2, and a second cryptographic key ID K2id; identifying a first derived cryptographic key in the first set of derived cryptographic keys DK1, wherein the first derived cryptographic key corresponds to a second secret cryptographic key K2 in the set of secret cryptographic keys PK, and the second secret cryptographic key K2 is identified by the second cryptographic key ID K2id; determining a second derived cryptographic key based on encrypting the second random or partially random value RV2 using the first secret cryptographic key K1; and determining at least one common cryptographic key based on the first derived cryptographic key and the second derived cryptographic key. The apparatus according to any one of the clauses 16 to 19, wherein determining at least one common cryptographic key based on a first derived cryptographic key and a second derived cryptographic key includes transmitting a first key component to a second UE, the first key component being encrypted using the first derived cryptographic key or the second derived key; receiving a second key component from the second UE, the second key component being encrypted using the other of the first derived cryptographic key or the second derived key; decrypting the second key component using the other of the first derived cryptographic key or the second derived key; and determining at least one common cryptographic key based on the first key component and the second key component. Clause 21. The apparatus according to any one of Clauses 16 to 20, further comprising: means for transmitting a first random or partially random value RV1 and a first cryptographic key ID K1id in plaintext to each UE in a group of UEs, excluding the first UE and the second UE; means for receiving from each UE in a group of UEs a unique random or partially random value RV and a cryptographic key ID Kid, wherein the cryptographic key ID Kid identifies the secret cryptographic key K of a set of secret cryptographic keys PK configured in each UE; means for determining at least one common cryptographic key for each UE based on a first set of derived cryptographic keys DK1, a first secret cryptographic key K1, a random or partially random value R, and the cryptographic key ID Kid; means for transmitting at least one common group cryptographic key to each UE, wherein at least one common group cryptographic key is encrypted using at least one common cryptographic key for each UE; and means for supporting secure sidelink communication of the group of UEs based on at least one common group cryptographic key. Clause 22. An apparatus, as described in any of Clauses 16 to 21, which includes supporting secure sidelink communication between a group of UEs based on at least one common group cryptographic key, and exchanging messages for the Sidelink Positioning Protocol (SLPP) with other members of the group of UEs, wherein the SLPP messages are encrypted or integrity protected using at least one common group cryptographic key, or both.

Claims

1. A method for enabling secure sidelink communication between groups of user devices (UEs), performed by a server, Determine the set of secret encryption keys PK and the corresponding set of encryption keys IDs KID, Determining a random or partially random value RV for each UE in the group of UEs, Based on the set of random or partially random values ​​RV and the secret encryption key PK for each UE, the set of derived encryption keys DK for each UE in the group of UEs is determined. Each UE in the group of UEs is securely configured using the random or partially random value RV of each UE, the derived set of encryption keys DK for each UE, one secret encryption key from the set of secret encryption keys PK, and one encryption key ID from the corresponding set of encryption key IDs KID. A method comprising the above, wherein the one encryption key ID corresponds to the one secret encryption key.

2. The method according to claim 1, comprising configuring each UE in a group of UEs using the random or partially random value RV of each UE, the derived set of cryptographic keys DK for each UE, the one private cryptographic key from the set of private cryptographic keys PK, and the one cryptographic key ID from the corresponding set of cryptographic key IDs KID, wherein configuring each UE in a group of UEs using a secure connection between each UE and the server, the secure connection being based on the server's public-private key pair.

3. Based on the set of random or partially random values ​​RV and the secret encryption key PK for each UE, the derived set of encryption keys DK for each UE in the group of UEs is determined. The method according to claim 1, comprising determining each derived cryptographic key in the derived cryptographic key set DK based on encrypting the random or partially random value RV using different secret cryptographic keys in the set of secret cryptographic keys PK, wherein the set of derived cryptographic keys DK and the set of secret cryptographic keys PK each contain an equal number of cryptographic keys, and each secret cryptographic key in the set of secret cryptographic keys PK is used to determine one derived cryptographic key in the set of derived cryptographic keys DK.

4. Periodically determine a new random or partially random value RV for each UE in the group of UEs and a new set of derived cryptographic keys DK, To securely configure each UE in the group of UEs using the new random or partially random value RV of each UE and the new set of derived cryptographic keys DK, The method according to claim 1, further comprising:

5. A method for supporting secure sidelink communication between a group of user devices (UEs), performed by a first UE of a group of UEs, The process involves securely receiving from a server a first random or partially random value RV1, a first set of derived encryption keys DK1, a first secret encryption key K1 of a set of secret encryption keys PK, and a first encryption key ID K1ID, wherein the first encryption key ID K1ID identifies the first secret encryption key K1. To send the first random or partially random value RV1 and the first encryption key ID K1ID in plain text to the second UE of the group of UEs, Receiving a second random or partially random value RV2 and a second encryption key ID K2ID in plain text from the second UE of the group of UEs, wherein the second encryption key ID K2ID identifies the second secret encryption key K2 of the set of secret encryption keys PK configured in the second UE. Based on the first set of derived encryption keys DK1, the first secret encryption key K1, the second random or partially random value RV2, and the second encryption key ID K2ID, at least one common encryption key is determined. Based on the aforementioned at least one common cryptographic key, secure side-link communication with the second UE is supported, Methods that include...

6. The method according to claim 5, wherein securely receiving the first random or partially random value RV1, the first set of derived cryptographic keys DK1, the first private cryptographic key K1, and the first cryptographic key ID K1ID from the server includes receiving the first random or partially random value RV1, the first set of derived cryptographic keys DK1, the first private cryptographic key K1, and the first cryptographic key ID K1ID using a secure connection between the first UE and the server, the secure connection being based on the public key-private key pair of the server.

7. The method according to claim 5, wherein each derived cryptographic key DKm in the first set of derived cryptographic keys DK1 corresponds to a separate secret cryptographic key PKm in the set of secret cryptographic keys PK, and each derived cryptographic key DKm includes the encryption of the first random or partially random value RV1 using the corresponding separate secret cryptographic key PKm in the set of secret cryptographic keys PK, the first set of derived cryptographic keys DK1 and the set of secret cryptographic keys PK include an equal number of cryptographic keys, and each secret cryptographic key in the set of secret cryptographic keys PK is used to determine one derived cryptographic key in the set of derived cryptographic keys DK.

8. Based on the first set of derived cryptographic keys DK1, the first secret cryptographic key K1, the second random or partially random value RV2, and the second cryptographic key ID K2ID, the at least one common cryptographic key can be determined. Identifying the first derived encryption key within the first set of derived encryption keys DK1, wherein the first derived encryption key corresponds to the second secret encryption key K2 within the set of secret encryption keys PK, and the second secret encryption key K2 is identified by the second encryption key ID K2ID. The second derived encryption key is determined based on the encryption of the second random or partially random value RV2 using the first secret encryption key K1. Based on the first derived encryption key and the second derived encryption key, the at least one common encryption key is determined, The method according to claim 5, including the method described in claim 5.

9. Based on the first derived cryptographic key and the second derived cryptographic key, the determination of the at least one common cryptographic key is: Transmitting the first key component to the second UE, wherein the first key component is encrypted using the first derived cryptographic key or the second derived key, Receiving a second key component from the second UE, wherein the second key component is encrypted using the other of the first derived cryptographic key or the second derived key, Deciphering the second key component using the first derived cryptographic key or the other of the second derived keys, Based on the first key component and the second key component, the at least one common cryptographic key is determined, The method according to claim 8, including the method described in claim 8.

10. To each UE in the group of UEs, excluding the first UE and the second UE, the first random or partially random value RV1 and the first cryptographic key ID K1ID are transmitted in plain text. Receiving a unique random or partially random value RV and an encryption key ID KID in plain text from each of the UEs in the group of UEs, wherein the encryption key ID KID identifies the secret encryption key K of the set of secret encryption keys PK configured in each of the UEs. Based on the first set of derived encryption keys DK1, the first secret encryption key K1, the random or partially random value RV, and the encryption key ID KID, determine at least one common encryption key for each UE. Transmitting at least one common group encryption key to each of the aforementioned UEs, wherein the at least one common group encryption key is encrypted using the at least one common encryption key of each of the aforementioned UEs. Based on the aforementioned at least one common group encryption key, secure side-link communication of the group of UEs is supported, The method according to claim 5, further comprising:

11. The method according to claim 5, comprising supporting secure sidelink communication of the group of UEs based on at least one common group cryptographic key, exchanging messages for Sidelink Positioning Protocol (SLPP) with other members of the group of UEs, wherein the SLPP messages are encrypted or integrity protected using the at least one common group cryptographic key, or both.

12. A device for enabling secure side-link communication between groups of user equipment (UEs), Means for determining a set of secret encryption keys PK and a corresponding set of encryption keys IDs KID, Means for determining a random or partially random value RV for each UE in the group of UEs, A means for determining the derived set of encryption keys DK for each UE in a group of UEs, based on the set of random or partially random values ​​RV and the secret encryption key PK for each UE, A device comprising means for securely configuring each UE in a group of UEs using the random or partially random value RV of each UE, the derived set of cryptographic keys DK for each UE, one secret cryptographic key from the set of secret cryptographic keys PK, and one cryptographic key ID from the corresponding set of cryptographic key IDs KID, wherein the one cryptographic key ID corresponds to the one secret cryptographic key.

13. The apparatus according to claim 12, wherein means for securely configuring each UE in a group of UEs using the random or partially random value RV of each UE, the derived set of cryptographic keys DK for each UE, the one private cryptographic key from the set of private cryptographic keys PK, and the one cryptographic key ID from the corresponding set of cryptographic key IDs KID, includes means for configuring each UE in a group of UEs using a secure connection between each UE and a server, wherein the secure connection is based on a public key-private key pair of the server.

14. A means for determining the derived set of cryptographic keys DK for each UE in a group of UEs, based on the set of random or partially random values ​​RV and the secret cryptographic key PK for each UE, The apparatus according to claim 12, comprising means for determining each derived cryptographic key in the derived cryptographic key set DK, wherein the derived cryptographic key set DK and the set of private cryptographic keys PK comprise an equal number of cryptographic keys, and each private cryptographic key in the set of private cryptographic keys PK is used to determine one derived cryptographic key in the set of derived cryptographic keys DK.

15. A means for periodically determining a new random or partially random value RV for each UE in the group of UEs and a new set of derived cryptographic keys DK, Means for securely configuring each UE in a group of UEs using the new random or partially random value RV of each UE and the new set of derived cryptographic keys DK, The apparatus according to claim 12, further comprising the following:

16. A device for supporting secure sidelink communication between a group of user equipment (UEs), which is performed by a first UE of a group of UEs, Means for securely receiving from a server a first random or partially random value RV1, a first set of derived encryption keys DK1, a first secret encryption key K1 of a set of secret encryption keys PK, and a first encryption key ID K1ID, wherein the first encryption key ID K1ID identifies the first secret encryption key K1. Means for transmitting the first random or partially random value RV1 and the first encryption key ID K1ID in plain text to a second UE of the group of UEs, Means for receiving a second random or partially random value RV2 and a second encryption key ID K2ID in plain text from the second UE of the group of UEs, wherein the second encryption key ID K2ID identifies the second secret encryption key K2 of the set of secret encryption keys PK configured in the second UE. A means for determining at least one common encryption key based on the first set of derived encryption keys DK1, the first secret encryption key K1, the second random or partially random value RV2, and the second encryption key ID K2ID, Means for supporting secure sidelink communication with the second UE based on the at least one common cryptographic key, A device equipped with the following features.

17. The apparatus according to claim 16, wherein the means for securely receiving the first random or partially random value RV1, the first set of derived cryptographic keys DK1, the first secret cryptographic key K1, and the first cryptographic key ID K1ID from the server includes means for receiving the first random or partially random value RV1, the first set of derived cryptographic keys DK1, the first secret cryptographic key K1, and the first cryptographic key ID K1ID using a secure connection between the first UE and the server, the secure connection being based on the public key-private key pair of the server.

18. The apparatus according to claim 16, wherein each derived cryptographic key DKm in the first set of derived cryptographic keys DK1 corresponds to a separate secret cryptographic key PKm in the set of secret cryptographic keys PK, each derived cryptographic key DKm comprises the encryption of a first random or partially random value RV1 using the corresponding separate secret cryptographic key PKm in the set of secret cryptographic keys PK, the first set of derived cryptographic keys DK1 and the set of secret cryptographic keys PK comprise an equal number of cryptographic keys, and each secret cryptographic key in the set of secret cryptographic keys PK is used to determine one derived cryptographic key in the set of derived cryptographic keys DK.

19. A means for determining the at least one common encryption key based on the first set of derived encryption keys DK1, the first secret encryption key K1, the second random or partially random value RV2, and the second encryption key ID K2ID, Means for identifying a first derived encryption key within the first set of derived encryption keys DK1, wherein the first derived encryption key corresponds to a second secret encryption key K2 within the set of secret encryption keys PK, and the second secret encryption key K2 is identified by the second encryption key ID K2ID, A means for determining a second derived encryption key based on encrypting the second random or partially random value RV2 using the first secret encryption key K1, A means for determining the at least one common encryption key based on the first derived encryption key and the second derived encryption key, The apparatus according to claim 16, comprising:

20. A means for determining the at least one common encryption key based on the first derived encryption key and the second derived encryption key, Means for transmitting the first key component to the second UE, wherein the first key component is encrypted using the first derived cryptographic key or the second derived key, Means for receiving a second key component from the second UE, wherein the second key component is encrypted using the other of the first derived cryptographic key or the second derived key, Means for decrypting the second key component using the first derived cryptographic key or the other of the second derived keys, A means for determining the at least one common cryptographic key based on the first key component and the second key component, The apparatus according to claim 19, comprising:

21. Means for transmitting the first random or partially random value RV1 and the first encryption key ID K1ID in plain text to each UE in the group of UEs, excluding the first UE and the second UE, Means for receiving a unique random or partially random value RV and an encryption key ID KID in plain text from each of the UEs in the group of UEs, wherein the encryption key ID KID identifies the secret encryption key K of the set of secret encryption keys PK configured in each of the UEs, A means for determining at least one common encryption key for each UE based on the first set of derived encryption keys DK1, the first secret encryption key K1, the random or partially random value RV, and the encryption key ID KID, Means for transmitting at least one common group encryption key to each of the aforementioned UEs, wherein the at least one common group encryption key is encrypted using the at least one common encryption key of each of the aforementioned UEs. Means for supporting secure sidelink communication of the group of UEs based on the at least one common group encryption key, The apparatus according to claim 16, further comprising the following:

22. The apparatus according to claim 16, wherein means for supporting secure sidelink communication of the group of UEs based on at least one common group cryptographic key includes means for exchanging messages for a sidelink positioning protocol (SLPP) with other members of the group of UEs, the SLPP messages being encrypted or integrity protected using the at least one common group cryptographic key, or both.

Images