CN117321981A - Message authentication optimization - Google Patents

Abstract

Apparatus, methods, and computer program products for cache construction for cryptography verification are provided that may be used in conjunction with a V2X communication system. An example method includes receiving at least one V2X message of a plurality of V2X messages from a second wireless device, the at least one V2X message being associated with an authentication key. The example method further includes determining whether the authentication key for the at least one V2X message is a target authentication key. The example method further includes determining to generate an entry for the authentication key in the cache if the authentication key is a target authentication key. The example method further includes generating an entry in the cache for the authentication key upon determining to generate the entry in the cache.

Description

Message authentication optimization

Cross Reference to Related Applications

The present application claims the benefits and priority of U.S. provisional application No.63/168,163 entitled "MESSAGE VERIFICATION OPTIMIZATION (message authentication optimization)" filed on 3 month 30 of 2021 and U.S. non-provisional patent application S/n.17/657,106 entitled "MESSAGE VERIFICATION OPTIMIZATION (message authentication optimization)" filed on 3 month 29 of 2022.

Technical Field

The present disclosure relates generally to cache construction for cryptography verification, and more particularly, to cryptography verification that may be used in conjunction with a vehicle networking (V2X) wireless communication system.

Introduction to the invention

Wireless communication systems are widely deployed to provide various telecommunication services such as telephony, video, data, messaging, and broadcast. A typical wireless communication system may employ multiple-access techniques capable of supporting communication with multiple users by sharing the available system resources. Examples of such multiple-access techniques include Code Division Multiple Access (CDMA) systems, time Division Multiple Access (TDMA) systems, frequency Division Multiple Access (FDMA) systems, orthogonal Frequency Division Multiple Access (OFDMA) systems, single carrier frequency division multiple access (SC-FDMA) systems, and time division-synchronous code division multiple access (TD-SCDMA) systems.

These multiple access techniques have been adopted in various telecommunications standards to provide a common protocol that enables different wireless devices to communicate at the urban, national, regional, and even global levels. An example telecommunications standard is 5G New Radio (NR). The 5G NR is part of the continuous mobile broadband evolution promulgated by the third generation partnership project (3 GPP) to meet new requirements associated with latency, reliability, security, scalability (e.g., with the internet of things (IoT)) and other requirements. The 5G NR includes services associated with enhanced mobile broadband (emmbb), large-scale machine type communication (emtc), and ultra-reliable low latency communication (URLLC). Some aspects of 5G NR may be based on the 4G Long Term Evolution (LTE) standard. There is a need for further improvements in 5G NR technology. These improvements are also applicable to other multiple access techniques and telecommunication standards employing these techniques.

Brief summary of the invention

The following presents a simplified summary of one or more aspects in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated aspects. This summary is not intended to identify key or critical elements of all aspects nor delineate the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that is presented later.

In an aspect of the disclosure, a method, apparatus, and computer-readable medium at a wireless device are provided. The wireless device may receive at least one V2X message of a plurality of internet of vehicles (V2X) messages from a second wireless device, the at least one V2X message being associated with an authentication key. The wireless device may determine whether the authentication key for the at least one V2X message is a target authentication key. If the authentication key is the target authentication key, the wireless device may determine to generate an entry for the authentication key in the cache. Upon determining to generate the entry in the cache, the wireless device may generate an entry in the cache for the authentication key.

To the accomplishment of the foregoing and related ends, the one or more aspects comprise the features hereinafter fully described and particularly pointed out in the claims. The following description and the annexed drawings set forth in detail certain illustrative features of the one or more aspects. These features are indicative, however, of but a few of the various ways in which the principles of various aspects may be employed.

Brief Description of Drawings

Fig. 1 is a diagram illustrating an example of a wireless communication system and an access network.

Fig. 2 illustrates example aspects of a side link slot structure.

Fig. 3 is a diagram illustrating an example of a first device and a second device involved in wireless communication based on, for example, V2V and/or other device-to-device communication.

Fig. 4 illustrates example wireless communications between V2X-based devices.

Fig. 5 illustrates an example cache construction.

FIG. 6 illustrates example V2X communications related to cache construction.

Fig. 7A-7C illustrate example cache construction and cache entry sizes associated with V2X communication regions.

Fig. 8 is a flow chart of a cache construction method for communication-related cryptography verification.

FIG. 9 is a flow chart of a cache construction method for communication-related cryptography verification.

Fig. 10 is a diagram illustrating an example of a hardware implementation of an example apparatus.

Detailed Description

The various configurations are described in detail below in conjunction with the accompanying drawings and are not meant to be the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of the various concepts. However, these concepts may be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form in order to avoid obscuring such concepts.

Several aspects of a telecommunications system are presented with reference to various apparatus and methods. These apparatus and methods are described in the following detailed description and are illustrated in the figures by various blocks, components, circuits, processes, algorithms, etc. (collectively referred to as "elements"). These elements may be implemented using electronic hardware, computer software, or any combination thereof. Whether such elements are implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system.

As an example, an element, or any portion of an element, or any combination of elements, may be implemented as a "processing system" that includes one or more processors. Examples of processors include: microprocessors, microcontrollers, graphics Processing Units (GPUs), central Processing Units (CPUs), application processors, digital Signal Processors (DSPs), reduced Instruction Set Computing (RISC) processors, system on a chip (SoC), baseband processors, field Programmable Gate Arrays (FPGAs), programmable Logic Devices (PLDs), state machines, gate logic, discrete hardware circuits, and other suitable hardware configured to perform the various functionalities described throughout this disclosure. One or more processors in the processing system may execute the software. Software (whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise) should be construed broadly to mean instructions, instruction sets, code segments, program code, programs, subroutines, software components, applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, or any combination thereof.

Accordingly, in one or more example aspects, implementations, and/or use cases, the described functionality may be implemented in hardware, software, or any combination thereof. If implemented in software, the functions may be stored on or encoded on a computer-readable medium as one or more instructions or code. Computer readable media includes computer storage media. A storage media may be any available media that can be accessed by a computer. By way of example, such computer-readable media can comprise Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable ROM (EEPROM), optical disk storage, magnetic disk storage, other magnetic storage devices, combinations of types of computer-readable media, or any other medium that can be used to store computer-executable code in the form of instructions or data structures that can be accessed by a computer.

Although aspects, implementations, and/or use cases are described herein by way of illustration of some examples, additional or different aspects, implementations, and/or use cases may be produced in many different arrangements and scenarios. The aspects, implementations, and/or use cases described herein may be implemented across many different platform types, devices, systems, shapes, sizes, and packaging arrangements. For example, aspects, implementations, and/or use cases may be generated via integrated chip implementations and other non-module component based devices (e.g., end user devices, vehicles, communication devices, computing devices, industrial equipment, retail/shopping devices, medical devices, artificial Intelligence (AI) enabled devices, etc.). While some examples may or may not be specific to each use case or application, broad applicability of the described examples may occur. Aspects, implementations, and/or use cases may range from chip-level or module components to non-module, non-chip-level implementations, and further to aggregated, distributed or Original Equipment Manufacturer (OEM) devices or systems incorporating one or more of the techniques herein. In some practical environments, devices incorporating the described aspects and features may also include additional components and features for implementing and practicing the claimed and described aspects. For example, the transmission and reception of wireless signals must include several components (e.g., hardware components including antennas, RF chains, power amplifiers, modulators, buffers, processors, interleavers, adders/summers, etc.) for analog and digital purposes. The techniques described herein may be practiced in a wide variety of devices, chip-level components, systems, distributed arrangements, aggregated or disassembled components, end-user devices, and the like, of various sizes, shapes, and configurations.

The deployment of a communication system, such as a 5G NR system, may be arranged with various components or constituent parts in a variety of ways. In a 5G NR system or network, a network node, network entity, mobility element of a network, radio Access Network (RAN) node, core network node, network element or network device (such as a Base Station (BS), or one or more units (or one or more components) performing base station functionality) may be implemented in an aggregated or disaggregated architecture.

Fig. 1 is a diagram illustrating an example of a wireless communication system and an access network 100. A wireless communication system, also known as a Wireless Wide Area Network (WWAN), includes a base station 102, a wireless device 104, an Evolved Packet Core (EPC) 160, and another core network 190 (e.g., a 5G core (5 GC)). Base station 102 may include macro cells (high power cell base stations) and/or small cells (low power cell base stations). The macrocell includes a base station. Small cells include femtocells, picocells, and microcells.

For example, a link between the wireless device 104 and the base station 102 or 180 may be established as an access link using the Uu interface. Other communications may be exchanged between wireless devices based on the side links. For example, some wireless devices 104 may communicate directly with each other using a device-to-device (D2D) communication link 158. In some examples, the D2D communication link 158 may use the DL/UL WWAN spectrum. The D2D communication link 158 may use one or more side link channels such as a physical side link broadcast channel (PSBCH), a physical side link discovery channel (PSDCH), a physical side link shared channel (PSSCH), and a physical side link control channel (PSCCH). D2D communication may be through a variety of wireless D2D communication systems such as, for example, wiMedia, bluetooth, zigBee, wi-Fi based on the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard, LTE, or NR.

Some wireless communication networks may include vehicle-based communication devices that may communicate according to: vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I) (e.g., from a vehicle-based communication device to a road infrastructure node, such as a Road Side Unit (RSU)), vehicle-to-network (V2N) (e.g., from a vehicle-based communication device to one or more network nodes, such as a base station), vehicle-to-pedestrian (V2P), cellular vehicle-to-everything (CV 2X), and/or combinations thereof, and/or with other devices, which may be collectively referred to as vehicle-to-everything (V2X) communication. Referring again to fig. 1, in some aspects, a wireless device 104 (e.g., an on-board unit (OBU), a roadside unit (RSU), a device carried by a road user of easy injury (VRU), or other wireless device) disposed at an automobile) may be configured to transmit a message directly to another wireless device 104. The communication may be based on V2X or other D2D communication, such as proximity services (ProSe), and the like. V2X-based communications and/or other D2D communications may also be transmitted and received by other transmitting and receiving devices, such as RSU 107, etc. Aspects of the communication may be based on PC5 or side link communication, for example, as described in connection with the example in fig. 2. Although the following description may provide examples regarding side link communications in conjunction with 5G NR, the concepts described herein may be applicable to other similar fields, such as LTE, LTE-A, CDMA, GSM, and other wireless technologies.

V2X communications (such as C-V2X communications) may enable vehicles to communicate with each other and everything around them. For example, the C-V2X communication may enable a vehicle to broadcast security messages, such as Basic Security Messages (BSM), intersection Mapping (MAP), collaboration Awareness Messages (CAM), to other C-V2X enabled vehicles. Additional examples of security messages may include signal phase and timing (SPaT), guest information messages (TIM), road Security Management (RSM), signal Request Messages (SRM), signal Status Messages (SSM), or Probe Vehicle Data (PVD). Some wireless technologies, such as 5G NR, may implement the ability to enable advanced security use cases to supplement basic security messages, such as Sensor Data Sharing Messages (SDSM), steering sharing and coordination messages (MSCM), and Collaborative Adaptive Cruise Control (CACC). These messages may also be referred to as Intelligent Transport System (ITS) messages. Since vehicles may use these messages for security applications and autopilot, reducing end-to-end latency may be important for C-V2X messages. At the same time, the recipient vehicle can ensure that the message is from a real source. The recipient vehicle may receive such messages from an OBU on another vehicle, an RSU such as a traffic light, a wireless device with a road user (VRU) with a vulnerable to injury such as a pedestrian or rider, and so on. Manipulating a vehicle based on messages from non-real sources (possibly malicious messages) may lead to catastrophic failure. Thus, the vehicle may be embedded with a dedicated Hardware Security Module (HSM). In a dedicated HSM, each transmitted V2X application layer message may be signed using a unique pseudonym certificate. The receiver may verify the certificate before using the message for a security application or an autopilot decision. However, such verification may introduce latency. In addition to validating only the latency that may be added, the cryptographic workload of validating all of these messages may be enormous, as the vehicle may need to receive messages from hundreds (if not thousands) of nearby on-vehicle OBUs, on-pedestrian devices, and infrastructure RSUs from each source (potentially approaching 50 Hz). For example, if there are 300 vehicles within a C-V2X range (e.g., 1 kilometer (km)). For BSM only, the receiver may receive 3000 messages per second. Messages for advanced applications such as SDSM, CPM, etc. may be transmitted at a rate of 10Hz and may result in higher authentication load. Signed messages from RSUs (such as SPAT and TIM) may also increase the verification load of the recipient vehicle. Each wireless device may be using the unique key for each application data plane for at least some number of minutes before re-randomizing to a new pseudonym.

The ability to safely and efficiently process all ITS messages may consume a variable amount of general purpose computing resources or dedicated hardware. The computational power costs may scale up as the latency and efficiency of these validations decrease and may consume a significant amount of power for the OBU at the vehicle. The optimization of processing more validations faster and more efficiently may enable the OBU to validate received messages without overloading processing power.

Caching information related to a particular certificate may be feasible because a vehicle may sign all of its BSM/CAM or other messages using the same certificate for a limited duration, which may significantly reduce verification latency. The cache may include cryptographic secret-specific pre-computed mathematical operations that may accelerate future verification based on the same key. However, such caches themselves may consume computing resources, such as processing power and memory. Furthermore, caching the new key may introduce additional latency to the verification. Aspects provided herein provide for optimizing a cache for new keys.

Referring again to fig. 1, the wireless device 104 may be associated with an OBU, RSU, or VRU, and may include a caching component 198, the caching component 198 configured to receive at least one V2X message of the plurality of V2X messages from the second wireless device, the at least one V2X message being associated with the authentication key. The caching component 198 may be further configured to determine whether the authentication key for the at least one V2X message is a target authentication key. The cache component 198 may be further configured to determine whether the validation key is a target validation key to generate an entry in the cache for the validation key. The cache component 198 may be further configured to generate an entry in the cache for the authentication key upon determining to generate the entry in the cache.

A wireless communication system, also referred to as a Wireless Wide Area Network (WWAN), includes a base station 102, a wireless device 104, an Evolved Packet Core (EPC) 160, and a core network (e.g., 5 GC) 190. Base station 102 may include macro cells (high power cell base stations) and/or small cells (low power cell base stations). The macrocell may include a base station. Small cells include femtocells, picocells, and microcells.

A base station 102 configured for 4G LTE, collectively referred to as an evolved Universal Mobile Telecommunications System (UMTS) terrestrial radio access network (E-UTRAN), may interface with EPC 160 through a backhaul link 132 (e.g., an S1 interface). A base station 102 configured for NR, collectively referred to as a next generation RAN (NG-RAN), may interface with a core network 190 over a backhaul link 184. Among other functions, the base station 102 may perform one or more of the following functions: user data delivery, radio channel ciphering and ciphering, integrity protection, header compression, mobility control functions (e.g., handover, dual connectivity), inter-cell interference coordination, connection setup and release, load balancing, distribution of non-access stratum (NAS) messages, NAS node selection, synchronization, radio Access Network (RAN) sharing, multimedia Broadcast Multicast Services (MBMS), subscriber and equipment tracking, RAN Information Management (RIM), paging, positioning, and delivery of alert messages. Base stations 102 may communicate with each other directly or indirectly (e.g., through EPC 160 or core network 190) over a backhaul link 134 (e.g., an X2 interface). The backhaul link 134 may be wired or wireless.

The base station 102 may communicate wirelessly with the wireless device 104. Each base station 102 may provide communication coverage for a respective geographic coverage area 110. There may be overlapping geographic coverage areas 110. For example, the small cell 102 'may have a coverage area 110' that overlaps with the coverage area 110 of one or more macro base stations 102. A network comprising small cells and macro cells may be referred to as a heterogeneous network. The heterogeneous network may also include a home evolved node B (eNB) (HeNB) that may provide services to a restricted group known as a Closed Subscriber Group (CSG). The communication link 120 between the base station 102 and the wireless device 104 may include Uplink (UL) (also referred to as reverse link) transmissions from the wireless device 104 to the base station 102 and/or Downlink (DL) (also referred to as forward link) transmissions from the base station 102 to the wireless device 104. Communication link 120 may use multiple-input multiple-output (MIMO) antenna techniques including spatial multiplexing, beamforming, and/or transmit diversity. These communication links may be through one or more carriers. For each carrier allocated in a carrier aggregation up to a total of yxmhz (x component carriers) for transmission in each direction, the base station 102/wireless device 104 may use a spectrum up to a bandwidth of Y MHz (e.g., 5, 10, 15, 20, 100, 400MHz, etc.). These carriers may or may not be contiguous with each other. The allocation of carriers may be asymmetric with respect to DL and UL (e.g., more or fewer carriers may be allocated to DL than UL). The component carriers may include a primary component carrier and one or more secondary component carriers. The primary component carrier may be referred to as a primary cell (PCell) and the secondary component carrier may be referred to as a secondary cell (SCell).

Some wireless devices 104 may communicate with each other using a device-to-device (D2D) communication link 158. The D2D communication link 158 may use the DL/UL WWAN spectrum. The D2D communication link 158 may use one or more side link channels such as a physical side link broadcast channel (PSBCH), a physical side link discovery channel (PSDCH), a physical side link shared channel (PSSCH), and a physical side link control channel (PSCCH). D2D communication may be through a variety of wireless D2D communication systems such as, for example, flashLinQ, wiMedia, bluetooth, zigBee, wi-Fi based on the IEEE 802.11 standard, LTE, or NR.

The wireless communication system may further include a Wi-Fi Access Point (AP) 150 in communication with a Wi-Fi Station (STA) 152 via a communication link 154 in a 5GHz unlicensed spectrum. When communicating in the unlicensed spectrum, the STA 152/AP 150 may perform a Clear Channel Assessment (CCA) prior to communication to determine whether the channel is available.

The small cell 102' may operate in licensed and/or unlicensed spectrum. When operating in unlicensed spectrum, the small cell 102' may employ NR and use the same 5GHz unlicensed spectrum as that used by the Wi-Fi AP 150. Small cells 102' employing NR in the unlicensed spectrum may push up access network coverage and/or increase access network capacity.

The electromagnetic spectrum is typically subdivided into various categories, bands, channels, etc., based on frequency/wavelength. In 5G NR, two initial operating bands have been identified as frequency range designated FR1 (410 MHz-7.125 GHz) and FR2 (24.25 GHz-52.6 GHz). Although a portion of FR1 is greater than 6GHz, FR1 is often (interchangeably) referred to as the "sub-6 GHz band" in various documents and articles. Similar naming problems sometimes occur with respect to FR2, which is commonly (interchangeably) referred to in various documents and articles as the millimeter wave "band, although it is different from the Extremely High Frequency (EHF) band (30 GHz-300 GHz) identified by the International Telecommunications Union (ITU) as the" millimeter wave "band.

The frequency between FR1 and FR2 is commonly referred to as the mid-band frequency. Recent 5G NR studies have identified the operating band of these mid-band frequencies as frequency range designation FR3 (7.125 GHz-24.25 GHz). The frequency bands falling within FR3 may inherit FR1 characteristics and/or FR2 characteristics and thus may effectively extend the characteristics of FR1 and/or FR2 into mid-band frequencies. Additionally, higher frequency bands are currently being explored to extend 5G NR operation above 52.6 GHz. For example, three higher operating bands have been identified as frequency range designation FR2-2 (52.6 GHz-71 GHz), FR4 (71 GHz-114.25 GHz) and FR5 (114.25 GHz-300 GHz). Each of these higher frequency bands falls within the EHF frequency band.

In view of the above, unless specifically stated otherwise, the term sub-6 GHz, etc., as used herein, may broadly represent frequencies that may be less than 6GHz, may be within FR1, or may include mid-band frequencies. Furthermore, unless specifically stated otherwise, the term "millimeter wave" or the like, if used herein, may refer broadly to frequencies, which may include mid-band frequencies, may be within FR2, FR4, FR2-2, and/or FR5, or may be within the EHF band.

Whether small cell 102' or a large cell (e.g., macro base station), base station 102 may include and/or be referred to as an eNB, g B node (gNB), or another type of base station. Some base stations (such as the gNB 180) may operate in the traditional sub-6 GHz spectrum, in millimeter wave frequencies, and/or near millimeter wave frequencies to communicate with the wireless device 104. When gNB 180 operates in millimeter wave frequencies or near millimeter wave frequencies, gNB 180 may be referred to as a millimeter wave base station. Millimeter-wave base station 180 may compensate for path loss and short range using beamforming 182 with wireless device 104. The base station 180 and the wireless device 104 may each include multiple antennas, such as antenna elements, antenna panels, and/or antenna arrays, to facilitate beamforming.

Devices may transmit and receive communications using beamforming. For example, fig. 1 illustrates that a base station 180 may transmit beamformed signals to wireless devices 104 in one or more transmit directions 182'. The wireless device 104 may receive the beamformed signals from the base station 180 in one or more receive directions 182 ". The wireless device 104 may also transmit the beamformed signals in one or more transmit directions to the base station 180. The base station 180 may receive the beamformed signals from the wireless devices 104 in one or more receive directions. The base station 180/wireless device 104 may perform beam training to determine the best receive direction and transmit direction for each of the base station 180/wireless device 104. The transmit direction and the receive direction of the base station 180 may be the same or may be different. The transmit direction and the receive direction of the wireless device 104 may be the same or may be different. Although the beamformed signals are illustrated between the wireless device 104 and the base station 102/180, aspects of beamforming may similarly be applied by the wireless device 104 or RSU 107 to communicate with another wireless device 104 or RSU 107, such as based on V2X, V V or D2D communications.

EPC 160 may include a Mobility Management Entity (MME) 162, other MMEs 164, a serving gateway 166, a Multimedia Broadcast Multicast Service (MBMS) gateway 168, a broadcast multicast service center (BM-SC) 170, and a Packet Data Network (PDN) gateway 172.MME 162 may be in communication with a Home Subscriber Server (HSS) 174. MME 162 is a control node that handles signaling between wireless device 104 and EPC 160. Generally, MME 162 provides bearer and connection management. All user Internet Protocol (IP) packets are communicated through the serving gateway 166, which serving gateway 166 itself is connected to the PDN gateway 172. The PDN gateway 172 provides wireless device IP address allocation as well as other functions. The PDN gateway 172 and BM-SC 170 are connected to an IP service 176.IP services 176 may include the internet, intranets, IP Multimedia Subsystem (IMS), PS streaming services, and/or other IP services. The BM-SC 170 may provide functionality for MBMS user service provisioning and delivery. The BM-SC 170 may be used as an entry point for content provider MBMS transmissions, may be used to authorize and initiate MBMS bearer services within a Public Land Mobile Network (PLMN), and may be used to schedule MBMS transmissions. The MBMS gateway 168 may be used to distribute MBMS traffic to base stations 102 belonging to a Multicast Broadcast Single Frequency Network (MBSFN) area broadcasting a particular service and may be responsible for session management (start/stop) and for collecting eMBMS related charging information.

The core network 190 may include access and mobility management functions (AMFs) 192, other AMFs 193, session Management Functions (SMFs) 194, and User Plane Functions (UPFs) 195. The AMF 192 may be in communication with a Unified Data Management (UDM) 196. The AMF 192 is a control node that handles signaling between the wireless device 104 and the core network 190. In general, AMF 192 provides QoS flows and session management. All user Internet Protocol (IP) packets are delivered through UPF 195. The UPF 195 provides wireless device IP address assignment as well as other functions. The UPF 195 is connected to an IP service 197. The IP services 197 may include the internet, intranets, IP Multimedia Subsystem (IMS), PS streaming services, and/or other IP services.

A base station may also be called a gNB, a node B, an evolved node B (eNB), an access point, a base transceiver station, a radio base station, a radio transceiver, a transceiver function, a Basic Service Set (BSS), an Extended Service Set (ESS), a transmission-reception point (TRP), or some other suitable terminology. Base station 102 provides an access point for wireless device 104 to EPC 160 or core network 190. Examples of wireless devices 104 include cellular telephones, smart phones, session Initiation Protocol (SIP) phones, laptops, personal Digital Assistants (PDAs), satellite radios, global positioning systems, multimedia devices, video devices, digital audio players (e.g., MP3 players), cameras, game consoles, tablet devices, smart devices, wearable devices, vehicles, electric meters, air pumps, large or small kitchen appliances, healthcare devices, implants, sensors/actuators, displays, or any other similar functional devices. Some wireless devices 104 may be referred to as IoT devices (e.g., parking meters, oil pumps, ovens, vehicles, heart monitors, etc.). The wireless device 104 may also be referred to as a station, mobile station, subscriber station, mobile unit, subscriber unit, wireless unit, remote unit, mobile device, wireless communication device, remote device, mobile subscriber station, access terminal, mobile terminal, wireless terminal, remote terminal, handset, user agent, mobile client, or some other suitable terminology.

Fig. 2 includes diagrams 200 and 210 illustrating example aspects of a slot structure that may be used for side-link communications (e.g., between wireless devices 104, RSUs 107, etc.). In some examples, the slot structure may be within a 5G/NR frame structure. In other examples, the slot structure may be within an LTE frame structure. Although the following description may focus on 5G NR, the concepts described herein may be applicable to other similar fields, such as LTE, LTE-A, CDMA, GSM, and other wireless technologies. The example slot structure in fig. 2 is merely one example, and other side link communications may have different frame structures and/or different channels for side link communications. A frame (10 ms) may be divided into 10 equally sized subframes (1 ms). Each subframe may include one or more slots. The subframe may also include a mini slot, which may include 7, 4, or 2 symbols. Each slot may include 7 or 14 symbols depending on the slot configuration. For slot configuration 0, each slot may include 14 symbols, and for slot configuration 1, each slot may include 7 symbols. Diagram 200 illustrates a single resource block of a single slot transmission, which may correspond to a Transmission Time Interval (TTI) of 0.5ms, for example. The physical side link control channel may be configured to occupy a plurality of Physical Resource Blocks (PRBs), e.g., 10, 12, 15, 20, or 25 PRBs. The PSCCH may be limited to a single subchannel. For example, the PSCCH duration may be configured as 2 symbols or 3 symbols. For example, a sub-channel may include 10, 15, 20, 25, 50, 75, or 100 PRBs. The resources for side-link transmission may be selected from a pool of resources comprising one or more sub-channels. As a non-limiting example, the resource pool may include between 1-27 subchannels. The PSCCH size may be established for a resource pool, for example, between 10-100% of a subchannel for a duration of 2 symbols or 3 symbols. Diagram 210 in fig. 2 illustrates an example in which the PSCCH occupies about 50% of the subchannel as one example illustrating the concept of a portion of the PSCCH occupying subchannel. A physical side link shared channel (PSSCH) occupies at least one subchannel. In some examples, the PSCCH may include a first portion of a side link control information (SCI) and the PSSCH may include a second portion of the SCI.

The resource grid may be used to represent a frame structure. Each slot may include Resource Blocks (RBs) (also referred to as Physical RBs (PRBs)) that extend for 12 consecutive subcarriers. The resource grid is divided into a plurality of Resource Elements (REs). The number of bits carried by each RE depends on the modulation scheme. As illustrated in fig. 2, some REs may include control information in the PSCCH and some REs may include demodulation RSs (DMRSs). At least one symbol may be used for feedback. Fig. 2 illustrates an example with two symbols for a physical side link feedback channel (PSFCH) with contiguous gap symbols. Symbols before and/or after feedback may be used to transition between data reception and feedback transmission. The gap enables the device to switch (e.g., in a subsequent time slot) from operating as a transmitting device to being ready to operate as a receiving device. As illustrated, data may be transmitted in the remaining REs. The data may include data messages as described herein. The location of any of the data, DMRS, SCI, feedback, gap symbols, and/or LBT symbols may be different from the example illustrated in fig. 2. In some examples, multiple time slots may be aggregated together.

Fig. 3 is a block diagram of a first wireless communication device 310 in communication with a second wireless communication device 350. In some examples, devices 310 and 350 may communicate based on V2X or other D2D communications. The communication may be based on a side link using, for example, a PC5 interface. Devices 310 and 350 may include wireless devices, RSUs, base stations, etc. Packets may be provided to controller/processor 375 that implements layer 3 and layer 2 functionality. Layer 3 includes a Radio Resource Control (RRC) layer, and layer 2 includes a Packet Data Convergence Protocol (PDCP) layer, a Radio Link Control (RLC) layer, and a Medium Access Control (MAC) layer.

Transmit (TX) processor 316 and Receive (RX) processor 370 implement layer 1 functionality associated with a variety of signal processing functions. Layer 1, which includes a Physical (PHY) layer, may include error detection on a transport channel, forward Error Correction (FEC) decoding/decoding of a transport channel, interleaving, rate matching, mapping onto a physical channel, modulation/demodulation of a physical channel, and MIMO antenna processing. TX processor 316 handles the mapping to signal constellations based on various modulation schemes, such as binary phase-shift keying (BPSK), quadrature phase-shift keying (QPSK), M-phase-shift keying (M-PSK), M-quadrature amplitude modulation (M-QAM). The coded and modulated symbols may then be split into parallel streams. Each stream may then be mapped to OFDM subcarriers, multiplexed with reference signals (e.g., pilots) in the time and/or frequency domain, and then combined together using an Inverse Fast Fourier Transform (IFFT) to produce a physical channel carrying the time domain OFDM symbol stream. The OFDM streams are spatially precoded to produce a plurality of spatial streams. The channel estimates from the channel estimator 374 may be used to determine the coding and modulation scheme and for spatial processing. The channel estimate may be derived from a reference signal and/or channel condition feedback transmitted by the device 350. Each spatial stream may then be provided to a different antenna 320 via a separate transmitter 318 TX. Each transmitter 318TX may modulate an RF carrier with a respective spatial stream for transmission.

At the device 350, each receiver 354RX receives a signal via its respective antenna 352. Each receiver 354RX recovers information modulated onto an RF carrier and provides the information to the Receive (RX) processor 356.TX processor 368 and RX processor 356 implement layer 1 functionality associated with various signal processing functions. RX processor 356 can perform spatial processing on the information to recover any spatial streams destined for device 350. If there are multiple spatial streams destined for device 350, they may be combined into a single OFDM symbol stream by RX processor 356. RX processor 356 then converts the OFDM symbol stream from the time domain to the frequency domain using a Fast Fourier Transform (FFT). The frequency domain signal comprises a separate OFDM symbol stream for each subcarrier of the OFDM signal. The symbols on each subcarrier, as well as the reference signal, are recovered and demodulated by determining the signal constellation points most likely to be transmitted by device 310. These soft decisions may be based on channel estimates computed by channel estimator 358. These soft decisions are then decoded and deinterleaved to recover the data and control signals that were originally transmitted by the device 310 on the physical channel. These data and control signals are then provided to a controller/processor 359 that implements layer 3 and layer 2 functionality.

A controller/processor 359 can be associated with the memory 360 that stores program codes and data. Memory 360 may be referred to as a computer-readable medium. The controller/processor 359 may provide demultiplexing between transport and logical channels, packet reassembly, cryptanalysis, header decompression, and control signal processing. The controller/processor 359 is also responsible for error detection using an ACK and/or NACK protocol to support HARQ operations.

Similar to the functionality described in connection with the transmissions by device 310, controller/processor 359 can provide RRC layer functionality associated with system information (e.g., MIB, SIB) acquisition, RRC connection, and measurement reporting; PDCP layer functionality associated with header compression/decompression, and security (ciphering, integrity protection, integrity verification); RLC layer functionality associated with upper layer PDU delivery, error correction by ARQ, concatenation, segmentation and reassembly of RLC SDUs, re-segmentation of RLC data PDUs, and re-ordering of RLC data PDUs; and MAC layer functionality associated with mapping between logical channels and transport channels, multiplexing MAC SDUs onto TBs, de-multiplexing MAC SDUs from TBs, scheduling information reporting, error correction by HARQ, priority handling, and logical channel prioritization.

Channel estimates derived by channel estimator 358 from reference signals or feedback transmitted by device 310 may be used by TX processor 368 to select appropriate coding and modulation schemes, as well as to facilitate spatial processing. The spatial streams generated by TX processor 368 may be provided to different antenna 352 via separate transmitters 354 TX. Each transmitter 354TX may modulate an RF carrier with a respective spatial stream for transmission.

Transmissions are processed at device 310 in a manner similar to that described in connection with the receiver functionality at device 350. Each receiver 318RX receives a signal through its corresponding antenna 320. Each receiver 318RX recovers information modulated onto an RF carrier and provides the information to the RX processor 370.

The controller/processor 375 may be associated with a memory 376 that stores program codes and data. Memory 376 may be referred to as a computer-readable medium. Controller/processor 375 provides demultiplexing between transport and logical channels, packet reassembly, cryptanalysis, header decompression, control signal processing. Controller/processor 375 is also responsible for error detection using ACK and/or NACK protocols to support HARQ operations.

At least one of TX processor 368, RX processor 356, and controller/processor 359 may be configured to perform aspects in conjunction with cache component 198 of fig. 1.

Fig. 4 illustrates an example 400 of wireless communication between devices based on V2X/V2V/D2D communication. The communication may be based on a slot structure including aspects described in connection with fig. 2. For example, the OBU 402 (which may also be a UE) may transmit a transmission 414 (e.g., including a control channel and/or a corresponding data channel), which transmission 414 may be received by the OBUs 404, 406, 408 (which may also be UEs). The control channel may include information for decoding the data channel and may also be used by the recipient device to avoid interference by suppressing transmissions on the occupied resources during data transmission. The number of TTIs that the data transmission will occupy, as well as RBs, may be indicated in a control message from the transmitting device. In addition to being operable as a recipient device, the OBUs 402, 404, 406, 408 may each also be operable as a transmitting device. Accordingly, the OBUs 406, 408 are illustrated as conveying transmissions 416, 420. The transmissions 414, 416, 420 may be broadcast or multicast to nearby devices. For example, the OBU 414 may transmit communications intended to be received by other OBUs within range 401 of the OBU 414. Additionally, the RSU 407 may receive communications from the OBUs 402, 404, 406, 408 and/or transmit communications to the OBUs 402, 404, 406, 408. The OBUs 402, 404, 406, 408 or RSUs 407 may include the cache component 198 of fig. 1. In some aspects, the OBU, RSU, and VRU may be capable of communicating with or without an active connection to the base station. For example, V2X communication may be based on different types or patterns of resource allocation mechanisms. In a first resource allocation mode (which may be referred to herein as "mode 1"), a centralized resource allocation may be provided by a network entity. For example, base station 102 or 180 may determine resources for side link communication and may allocate resources for different OBUs, RSUs, and VRUs for V2X communication. In this first mode, the device may receive a resource allocation from the base station 102 or 180. In a second resource allocation mode (which may be referred to herein as "mode 2"), distributed resource allocation may be provided. In mode 2, each device may autonomously determine the resources to use. To coordinate the selection of sidelink resources by individual devices, each device may use sensing techniques to monitor the reservation of resources by other devices and may select resources from unreserved resources for sidelink transmission. The OBU, RSU and VRU may determine one or more radio resources used by other devices in the time and frequency domains in order to select transmission resources that avoid collisions with other devices. Thus, in a second mode (e.g., mode 2), an individual wireless device may autonomously select resources for side link transmission, e.g., without a central entity (such as a base station indicating resources for the device).

V2X communications (such as C-V2X communications) may enable vehicles to communicate with each other and everything around them. For example, the C-V2X communication may enable the vehicle to broadcast a security message, such as BSM, MAP, CAM, to other C-V2X enabled vehicles. Additional examples of security messages may include SPaT, TIM, RSM, SRM, SSM or PVD. Some wireless technologies (such as 5 GNR) may implement functionality to enable advanced security use cases to supplement basic security messages such as SDSM, MSCM, and CACC. These messages may also be referred to as ITS messages. Since vehicles may use these messages for security applications and autopilot, reducing end-to-end latency may be important for C-V2X messages. At the same time, the recipient vehicle can ensure that the message is from a real source. The recipient vehicle may receive such messages from an OBU on another vehicle, an RSU such as a traffic light, a wireless device with a VRU such as a pedestrian or rider, and so on. Manipulating the vehicle based on potentially malicious messages from non-real sources may lead to catastrophic failure. Thus, the vehicle may be embedded with a dedicated HSM. In a dedicated HSM, each transmitted V2X application layer message may be signed using a unique pseudonym certificate. The receiver may verify the certificate before using the message for a security application or autonomous driving decision. However, such verification may introduce latency. In addition to validating only the latency that may be added, the cryptographic workload of validating all of these messages may be enormous, as the vehicle may need to receive messages from hundreds (if not thousands) of nearby on-vehicle OBUs, on-pedestrian devices, and infrastructure RSUs from each source (potentially approaching 50 Hz). For example, if there are 300 vehicles within a C-V2X range (e.g., 1 km). For BSM only, the receiver may receive 3000 messages per second. Messages for advanced applications such as SDSM, CPM, etc. may be transmitted at a rate of 10Hz and may result in higher authentication load. Signed messages from RSUs (such as SPAT and TIM) may also increase the verification load of the recipient vehicle. Each wireless device may be using the unique key for each application data plane for at least some number of minutes before re-randomizing to a new pseudonym.

The ability to safely and efficiently process all ITS messages may consume a variable amount of general purpose computing resources or dedicated hardware. The computational power costs may scale up as the latency and efficiency of these validations decrease and may consume a significant amount of power for the OBU at the vehicle. The optimization of processing more validations faster and more efficiently may enable the OBU to validate received messages without overloading processing power.

Since a vehicle may sign all of its BSM/CAM or other messages using the same certificate for a limited duration, it may be feasible to cache information related to a particular certificate, which may significantly reduce verification latency. The cache may include cryptographic secret-specific pre-computed mathematical operations that may accelerate future verification based on the same key. However, such caches themselves may consume computing resources, such as processing power and memory. Furthermore, caching the new key may introduce additional latency to the verification. Aspects provided herein provide for optimization of the caching of new keys. In some aspects, the cache may be a look-up table (LUT).

In some aspects, a wireless device (such as OBU 402, 404, 406, 408, or RSU 407) may route messages received at a C-V2X modem to an ITS stack (as further described in connection with fig. 8 and 9). In some aspects, the ITS stack may include a security software component to verify consistency and integrity via PKI/certificates in accordance with international standards (e.g., IEEE 1609.2). In some aspects, a wireless device, such as OBU 402, 404, 406, 408 or RSU 407, may use a cryptographic authentication library to enable asymmetric cryptographic authentication of a Secure Protocol Data Unit (SPDU) of a message, such as by implanting an Elliptic Curve Cryptography (ECC) cryptographic code, e.g., national Institute of Standards Technology (NIST) -P256, chinese SM-2, brainool-256, etc. In some aspects, a wireless device, such as OBU 402, 404, 406, 408 or RSU 407, may encrypt a message using IEEE 802.11bd and V2X for Dedicated Short Range Communications (DSRC).

Cache construction may add additional latency to the verification of new keys and may interfere with the verification process and other important tasks. If an ITS station (such as an OBU) is powered up in a congested urban area, there may be thousands of new public keys to begin processing. Building a cache for a burst new certificate (and associated public key) of a V2X message may dominate CPU load and interrupt other latency sensitive tasks. In some aspects, a wireless device (such as a cache assistant for the wireless device as further described in fig. 8 and 9) may build cache entries at a periodic rate that follows the rate specified by the cache build period. In some aspects, the cache build period may be configurable. For example, the cache build period may be configurable, either by the wireless device itself or by a network entity. In some aspects, the cache build period may be dynamic and based on the current load and the predicted load of the system. The wireless device may build the cache entry as a lower priority thread in the background (not as part of the authentication request) so as not to add latency to the authentication request. To handle burst arrivals of V2X messages, the wireless device may reduce the cache build period.

As illustrated by example 500 of fig. 5, a wireless device may receive a number of V2X messages within a first time frame (time frame 1) and a number of V2X messages within a second time frame (time frame 2). The wireless device may build the cache according to the cache build period 502. If there is a burst of V2X messages arriving in time frame 3, the wireless device may adjust the cache construction period to the adjusted cache construction period 504, thereby reducing the cache construction rate and increasing the cache construction period. For example, the wireless device may increase the cache build period in order to release more processing power to validate the message.

In a congested environment, the number of keys may be more than the allocated cache size, and it may not be possible to build a cache for all keys. In some aspects, the cache assistant may build cache entries for all keys after a cache build period when the configured cache size is sufficient to support that all keys are continuously verified (keys used at least once every X seconds). When the number of allocated cache entries is less than the number of keys used periodically (at least once every X seconds), the cache assistant may replace the cached entries with uncached entries that are used more frequently (up to at least the Y Hz variance threshold). By replacing the least common entry, the benefits of using a cache can be focused on the most common keys.

In some aspects, the wireless device may build the cache based on the relevance of the messages. For example, some RSUs, OBUs, or other wireless devices may be temporarily in range of the wireless device, while some wireless devices may be in range for a longer duration. In addition to making selections based on the relative frequency of use of any given key, CPM, BSM, CAM or additional application plane metadata in the content of the geographic network header may be used to optimize decisions regarding which cache tables may be worth investing further based on the cost of construction. For example, the cache assistant may select keys for the OBU, RSU, or VRU devices that are most likely to be within the longest predicted future amount of time (based on the location, heading, station location/speed/heading of the device that transmitted the message). For example, if the transmitting device is moving away from the receiving device at a high speed and the distance is increasing, the key may be less relevant and may not be a candidate for which to construct a cache entry.

For example, as illustrated by example 600 of fig. 6, for OBU 602, if a further distance OBU 608 is moving away 602 at a high speed, message 618 from OBU 608 may be less relevant, and OBU 602 may not establish a cache entry for message 618. As further illustrated in example 600, for OBU 602, if OBU 604 is close to OBU 602 and is heading to OBU 602, message 614 from OBU 604 may have a high correlation and OBU 602 may build a cache entry for message 614. Similarly, for OBU 602, if OBU 606 and OBU 610 are not going to OBU 602, message 616 from OBU 604 and message 620 from OBU 610 may have low correlation, and OBU 602 may not build a cache entry for message 616 and message 620. In some aspects, messages 622 from devices of nearby VRUs that are moving toward OBU 602 may have high correlation, and OBU 602 may construct a cache entry for messages 622. In some aspects, OBU 602 may use range 660 to determine whether to construct an entry for a key. For example, if the device transmitting the message associated with the key is outside of range 660, OBU 602 may determine not to make an entry for the key.

In some aspects, the OBU 602 may additionally use a local dynamic map, which may include a location of the OBU or RSU and a history of previous exposure durations of the OBU or RSU. For example, the previous exposure duration may be the length of a typical traffic light and may be a vehicle stopped near the OBU 602. In some aspects, the OBU 602 may use a correlation of the transmitting device, such as direction/heading, speed, or distance (which may indicate time of collision) to determine which public keys to pre-calculate to consider to generate the cache entry. Target Classification (TC) may be performed and the results may be fed into a cache assistant for priority determination and determination of which keys are to be handled first or which keys need to be removed from the cache. For example, RSUs, OBUs, and VRUs may be categorized. In another example, other classifications may be further introduced. In some aspects, certificate expiration may also be considered in determining priority. For example, the OBU 602 may not generate a cache entry for a soon expired certificate because a soon expired certificate may not be likely to be received again.

In some aspects, the size of the cached entries may be based on the environment surrounding the OBU. The OBU can learn about the environment (date, time, place) and can use analysis/other sensors and use appropriate algorithms to select the correct entry size. For example, in a congested environment with low speed traffic, a cache with more entries and less information per entry may be used. For less congested environments, caches with more entries and less information per entry may be used.

As illustrated by example 700 in fig. 7A, OBU 702 may be in a less crowded environment (in range 701) with OBUs 704, 706, and 708 and VRU 710. Accordingly, the OBU 702 may build a cache 720 having an entry size of 16 kilobytes (kB). The OBUs in fig. 7A may be illustrative and may not reflect the actual number of OBUs within the range. Cache 720 in fig. 7A may be illustrative and may not represent the actual size of the cache. For example, if the cache size of cache 720 is a 20 Megabyte (MB) cache, a total of 1250 entries may be feasible. As illustrated by example 755 in fig. 7B, OBU 752 may be in a more crowded environment (in range 751) with OBUs 754, 756, 758, 762, 764, 766, and 768, and VRU 760. Accordingly, OBU 752 may build a cache 770 with an entry size of 4 kB. The OBUs in fig. 7B may be illustrative and may not reflect the actual number of OBUs within that range. The cache 770 in fig. 7B may be illustrative and may not represent the actual size of the cache. For example, if the cache size of cache 770 is a 20MB cache, a total of 5000 entries may be feasible. In some aspects, smaller entry sizes may optimize verification latency for a large number of nearby devices. In some aspects, a larger entry size may significantly optimize the verification latency of a smaller number of nearby devices.

In some aspects, the OBU may determine an entry size of each entry upon generating the entry, and the cache may have a mixed entry size. For example, as illustrated in fig. 7C, cache 780 may include some entries 782, 784, 786, 788, and 790 of one size (such as 16 kB) and other entries of a different size (such as 4 kB). The cache 780 in fig. 7C may be illustrative and may not represent the actual size of the cache.

Fig. 8 is a flow chart 800 of a cache construction method for cryptography verification that may be associated with wireless communications. The method may be performed by a wireless device (which may be otherwise referred to as a first wireless device) (e.g., wireless device 104, OBU 402, 404, 406, 408, 602, 702, 752; equipment 1002). Although the methods in some aspects are described in connection with V2X communications, the cache construction methods in some other aspects may be applied independent of wireless communications.

At 802, the wireless device may receive at least one V2X message of a plurality of V2X messages from a second wireless device, the at least one V2X message may be associated with an authentication key. For example, the OBU 602, 702, or 752 may receive at least one V2X message of the plurality of V2X messages from the second wireless device, the at least one V2X message may be associated with the authentication key. In some aspects, 802 may be performed by cellular baseband processor 1004 in fig. 10. The wireless device may be one of an OBU, RSU or VRU and the second wireless device may be one of an OBU, RSU or VRU. In some aspects, the authentication key may be located in a security wrapper (wrapper) of a header in the at least one V2X message. In some aspects, the authentication key corresponds to at least one application of the second wireless device. For example, the application may include one or more of the following: forward Collision Warning (FCW), pre-collision sensing, cooperative collision warning, ramp speed warning, emergency vehicle signal preemption, do not overtake warning, queued travel message, sensor share message, cooperative driving message, road condition warning, or other V2X application.

At 804, the wireless device may determine whether the authentication key for the at least one V2X message is a target authentication key. For example, the OBU 602, 702, or 752 may determine whether the authentication key for the at least one V2X message is the target authentication key. In some aspects, 804 may be performed by a cache assistant 1048 in the security software component 1042 in fig. 10. As part of 804, the wireless device may determine a correlation of the authentication key for the at least one V2X message at 814. For example, if the correlation is high, the wireless device may determine that the authentication key is the target authentication key, or if the correlation is low, determine that the authentication key is not the target authentication key. In some aspects, the wireless device may determine the correlation based on one or more of: a location of the second wireless device, a direction of movement of the second wireless device, a velocity of the second wireless device, or a distance associated with the second wireless device relative to the first wireless device. In some aspects, the wireless device may further determine the correlation by performing a target classification on the second wireless device. For example, the wireless device may determine the correlation as described in connection with fig. 6. In some aspects, the wireless device may further determine a correlation of the authentication key based on a credential expiration associated with the authentication key for the at least one V2X message. For example, if the certificate associated with the authentication key expires, the wireless device may determine that the correlation is low.

In some aspects, if there is no existing entry in the cache associated with the authentication key and if the authentication key is the target authentication key, the wireless device may determine that an entry for the authentication key is to be generated in the cache at 808. In some aspects, 808 may be performed by the cache assistant 1048 in fig. 10. For example, the OBU 602, 702, or 752 may determine to generate an entry in the cache for the verification key.

In some aspects, as part of 810, the wireless device may determine a size of an entry in the cache based on at least one of: the speed of the second wireless device, the density of the second wireless device, a first set of one or more attributes comprising a first region of the first wireless device, or a second set of one or more attributes comprising a second region of the second wireless device. For example, the OBU 602, 702, or 752 may determine the size of an entry in the cache based on at least one of: the speed of the second wireless device, the density of the second wireless device, a first set of one or more attributes comprising a first region of the first wireless device, or a second set of one or more attributes comprising a second region of the second wireless device. For example, the size of the entry may be one of a defined large size (e.g., 16 kB) or a defined small size (e.g., 4 kB). In some aspects, the first set comprising one or more attributes or the second set comprising one or more attributes may include a congestion level associated with the first region or the second region. For example, as previously described in connection with fig. 7A and 7B, the entry size may be smaller if the congestion level is higher, and the entry size may be larger if the congestion level is lower.

Upon determining that the entry is to be generated in the cache, the wireless device may generate an entry for the authentication key in the cache, 810. For example, the OBU 602, 702, or 752 may generate an entry in the cache for the authentication key upon determining to generate the entry in the cache. In some aspects, 810 may be performed by the cache assistant 1048 in fig. 10. In some aspects, the entry in the cache is generated in a background session separate from the authentication procedure for the authentication key for the at least one V2X message. In some aspects, the background session may be associated with a first priority, and the authentication procedure for the authentication key for the at least one V2X message may be associated with a second priority, which may be lower than the first priority. In some aspects, the entries in the cache may be generated based on a group of wireless devices in which the first wireless device and the second wireless device may be included. In some aspects, entries in the cache may be periodically generated based on cache construction periods (such as cache construction periods 502 and 504 in fig. 5). In some aspects, the cache construction period may be based on one or more of: a current computational load associated with the wireless device and a predicted computational load associated with the wireless device. In some aspects, the cache construction period may be further based on the V2X message arrival rate within the time frame, e.g., as previously described in connection with fig. 5.

Fig. 9 is a flow chart 900 of a cache construction method for cryptography verification that may be associated with wireless communications. The method may be performed by a wireless device (which may be otherwise referred to as a first wireless device) (e.g., wireless device 104, OBU 402, 404, 406, 408, 602, 702, 752; equipment 1002). Although the methods in some aspects are described in connection with V2X communications, the cache construction methods in some other aspects may be applied independent of wireless communications.

At 902, the wireless device may receive at least one V2X message of a plurality of V2X messages from a second wireless device, the at least one V2X message may be associated with an authentication key. For example, the OBU 602, 702, or 752 may receive at least one V2X message of the plurality of V2X messages from the second wireless device, the at least one V2X message may be associated with the authentication key. In some aspects, 902 may be performed by the cellular baseband processor 1004 in fig. 10. The wireless device may be one of an OBU, RSU or VRU and the second wireless device may be one of an OBU, RSU or VRU. In some aspects, the authentication key may be located in a security wrapper (wrapper) of a header in the at least one V2X message. In some aspects, the authentication key corresponds to at least one application of the second wireless device. For example, the application may include one or more of the following: forward Collision Warning (FCW), pre-collision sensing, cooperative collision warning, ramp speed warning, emergency vehicle signal preemption, do not overtake warning, queued travel message, sensor share message, cooperative driving message, road condition warning, or other V2X application.

In some aspects, at 912, the wireless device may route the at least one message from the cellular C-V2X modem (such as the cellular baseband processor 1004) to an ITS stack (such as the ITS component 1040) or security software modules (such as the security software component 1042 and the cryptography verification component 1044). For example, the OBU 602, 702, or 752 may route the at least one message from the cellular C-V2X modem to the ITS stack. In some aspects, 912 may be performed by cellular baseband processor 1004 in fig. 10.

At 904, the wireless device may determine whether the authentication key for the at least one V2X message is a target authentication key. For example, the OBU 602, 702, or 752 may determine whether the authentication key for the at least one V2X message is the target authentication key. In some aspects 904 may be performed by a cache assistant 1048 in the security software component 1042 in fig. 10. As part of 904, the wireless device may determine a correlation of the authentication key with the at least one V2X message at 914. For example, if the correlation is high, the wireless device may determine that the authentication key is the target authentication key, or if the correlation is low, determine that the authentication key is not the target authentication key. In some aspects, the wireless device may determine the correlation based on one or more of: a location of the second wireless device, a direction of movement of the second wireless device, a velocity of the second wireless device, or a distance associated with the second wireless device relative to the first wireless device. In some aspects, the wireless device may further determine the correlation by performing a target classification on the second wireless device. For example, the wireless device may determine the correlation as described in connection with fig. 6. In some aspects, the wireless device may further determine a correlation of the authentication key based on a credential expiration associated with the authentication key for the at least one V2X message. For example, if the certificate associated with the authentication key expires, the wireless device may determine that the correlation is low.

In some aspects, the wireless device may further determine whether the authentication key for the at least one V2X message is a target authentication key based on one or more of: the frequency of use of the authentication key, the set of application plane metadata associated with the at least one V2X message, the range of consideration associated with the second wireless device, the collision time associated with the second wireless device, or a local dynamic mapping associated with a group of wireless devices within the area including the first wireless device and the second wireless device. For example, the consideration ranges may correspond to the ranges 660, 701, 751, etc. In some aspects, the range is considered to be based on one or more of a location of the second wireless device, a speed of the second wireless device, or a distance associated with the second wireless device relative to the first wireless device. In some aspects, the application plane metadata set may include one or more of the following: BSM metadata, MAP metadata, SPaT metadata, TIM metadata, RSM metadata, SRM metadata, CAM metadata, SSM metadata, global Navigation Satellite System (GNSS) metadata or maritime Radio Technical Commission (RTCM) metadata, SDSM metadata, MSCM metadata, CACC metadata or PVD metadata. In some aspects, the local dynamic map may include a duration of exposure history of exposure histories associated with groups of wireless devices within the area, which may represent a frequency of each wireless device and a duration in the vicinity of the wireless device. For example, if a wireless device is frequently near an RSU a, the duration of the exposure history may indicate that the RSU a is frequently near the wireless device and a period of time associated with the presence.

At 906, the wireless device may determine whether an existing entry associated with the authentication key exists in the cache. For example, the OBU 602, 702, or 752 may determine whether there is an existing entry in the cache associated with the validation key. In some aspects, 906 may be performed by the cache assistant 1048 in fig. 10. In some aspects, the entry in the cache may correspond to information of the authentication key. For example, the information of the authentication key may include a pre-computed mathematical operation specific to a set of cryptographic keys of the authentication key. In some aspects, the caches may correspond to caches 720, 770, 780, or 1046. In some aspects, the cache may be a look-up table (LUT).

In some aspects, if there is an existing entry in the cache associated with the authentication key, the wireless device may perform authentication of the authentication key based on the existing entry (such as by performing the authentication in the process) at 916. For example, the OBU 602, 702, or 752 may perform verification of the verification key based on existing entries. In some aspects, 916 can be performed by the cryptography verification component 1044 in fig. 10.

In some aspects, if there is no existing entry in the cache associated with the authentication key and if the authentication key is the target authentication key, the wireless device may determine that an entry for the authentication key is to be generated in the cache at 908. In some aspects, 908 may be performed by the cache assistant 1048 in fig. 10. For example, the OBU 602, 702, or 752 may determine to generate an entry in the cache for the verification key. In some aspects, as part of 908, the wireless device may determine a cache size limit associated with the cache at 920. For example, the OBU 602, 702, or 752 may determine a cache size limit associated with the cache. The cache size limit may be a total size limit of the entire cache. In some aspects, if the wireless device determines at 924 that the cache size limit supports continuous generation of one or more caches associated with one or more target validation keys that are used less frequently than the threshold, the wireless device may determine to generate an entry in the cache for the validation key. In some aspects, if the wireless device determines that the cache size limit does not support continuous generation of one or more caches associated with one or more target authentication keys having a frequency of use below the threshold, the wireless device may compare the first frequency of use associated with the one or more entries to the second frequency of use associated with the target authentication key at 922. If the first frequency of use is less than the second frequency of use by a defined threshold, such as Y Hz, the wireless device may generate an entry for the authentication key in the cache (as part of 910) by replacing the one or more entries with the entry at 926.

In some aspects, as part of 910, the wireless device may determine the size of the entry in the cache based on at least one of: the speed of the second wireless device, the density of the second wireless device, a first set of one or more attributes comprising a first region of the first wireless device, or a second set of one or more attributes comprising a second region of the second wireless device. For example, the OBU 602, 702, or 752 may determine the size of an entry in the cache based on at least one of: the speed of the second wireless device, the density of the second wireless device, a first set of one or more attributes comprising a first region of the first wireless device, or a second set of one or more attributes comprising a second region of the second wireless device. For example, the size of the entry may be one of a defined large size (e.g., 16 kB) or a defined small size (e.g., 4 kB). In some aspects, the first set comprising one or more attributes or the second set comprising one or more attributes may include a congestion level associated with the first region or the second region. For example, as previously described in connection with fig. 7A and 7B, the entry size may be smaller if the congestion level is higher, and the entry size may be larger if the congestion level is lower.

Upon determining that the entry is to be generated in the cache, the wireless device may generate an entry in the cache for the authentication key at 910. For example, the OBU 602, 702, or 752 may generate an entry in the cache for the authentication key upon determining to generate an entry in the cache. In some aspects, 910 may be performed by the cache assistant 1048 in fig. 10. In some aspects, the entry in the cache is generated in a background session separate from the authentication procedure for the authentication key for the at least one V2X message. In some aspects, the background session may be associated with a first priority, and the authentication procedure for the authentication key for the at least one V2X message may be associated with a second priority, which may be lower than the first priority. In some aspects, the entries in the cache may be generated based on a group of wireless devices in which the first wireless device and the second wireless device may be included. In some aspects, entries in the cache may be periodically generated based on cache construction periods (such as cache construction periods 502 and 504 in fig. 5). In some aspects, the cache construction period may be based on one or more of: a current computational load associated with the wireless device and a predicted computational load associated with the wireless device. In some aspects, the cache construction period may be further based on the V2X message arrival rate within the time frame, e.g., as previously described in connection with fig. 5.

Fig. 10 is a diagram 1000 illustrating an example of a hardware implementation of an apparatus 1002. The apparatus 1002 is a wireless device and includes a cellular baseband processor 1004 (also referred to as a modem) coupled to a cellular RF transceiver 1022 and one or more Subscriber Identity Module (SIM) cards 1020, an application processor 1006 coupled to a Secure Digital (SD) card 1008 and a screen 1010, a bluetooth module 1012, a Wireless Local Area Network (WLAN) module 1014, a Global Positioning System (GPS) module 1016, and a power supply 1018. Cellular baseband processor 1004 communicates with wireless device 104 and/or BS102/180 through cellular RF transceiver 1022. The cellular baseband processor 1004 may include a computer readable medium/memory. The computer readable medium/memory may be non-transitory. The cellular baseband processor 1004 is responsible for general processing, including the execution of software stored on the computer-readable medium/memory. The software, when executed by the cellular baseband processor 1004, causes the cellular baseband processor 1004 to perform the various functions described supra. The computer readable medium/memory can also be used for storing data that is manipulated by the cellular baseband processor 1004 when executing software. Cellular baseband processor 1004 further includes a receiving component 1030, a communication manager 1032, and a transmitting component 1034. The communications manager 1032 includes the one or more illustrated components. The components within the communications manager 1032 may be stored in a computer-readable medium/memory and/or configured as hardware within the cellular baseband processor 1004. Cellular baseband processor 1004 may be a component of wireless device 350 and may include memory 360 and/or at least one of: a TX processor 368, an RX processor 356, and a controller/processor 359. In one configuration, the apparatus 1002 may be a modem chip and include only the baseband processor 1004, and in another configuration, the apparatus 1002 may be an entire wireless device (e.g., see 350 of fig. 3) and include additional modules of the foregoing apparatus 1002. The communication manager 1032 may receive at least one V2X message of the plurality of V2X messages from the second wireless device, the at least one V2X message may be associated with the authentication key, as described in connection with 802 in fig. 8 and 902 in fig. 9.

The apparatus 1002 may further include an ITS component 1040, a security software component 1042 that may include a cache assistant 1048, and a cryptography verification component 1044 that may include a cache 1046, as previously described in connection with fig. 8. Cache 1046 may correspond to caches 720, 770, and 780 described in connection with fig. 7A-7C. In some aspects, the cryptographic verification component 1044 may be configured to perform verification of the V2X message based on or independent of the entry in the cache. In some aspects, the security software component 1042 may be configured to determine whether the verification key is a target verification key to generate an entry for the verification key in the cache, e.g., as described in connection with 808 in fig. 8 and 908 in fig. 9. In some aspects, the security software component 1042 may be configured to generate an entry for the authentication key in the cache upon determining to generate the entry in the cache, e.g., as described in connection with 810 in fig. 8 and 910 in fig. 9.

The apparatus may include additional components to perform each of the blocks of the algorithms in the foregoing flowcharts of fig. 8-9. As such, each block in the foregoing flow diagrams of fig. 8-9 may be performed by a component and the apparatus may include one or more of those components. These components may be one or more hardware components specifically configured to perform the process/algorithm, implemented by a processor configured to perform the process/algorithm, stored in a computer-readable medium for implementation by a processor, or some combination thereof.

In some aspects, the apparatus 1002 may include means for receiving at least one V2X message of a plurality of V2X messages from a second wireless device, the at least one V2X message associated with an authentication key. In some aspects, the apparatus 1002 may further include means for determining whether the authentication key for the at least one V2X message is a target authentication key. In some aspects, the apparatus 1002 may further include means for determining whether the validation key is a target validation key to generate an entry for the validation key in the cache. In some aspects, the apparatus 1002 may further include means for: determining a correlation of the authentication key for the at least one V2X message based on one or more of: a location of the second wireless device, a direction of movement of the second wireless device, a velocity of the second wireless device, or a distance associated with the second wireless device relative to the first wireless device. In some aspects, the apparatus 1002 may further include means for performing object classification for the second wireless device. In some aspects, the apparatus 1002 may further comprise means for: the size of the entry in the cache is determined based on at least one of: the speed of the second wireless device, the density of the second wireless device, a first set of one or more attributes comprising a first region of the first wireless device, or a second set of one or more attributes comprising a second region of the second wireless device. In some aspects, the apparatus 1002 may further include means for determining a cache size limit associated with the cache. In some aspects, the apparatus 1002 may further include means for determining that the cache size limit supports continuous generation of one or more caches associated with one or more target authentication keys that are used less frequently than a threshold. In some aspects, the apparatus 1002 may further include means for comparing a first frequency of use associated with the one or more entries with a second frequency of use associated with the target authentication key, the second frequency of use being higher than the first frequency of use. In some aspects, the apparatus 1002 may further include means for generating an entry for the authentication key in the cache, including replacing one or more entries with the entry. In some aspects, the apparatus 1002 may further include means for receiving at least one message associated with the authentication key. In some aspects, the apparatus 1002 may further include means for determining whether the authentication key is a target authentication key. In some aspects, the apparatus 1002 may further include means for generating an entry for the authentication key in the cache by determining whether the authentication key is a target authentication key by determining a correlation of the authentication key. In some aspects, the apparatus 1002 may further include means for determining a size of an entry in the cache. In some aspects, the apparatus 1002 may further include means for generating an entry in the cache having the size for the authentication key upon determining to generate the entry in the cache and determining the size, wherein the entry in the cache is generated in a background session separate from an authentication procedure for the authentication key.

The foregoing means may be one or more of the foregoing components in the apparatus 1002 configured to perform the functions recited by the foregoing means. As described above, the apparatus 1002 may include a TX processor 368, an RX processor 356, and a controller/processor 359. As such, in one configuration, the foregoing means may be the TX processor 368, the RX processor 356, and the controller/processor 359 configured to perform the functions recited by the foregoing means.

It is to be understood that the specific order or hierarchy of the various blocks in the disclosed process/flow diagrams is an illustration of an example approach. It will be appreciated that the specific order or hierarchy of blocks in the processes/flow diagrams may be rearranged based on design preferences. Further, some blocks may be combined or omitted. The accompanying method claims present elements of the various blocks in a sample order, and are not limited to the specific order or hierarchy presented.

The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Accordingly, the claims are not to be limited to the aspects described herein, but are to be accorded the full scope consistent with the language claims. Reference to an element in the singular is not intended to mean "one and only one" (unless specifically so stated) but rather "one or more". Terms such as "if", "when … …" and "simultaneous" do not mean an immediate time relationship or reaction. That is, these phrases (e.g., "when … …") do not imply that an action will occur in response to or during the occurrence of an action, but rather merely that a condition is met, and do not require specific or immediate time constraints for the action to occur. The term "exemplary" is used herein to mean "serving as an example, instance, or illustration. Any aspect described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other aspects. The term "some" means one or more unless specifically stated otherwise. Combinations such as "at least one of A, B or C", "one or more of A, B or C", "at least one of A, B and C", "one or more of A, B and C", and "A, B, C or any combination thereof" include any combination of A, B and/or C, and may include a plurality of a, a plurality of B, or a plurality of C. Specifically, combinations such as "at least one of A, B or C", "one or more of A, B or C", "at least one of A, B and C", "one or more of A, B and C", and "A, B, C or any combination thereof" may be a alone, B alone, C, A and B, A and C, B and C alone, or a and B and C, wherein any such combination may comprise one or more members of A, B or C. A collection should be interpreted as a collection of elements, where the elements are numbered one or more. Accordingly, for an X set, X may include one or more elements. If a first apparatus receives data from a second apparatus or transmits data to a second device, the data may be received/transmitted directly between the first apparatus and the second apparatus or indirectly between the first apparatus and the second apparatus through a set of apparatuses. The elements of each aspect described throughout this disclosure are expressly incorporated herein by reference for all structural and functional equivalents that are presently or later to be known to those of ordinary skill in the art and are intended to be encompassed by the claims. Furthermore, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. The terms "module," mechanism, "" element, "" device, "and the like may not be a substitute for the term" means. As such, no element of a claim should be construed as a means-plus-function unless the element is explicitly recited using the phrase "means for … …".

As used in this disclosure outside of the claims, the phrase "based on" includes all interpretations and should not be limited to any single interpretation unless specifically stated or indicated as such. For example, the phrase "a-based" (where "a" may be information, conditions, factors, etc.) may be interpreted as: "based at least on A", "based in part on A", "based at least in part on A", "based only on A" or "based only on A". Thus, as disclosed herein, "based on a" may refer in one aspect to "based at least on a". In another aspect, "based on a" may mean "based in part on a". In another aspect, "based on a" may mean "based at least in part on a". In another aspect, "based on a" may mean "based on a only". In another aspect, "based on a" may mean "based on a only". In another aspect, "a-based" may refer to any combination of interpretations in the alternative. As used in the claims, the phrase "based on a" should be read as "based at least on a" unless specifically stated differently.

The following aspects are merely illustrative and may be combined with other aspects or teachings described herein without limitation.

The following aspects are merely illustrative and may be combined with other aspects or teachings described herein without limitation.

Aspect 1 is a method for cryptography-verified cache construction in connection with wireless communication at a first wireless device, comprising: receiving at least one V2X message of the plurality of V2X messages from the second wireless device, the at least one V2X message being associated with the authentication key; determining whether the authentication key for the at least one V2X message is a target authentication key; if the authentication key is the target authentication key, determining that an entry for the authentication key is to be generated in the cache; and upon determining that the entry is to be generated in the cache, generating an entry for the authentication key in the cache.

Aspect 2 is the method of aspect 1, wherein the authentication key is located in a security wrapper of a header in the at least one V2X message.

Aspect 3 is the method of any one of aspects 1-2, wherein the authentication key corresponds to at least one application of the second wireless device.

Aspect 4 is the method of any one of aspects 1-3, wherein the application comprises one or more of: forward collision warning, pre-collision sensing, cooperative collision warning, ramp speed warning, emergency vehicle signal preemption, do not overtake warning, queue travel message, sensor share message, cooperative driving message, or road condition warning.

Aspect 5 is the method of any one of aspects 1-4, wherein determining whether the authentication key for the at least one V2X message is the target authentication key comprises: determining a relevance of the authentication password for the at least one V2X message based on one or more of: a location of the second wireless device, a direction of movement of the second wireless device, a velocity of the second wireless device, or a distance associated with the second wireless device relative to the first wireless device.

Aspect 6 is the method of any one of aspects 1-5, wherein determining the relevance of the verification password further comprises performing a target classification for the second wireless device.

Aspect 7 is the method of any one of aspects 1-6, wherein the correlation of the authentication key is determined further based on a credential expiration associated with the authentication key for the at least one V2X message.

Aspect 8 is the method of any one of aspects 1-7, wherein determining whether the authentication key for the at least one V2X message is the target authentication key is further based on one or more of: the frequency of use of the authentication key, the set of application plane metadata associated with the at least one V2X message, the range of consideration associated with the second wireless device, the collision time associated with the second wireless device, or a local dynamic mapping associated with a group of wireless devices within the area including the first wireless device and the second wireless device.

Aspect 9 is the method of any one of aspects 1-8, wherein the set of application plane metadata comprises one or more of: BSM metadata, MAP metadata, SPaT metadata, CAM metadata, TIM metadata, RSM metadata, SRM metadata, SSM metadata, GNSS or RTCM metadata, SDSM metadata, MSCM metadata, CACC metadata, or PVD metadata.

Aspect 10 is the method of any one of aspects 1-9, wherein the considering range is based on one or more of: a location of the second wireless device, a velocity of the second wireless device, or a distance associated with the second wireless device relative to the first wireless device.

Aspect 11 is the method of any one of aspects 1-10, wherein the local dynamic mapping further includes a duration of an exposure history associated with a group of wireless devices within the area.

Aspect 12 is the method of any one of aspects 1-11, wherein the entry in the cache corresponds to information used to verify the key.

Aspect 13 is the method of any one of aspects 1-12, wherein the information for the authentication key includes a pre-computed mathematical operation specific to a set of cryptographic keys of the authentication key.

Aspect 14 is the method of any one of aspects 1-13, wherein the cache is a LUT.

Aspect 15 is the method of any one of aspects 1-14, further comprising: the size of the entry in the cache is determined based on at least one of: the speed of the second wireless device, the density of the second wireless device, a first set of one or more attributes comprising a first region of the first wireless device, or a second set of one or more attributes comprising a second region of the second wireless device.

Aspect 16 is the method of any one of aspects 1-15, wherein the first set comprising one or more attributes or the second set comprising one or more attributes may include a degree of congestion associated with the first region or the second region.

Aspect 17 is the method of any one of aspects 1-16, wherein the entry in the cache is generated based on a group of wireless devices in which the first wireless device and the second wireless device are included.

Aspect 18 is the method of any one of aspects 1-17, wherein the entries in the cache are generated periodically based on a cache build period.

Aspect 19 is the method of any one of aspects 1-18, wherein the cache construction period is based on one or more of: a current computational load associated with the first wireless device and a predicted computational load associated with the first wireless device.

Aspect 20 is the method of any one of aspects 1-19, wherein the cache construction period is further based on a V2X message arrival rate within the time frame.

Aspect 21 is the method of any one of aspects 1-20, wherein the entry in the cache is generated in a background session separate from an authentication procedure for an authentication key for the at least one V2X message.

Aspect 22 is the method of any one of aspects 1-21, wherein the background session is associated with a first priority and the authentication procedure for the authentication key for the at least one V2X message is associated with a second priority, the first priority being lower than the second priority.

Aspect 23 is the method of any one of aspects 1-22, further comprising: a cache size limit associated with the cache is determined.

Aspect 24 is the method of any one of aspects 1-23, wherein determining that an entry for the authentication key is to be generated in the cache comprises determining that a cache size limit supports continuous generation of one or more caches associated with one or more target authentication keys that are less frequently used than a threshold.

Aspect 25 is the method of any one of aspects 1-24, wherein: determining to generate an entry for the authentication key in the cache includes comparing a first frequency of use associated with the one or more entries to a second frequency of use associated with the target authentication key, the second frequency of use being higher than the first frequency of use; and generating an entry for the authentication key in the cache includes replacing the one or more entries with the entry.

Aspect 26 is the method of any one of aspects 1-25, wherein the first wireless device is one of an OBU, an RSU, or a device with a VRU deployed at the car, and the second wireless device is one of an OBU, an RSU, or a VRU.

Aspect 27 is the method of any one of aspects 1 to-26, further comprising: the at least one V2X message is routed from the C-V2X modem to the ITS stack or security software module.

Aspect 28 is the method of any one of aspects 1-27, wherein determining that an entry for the authentication key is to be generated in the cache comprises: determining whether there is an existing entry in the cache associated with the authentication key; upon determining that an existing entry associated with the authentication key exists in the cache, performing authentication of the authentication key based on the existing entry; and upon determining that there is no existing entry in the cache associated with the authentication key, generating an entry in the cache.

Aspect 29 is a cache building method at a computing device for cryptography verification, comprising: receiving at least one message associated with an authentication key; determining whether the authentication key is a target authentication key; if the authentication key is a target authentication key, determining that an entry for the authentication key is to be generated in the cache by determining a correlation of the authentication key; determining a size of the entry in the cache; and means for generating an entry in the cache having the size for the authentication key upon determining to generate the entry in the cache and determining the size, wherein the entry in the cache is generated in a background session separate from an authentication procedure for the authentication key.

Aspect 30 is the method of aspect 29, wherein: determining to generate an entry for the authentication key in the cache includes comparing a first frequency of use associated with the one or more entries to a second frequency of use associated with the target authentication key, the second frequency of use being higher than the first frequency of use; and generating an entry for the authentication key in the cache includes replacing the one or more entries with the entry.

Aspect 31 is the method of any one of aspects 29-30, wherein the entries in the cache are generated periodically based on a cache build period.

Aspect 32 is the method of any one of aspects 29-31, wherein the cache construction period is based on one or more of: a current computing load associated with the computing device and a predicted computing load associated with the computing device.

Aspect 33 is the method of any one of aspects 29-32, wherein determining that an entry for the authentication key is to be generated in the cache comprises: determining whether an existing entry associated with the authentication key exists in the cache; upon determining that an existing entry exists in the cache that is associated with the authentication key, performing authentication of the authentication key based on the existing entry; and upon determining that there is no existing entry in the cache associated with the authentication key, generating the entry in the cache.

Aspect 34 is a cache construction apparatus for cryptography verification associated with wireless communications, comprising: a memory; and at least one processor coupled to the memory and configured to: receiving at least one V2X message of the plurality of V2X messages from the second wireless device, the at least one V2X message being associated with the authentication key; determining whether the authentication key for the at least one V2X message is a target authentication key; if the authentication key is the target authentication key, determining that an entry for the authentication key is to be generated in the cache; and upon determining that the entry is to be generated in the cache, generating an entry for the authentication key in the cache.

Aspect 35 is the apparatus of aspect 34, wherein the at least one processor is configured to perform the method of any one of aspects 2-28, and wherein the at least one processor is coupled to at least one of a transceiver or an antenna.

Aspect 36 is a cache building apparatus for cryptography verification associated with wireless communications, comprising: means for receiving at least one V2X message of the plurality of V2X messages from the second wireless device, the at least one V2X message being associated with an authentication key; means for determining whether the authentication key for the at least one V2X message is a target authentication key; means for determining that an entry for the authentication key is to be generated in the cache if the authentication key is a target authentication key; and means for generating an entry in the cache for the authentication key upon determining to generate the entry in the cache.

Aspect 37 is the apparatus of aspect 36, further comprising means for performing the method as in any of aspects 2-28.

Aspect 38 is a computer-readable medium storing computer-executable code that, when executed by a processor, causes the processor to: receiving at least one V2X message of the plurality of V2X messages from the second wireless device, the at least one V2X message being associated with the authentication key; determining whether the authentication key for the at least one V2X message is a target authentication key; if the authentication key is the target authentication key, determining that an entry for the authentication key is to be generated in the cache; and upon determining that the entry is to be generated in the cache, generating an entry for the authentication key in the cache.

Aspect 39 is a computer-readable medium of aspect 38, wherein the code, when executed by a processor, causes the processor to perform the method of any of aspects 2-28.

Aspect 40 is an apparatus for cache building for cryptography verification at a computing device, comprising: a memory; and at least one processor coupled to the memory and configured to perform the method of any of aspects 29-33, and the at least one processor may be coupled to at least one of a transceiver or an antenna.

Aspect 41 is an apparatus for cache construction for cryptography verification at a wireless device, comprising means for performing the method of any of aspects 29-33.

Aspect 42 is a computer-readable medium storing computer-executable code that, when executed by a processor, causes the processor to perform the method of any one of aspects 29-33.

Claims (30)

1. An apparatus for cryptographically validated cache construction related to communication at a first wireless device, comprising:

a memory; and

at least one processor coupled to the memory and configured to, based at least in part on information stored in the memory:

receiving at least one V2X message of a plurality of internet of vehicles (V2X) messages from a second wireless device, the at least one V2X message being associated with an authentication key;

determining whether the authentication key for the at least one V2X message is a target authentication key;

determining that an entry for the authentication key is to be generated in a cache if the authentication key is the target authentication key; and

upon determining that the entry is to be generated in the cache, the entry for the authentication key is generated in the cache.

2. The apparatus of claim 1, wherein the authentication key is located in a security wrapper of a header in the at least one V2X message, or wherein the authentication key corresponds to at least one application of the second wireless device.

3. The apparatus of claim 2, wherein the at least one application comprises one or more of: forward collision warning, pre-collision sensing, cooperative collision warning, ramp speed warning, emergency vehicle signal preemption, do not overtake warning, queue travel message, sensor share message, cooperative driving message, or road condition warning.

4. The apparatus of claim 1, wherein the at least one processor is configured to determine whether the authentication key for the at least one V2X message is the target authentication key by: determining a correlation of the authentication key for the at least one V2X message based on one or more of: a location of the second wireless device, a direction of movement of the second wireless device, a velocity of the second wireless device, or a distance associated with the second wireless device relative to the first wireless device.

5. The apparatus of claim 4, wherein the at least one processor is configured to determine the correlation of the authentication key by performing a target classification on the second wireless device.

6. The apparatus of claim 5, wherein the at least one processor is configured to determine the correlation of the authentication key based on expiration of a certificate associated with the authentication key for the at least one V2X message.

7. The apparatus of claim 1, wherein the at least one processor is configured to determine whether the authentication key for the at least one V2X message is the target authentication key based on one or more of: the frequency of use of the authentication key, the set of application plane metadata associated with the at least one V2X message, a range of consideration associated with the second wireless device, a collision time associated with the second wireless device, or a local dynamic mapping associated with a group of wireless devices within an area including the first wireless device and the second wireless device.

8. The apparatus of claim 7, wherein the set of application plane metadata comprises one or more of: basic Security Message (BSM) metadata, cross MAP (MAP) metadata, signal phase and timing (SPaT) metadata, collaborative Awareness Message (CAM) metadata, guest information message (TIM) metadata, road Security Management (RSM) metadata, signal Request Message (SRM) metadata, signal Status Message (SSM) metadata, global Navigation Satellite System (GNSS) or marine Radio Technical Commission (RTCM) metadata, sensor Data Sharing Message (SDSM) metadata, maneuver Sharing and Coordination Message (MSCM) metadata, collaborative Adaptive Cruise Control (CACC) metadata, or Probe Vehicle Data (PVD) metadata.

9. The apparatus of claim 7, wherein the consideration range is based on one or more of: a location of the second wireless device, a velocity of the second wireless device, or a distance associated with the second wireless device relative to the first wireless device.

10. The apparatus of claim 7, wherein the local dynamic map further comprises a duration of an exposure history associated with the group of wireless devices within the area.

11. The apparatus of claim 1, wherein the entry in the cache corresponds to first information for the authentication key, and wherein the first information for the authentication key comprises a set of cryptographic secret-specific pre-computed mathematical operations for the authentication key.

12. The apparatus of claim 1, wherein the cache is a look-up table (LUT).

13. The apparatus of claim 1, wherein the at least one processor is further configured to: determining a size of the entry in the cache based on at least one of: the speed of the second wireless device, the density of the second wireless device, a first set of one or more attributes comprising a first region of the first wireless device, or a second set of one or more attributes comprising a second region of the second wireless device, wherein the first set of one or more attributes or the second set of one or more attributes comprises a degree of congestion associated with the first region or the second region.

14. The apparatus of claim 1, wherein the entry in the cache is generated based on a group of wireless devices, wherein the first wireless device and the second wireless device are included in the group of wireless devices.

15. The apparatus of claim 1, wherein the entries in the cache are generated periodically based on a cache build period, wherein the cache build period is based on one or more of: the current computational load associated with the first wireless device and the predicted computational load associated with the first wireless device, or wherein the cache construction period is further based on a V2X message arrival rate within a time frame.

16. The apparatus of claim 1, wherein the entry in the cache is generated in a background session separate from an authentication procedure for the authentication key for the at least one V2X message.

17. The apparatus of claim 16, wherein the background session is associated with a first priority and the authentication procedure for the authentication key for the at least one V2X message is associated with a second priority, the first priority being lower than the second priority.

18. The apparatus of claim 1, wherein the at least one processor is further configured to: a cache size limit associated with the cache is determined.

19. The apparatus of claim 18, wherein the at least one processor is configured to: the entry for the validation key is determined to be generated in the cache by determining that the cache size limit supports continuous generation of one or more caches associated with one or more target validation keys that are used less frequently than a threshold.

20. The apparatus of claim 19, wherein:

determining to generate the entry for the verification key in the cache includes comparing a first frequency of use associated with one or more entries with a second frequency of use associated with the target verification key, the second frequency of use being higher than the first frequency of use; and is also provided with

Generating the entry for the authentication key in the cache includes replacing the one or more entries with the entry.

21. The apparatus of claim 1, wherein the first wireless device is one of an on-board unit (OBU), a Road Side Unit (RSU), or a device carried by a road user of easy injury (VRU) deployed at an automobile, and the second wireless device is one of the OBU, the RSU, or the VRU.

22. The apparatus of claim 1, wherein the at least one processor is further configured to:

the at least one V2X message is routed from a cellular internet of vehicles (C-V2X) modem to an Intelligent Transport System (ITS) stack or security software module.

23. The apparatus of claim 1, wherein the at least one processor is configured to determine that the entry for the authentication key is to be generated in the cache by:

determining whether an existing entry associated with the authentication key exists in the cache; and

upon determining that the existing entry associated with the authentication key does not exist in the cache, the entry is generated in the cache.

24. The apparatus of claim 1, further comprising a transceiver or antenna coupled to the at least one processor.

25. An apparatus for cache construction for cryptography validation at a computing device, comprising:

a memory; and

at least one processor coupled to the memory and configured to, based at least in part on information stored in the memory:

Receiving at least one message associated with an authentication key;

determining whether the authentication key is a target authentication key;

determining that an entry for the authentication key is to be generated in a cache by determining a correlation of the authentication key if the authentication key is the target authentication key;

determining a size of the entry in the cache; and

generating the entry in the cache having the size for the authentication key upon determining to generate the entry in the cache and determining the size, wherein the entry in the cache is generated in a background session separate from an authentication procedure for the authentication key.

26. The apparatus of claim 25, wherein the at least one processor is configured to determine that the entry for the authentication key is to be generated in the cache by:

comparing a first frequency of use associated with one or more items with a second frequency of use associated with the target authentication key, the second frequency of use being higher than the first frequency of use; and

generating the entry for the authentication key in the cache includes replacing the one or more entries with the entry.

27. The apparatus of claim 25, wherein the entries in the cache are generated periodically based on a cache build period, and wherein the cache build period is based on one or more of: a current computing load associated with the computing device and a predicted computing load associated with the computing device.

28. The apparatus of claim 25, the entry for the authentication key to be generated in the cache is determined by:

determining whether an existing entry associated with the authentication key exists in the cache; and

upon determining that the existing entry associated with the authentication key does not exist in the cache, the entry is generated in the cache.

29. A method for cryptographically validated cache construction related to communication at a first wireless device, comprising:

receiving at least one V2X message of a plurality of internet of vehicles (V2X) messages from a second wireless device, the at least one V2X message being associated with an authentication key;

determining whether the authentication key for the at least one V2X message is a target authentication key;

Determining that an entry for the authentication key is to be generated in the cache if the authentication key is the target authentication key; and

upon determining that the entry is to be generated in the cache, the entry for the authentication key is generated in the cache.

30. A method for cache construction for cryptography validation at a computing device, comprising:

receiving at least one message associated with an authentication key;

determining whether the authentication key is a target authentication key;

determining that an entry for the authentication key is to be generated in a cache by determining a correlation of the authentication key if the authentication key is the target authentication key;

determining a size of the entry in the cache; and

generating the entry in the cache having the size for the authentication key upon determining to generate the entry in the cache and determining the size, wherein the entry in the cache is generated in a background session separate from an authentication procedure for the authentication key.