Secure management of operational identity data (IDS)

Abstract

Systems and techniques for securely managing operation identification information (IDs) for vehicle-based communications are described. For example, the method may include transmitting a message associated with a potential operation by a vehicle, determining an operation identification information (ID) for the potential operation based on the message, and transmitting a first operation message (including the operation ID) for the potential operation. In another example, the method may include receiving a first operation message including the operation ID, determining that the first operation ID is a new operation ID, and determining whether the first operation ID matches a second operation ID determined based on a previously received message based on the first operation ID being a new operation ID. In another example, the method may include receiving an operation message including the same operation identification information (ID) and one or more source IDs, and determining whether the source ID(s) of the operation message match.

Description

[Technical field]

[0001] For example, aspects of the present disclosure relate to arrangements for securely managing operational identifications (IDs) for vehicle-based communications, such as vehicle-to-everything (V2X) communications. [Background technology]

[0002] Wireless communication systems have been widely deployed to provide various telecommunication services such as telephone, video, data, messaging, and broadcast. A typical wireless communication system may employ multiple access technologies capable of supporting communication with multiple users by sharing available system resources. Examples of such multiple access technologies 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.

[0003] These multiple access technologies have been adopted in various telecommunications standards to provide a common protocol that allows different wireless devices to communicate at a city, country, region, or even global level. An exemplary telecommunications standard is 5G New Radio (NR). 5G NR is part of the continuing mobile broadband evolution promulgated by the Third Generation Partnership Project (3GPP) to meet new requirements associated with latency, reliability, security, scalability (e.g., for the Internet of Things (IoT)), and other requirements. 5G NR includes services associated with enhanced mobile broadband (eMBB), massive machine type communications (mMTC), and ultra-reliable low latency communications (URLLC). Some aspects of 5G NR may be based on the 4G Long Term Evolution (LTE) standard. Aspects of wireless communication may include direct communication between devices, such as V2X communication, vehicle-to-vehicle (V2V) communication, and / or device-to-device (D2D) communication. Further improvements are needed for V2X, V2V, and / or D2D technologies. These improvements may also be applicable to other multiple access technologies and telecommunication standards employing these technologies. Summary of the Invention

[0004] The following presents a simplified summary of one or more aspects disclosed herein. As such, the following summary is not intended to be an extensive overview of all contemplated aspects, nor is it intended to identify key or critical elements of all contemplated aspects or to delineate the scope of any particular aspect. Thus, the sole purpose of the following summary is to present certain concepts of one or more aspects of the mechanisms disclosed herein in a simplified form prior to the detailed description presented below.

[0005] Systems, apparatus, methods, and computer-readable media for securely managing operation IDs for vehicle-based communications (e.g., V2X communications) are disclosed. According to at least one example, a method for wireless communications in a vehicle is provided. The method includes transmitting a message at the vehicle associated with a potential operation by the vehicle, determining an operation identification (ID) at the vehicle for the potential operation based on the message, and transmitting a first operation message at the vehicle for the potential operation including the operation ID.

[0006] In another example, an apparatus for wireless communication is provided that includes a memory (e.g., configured to store data, such as virtual content data, one or more images, etc.) and one or more processors coupled to the memory (e.g., implemented in circuitry). The one or more processors are configured and operable to: transmit a message associated with a potential operation by a vehicle, determine a operation identification (ID) for the potential operation based on the message, and transmit a first operation message for the potential operation that includes the operation ID.

[0007] In another example, a non-transitory computer-readable medium is provided having instructions stored thereon that, when executed by one or more processors, cause the one or more processors to transmit a message associated with a potential operation by a vehicle, determine a operation identification (ID) for the potential operation based on the message, and transmit a first operation message for the potential operation including the operation ID.

[0008] In another example, an apparatus for wireless communication is provided that includes means for transmitting a message associated with a potential operation by a vehicle, means for determining a operation identification (ID) for the potential operation based on the message, and means for transmitting a first operation message for the potential operation that includes the operation ID.

[0009] According to at least one additional or alternative example, a method for wireless communication is provided that includes receiving a first operation message at a first vehicle from a second vehicle, the first operation message including a first operation identification (ID), determining at the first vehicle that a first operation ID of the first operation message is a new operation ID, and determining at the first vehicle whether the first operation ID matches a second operation ID determined based on a previously received message based on the first operation ID being a new operation ID.

[0010] In another example, an apparatus for wireless communication is provided that includes a memory (e.g., configured to store data, such as virtual content data, one or more images, etc.) and one or more processors coupled to the memory (e.g., implemented in a circuit). The one or more processors are configured to and are capable of receiving a first operation message from a vehicle including a first operation identification (ID), determining that the first operation ID of the first operation message is a new operation ID, and determining whether the first operation ID matches a second operation ID determined based on a previously received message based on the first operation ID being a new operation ID.

[0011] In another embodiment, a non-transitory computer-readable medium is provided having instructions stored thereon that, when executed by one or more processors, cause the one or more processors to receive a first operation message from a vehicle including a first operation identification (ID), determine that the first operation ID of the first operation message is a new operation ID, and determine whether the first operation ID matches a second operation ID determined based on a previously received message based on the first operation ID being a new operation ID.

[0012] In another example, an apparatus for wireless communication is provided that includes means for receiving a first operation message from a vehicle including a first operation identification (ID), means for determining that the first operation ID of the first operation message is a new operation ID, and means for determining whether the first operation ID matches a second operation ID determined based on a previously received message based on the first operation ID being a new operation ID.

[0013] According to at least one additional or alternative example, a method for wireless communication is provided that includes receiving, at a vehicle, a plurality of operational messages from one or more vehicles, the operational messages including a same operational identification (ID) and one or more source IDs, and determining, at the vehicle, whether the one or more source IDs of the plurality of operational messages match.

[0014] In another example, an apparatus for wireless communication is provided that includes a memory (e.g., configured to store data, such as virtual content data, one or more images, etc.) and one or more processors coupled to the memory (e.g., implemented in circuitry). The one or more processors are configured and operable to: receive a plurality of operational messages from one or more vehicles that include a same operational identification (ID) and one or more source IDs, and determine whether the one or more source IDs of the plurality of operational messages match.

[0015] In another example, a non-transitory computer-readable medium is provided having instructions stored thereon that, when executed by one or more processors, cause the one or more processors to receive a plurality of operational messages from one or more vehicles that include the same operational identification (ID) and one or more source IDs, and determine whether the one or more source IDs of the plurality of operational messages match.

[0016] In another example, an apparatus for wireless communication is provided that includes means for receiving a plurality of operational messages from one or more vehicles, the plurality of operational messages including a same operational identification (ID) and one or more source IDs, and means for determining whether the one or more source IDs of the plurality of operational messages match.

[0017] In some aspects, the device is or is a part of a mobile device (e.g., a mobile phone or so-called "smartphone" or other mobile device), a wearable device, an extended reality device (e.g., a virtual reality (VR) device, an augmented reality (AR) device, or a mixed reality (MR) device), a personal computer, a laptop computer, a vehicle (e.g., a car or truck), a server computer, a robotic device, or other device. In some aspects, the device includes a radio detection and ranging (radar) sensor for capturing radio frequency (RF) signals. In some aspects, the device includes one or more light detection and ranging (LIDAR) sensors, radar sensors, or other light-based sensors for capturing other light-based (e.g., light frequency) signals. In some aspects, the device includes a camera or cameras for capturing one or more images. In some aspects, the device further includes a display for displaying one or more images, notifications, and / or other displayable data. In some aspects, the devices described above may include one or more sensors, which may be used to determine the location of the device, the state of the device (e.g., temperature, humidity level, and / or other conditions), and / or for other purposes.

[0018] This Summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used alone to determine the scope of the claimed subject matter, which subject matter should be understood by reference to the entire specification of this patent, any or all drawings, and appropriate portions of each claim.

[0019] Other objects and advantages associated with the embodiments disclosed herein will become apparent to those skilled in the art based on the accompanying drawings and detailed description.

[0020] The accompanying drawings are presented to aid in the explanation of various aspects of the present disclosure and are provided only to illustrate, not limit, the aspects. [Brief description of the drawings]

[0021] [Figure 1] FIG. 1 illustrates an example of a wireless communication system and access network in accordance with certain aspects of the present disclosure. [Diagram 2] 1 illustrates example aspects of a side link slot configuration in accordance with certain aspects of the present disclosure. [Figure 3A] FIG. 1 illustrates an example of a first device and a second device engaged in wireless communication (e.g., V2V communication, V2X communication, and / or device-to-device communication) in accordance with certain aspects of the present disclosure. [Figure 3B] FIG. 1 illustrates an example of a disaggregated base station architecture that may be employed by the disclosed system for securely managing operational IDs for communications (e.g., V2X communications), in accordance with some examples. [Figure 4] FIG. 1 illustrates examples of various user equipment (UEs) communicating via a direct communication interface (e.g., a cellular-based PC5 sidelink interface, a Dedicated Short Range Communication (DSRC) interface defined in 802.11p, or other direct interface) and a wide area network (Uu) interface, in accordance with certain aspects of the present disclosure. [Diagram 5] FIG. 1 is a block diagram illustrating an example of a vehicle computing system in accordance with some aspects of the present disclosure. [Figure 6] FIG. 2 is a block diagram illustrating an example of a computing system of a user device in accordance with some aspects of the present disclosure. [Figure 7] FIG. 1 illustrates an example of devices involved in wireless communication (e.g., sidelink communication) in accordance with certain aspects of the present disclosure. [Figure 8A]FIG. 1 illustrates an example of sensor sharing for a cooperative automated driving system in accordance with some aspects of the disclosure. [Figure 8B] FIG. 1 illustrates an example of sensor sharing for a cooperative automated driving system in accordance with some aspects of the disclosure. [Figure 8C] FIG. 1 illustrates an example of sensor sharing for a cooperative automated driving system in accordance with some aspects of the disclosure. [Figure 8D] FIG. 1 illustrates an example of sensor sharing for a cooperative automated driving system in accordance with some aspects of the disclosure. [Figure 9] FIG. 1 illustrates an example of sensor sharing for a cooperative automated driving system in accordance with some aspects of the disclosure. [Figure 10] FIG. 1 illustrates an example of a vehicle configuration for vehicle operation in a takeover scenario, in accordance with some aspects of the present disclosure. [Figure 11] FIG. 2 illustrates an example of a vehicle configuration for vehicle operation in a merging scenario, in accordance with some aspects of the present disclosure. [Figure 12A] FIG. 1 illustrates an example vehicle configuration for vehicle operation in a lane change scenario, in accordance with certain aspects of the present disclosure. [Figure 12B] FIG. 1 illustrates an example vehicle configuration for vehicle operation in a lane change scenario, in accordance with certain aspects of the present disclosure. [Figure 13] FIG. 12C is a diagram of an example of a communication (e.g., V2X communication) exchange for the vehicle operation of FIGS. 12A and 12B in accordance with some aspects of the disclosure. [Figure 14] FIG. 2 is a diagram of an example Maneuver Sharing and Coordination Message (MSCM) in accordance with some aspects of the present disclosure. [Figure 15] FIG. 1 is a diagram of an example base protocol that may be employed for operational sharing and coordination messages (MSCMs) in accordance with some aspects of the present disclosure. [Figure 16]FIG. 1 is a diagram of an example of an exemplary emergency protocol that may be employed for MSCM, in accordance with certain aspects of the present disclosure. [Figure 17] FIG. 11 is a flow diagram illustrating an example of a process for generating a unique operation ID for a communication (e.g., a V2X communication) according to certain aspects of the disclosure. [Figure 18] FIG. 1 is a flow diagram illustrating an example of a process for a local Misbehavior Detector and Reports (MBDR) scheme for operational ID collisions for communications (e.g., V2X communications) in accordance with some aspects of the disclosure. [Figure 19] 1 is a flow diagram illustrating an example of a process for wireless communication according to certain aspects of the present disclosure. [Figure 20] 4 is a flow diagram illustrating another example of a process for wireless communication in accordance with certain aspects of the present disclosure. [Figure 21] 4 is a flow diagram illustrating another example of a process for wireless communication in accordance with certain aspects of the present disclosure. [Figure 22] FIG. 2 illustrates an example of a hardware implementation of an exemplary apparatus in accordance with some aspects of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0022] Certain aspects of the present disclosure are provided below for illustrative purposes. Alternative aspects may be devised without departing from the scope of the present disclosure. In addition, well-known elements of the present disclosure are not described in detail or are omitted so as not to obscure the relevant details of the present disclosure. As will be apparent to one skilled in the art, some of the aspects described herein may be applied independently, and some of them may be applied in combination. In the following description, for the purpose of explanation, specific details are set forth to provide a thorough understanding of the aspects of the present application. However, it will be apparent that the various aspects may be practiced without these specific details. The figures and descriptions are not intended to be limiting.

[0023] The following description provides only exemplary embodiments and is not intended to limit the scope, applicability, or configuration of the present disclosure. Rather, the following description of exemplary embodiments will provide those skilled in the art with an enabling description for implementing the exemplary embodiments. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the present application as set forth in the appended claims.

[0024] The terms "exemplary" and / or "example" are used herein to mean "serving as an example, instance, or illustration." Any aspect described herein as "exemplary" and / or "example" is not necessarily to be construed as preferred or advantageous over other aspects. Similarly, the term "aspects of the present disclosure" does not require that all aspects of the present disclosure include the discussed feature, advantage or mode of operation.

[0025] Wireless communication systems are being deployed to provide a variety of telecommunication services, including telephone, video, data, messaging, and broadcast, among others. Wireless communication systems have evolved through various generations. The 5G mobile standard calls for higher data rates, more connections, and better coverage, among other improvements. The 5G standard (also called "New Radio" or "NR") is designed to provide data rates of tens of megabits per second to each of tens of thousands of users, according to the Next Generation Mobile Network Alliance.

[0026] A vehicle is an example of a device or system that may include wireless communication capabilities. For example, vehicles (e.g., automobiles, autonomous vehicles, aircraft, watercraft, among others) may communicate with other vehicles and / or other devices that have wireless communication capabilities. Wireless vehicular communication systems encompass vehicle-to-vehicle (V2V) communications, vehicle-to-infrastructure (V2I) communications, and vehicle-to-pedestrian (V2P) communications, all of which are collectively referred to as vehicle-to-everything (V2X) communications. V2X communications is a vehicular communication system that supports wireless transmission of information from a vehicle to other entities located in a traffic system that may affect the vehicle (e.g., other vehicles, pedestrians with smartphones, and / or other traffic infrastructure). The main objective of V2X technology is to improve road safety, fuel savings, and traffic efficiency.

[0027] In a V2X communication system, information is transmitted from vehicle sensors (and other sources) over a wireless link, allowing the information to be communicated to other vehicles, pedestrians, and / or traffic infrastructure. The information may be transmitted using one or more vehicle-based messages, such as C-V2X messages, which may include Sensor Data Sharing Messages (SDSMs), Basic Safety Messages (BSMs), Cooperative Awareness Messages (CAMs), Collective Perception Messages (CPMs), and / or other types of messages. By sharing this information with other vehicles, V2X technology improves vehicle (and driver) awareness of potential hazards to help reduce collisions with other vehicles and entities. Additionally, V2X technology improves traffic efficiency by providing vehicles with traffic alerts regarding potential upcoming road hazards and obstacles so that the vehicles may select alternative traffic routes.

[0028] As mentioned above, V2X technology includes V2V communication, which may also be referred to as peer-to-peer communication. V2V communication allows vehicles to wirelessly communicate directly with each other while on the road. With V2V communication, vehicles can gain situational awareness by receiving information from other vehicles about potential future road hazards (e.g., unexpected approaching vehicles, accidents, and road conditions). Vehicle-based messages (e.g., SDSMs, BSMs, CAMs, and CPMs) are beneficial because they can provide vehicles with awareness and understanding of potential future road hazards.

[0029] The IEEE 802.11p standard supports the use of a Dedicated Short Range Communications (DSRC) interface for V2X wireless communications. Features of the IEEE 802.11p-based DSRC interface include low latency and use of the unlicensed 5.9 gigahertz (GHz) frequency band. Cellular V2X (C-V2X) has been adopted as an alternative to the use of the IEEE 802.11p-based DSRC interface for wireless communications. The 5G Automotive Association (5 GAA) supports the use of C-V2X technology. In some cases, C-V2X technology uses Long Term Evolution (LTE) as the underlying technology, and C-V2X functionality is based on LTE technology. C-V2X includes multiple modes of operation. One of the modes of operation enables direct wireless communication between vehicles over the LTE sidelink PC5 interface. Similar to the IEEE 802.11p-based DSRC interface, the LTE C-V2X sidelink PC5 interface operates in the 5.9 GHz frequency band.

[0030] In recent years, there has been a lot of research and development on automated driving using V2X communication, with a primary focus on improving traffic safety and efficiency. Autonomous driving is performed using sensors for object detection, path planning, and actuation. Research is ongoing for each of these processes to improve safety and efficiency. Various organizations are conducting autonomous driving development to make driving safer and more effective by using V2X technology. These organizations are defining network architectures and messaging for V2X. For example, SDSM, BSM, CAM, and CPM are V2X messages used by vehicles to provide real-time information on the vehicle's status and, in some cases, to share real-time information about the vehicle's surroundings. These messages (e.g., SDSM, BSM, CAM, and CPM) are not designed for cooperative path planning, which requires the inclusion of future (planned) information for an overall optimal path planning.

[0031] Future (planned) information for optimal path planning should include an enumeration of the vehicle's planned positions over time (i.e., planned trajectories). The Maneuver Shared Coordination Message (MSCM) (e.g., MSCM 1400 in FIG. 14) is a V2X message that can be used to exchange planned trajectories between vehicles to perform maneuver coordination. MSCM enables vehicles to coordinate planned maneuvers for safer and more efficient driving. It should be noted that the MSCM format is still under development.

[0032] MSCM relies on a maneuver identification (ID) (e.g., maneuver ID 1414 in FIG. 14 described below). In some cases, the maneuver ID may be similar to a session ID and may allow maneuver participants to track updates to a particular maneuver. Currently, no solution is proposed in standards (e.g., Society of Automotive Engineering (SAE) standards such as SAE J1386) for generating unique maneuver IDs. Maneuver IDs should be unique to avoid any possible maneuver ID collisions (e.g., collisions that occur when two or more maneuvers have the same maneuver ID), which may lead to the cancellation of the maneuver. A generation method that provides a non-unique maneuver ID may lead to the cancellation (or abandonment) of the maneuver.

[0033] In some cases, a random number generator may be used to generate a random value for the MCSM's operation ID. However, using a random number generator to generate a random value for the operation ID may not prevent the risk of operation ID collisions because the random value is not necessarily unique. In some other cases, the vehicle's digital certificate may be used to generate the operation ID. However, since the vehicle may have to generate more operation IDs than the digital certificate, and the digital certificate is typically already used (e.g., hashed) to generate the MSCM's source ID (e.g., source ID 1410 in FIG. 14), using the vehicle's digital certificate to generate the operation ID may be problematic.

[0034] Currently, there are also no available solutions or techniques (e.g., no detectors) for detecting attacks related to conflicting operation IDs. Attacks related to conflicting operation IDs may lead to some operation cancellations (or operation cessation). Thus, undetected attacks related to conflicting operation IDs may lead to poor management of traffic (e.g., because multiple operations are cancelled).

[0035] In some aspects of the present disclosure, systems, apparatuses, methods (also referred to as processes), and computer-readable media (collectively referred to herein as "systems and techniques") for securely managing operation IDs for vehicle-based communications, such as V2X communications, are described herein. The systems and techniques effectively improve traffic safety and efficiency by providing a unique operation ID for each operation and by providing misbehavior detection and reporting (MBDS) for operation ID collisions.

[0036] In some aspects, a vehicle or other device may determine or generate a unique operation ID for each operation that the vehicle or other device plans to perform. A vehicle may determine a unique operation ID for a particular operation (and corresponding operation session) based on a preceding message, such as a BSM or an operation message indicating an intent to perform a particular operation (e.g., MSCM type zero (0)), referred to herein as an operation message of intent. The preceding message may be transmitted prior to the operation message (e.g., MSCM) in which the unique operation ID will be included. In some cases, to determine a unique operation ID based on a preceding message, the vehicle may apply a hash algorithm to the preceding message to generate a hash message (or hash code) that may be utilized as the operation ID of the operation message (e.g., MSCM). The hash code (or value) resulting from the hash algorithm may provide a unique value that may prevent possible collision of operation IDs of different operation sessions. In some cases, the size of the preceding message itself (e.g., BSM or operation message of intent) may be too large for the operation ID field of the operation message (e.g., MSCM). However, the hash code generated from hashing the preceding message is significantly smaller in size than the size of the preceding message itself, and is small enough in size to fit within the operation ID field of an operation message (e.g., MSCM). Although a hash algorithm is described herein as a method for generating a unique operation ID, other algorithms may be used to generate a unique identification.

[0037] Additionally or alternatively, in some aspects, the systems and techniques described herein may include one or more processes for operation ID collision detection. For example, a first process (e.g., referred to as process A) may be executed to determine whether a newly received operation ID in an operation message (e.g., MSCM) for a particular operation session matches an operation ID generated locally (e.g., using the hash-based technique described above) for the particular operation session. In some cases, process A may further include verifying that the operation ID was generated by a particular source ID (e.g., generated by a vehicle associated with the source ID of the operation). In another example, a second process (e.g., process B) may be executed to verify whether an attacker has spoofed the source ID of an operation message (e.g., MSCM) for a particular operation session, such as by comparing the source IDs of multiple operation messages that have a common operation ID. If misconduct is detected (e.g., for either or both of processes A and B), the vehicle may generate a misconduct report that includes specific details of the detected misconduct. The vehicle may transmit the misconduct report to one or more other vehicles, to a server, or to another entity. If no fraudulent activity is detected (eg, the operation ID matches and / or the source ID matches), the vehicle may remain idle by processing the operation message according to the common protocol.

[0038] Additional features of the disclosure are described in greater detail below.

[0039] The terms "user equipment" (UE) and "network entity" as used herein are not intended to be specific or limited to any particular radio access technology (RAT) unless otherwise specified. In general, a UE may be any wireless communication device (e.g., a mobile phone, a router, a tablet computer, a laptop computer, and / or a tracking device, etc.), a wearable (e.g., a smart watch, a smart glass, a wearable ring, and / or an extended reality (XR) device, such as a virtual reality (VR) headset, an augmented reality (AR) headset or glasses, or a mixed reality (MR) headset), a vehicle (e.g., an automobile, a motorcycle, a bicycle, etc.), and / or an Internet of Things (IoT) device, etc., used by a user to communicate over a wireless communication network. A UE may be mobile or may be stationary (e.g., at a certain time) and may communicate with a radio access network (RAN). As used herein, the term "UE" may be referred to interchangeably as an "access terminal" or "AT", "client device", "wireless device", "subscriber device", "subscriber terminal", "subscriber station", "user terminal" or "UT", "mobile device", "mobile terminal", "mobile station", or variations thereof. In general, a UE may communicate with a core network via a RAN, through which the UE may be connected to external networks, such as the Internet, and to other UEs. Of course, other mechanisms for connecting to the core network and / or the Internet are also possible for a UE, such as via a wired access network, a wireless local area network (WLAN) network (e.g., based on the IEEE 802.11 communications standard, etc.).

[0040] In some cases, the network entity may be implemented in an aggregated or monolithic base station or server architecture, or alternatively in a non-aggregated base station or server architecture, and may include one or more of a central unit (CU), a distributed unit (DU), a radio unit (RU), a Near-Real Time (RT) RAN Intelligent Controller (RIC), or a Non-Real Time (Non-RT) RIC. In some cases, the network entity may include a server device, such as a Multi-Access Edge Computing (MEC) device. A base station or server (e.g., aggregated / monolithic base station architecture or disaggregated base station architecture) may operate according to one of multiple RATs communicating with UEs, road side units (RSUs), and / or other devices depending on the network being deployed, and may alternatively be referred to as an access point (AP), network node, NodeB (NB), evolved NodeB (eNB), next generation eNB (ng-eNB), new radio (NR) NodeB (also referred to as gNB or gNodeB), etc. A base station may be primarily used to support wireless access by UEs, including supporting data, voice, and / or signaling connections for supported UEs. In some systems, the base station may provide edge node signaling functions, while in other systems it may provide additional control and / or network management functions. The communication link through which a UE can send signals to a base station is called an uplink (UL) channel (eg, a reverse traffic channel, a reverse control channel, an access channel, etc.).A communication link through which a base station can send signals to a UE is called a downlink (DL), or a forward link channel (e.g., a paging channel, a control channel, a broadcast channel, or a forward traffic channel, etc.). The term traffic channel (TCH), as used herein, can refer to either an uplink, a reverse or downlink, and / or a forward traffic channel.

[0041] The term "network entity" or "base station" (e.g., having an aggregated / monolithic base station architecture or a non-aggregated base station architecture) may refer to a single physical TRP or multiple physical TRPs that may or may not be collocated. For example, when the term "network entity" or "base station" refers to a single physical TRP, the physical TRP may be an antenna of the base station, corresponding to a cell (or several cell sectors) of the base station. When the term "network entity" or "base station" refers to multiple collocated physical TRPs, the physical TRP may be an array of antennas of the base station (e.g., as in the case of a multiple-input multiple-output (MIMO) system or when the base station employs beamforming). When the term "base station" refers to multiple non-collocated physical TRPs, the physical TRP may be a distributed antenna system (DAS) (a network of spatially separated antennas connected to a common source via a transport medium) or a remote radio head (RRH) (a remote base station connected to a serving base station). Alternatively, a non-co-located physical TRP may be a serving base station that receives measurement reports from the UE and neighboring base stations whose reference radio frequency (RF) signals (or simply "reference signals") the UE is measuring. Since a TRP is a point from which a base station transmits and receives wireless signals, as used herein, references to transmission from or reception at a base station should be understood as referring to a particular TRP of the base station.

[0042] In some implementations that support positioning of UEs, a network entity or base station may not support wireless access by the UE (e.g., may not support data, voice, and / or signaling connections for the UE) but may instead transmit reference signals to the UE to be measured by the UE and / or receive and measure signals transmitted by the UE. Such base stations may be referred to as positioning beacons (e.g., when they transmit signals to the UE) and / or location measurement units (e.g., when they receive and measure signals from the UE).

[0043] A roadside unit (RSU) is a device that can send and receive messages to and from one or more UEs, other RSUs, and / or base stations over a communication link or interface (e.g., a cellular-based sidelink or PC5 interface, an 802.11 or WiFi™-based dedicated short-range communication (DSRC) interface, and / or other interfaces). Examples of messages that can be sent and received by an RSU include vehicle-to-everything (V2X) messages, which are described in more detail below. RSUs can be located in various transportation infrastructure systems, including roads, bridges, parking lots, toll booths, and / or other infrastructure systems. In some examples, an RSU can facilitate communication between UEs (e.g., vehicles, pedestrian user devices, and / or other UEs) and a transportation infrastructure system. In some implementations, an RSU can communicate with a server, a base station, and / or other systems that can perform centralized management functions.

[0044] The RSU may communicate with a communication system of the UE. For example, an intelligent transport system (ITS) of the UE (e.g., vehicles and / or other UEs) may be used to generate and sign messages for transmission to the RSU and to verify messages received from the RSU. The RSU may communicate with vehicles traveling along roads, bridges, or other infrastructure systems (e.g., via a PC5 interface, a DSRC interface, etc.) to obtain traffic-related data (e.g., vehicle time, speed, location, etc.). In some cases, in response to obtaining the traffic-related data, the RSU may determine or estimate traffic congestion information (e.g., start of traffic congestion, end of traffic congestion, etc.), travel time, and / or other information for a particular location. In some examples, the RSU may communicate with other RSUs (e.g., via a PC5 interface, a DSRC interface, etc.) to determine the traffic-related data. The RSU may transmit information (e.g., traffic congestion information, travel time information, and / or other information) to other vehicles, pedestrian UEs, and / or other UEs. For example, an RSU may broadcast or transmit information to any UEs (eg, vehicles, pedestrian UEs, etc.) that are within the coverage range of the RSU.

[0045] A radio frequency signal or "RF signal" includes electromagnetic waves of a given frequency that transport information through space between a transmitter and a receiver. As used herein, a transmitter may transmit a single "RF signal" or multiple "RF signals" to a receiver. However, the receiver may receive multiple "RF signals" corresponding to each transmitted RF signal due to the propagation characteristics of RF signals through multipath channels. The same RF signal transmitted over different paths between a transmitter and a receiver may be referred to as a "multipath" RF signal. As used herein, an RF signal may also be referred to as a "wireless signal" or simply a "signal" when it is clear from the context that the term "signal" refers to a wireless signal or an RF signal.

[0046] 1 illustrates an example of a wireless communication system and access network 100 in accordance with various aspects. The wireless communication system (also referred to as a wireless wide area network (WWAN)) includes a base station 102, a UE 104, an Evolved Packet Core (EPC) 160, and a core network (e.g., 5GC) 190. The base station 102 may include a macro cell (high power cellular base station) and / or a small cell (low power cellular base station). The macro cell includes a base station. The small cell includes a femto cell, a pico cell, and a micro cell.

[0047] A base station 102 configured for 4G LTE (collectively referred to as Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network, E-UTRAN) may interface with the EPC 160 through a backhaul link 132 (e.g., an S1 interface). A base station 102 configured for NR (collectively referred to as Next Generation RAN, NG-RAN) may interface with the core network 190 via a backhaul link 184. In addition to other functions, the base stations 102 may perform one or more of the following functions: forwarding user data, encryption and decryption of radio channels, 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 service (MBMS), subscriber and equipment tracking, RAN information management (RIM), paging, positioning, and distribution of alert messages. The base stations 102 may communicate with each other directly or indirectly (e.g., through the EPC 160 or the core network 190) via backhaul links 134 (e.g., X2 interfaces). The backhaul links 134 may be wired or wireless.

[0048] The base stations 102 may wirelessly communicate with the UE 104. Each of the base stations 102 may provide communication coverage for a respective geographic coverage area 110. There may be overlapping geographic coverage areas 110. For example, a 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 including both small cells and macro cells may be known as a heterogeneous network. A heterogeneous network may also include home evolved Node Bs (eNBs) (HeNBs) that may provide service to restricted groups known as closed subscriber groups (CSGs). A communication link 120 between the base station 102 and the UE 104 may include uplink (UL) (also referred to as reverse link) transmissions from the UE 104 to the base station 102 and / or downlink (DL) (also referred to as forward link) transmissions from the base station 102 to the UE 104. The communication link 120 may use multiple-input multiple-output (MIMO) antenna techniques, including spatial multiplexing, beamforming, and / or transmit diversity. The communication link may be over one or multiple carriers. The base station 102 / UE 104 may use spectrum with a bandwidth of up to YMHz (e.g., 5, 10, 15, 20, 100, 400 MHz, etc.) per carrier, allocated in a carrier aggregation of up to YxMHz (x component carriers) in total, used for transmission in each direction. The carriers may be adjacent or non-adjacent to each other. The carrier allocation may be asymmetric for DL ​​and UL (e.g., more or fewer carriers may be allocated for DL ​​than for 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).

[0049] Particular UEs 104 may communicate with each other using device-to-device (D2D) communication links 158. The D2D communication links 158 may use DL / UL WWAN spectrum. The D2D communication links 158 may use one or more sidelink channels, such as a physical sidelink broadcast channel (PSBCH), a physical sidelink discovery channel (PSDCH), a physical sidelink shared channel (PSSCH), and a physical sidelink control channel (PSCCH). The D2D communication may be through various wireless D2D communication systems, such as, for example, FlashLinQ, WiMedia, Bluetooth, ZigBee, Wi-Fi based on IEEE 802.11 standard, LTE, or NR.

[0050] The wireless communication system may further include a Wi-Fi access point (AP) 150 in communication with Wi-Fi stations (STAs) 152 over communication links 154 in the 5 GHz unlicensed frequency spectrum. When communicating in the unlicensed frequency spectrum, the STAs 152 / AP 150 may perform a clear channel assessment (CCA) prior to communication to determine if a channel is available.

[0051] The small cell 102' may operate in a licensed and / or unlicensed frequency spectrum. When operating in an unlicensed frequency spectrum, the small cell 102' may employ NR and use the same 5 GHz unlicensed frequency spectrum used by the Wi-Fi AP 150. By employing NR in the unlicensed frequency spectrum, the small cell 102' may provide increased coverage to and / or increase the capacity of the access network.

[0052] The base station 102, whether a small cell 102' or a large cell (e.g., macro base station), may include an eNB, gNodeB (gNB), or other type of base station. Some base stations, such as the gNB 180, may operate in conventional sub-6 GHz spectrum, millimeter wave (mmW) frequencies, and / or sub-mmW frequencies in communication with the UE 104. When the gNB 180 operates in mmW or sub-mmW frequencies, it may be referred to as a mmW base station. Extremely high frequency (EHF) is a part of RF in the electromagnetic spectrum. EHF has a range of 30 GHz to 300 GHz and a wavelength of 1 millimeter to 10 millimeters. Radio waves in this band may be referred to as millimeter waves. Sub-mmW may go down to frequencies of 3 GHz with a wavelength of 100 millimeters. The super high frequency (SHF) band ranges from 3 GHz to 30 GHz and is also referred to as centimeter wave. Communications using mmW / sub-mmW radio frequency bands have very high path loss and short distances. The mmW base station 180 can utilize beamforming 182 with the UE 104 to compensate for the very high path loss and short distances.

[0053] Devices may use beamforming to transmit and receive communications. For example, FIG. 1 shows that the base station 180 may transmit a beamformed signal to the UE 104 in one or more transmit directions 182′. The UE 104 may receive the beamformed signal from the base station 180 in one or more receive directions 182″. The UE 104 may also transmit a beamformed signal to the base station 180 in one or more transmit directions. The base station 180 may receive a beamformed signal from the UE 104 in one or more receive directions. The base station 180 / UE 104 may perform beam training to determine the best receive and transmit directions for each of the base stations 180 / UE 104. The transmit and receive directions for the base station 180 may or may not be the same. The transmit and receive directions for the UE 104 may or may not be the same. Although a beamformed signal is shown between the UE 104 and the base station 102 / 180, the beamforming aspect may also be applied by the UE 104 or RSU 107 to communicate with another UE 104 or RSU 107 based on sidelink communications, such as V2X or D2D communications.

[0054] The 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. The MME 162 may communicate with a Home Subscriber Server (HSS) 174. The MME 162 is a control node that handles signaling between the UE 104 and the EPC 160. In general, the MME 162 provides bearer and connection management. All user Internet protocol (IP) packets are forwarded through the Serving Gateway 166, which is itself connected to the PDN Gateway 172. The PDN Gateway 172 provides IP address allocation for the UE as well as other functions. The PDN Gateway 172 and the BM-SC 170 are connected to IP services 176, which may include the Internet, an intranet, an IP Multimedia Subsystem (IMS), PS streaming services, and / or other IP services. The BM-SC 170 may provide functionality for provisioning and delivery of MBMS user services. The BM-SC 170 may act as an entry point for content providers' MBMS transmissions and may be used to authorize and initiate MBMS bearer services in the public land mobile network (PLMN) and may be used to schedule MBMS transmissions.The MBMS Gateway 168 can 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 is responsible for session management (start / stop) and collection of eMBMS related charging information.

[0055] The core network 190 may include an Access and Mobility Management Function (AMF) 192, other AMFs 193, a Session Management Function (SMF) 194, and a User Plane Function (UPF) 195. The AMF 192 may communicate with a Unified Data Management (UDM) 196. The AMF 192 is a control node that handles signaling between the UE 104 and the core network 190. In general, the AMF 192 provides QoS flow and session management. All user Internet Protocol (IP) packets are forwarded through the UPF 195. The UPF 195 provides IP address allocation for the UE as well as other functions. The UPF 195 is connected to IP services 197. The IP services 197 may include the Internet, intranet, IP Multimedia Subsystem (IMS), PS streaming services, and / or other IP services.

[0056] The base station 102 may also be referred to as a gNB, Node B, evolved Node B (eNB), access point, base transceiver station, radio base station, radio transceiver, transceiver function, basic service set (BSS), extended service set (ESS), transmit reception point (TRP), or some other suitable terminology. The base station 102 provides an access point to the EPC 160 or core network 190 for the UE 104. Examples of the UE 104 include a mobile phone, a smartphone, a session initiation protocol (SIP) phone, a laptop, a personal digital assistant (PDA), a satellite radio, a global positioning system, a multimedia device, a video device, a digital audio player (e.g., MP3 player), a camera, a game console, a tablet, a smart device, a wearable device, a vehicle, an electric meter, a gas pump, a large or small cooking appliance, a healthcare device, an embedded device, a sensor / actuator, a display, or any other similar functional device. Some of the UEs 104 may be referred to as IoT devices (e.g., a parking meter, a gas pump, a toaster, a vehicle, a heart monitor, etc.) The UEs 104 may also be referred to as a station, a mobile station, a subscriber station, a mobile unit, a subscriber unit, a wireless unit, a remote unit, a mobile device, a wireless device, a wireless communication device, a remote device, a mobile subscriber station, an access terminal, a mobile terminal, a wireless terminal, a remote terminal, a handset, a user agent, a mobile client, a client, or some other suitable terminology.

[0057] Some wireless communication networks may include vehicle-based communication devices that may collectively be referred to as vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I) (e.g., from a vehicle-based communication device to a road infrastructure node such as a roadside 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), cellular-vehicle-to-everything (C-V2X), enhanced V2X (e-V2X), and / or vehicle-to-anything (V2X) communication capable of communicating from and / or with other devices. Referring again to FIG. 1, in some aspects, a UE 104, e.g., a transmitting Vehicle User Equipment (VUE) or other UE, may be configured to transmit a message directly to another UE 104. The communication may be based on V2X or other D2D communication such as Proximity Services (ProSe). The communication based on V2X and / or D2D communication may be transmitted and received by other transmitting / receiving devices such as a Roadside Unit (RSU) 107. The communication aspect may be based on PC5 or sidelink communication, for example as described in relation to the example of FIG. 2. The following description may provide an example of V2X / D2D communication related to 5G NR, but the concepts described herein may be applicable to other similar domains such as LTE, LTE-A, CDMA, GSM, and other wireless technologies.

[0058] FIG. 2 illustrates an exemplary diagram 200 illustrating sidelink subframes within a frame configuration that may be used for sidelink communications, such as between UEs 104, between a UE and an infrastructure, between a UE and an RSU, etc. The frame configuration may be within an LTE frame configuration. The following description may focus on LTE, but the concepts described herein may be applicable to other similar domains, such as 5G NR, LTE-A, CDMA, GSM, and other wireless technologies. This is only an example, and other wireless communication technologies may have different frame configurations and / or different channels. A frame (10 ms) may be divided into 10 subframes (1 ms) of equal size. Each subframe may include two slots. Each slot may include 7 SC-FDMA symbols. In slot configuration 0, each slot may include 14 symbols, and in slot configuration 1, each slot may include 7 symbols. Although diagram 200 illustrates a single RB subframe, sidelink communications may include multiple RBs.

[0059] A resource grid may be used to represent the frame structure. Each time slot may include resource blocks (RBs) (also referred to as physical RBs (PRBs)) spanning 12 consecutive subcarriers. The resource grid is divided into multiple resource elements (REs). The number of bits carried by each RE depends on the modulation scheme. As shown in FIG. 2, some of the REs may include reference signals, such as demodulation RS (DMRS). At least one symbol may be used for feedback as described herein. Symbols before and / or after feedback may be used for turnaround between receiving data and transmitting feedback. Another symbol, e.g., a symbol at the end of a subframe, may be used as a guard symbol that is not transmitted or received. The guard allows a device to switch from operating as a transmitting device to prepare to operate as a receiving device, e.g., in the next subframe. As shown, data or control may be transmitted in the remaining REs. For example, data may be carried in the PSSCH and control information may be carried in the PSCCH. The control information may include Sidelink Control Information (SCI). The location of any of the reference signals, control, and data may differ from the example shown in FIG.

[0060] 2 merely illustrates one non-limiting example of a frame configuration that may be used. The aspects described herein may be applied to communications using other different frame formats.

[0061] 3A is a block diagram of a first wireless communication device 310 communicating with a second wireless communication device 350, e.g., via V2V / V2X / other communication. The device 310 may constitute a receiving device, e.g., a transmitting device, that communicates with the device 350. The communication may be based on a sidelink, e.g., the transmitting device 310 may constitute a UE, an RSU, etc. The receiving device may constitute a UE, an RSU, etc. The packets may be provided to a 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.

[0062] The transmit (TX) processor 316 and receive (RX) processor 370 implement Layer 1 functionality associated with various signal processing functions. Layer 1, including the physical (PHY) layer, may include error detection on transport channels, forward error correction (FEC) encoding / decoding of transport channels, interleaving, rate matching, mapping onto physical channels, modulation / demodulation of physical channels, and MIMO antenna processing. The TX processor 316 processes mapping to signal constellations based on various modulation schemes (e.g., 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 can then be mapped to an OFDM subcarrier, multiplexed with a reference signal (e.g., pilot) in the time and / or frequency domain, and then combined together using an Inverse Fast Fourier Transform (IFFT) to generate a physical channel carrying a time-domain OFDM symbol stream. This OFDM stream is spatially precoded to generate multiple spatial streams. Channel estimates from a channel estimator 374 can be used to determine the coding and modulation schemes, as well as for spatial processing. The channel estimates can be derived from a reference signal and / or channel condition feedback transmitted by the device 350. Each spatial stream can then be provided to a different antenna 320 via a separate transmitter 318TX. Each transmitter 318TX can modulate an RF carrier with the respective spatial stream for transmission.

[0063] In the device 350, each receiver 354RX receives a signal through its respective antenna 352. Each receiver 354RX recovers information modulated onto an RF carrier and provides the information to a receive (RX) processor 356. The TX processor 368 and the RX processor 356 implement layer 1 functionality associated with various signal processing functions. The RX processor 356 may perform spatial processing on the information to recover any spatial streams destined for the device 350. Multiple spatial streams may be combined by the RX processor 356 into a single OFDM symbol stream if destined for the device 350. The 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 includes 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 most likely signal constellation point transmitted by the device 310. These soft decisions may be based on channel estimates calculated by a channel estimator 358. The soft decisions are then decoded and deinterleaved to recover the data and control signals originally transmitted by the device 310 on the physical channel. The data and control signals are then provided to a controller / processor 359, which implements Layer 3 and Layer 2 functionality.

[0064] The controller / processor 359 can be associated with a memory 360 that stores program codes and data. The memory 360 may be referred to as a computer-readable medium. The controller / processor 359 can provide demultiplexing between transport and logical channels, packet reassembly, decryption, 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.

[0065] Similar to the functionality described in connection with transmission by the device 310, the controller / processor 359 provides RRC layer functionality associated with system information (e.g., MIBs, SIBs) acquisition, RRC connection, and measurement reporting; PDCP layer functionality associated with header compression / decompression and security (encryption, decryption, integrity protection, integrity verification); RLC layer functionality associated with forwarding of higher layer PDUs, error correction via ARQ, concatenation, segmentation, and reassembly of RLC SDUs, resegmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functionality associated with mapping of logical channels to transport channels, multiplexing of MAC SDUs onto the TB, demultiplexing of MAC SDUs from the TB, scheduling information reporting, error correction via HARQ, priority handling, and logical channel prioritization.

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

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

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

[0069] At least one of the TX processor 368, RX processor 356, or controller / processor 359, or the TX 316, RX processor 370, or controller / processor 375 of the device 350 may be configured to perform the aspects described in connection with 198 or 199 of FIG.

[0070] 3B illustrates an example of an architecture of a disaggregated base station 3300 that may be employed by the disclosed system for securely managing operational IDs for communications (e.g., V2X communications), according to some examples. A communications system deployment, such as a 5G NR system, may be configured in multiple ways with various components or parts. In a 5G NR system, or network, a network node, network entity, mobility element of the network, a radio access network (RAN) node, a core network node, a network element, or a network equipment, such as a base station (BS), or one or more units (or one or more components) performing a base station function may be implemented in an aggregated or separated architecture. For example, a BS (e.g., a Node B (NB), evolved NB (eNB), NR BS, 5G NB, AP, transmit / receive point (TRP), or cell, etc.) may be implemented as an aggregated base station (also known as a standalone BS or monolithic BS) or a disaggregated base station.

[0071] An aggregated base station may be configured to utilize a radio protocol stack that is physically or logically integrated within a single RAN node. A separated base station may be configured to utilize a protocol stack that is physically or logically distributed among two or more units, such as one or more centralized or centralized units (CUs), one or more distributed units (DUs), or one or more radio units (RUs). In some aspects, a CU may be implemented within a RAN node, and one or more DUs may be co-located with the CU or alternatively geographically or virtually distributed across one or more other RAN nodes. A DU may be implemented to communicate with one or more RUs. Each of the CU, DU, and RU may also be implemented as a virtual unit, i.e., a virtual central unit (VCU), a virtual distributed unit (VDU), or a virtual radio unit (VRU).

[0072] The operation of a base station type or network design may take into account the aggregated nature of the base station functions. For example, a separated base station may be utilized in an integrated access backhaul (IAB) network, an open radio access network (O-RAN, such as the network configuration supported by the O-RAN alliance), or a virtualized radio access network (vRAN, also known as a cloud radio access network (C-RAN)). Disaggregation may include distributing functions across two or more units in different physical locations, as well as distributing the functions of at least one unit virtually, which may allow flexibility in network design. Various units of a disaggregated base station, or a disaggregated RAN architecture, may be configured for wired or wireless communication with at least one other unit.

[0073] As mentioned above, FIG. 3B shows a diagram illustrating an exemplary disaggregated base station 3300 architecture. The disaggregated base station 3300 architecture may include one or more central units (CUs) 3310 that may communicate directly with the core network 3320 via a backhaul link or indirectly with the core network 3320 through one or more disaggregated base station units (e.g., a near real-time (near RT) RAN intelligent controller (RIC) 3325 via an E2 link, or a non-real-time (non-RT) RIC 3315 associated with a service management and orchestration (SMO) framework 3305, or both). The CU 3310 may communicate with one or more distributed units (DUs) 3330 via respective midhaul links, such as an F1 interface. The DU 3330 may communicate with one or more radio units (RUs) 3340 via respective fronthaul links. The RUs 3340 may communicate with each UE 3120 via one or more RF access links. In some implementations, a UE 3120 may be served by multiple RUs 3340 simultaneously.

[0074] Each of the units, i.e., CU3310, DU3330, RU3340, quasi-RT RIC3325, non-RT RIC3315, and SMO framework 3305, may include or be coupled to one or more interfaces configured to receive or transmit signals, data, or information (collectively, signals) via a wired or wireless transmission medium. Each of the units, or an associated processor or controller providing instructions to the unit's communication interface, may be configured to communicate with one or more of the other units via a transmission medium. For example, a unit may include a wired interface configured to receive or transmit signals to one or more of the other units via a wired transmission medium. In addition, a unit may include a wireless interface, which may include a receiver, transmitter, or transceiver (such as an RF transceiver), configured to receive signals from and / or transmit signals to one or more of the other units via a wireless transmission medium.

[0075] In some aspects, the CU 3310 may host one or more upper layer control functions. Such control functions may include Radio Resource Control (RRC), Packet Data Convergence Protocol (PDCP), Service Data Adaptation Protocol (SDAP), and the like. Each control function may be implemented with an interface configured to communicate signals with other control functions hosted by the CU 3310. The CU 3310 may be configured to handle user plane functions (i.e., Central Unit-User Plane (CU-UP)), control plane functions (i.e., Central Unit-Control Plane (CU-CP)), or a combination thereof. In some implementations, the CU 3310 may be logically divided into one or more CU-UP units and one or more CU-CP units. The CU-UP units may communicate bidirectionally with the CU-CP units over an interface such as an E1 interface when implemented in an O-RAN configuration. The CU 3310 may be implemented to communicate with the DU 3330, as necessary, for network control and signaling.

[0076] The DU3330 may correspond to a logical unit including one or more base station functions for controlling the operation of one or more RU3340. In some aspects, the DU3330 may host one or more of a Radio Link Control (RLC) layer, a Medium Access Control (MAC) layer, and one or more upper physical (PHY) layers (such as modules for forward error correction (FEC) encoding and decoding, scrambling, modulation and demodulation, etc.) at least in part according to a functional division such as that defined by the 3rd Generation Partnership Project (3GPP). In some aspects, the DU3330 may further host one or more lower PHY layers. Each layer (or module) may be implemented with an interface configured to communicate signals with other layers (and modules) hosted by the DU3330 or control functions hosted by the CU3310.

[0077] The lower layer functions may be implemented by one or more RUs 3340. In some deployments, the RUs 3340 controlled by the DU 3330 may correspond to logical nodes hosting RF processing functions, or lower PHY layer functions (such as performing fast Fourier transform (FFT), inverse FFT (iFFT), digital beamforming, physical random access channel (PRACH) extraction and filtering, etc.), or both, based at least in part on a functional division such as a lower layer functional division. In such an architecture, the RU 3340(s) may be implemented to handle over the air (OTA) communications with one or more UEs 3120. In some implementations, real-time and non-real-time aspects of control plane and user plane communications with the RU(s) 3340 may be controlled by the corresponding DU 3330. In some scenarios, this configuration may enable the DU(s) 3330 and CU 3310 to be implemented in a cloud-based RAN architecture, such as a vRAN architecture.

[0078] The SMO framework 3305 may be configured to support RAN deployment and provisioning of non-virtualized and virtualized network elements. For non-virtualized network elements, the SMO framework 3305 may be configured to support deployment of dedicated physical resources for RAN coverage requirements that can be managed via an operation and maintenance interface (such as an O1 interface). For virtualized network elements, the SMO framework 3305 may be configured to interact with a cloud computing platform (such as an open cloud (O-cloud) 3390) to perform network element life cycle management (e.g., instantiate virtualized network elements) via a cloud computing platform interface (e.g., an O2 interface). Such virtualized network elements may include, but are not limited to, the CU 3310, the DU 3330, the RU 3340, and the quasi-RT RIC 3325. In some implementations, the SMO framework 3305 may communicate with hardware aspects of a 4G RAN, such as an open eNB (O-eNB) 3311, via an O1 interface. Additionally, in some implementations, the SMO framework 3305 can communicate directly with one or more RUs 3340 via an O1 interface. The SMO framework 3305 can also include a non-RT RIC 3315 configured to support the functionality of the SMO framework 3305.

[0079] The non-RT RIC 3315 may be configured to include logic functions that enable non-real-time control and optimization of RAN elements and resources, artificial intelligence / machine learning (AI / ML) workflows including model training and updates, or policy-based guidance of applications / features in the quasi-RT RIC 3325. The non-RT RIC 3315 may be coupled to or in communication with the quasi-RT RIC 3325 (e.g., via an A1 interface). The quasi-RT RIC 3325 may be configured to include logic functions that enable near real-time control and optimization of RAN elements and resources through data collection and action via one or more CUs 3310, one or more DUs 3330, or both, and an interface connecting the O-eNB to the quasi-RT RIC 3325 (e.g., via an E2 interface).

[0080] In some implementations, the non-RT RIC 3315 may receive parameters or external enrichment information from an external server to generate the AI / ML models deployed to the quasi-RT RIC 3325. Such information may be utilized by the quasi-RT RIC 3325 or may be received from a non-network data source or from a network function in the SMO framework 3305 or the non-RT RIC 3315. In some examples, the non-RT RIC 3315 or the quasi-RT RIC 3325 may be configured to adjust RAN behavior or performance. For example, the non-RT RIC 3315 may employ the AI / ML models to monitor long-term trends and patterns in performance and implement corrective actions through the SMO framework 3305 (e.g., reconfiguration via O1) or through the creation of RAN management policies (e.g., A1 policies).

[0081] FIG. 4 illustrates examples of different communication mechanisms used by various UEs. In one example of sidelink communication, FIG. 4 illustrates a vehicle 404, a vehicle 405, and an RSU 403 communicating with each other using a PC5, DSRC, or other device-to-device direct signaling interface. In addition, the vehicle 404 and the vehicle 405 may communicate with a base station 402 (shown as BS 402) using a network (Uu) interface. In some examples, the base station 402 may include a gNB. FIG. 4 also illustrates a user device 407 communicating with the base station 402 using the network (Uu) interface. As described below, functionality may be transferred from a vehicle (e.g., vehicle 404) to a user device (e.g., user device 407) based on one or more characteristics or factors (e.g., temperature, humidity, etc.). In one example embodiment, as shown in FIG. 4, the V2X functionality can be transferred from the vehicle 404 to the user device 407, which can then communicate with other vehicles (e.g., vehicle 405) via a PC5 interface (or other direct device-to-device interface, such as a DSRC interface).

[0082] 4 illustrates a particular number of vehicles (e.g., two vehicles 404 and 405) communicating with each other and / or with the RSU 403, the BS 402, and / or the user device 407, but the disclosure is not so limited. For example, dozens or hundreds of such vehicles may communicate with each other and / or with the RSU 403, the BS 402, and / or the user device 407. At any given time, each of such vehicles, the RSU 403, the BS 402, and / or the user device 407 may transmit various types of information as messages to other nearby vehicles, resulting in each of the vehicles (e.g., vehicles 404 and / or 405), the RSU 403, the BS 402, and / or the user device 407 receiving hundreds or thousands of messages per second from other nearby vehicles, RSUs, base stations, and / or other UEs.

[0083] 4, various UEs (e.g., vehicles, user devices, etc.) and RSU(s) may communicate directly using any suitable type of direct interface, such as an 802.11 DSRC interface, a Bluetooth™ interface, and / or other interfaces. For example, a vehicle may communicate with a user device over a direct communication interface (e.g., using PC5 and / or DSRC), a vehicle may communicate with another vehicle over a direct communication interface, a user device may communicate with another user device over a direct communication interface, a UE (e.g., vehicle, user device, etc.) may communicate with an RSU over a direct communication interface, an RSU may communicate with another RSU over a direct communication interface, etc.

[0084] 5 is a block diagram illustrating an example of a vehicle computing system 550 of a vehicle 504. The vehicle 504 is an example of a UE that can communicate with a network (e.g., eNBs, gNBs, positioning beacons, position measurement units, and / or other network entities) over a Uu interface and can communicate with other UEs using V2X communications over a PC5 interface (or other direct device-to-device interface such as a DSRC interface). As shown, the vehicle computing system 550 can include at least a power management system 551, a control system 552, an infotainment system 554, an intelligent transportation system (ITS) 555, one or more sensor systems 556, and a communication system 558. In some cases, the vehicle computing system 550 may include or be implemented using any type of processing device or system, such as one or more central processing units (CPUs), digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), application processors (APs), graphics processing units (GPUs), vision processing units (VPUs), Neural Network Signal Processors (NSPs), microcontrollers, dedicated hardware, any combination thereof, and / or other processing devices or systems.

[0085] The control system 552 may be configured to control one or more operations of the vehicle 504, the power management system 551, the computing system 550, the infotainment system 554, the ITS 555, and / or one or more other systems of the vehicle 504 (e.g., a braking system, a steering system, a safety system other than the ITS 555, a cabin system, and / or other systems). In some examples, the control system 552 may include one or more electronic control units (ECUs). An ECU may control one or more of the electronic systems or subsystems within the vehicle. Examples of specific ECUs that may be included as part of the control system 552 include an engine control module (ECM), a powertrain control module (PCM), a transmission control module (TCM), a brake control module (BCM), a central control module (CCM), a central timing module (CTM), among others. In some cases, the control system 552 can receive sensor signals from one or more sensor systems 556 and can communicate with other systems of the vehicle computing system 550 in order to operate the vehicle 504.

[0086] The vehicle computing system 550 also includes a power management system 551. In some implementations, the power management system 551 can include a power management integrated circuit (PMIC), a standby battery, and / or other components. In some cases, other systems of the vehicle computing system 550 can include one or more PMICs, batteries, and / or other components. The power management system 551 can perform power management functions for the vehicle 504, such as managing the power supply for the computing system 550 and / or other parts of the vehicle. For example, the power management system 551 can provide a stable power supply, taking into account power fluctuations, such as based on starting the vehicle's engine. In another example, the power management system 551 can perform thermal monitoring operations, such as by checking the ambient temperature and / or transistor junction temperature. In another example, the power management system 551 may perform certain functions based on detecting a certain temperature level, such as, among other functions, causing a cooling system (e.g., one or more fans, an air conditioning system, etc.) to cool certain components of the vehicle computing system 550 (e.g., a control system 552, such as one or more ECUs), shutting down certain functions of the vehicle computing system 550 (e.g., limiting the infotainment system 554 by shutting down one or more displays, disconnecting from a wireless network, etc.).

[0087] The vehicle computing system 550 further includes a communication system 558. The communication system 558 can include both software and hardware components for transmitting signals to and from a network (e.g., a gNB or other network entity via a Uu interface) and / or other UEs (e.g., to another vehicle or UE via a PC5 interface, a WiFi interface (e.g., DSRC), a Bluetooth™ interface, and / or other wireless and / or wired interfaces). For example, the communication system 558 is configured to wirelessly transmit and receive information via any suitable wireless network (e.g., a 3G network, a 4G network, a 5G network, a WiFi network, a Bluetooth™ network, and / or other networks). The communication system 558 includes various components or devices used to perform wireless communication functions, including an original equipment manufacturer (OEM) subscriber identity module (referred to as a SIM or SIM card) 560, a user SIM 562, and a modem 564. Although vehicle computing system 550 is shown as having two SIMs and one modem, in some implementations computing system 550 can have any number of SIMs (e.g., one SIM or more than two SIMs) and any number of modems (e.g., one modem, two modems, or more than two modems).

[0088] A SIM is a device (e.g., an integrated circuit) that can securely store a particular subscriber or user's International Mobile Subscriber Identity (IMSI) number and associated keys (e.g., encryption-decryption keys). The IMSI and keys may be used to identify and authenticate a particular UE subscriber. The OEM SIM 560 may be used by the communication system 558 to establish wireless connections for vehicle-based operations, to perform emergency-calling (eCall) functions, to communicate with the vehicle manufacturer's communication system (e.g., for software updates, etc.), among other operations. The OEM SIM 560 may be important for the OEM SIM to support critical services such as eCall for making emergency calls in the event of a vehicle accident or other emergency. For example, eCall may include a service that automatically calls an emergency number (e.g., "9-1-1" in the United States, "1-1-2" in Europe, etc.) in the event of a vehicle accident to communicate the location of the vehicle to emergency services such as the police, fire department, etc.

[0089] The user SIM 562 may be used by the communication system 558 to perform wireless network access functions to support user data connectivity (e.g., for calling, messaging, infotainment-related services, among others). In some cases, the user's user device may connect with the vehicle computing system 550 via an interface (e.g., PC5, Bluetooth™, WiFI™ (e.g., DSRC), Universal Serial Bus (USB) port, and / or other wireless or wired interface). Once connected, the user device may transition wireless network access functions from the user device to the vehicle's communication system 558, in which case the user device may cease performing wireless network access functions (e.g., while the communication system 558 performs wireless access functions). The communication system 558 may begin interacting with a base station to perform one or more wireless communication operations, such as facilitating calls, transmitting and / or receiving data (e.g., messaging, video, audio, etc.), among other operations. In such cases, other components of the vehicle computing system 550 may be used to output data received by the communication system 558. For example, infotainment system 554 (described below) may display video received by communication system 558 on one or more displays and / or output audio received by communication system 558 using one or more speakers.

[0090] A modem is a device that modulates one or more carrier signals to encode digital information for transmission and demodulates the signals to decode the transmitted information. Modem 564 (and / or one or more other modems of communication system 558) may be used to communicate data for OEM SIM 560 and / or user SIM 562. In some examples, modem 564 may include a 4G (or LTE) modem and another modem (not shown) of communication system 558 may include a 5G (or NR) modem. In some examples, communication system 558 may include one or more Bluetooth™ modems (e.g., for Bluetooth™ Low Energy (BLE) or other types of Bluetooth communications), one or more WiFi™ modems (e.g., for DSRC communications and / or other WiFi communications), wideband modems (e.g., ultra-wideband (UWB) modems), any combination of these, and / or other types of modems.

[0091] In some cases, modem 564 (and / or one or more other modems of communication system 558) may be used to perform V2X communications (e.g., with other vehicles in V2V communications, with other devices in D2D communications, with infrastructure systems in V2I communications, with pedestrian UEs in V2P communications, etc.). In some examples, communication system 558 may include a V2X modem used to perform V2X communications (e.g., sidelink communications over a PC5 interface or a DSRC interface), in which case the V2X modem may be separate from one or more modems used for wireless network access functions (e.g., for network communications over a network / Uu interface and / or sidelink communications other than V2X communications).

[0092] In some examples, the communication system 558 may be or may include a telematics control unit (TCU). In some implementations, the TCU may include a network access device (NAD) (sometimes also referred to as a network control unit or NCU). The NAD may include a modem 564, any other modems not shown in FIG. 5, an OEM SIM 560, a user SIM 562, and / or other components used for wireless communications. In some examples, the communication system 558 may include a Global Navigation Satellite System (GNSS). In some cases, the GNSS may be part of one or more sensor systems 556, as described below. The GNSS may provide the vehicle computing system 550 with the ability to perform one or more location services, navigation services, and / or other services that can utilize GNSS capabilities.

[0093] In some cases, the communications system 558 may further include one or more wireless interfaces (e.g., including one or more transceivers and one or more baseband processors for each wireless interface) for transmitting and receiving wireless communications, one or more wired interfaces (e.g., serial interfaces such as universal serial bus (USB) inputs, lightening connectors, and / or other wired interfaces) for performing communications over one or more hardwired connections, and / or other components that may enable the vehicle 504 to communicate with a network and / or other UEs.

[0094] The vehicle computing system 550 may also include an infotainment system 554 that may control content, and one or more output devices of the vehicle 504 that may be used to output content. The infotainment system 554 may also be referred to as an in-vehicle infotainment (IVI) system or an in-car entertainment (ICE) system. The content may include navigation content, media content (e.g., video content, music or other audio content, and / or other media content), among other content. The one or more output devices may include one or more graphical user interfaces, one or more displays, one or more speakers, one or more extended reality devices (e.g., VR, AR, and / or MR headsets), one or more haptic feedback devices (e.g., one or more devices configured to vibrate a seat, a steering wheel, and / or other parts of the vehicle 504), and / or other output devices.

[0095] In some examples, the computing system 550 may include an intelligent transportation system (ITS) 555. In some examples, the ITS 555 may be used to implement V2X communications. For example, the ITS stack of the ITS 555 may generate V2X messages based on information from an application layer of the ITS. In some cases, the application layer may determine whether certain conditions are met to generate messages for use by the ITS 555 and / or to generate messages to be transmitted to other vehicles (in the case of V2V communications), pedestrian UEs (in the case of V2P communications), and / or infrastructure systems (in the case of V2I communications). In some cases, the communication system 558 and / or the ITS 555 may obtain car access network (CAN) information (e.g., from other components of the vehicle via a CAN bus). In some examples, the communication system 558 (e.g., the TCU NAD) may obtain CAN information via a CAN bus and transmit the CAN information to the PHY / MAC layer of the ITS 555. ITS 555 can provide CAN information to the ITS stack of ITS 555. The CAN information can include vehicle related information such as vehicle orientation, vehicle speed, crash information, among other information. The CAN information can be provided to ITS 555 continuously or periodically (e.g., every 1 millisecond (ms), every 10 ms, etc.).

[0096] The conditions used to determine whether to generate a message may be determined using the CAN information based on safety-related and / or other applications, including road safety, traffic efficiency, infotainment, business-related, and / or other applications. In one exemplary embodiment, the ITS 555 may perform lane change assistance or negotiation. For example, the ITS 555 may use the CAN information to determine that the driver of the vehicle 504 is attempting to change lanes from a current lane to an adjacent lane (e.g., based on the turn signal being activated, the user turning or steering into the adjacent lane, etc.). Based on determining that the vehicle 504 is attempting to change lanes, the ITS 555 may determine that a lane change condition associated with a message to be sent to other vehicles in the adjacent lane near the vehicle is met. The ITS 555 may trigger the ITS stack to generate one or more messages for sending to other vehicles, which may be used to negotiate a lane change with the other vehicles. Other example applications include forward collision warning, automatic emergency breaking, lane departure warning, pedestrian avoidance or protection (e.g., when a pedestrian is detected near the vehicle 504 based on V2P communication with a user's UE, etc.), and traffic sign recognition, among others.

[0097] The ITS 555 may generate messages (e.g., V2X messages) using any suitable protocol. Examples of protocols that may be used by the ITS 555 include one or more Society of Automotive Engineers (SAE) standards, such as SAE J2735, SAE J2945, SAE J3161, and / or other standards, which are incorporated herein by reference in their entirety for all purposes.

[0098] The security layer of the ITS 555 may be used to securely sign messages from the ITS stack that are sent to and verified by other UEs configured for V2X communications, such as other vehicles, pedestrian UEs, and / or infrastructure systems. The security layer may also verify messages received from such other UEs. In some implementations, the signing and verification process may be based on the security context of the vehicle. In some examples, the security context may include one or more encryption-decryption algorithms, public and / or private keys used to generate a signature using the encryption-decryption algorithms, and / or other information. For example, each ITS message generated by the ITS 555 may be signed by the security layer of the ITS 555. The signature may be obtained using the public key and the encryption-decryption algorithm. Vehicles, pedestrian UEs, and / or infrastructure systems receiving the signed message may verify the signature to ensure that the message is from an authorized vehicle. In some examples, the one or more encryption-decryption algorithms may include one or more symmetric encryption algorithms (e.g., advanced encryption standard (AES), data encryption standard (DES), and / or other symmetric encryption algorithms), one or more asymmetric encryption algorithms using public and private keys (e.g., Rivest-Shamir-Adleman (RSA) and / or other asymmetric encryption algorithms), and / or other encryption-decryption algorithms.

[0099] In some examples, the ITS 555 can determine a particular action to perform (e.g., a V2X-based action) based on the message received from the other UE. The action can include safety-related actions and / or other actions, such as actions for road safety, traffic efficiency, infotainment, business, and / or other applications. In some examples, the action can include causing the vehicle (e.g., the control system 552) to perform an automatic function, such as auto-destroy, auto-steer (e.g., to maintain heading in a particular lane), automated lane change negotiation with the other vehicle, among other automatic functions. In one exemplary embodiment, a message indicating that the other vehicle will make an emergency stop can be received by the communication system 558 from another device (e.g., via a PC5 interface, a DSRC interface, or other device-to-device direct interface). In response to receiving the message, the ITS stack can generate a message or command and can send the message or command to the control system 552, which can cause the control system 552 to cause the vehicle 504 to automatically destroy so that the vehicle 504 stops before it crashes into the other vehicle. In other illustrative examples, the actions may include triggering the display of a message alerting the driver that there is another vehicle in a lane next to the vehicle, alerting the driver to stop the vehicle, alerting the driver that there is a pedestrian in the crosswalk ahead, and alerting the driver that a toll booth is within a certain distance (e.g., within one mile) of the vehicle, among other things.

[0100] In some examples, the ITS 555 may receive a large number of messages from other UEs (e.g., vehicles, RSUs, etc.), where the ITS 555 will authenticate (e.g., decrypt and decrypt) each of the messages and / or determine which action to perform. Such a large number of messages may lead to a large computational load for the vehicle computing system 550. In some cases, the large computational load may increase the temperature of the computing system 550. The increased temperature of the components of the computing system 550 may adversely affect the ability of the computing system 550 to process a large number of incoming messages. Based on the temperature of the vehicle computing system 550 (or its components) exceeding or approaching one or more thermal levels, one or more functions may be migrated from the vehicle 504 to another device (e.g., a user device, an RSU, etc.). Migrating one or more functions may reduce the computational load of the vehicle 504 and help reduce the temperature of the components. A thermal load balancer may be provided that enables the vehicle computing system 550 to perform thermal-based load balancing to control processing load depending on the temperature of the computing system 550 and the processing capabilities of the vehicle computing system 550.

[0101] Computing system 550 further includes one or more sensor systems 556 (e.g., a first sensor system through an Nth sensor system, where N is a value equal to or greater than 0). When including multiple sensor systems, sensor system(s) 556 may include different types of sensor systems that may be located on or within different portions of vehicle 504. The sensor system(s) 556 may include one or more camera sensor systems, LIDAR sensor systems, radio detection and ranging (RADAR) sensor systems, electromagnetic detection and ranging (EmDAR) sensor systems, sound navigation and ranging (SONAR) sensor systems, sound detection and ranging (SODAR) sensor systems, global navigation satellite system (GNSS) receiver systems (e.g., one or more global positioning system (GPS) receiver systems), accelerometers, gyroscopes, inertial measurement units (IMUs), infrared sensor systems, laser range finder systems, ultrasonic sensor systems, infra-red sensor systems, microphones, any combination thereof, and / or other sensor systems. It should be understood that any number of sensors or sensor systems may be included as part of the computing system 550 of the vehicle 504.

[0102] Although the vehicle computing system 550 is shown as including certain components and / or systems, one skilled in the art will understand that the vehicle computing system 550 can include more or less components than those shown in FIG. 5. For example, the vehicle computing system 550 can also include one or more input devices and one or more output devices (not shown). In some implementations, the vehicle computing system 550 can also include at least one processor (e.g., as part of or separate from the control system 552, infotainment system 554, communication system 558, and / or sensor system(s) 556) and at least one memory having computer-executable instructions executed by the at least one processor. The at least one processor is in communication with and / or electrically connected to (said to be "coupled" or "communicatively coupled") the at least one memory. The at least one processor may include, for example, one or more microcontrollers, one or more central processing units (CPUs), one or more field programmable gate arrays (FPGAs), one or more graphics processing units (GPUs), one or more application processors (e.g., for running or executing one or more software applications), and / or other processors. The at least one memory may include, for example, read-only memory (ROM), random access memory (RAM) (e.g., static RAM (SRAM)), electrically erasable programmable read-only memory (EEPROM), flash memory, one or more buffers, one or more databases, and / or other memories.The computer-executable instructions stored at least in or on the memory may be executed to perform one or more of the functions or operations described herein.

[0103] FIG. 6 illustrates an example of a computing system 670 of a user device 607. The user device 607 is an example of a UE that may be used by an end user. For example, the user device 607 may include a mobile phone, a router, a tablet computer, a laptop computer, a tracking device, a wearable device (e.g., a smart watch, glasses, an XR device, etc.), an Internet of Things (IoT) device, and / or other devices used by a user to communicate over a wireless communication network. The computing system 670 includes software and hardware components that may be electrically or communicatively coupled (or may otherwise communicate, as appropriate) via a bus 689. For example, the computing system 670 includes one or more processors 684. The one or more processors 684 may include one or more CPUs, ASICs, FPGAs, APs, GPUs, VPUs, NSPs, microcontrollers, dedicated hardware, any combination thereof, and / or other processing devices or systems. A bus 689 may be used by one or more processors 684 to communicate between the cores and / or with one or more memory devices 686.

[0104] The computing system 670 may also include one or more memory devices 686, one or more digital signal processors (DSPs) 682, one or more SIMs 674, one or more modems 676, one or more wireless transceivers 678, an antenna 687, one or more input devices 672 (e.g., a camera, a mouse, a keyboard, a touch-sensitive screen, a touchpad, a keypad, a microphone, etc.), and one or more output devices 680 (e.g., a display, speakers, a printer, etc.).

[0105] The one or more wireless transceivers 678 may receive wireless signals (e.g., signals 688) via antenna 687 from one or more other devices, such as other user devices, vehicles (e.g., vehicle 504 of FIG. 5 described above), network devices (e.g., base stations such as eNBs and / or gNBs, WiFi routers, etc.), cloud networks, etc. In some examples, computing system 670 may include multiple antennas. The wireless signals 688 may be transmitted over a wireless network. The wireless network may be any wireless network, such as a cellular or telecommunications network (e.g., 3G, 4G, 5G, etc.), a wireless local area network (e.g., a WiFi network), a Bluetooth™ network, and / or other network. In some examples, the one or more wireless transceivers 678 may include an RF front end that includes one or more components such as an amplifier, a mixer (also called a signal multiplier) for signal downconversion, a frequency synthesizer (also called an oscillator) that provides a signal to the mixer, a baseband filter, an analog-to-digital converter (ADC), one or more power amplifiers, among other components. The RF front end can generally handle the selection of the wireless signal 688 and the conversion to a baseband or intermediate frequency, and can convert the RF signal to the digital domain.

[0106] In some cases, the computing system 670 may include a coding-decoding device (or CODEC) configured to encode and / or decode data transmitted and / or received using the one or more wireless transceivers 678. In some cases, the computing system 670 may include an encryption-decryption device or component configured to encrypt and / or decrypt data transmitted and / or received by the one or more wireless transceivers 678 (e.g., according to the AES and / or DES standards).

[0107] The one or more SIMs 674 may each securely store an IMSI number and associated keys assigned to a user of the user device 607. As discussed above, the IMSI and keys may be used to identify and authenticate a subscriber when accessing a network provided by a network service provider or operator associated with the one or more SIMs 674. The one or more modems 676 may modulate one or more signals to encode information for transmission using the one or more wireless transceivers 678. The one or more modems 676 may also demodulate signals received by the one or more wireless transceivers 678 to decode the transmitted information. In some examples, the one or more modems 676 may include a 4G (or LTE) modem, a 5G (or NR) modem, a modem configured for V2X communications, and / or other types of modems. The one or more modems 676 and the one or more wireless transceivers 678 may be used to communicate data for the one or more SIMs 674.

[0108] The computing system 670 may also include (and / or be in communication with) one or more non-transitory machine-readable storage media or storage devices (e.g., one or more memory devices 686), which may include, but are not limited to, local and / or network-accessible storage, disk drives, drive arrays, optical storage devices, and / or solid-state storage devices such as RAM and / or ROM, which may be programmable, flash-updateable, etc. Such storage devices may be configured to implement any suitable data storage system, including, but not limited to, various file systems, database structures, and the like.

[0109] In various aspects, functions may be stored as one or more computer program products (e.g., instructions or code) in memory device 686 and executed by one or more processors 684 and / or one or more DSPs 682. Computing system 670 may also include software elements (e.g., within one or more memory devices 686) including, for example, an operating system, device drivers, executable libraries, and / or other code, such as one or more application programs, which may include computer programs that implement functions provided by various aspects and / or may be designed to implement methods and / or configure systems described herein.

[0110] FIG. 7 illustrates an example of wireless communication 700 between devices based on sidelink communication, such as V2X or other D2D communication. The communication may be based on a slot configuration including aspects described in connection with FIG. 2. For example, a transmitting UE 702 may transmit a transmission 714 including, for example, a control channel and / or a corresponding data channel, which may be received by the receiving UEs 704, 706, 708. At least one of the UEs may include an autonomous vehicle or an unmanned aerial vehicle. The control channel may include information for decoding the data channel and may be used by the receiving device during data transmission to avoid interference by refraining from transmitting on the occupied resources. The number of TTIs as well as the RBs occupied by the data transmission may be indicated in a control message from the transmitting device. The UEs 702, 704, 706, 708 may each be capable of operating as a transmitting device in addition to operating as a receiving device. Thus, the UEs 706, 708 are shown as transmitting transmissions 716, 720. The transmissions 714, 716, 720 (and 718 by the RSU 707) may be broadcast or multicast to nearby devices. For example, the UE 714 may transmit a communication intended for reception by other UEs within range 701 of the UE 714. Additionally / alternatively, the RSU 707 may receive communications from and / or transmit communications 718 to the UEs 702, 704, 706, 708.

[0111] The UE 702, 704, 706, 708, or RSU 707 may include detection components similar to 198 described in connection with FIG. 1. The UE 702, 704, 706, 708, or RSU 707 may include BSM or mitigation components similar to 199 described in connection with FIG.

[0112] In wireless communication such as V2X communication, a V2X entity may perform sensor sharing with other V2X entities for cooperative automated driving. For example, referring to the schematic diagram 800 of FIG. 8A, a host vehicle (HV) 802 may detect some items in its environment. For example, the HV 802 may detect the presence of a non-V2X entity (NV) 806 in block 832. The HV 802 may inform other entities such as a first remote vehicle (RV1) 804 and / or a roadside unit (RSU) 808 about the presence of the NV 806 when the first remote vehicle (RV1) 804 or a roadside unit (RSU) 808 cannot detect the NV 806 by themselves. The HV 802 informing the RV1 804 and / or the RSU 808 about the NV 806 is a sharing of sensor information. Referring to diagram 810 in FIG. 8B, HV 802 may detect a physical obstacle 812, such as a pothole, debris, or object that may be an obstacle in the path of HV 802 and / or RV1 804 that has not yet been detected by RV1 804 and / or RSU 808. HV 802 may inform RV1 and / or RSU 808 about the obstacle 812 so that the obstacle 812 can be avoided. Referring to diagram 820 in FIG. 8C, HV 802 may detect the presence of a vulnerable road user (VRU) 822 and may share the detection of the VRU 822 with RV1 804 and RSU 808 if RSU 808 and / or RV1 804 cannot detect the VRU 822. Referring to diagram 830 of FIG. 8D, when an HV detects a nearby entity (e.g., NV, VRU, obstacle), it may send a sensor data sharing message (SDSM) 834 to the RV and / or RSU to share the detection of the entity. The SDSM 834 may be a broadcast message so that any receiving device in the vicinity of the HV can receive the message. In some cases, the shared information may be relayed to other entities, such as the RV. For example, referring to diagram 900 of FIG. 9, an HV 902 may detect the presence of an NV 906 and / or a VRU 922.The HV 902 may broadcast an SDSM 910 to the RSU 908 to report the detection of the NV 906 and / or the VRU 922. The RSU 908 may relay the SDSM 910 received from the HV 902 to the remote vehicles so that the remote vehicles are aware of the presence of the NV 906 and / or the VRU 922. For example, the RSU 908 may send an SDSM 912 to the RV1 904, where the SDSM 912 includes information regarding the detection of the NV 906 and / or the VRU 922.

[0113] As mentioned above, a Maneuver Shared Coordination Message (MSCM) is a V2X message that can be used to exchange planned trajectories between vehicles to execute maneuver coordination. MSCM (e.g., MSCM 1400 of FIG. 14) allows vehicles to share their maneuver intent to coordinate their planned maneuvers for safer and more efficient operation. A series of MSCMs transmitted between vehicles can be utilized for maneuver coordination and execution. A series of MSCMs can consist of handshake sessions between vehicles affected by the intended maneuver. The use of MSCMs depends on the exchange of MSCMs and communication protocols such as a basic protocol (e.g., basic protocol 1500 of FIG. 15) and an emergency protocol (e.g., emergency protocol 1600 of FIG. 16). 10, 11, 12A, and 12B show example vehicle configurations 1000, 1100, 1200, 1210 for operation in a variety of different scenarios (e.g., overtaking, merging, and lane change scenarios) in which MSCM may be utilized to coordinate vehicle operation.

[0114] It should also be noted that each MSCM in a set of MSCMs utilized to coordinate a maneuver (e.g., an overtaking maneuver, a merging maneuver, or a lane change maneuver) may have a specific type (e.g., MSCM type 1408 in FIG. 14 ) that may indicate the type of MSCM. The specific types of MSCMs may include, but are not limited to, an intent operation message, a request operation message, a response operation message, a reservation operation message, an HV cancel operation message, an RV cancel operation message, and an execution status operation message. An example base protocol 1500 for MSCMs shown in FIG. 15 illustrates some example types of MSCMs. For example, in FIG. 15 , MCSM message types for an exemplary base protocol 1500 are shown to include operation intent (e.g., MSCM type 0) 1510, operation request (e.g., MSCM type 1) 1511, operation response (e.g., MSCM type 2) 1512, operation reservation (e.g., MSCM type 3) 1513, host vehicle (HV) operation cancel (e.g., MSCM type 4) 1514, remote vehicle (RV) operation cancel (e.g., MSCM type 5) 1515, and operation execution status (e.g., MSCM type 7) 1517.

[0115] The MSCM of intent (e.g., MSCM Type 0) may be broadcast at a particular power level to allow a particular range of transmission so that vehicles affected by the intended operation can receive the MSCM and other vehicles do not receive the MSCM. Alternatively, the MSCM of intent (e.g., MSCM Type 0) may be broadcast at a maximum power level to allow a maximum allowable range of transmission so that all vehicles located within a maximum allowable range of transmission can receive the MSCM. In response to receiving the MSCM of intent, a response MSCM (e.g., MSCM Type 2) may be broadcast (e.g., unicast) only to the particular vehicle that transmitted the MSMC of intent (e.g., MSCM Type 0).

[0116] It should be noted that a set of MSCMs utilized for a maneuver (e.g., an overtaking maneuver, a merging maneuver, or a lane-changing maneuver) may have a single maneuver ID (e.g., maneuver ID 1414 in FIG. 14) assigned to the MSCM. The maneuver ID is similar to a session ID and is utilized to identify the particular maneuver (e.g., an overtaking maneuver, a merging maneuver, or a lane-changing maneuver) to which the set of MSCMs pertain, allowing the vehicle to track updates related to that particular maneuver. As previously discussed, the maneuver ID should be unique to avoid any possible maneuver ID collisions (e.g., collisions that occur when two or more maneuvers have the same maneuver ID) that may result in the cancellation of a maneuver.

[0117] Currently, there are no available solutions for generating unique operation IDs or for detecting attacks related to colliding operation IDs that can lead to the undoing of multiple operations. The disclosed systems and techniques provide a unique operation ID for each operation (e.g., process 1700 of FIG. 17) and provide fraud detection and reporting (MBDS) for operation ID collisions (e.g., process 1800 of FIG. 18).

[0118] FIG. 10 illustrates an example of a vehicle configuration 1000 for vehicle operation in an overtaking scenario. In FIG. 10, the vehicle configuration 1000 is shown to include multiple equipped (e.g., V2X-enabled) network devices. The multiple equipped network devices include vehicles (e.g., cars) 1004, 1006, and a vehicle (e.g., truck) 1002. The vehicle configuration 1000 may include more or fewer equipped network devices than those shown in FIG. 10. In addition, the vehicle configuration 1000 may include non-equipped network devices (not shown in FIG. 10), such as non-equipped vehicles, vulnerable road users (VRUs), such as cyclists, and pedestrians. In addition, the vehicle configuration 1000 may include more or fewer different types of equipped network devices (e.g., may include equipped UEs) than those shown in FIG. 10. Additionally, in one or more examples, the equipped network devices may be equipped with disparate capabilities, which may include, but are not limited to, C-V2X / DSRC capabilities, 4G / 5G cellular connectivity, GPS capabilities, camera capabilities, radar capabilities, and / or LIDAR capabilities.

[0119] A number of the equipment network devices may be capable of performing V2X communications. In addition, at least some of the equipment network devices may be capable of transmitting and receiving sensing signals for radar (e.g., RF sensing signals) and / or LIDAR (e.g., optical sensing signals) to detect nearby vehicles and / or objects. In one or more examples, the vehicles 1002, 1004, 1006 may be capable of transmitting and receiving certain sensing signals (e.g., camera sensing signals, radar sensing signals, and / or LIDAR sensing signals).

[0120] In some examples, some of the on-board network devices 1002, 1004, 1006 may have higher capability sensors (e.g., GPS receivers, cameras, RF antennas, and / or optical lasers and / or light sensors) than other on-board network devices of the vehicle configuration 1000. For example, the vehicle (e.g., truck) 1002 may have more expensive and higher capability sensors than other vehicles (e.g., cars) 1006, 1004. In one illustrative example, the vehicle 1002 may have one or more LIDAR sensors (e.g., high performance optical lasers and light sensors) that are higher capability than other on-board network devices in the vehicle configuration 1000. For example, the LIDAR of the vehicle 1002 may be capable of detecting VRUs (e.g., cyclists) and / or pedestrians with a high degree of confidence (e.g., 70 percent confidence). In another example, the vehicle 1002 may have a higher capability radar (e.g., high performance RF antennas) than other on-board network devices in the vehicle configuration 1000. For example, the radar of the vehicle 1002 may be capable of detecting VRUs and / or pedestrians with a high degree of confidence (eg, 85 percent confidence).

[0121] During operation, the equipment network devices (e.g., vehicles 1002, 1004, 1006) may transmit and / or receive sensing signals (e.g., RF and / or optical signals) to sense and detect vehicles (e.g., vehicles 1002, 1004, 1006) and / or objects (not shown) located in and around a roadway. The equipment network devices (e.g., vehicles 1002, 1004, 1006) may then use the sensing signals to determine characteristics (e.g., movement, size, type, direction of travel, and speed) of the detected vehicles and / or objects. The equipment network devices (e.g., vehicles 1002, 1004, 1006) may generate at least one vehicle-based message (e.g., a C-V2X message, such as a Sensor Data Sharing Message (SDSM), Basic Safety Message (BSM), Cooperative Awareness Message (CAM), Collective Perception Message (CPM), and / or other types of messages) that includes information related to the determined characteristics of the detected vehicles and / or objects.

[0122] The vehicle-based message may include information related to the detected vehicle or object (e.g., the location of the vehicle or object, the accuracy of the location, the speed of the vehicle or object, the direction the vehicle or object is moving, and / or other information related to the vehicle or object), traffic conditions (e.g., slow and / or congested traffic, fast traffic, information related to an accident, etc.), weather conditions (e.g., rain, snow, etc.), message type (e.g., emergency message, non-emergency or "normal" message, etc.), road topology (line-of-sight (LOS) or non-LOS (NLOS), etc.), any combination thereof, and / or other information. In some examples, the vehicle-based message may also include information regarding a preference of the equipment network device for receiving vehicle-based messages from other particular equipment network devices. In some cases, the vehicle-based messages may include the current capabilities of the equipment network devices (e.g., vehicles 1002, 1004, 1006), such as the sensing capabilities, processing capabilities, thermal conditions of the equipment network devices (which may affect the accuracy with which the equipment network devices sense vehicles and / or objects), and health conditions of the equipment network devices.

[0123] In some aspects, the vehicle-based message may include a dynamic neighbor list (also referred to as a Local Dynamic Map (LDM) or dynamic surroundings map) for each of the equipment network devices (e.g., vehicles 1002, 1004, 1006). For example, each dynamic neighbor list may include a list of all of the vehicles and / or objects located within a certain predetermined distance (or distance radius) from the corresponding equipment network device. In some cases, each dynamic neighbor list includes a mapping, which may include road and terrain topology, of all of the vehicles and / or objects located within a certain predetermined distance (or distance radius) from the corresponding equipment network device.

[0124] In some implementations, the vehicle-based message may include a specific use case or safety warning, such as a do-not-pass warning (DNPW) or a forward collision warning (FCW), related to the current state of an on-board network device (e.g., vehicle 1002, 1004, 1006). In some examples, the vehicle-based message may be in the form of a standard BSM, CAM, CPM, SDSM (e.g., SAE J3224 SDSM), and / or other format.

[0125] In FIG. 10, the vehicle configuration 1000 illustrates an example of an overtaking scenario in which a vehicle 1004 desires to overtake a vehicle (e.g., truck) 1002. Specifically, in FIG. 10, the vehicle 1004 is shown traveling behind the vehicle (e.g., truck) 1002, and a vehicle 1006 is traveling in the opposite direction from the vehicles 1002, 1004 in the opposite lane. The vehicle 1004 (or the driver of the vehicle) desires to overtake the vehicle (e.g., truck) 1002. Thus, the vehicle 1004 (or the driver of the vehicle) desires to execute an overtaking maneuver to overtake the vehicle 1002. In doing so, in one or more examples, the vehicle 1004 may utilize a series of MSCMs (e.g., MSCM 1400 of FIG. 14) to coordinate the overtaking maneuver with the other vehicles 1002, 1006.

[0126] 10, the vehicle 1004 may transmit an intent operation message (e.g., MSCM type 0) and a request operation message (e.g., MSCM type 1) to the other vehicle 1002, 1006 to inform the other vehicle 1002, 1006 of the intent and desire of the vehicle 1004 to overtake the vehicle (e.g., truck) 1002. In response, the vehicles 1002, 1006 may transmit a reply operation message (e.g., MSCM type 2) to the vehicle 1004 to indicate to the vehicle 1004 that they have accepted and accepted the intent and request of the vehicle 1004, and will assist the vehicle 1004 with the requested overtaking maneuver.

[0127] After receiving the response operation messages (e.g., MSCM type 2) from the vehicles 1002, 1006, the vehicle 1004 may send a reservation operation message (e.g., MSCM type 3) to the vehicles 1002, 1006 to confirm that the vehicle 1004 received their response operation messages and intends to proceed with the overtaking maneuver. The vehicle 1004 may then proceed to perform the overtaking maneuver and send an execution status operation message (e.g., MSCM type 7) to the vehicles 1002, 1006 to inform the vehicles 1002, 1006 of the status of the execution of the overtaking maneuver by the vehicle 1004. It should be noted that this is only one example of a series of MSCMs that may be utilized by the vehicles 1004 to coordinate a maneuver, and that in other examples, more or fewer MSCMs and / or other MSCMs may be employed to perform the maneuver.

[0128] FIG. 11 is a diagram illustrating an example of a vehicle configuration 1100 for vehicle operation in a merging scenario. In FIG. 11, the vehicle configuration 1100 is shown to include multiple equipped (e.g., V2X-enabled) network devices. The multiple equipped network devices include vehicles (e.g., automobiles) 1102, 1104, 1106, 1108, 1110. In one or more examples, the vehicle configuration 1100 may include more or fewer equipped network devices than those shown in FIG. 11. In addition, the vehicle configuration 1100 may include non-equipped network devices (not shown in FIG. 11), such as non-equipped vehicles, VRUs, and pedestrians. In one or more examples, the vehicle configuration 1100 may include more different types of equipped network devices than those shown in FIG. 11 (e.g., may include equipped UEs and / or equipped trucks). Additionally, equipped network devices may be equipped with disparate capabilities, which may include, but are not limited to, C-V2X / DSRC capabilities, 4G / 5G cellular connectivity, GPS capabilities, camera capabilities, radar capabilities, and / or LIDAR capabilities.

[0129] A number of equipment network devices (e.g., vehicles 1102, 1104, 1106, 1108, 1110) may be capable of performing V2X communications. At least some of the equipment network devices may be capable of transmitting and receiving sensing signals for radar (e.g., RF sensing signals) and / or LIDAR (e.g., optical sensing signals) to detect nearby vehicles and / or objects. In one or more examples, the vehicles 1102, 1104, 1106, 1108, 1110 may be capable of transmitting and receiving certain sensing signals (e.g., camera sensing signals, radar sensing signals, and / or LIDAR sensing signals). In some examples, some of the equipment network devices (e.g., vehicles 1102, 1104, 1106, 1108, 1110) may have higher capability sensors (e.g., GPS receivers, cameras, RF antennas, and / or optical lasers and / or optical sensors) than other equipment network devices (e.g., vehicles 1102, 1104, 1106, 1108, 1110) of the vehicle configuration 1100.

[0130] During operation, the equipment network devices (e.g., vehicles 1102, 1104, 1106, 1108, 1110) may transmit and / or receive sensing signals (e.g., RF and / or optical signals) to sense and detect vehicles (e.g., vehicles 1102, 1104, 1106, 1108, 1110) and / or objects (not shown in FIG. 11 ) located in and around the roadway. The equipment network devices (e.g., vehicles 1102, 1104, 1106, 1108, 1110) may utilize the sensing signals to determine characteristics (e.g., movement, size, type, direction of travel, and speed) of the detected vehicles and / or objects.

[0131] An equipment network device (e.g., vehicles 1102, 1104, 1106, 1108, 1110) may generate at least one vehicle-based message (e.g., SDSM, BSM, CAM, CPM) that includes information regarding characteristics of the detected vehicle and / or object. In one or more examples, the vehicle-based message may include a specific use case or safety warning, such as a DNPW or FCW, related to the current state and environment of the equipment network device (e.g., vehicles 1102, 1104, 1106, 1108, 1110). In some examples, the vehicle-based message may be in the form of a standard BSM, CAM, CPM, SDSM (e.g., SAE J3224 SDSM), and / or other format.

[0132] In Fig. 11, vehicle configuration 1100 illustrates an example of a merging scenario where vehicle 1104 wishes to merge onto a highway. Specifically, in Fig. 11, vehicles 1106, 1102, and 1108 are shown traveling in the same direction on the highway. Vehicle 1110 is shown traveling in the opposite direction of vehicles 1106, 1102, and 1108 on the opposite lane of the highway. Vehicle 1108 is further shown traveling behind vehicle 1102. Vehicle 1104 wishes to merge onto the highway into the space between vehicle 1102 and vehicle 1108. Thus, vehicle 1104 (or the driver of that vehicle) wishes to perform a merge maneuver to merge onto the highway into the space between vehicle 1102 and vehicle 1108. In one or more examples, the vehicle 1104 may use a series of MSCMs to coordinate merging maneuvers with the vehicles 1102, 1108.

[0133] 11 , vehicle 1104 may transmit intent operation messages (e.g., MSCM type 0) and request operation messages (e.g., MSCM type 1) to vehicles 1002, 1108 to inform vehicles 1102, 1108 of vehicle 1104's intent and request to merge onto the highway at a location between vehicles 1102 and 1108. In response, vehicles 1102, 1108 may transmit reply operation messages (e.g., MSCM type 2) to vehicle 1104 to indicate to vehicle 1104 that they have accepted and accepted vehicle 1104's intent and request to merge onto the highway, and will assist vehicle 1104 with the requested merge maneuver.

[0134] After receiving the response operation messages (e.g., MSCM type 2) from the vehicles 1102, 1108, the vehicle 1104 may send a reservation operation message (e.g., MSCM type 3) to the vehicles 1102, 1108 to confirm that the vehicle 1104 received those response operation messages and plans to execute a merge maneuver to merge onto the highway. The vehicle 1104 may then proceed to execute the merge maneuver and send an execution status operation message (e.g., MSCM type 7) to the vehicles 1102, 1108 to inform the vehicles 1102, 1108 of the status of the execution of the merge maneuver by the vehicle 1104. It should be noted that this is one example of a series of MSCMs that may be utilized by the vehicles 1104 to coordinate a merge maneuver, and that more or fewer MSCMs, and / or other MSCMs may be employed to execute the maneuver.

[0135] 12A and 12B are diagrams illustrating an example of a vehicle configuration 1200, 1210 for vehicle operation in a lane change scenario. FIG. 13 is a diagram of an example of a communication (e.g., V2X communication) exchange 1300 for vehicle operation of FIGS. 12A and 12B. In FIGS. 12A and 12B, the vehicle configuration 1200 is shown to include multiple equipped (e.g., V2X-enabled) network devices. The multiple equipped network devices include vehicles (e.g., automobiles) 1202 (HV), 1206 (RV-1), 1208 (RV-2). Also shown are non-equipped network devices including non-equipped vehicle 1204 (RV-3). The vehicle configuration 1200 may include more or fewer equipped network devices and / or more or fewer non-equipped network devices than those illustrated in FIGS. 12A and 12B. In addition, vehicle configuration 1200 may include more or fewer different types of equipped network devices (which may include, for example, equipped UEs) and / or more or fewer different types of unequipped network devices (which may include, for example, unequipped UEs) than those shown in Figures 12A and 12B. In addition, the equipped network devices may be equipped with disparate capabilities, which may include, but are not limited to, C-V2X / DSRC capabilities, 4G / 5G cellular connectivity, GPS capabilities, camera capabilities, radar capabilities, and / or LIDAR capabilities.

[0136] In one or more examples, the equipment network devices (e.g., vehicles 1202, 1206, 1208) may be capable of performing V2X communications. At least some of the equipment network devices (e.g., vehicles 1202, 1206, 1208) may be capable of transmitting and receiving sensing signals for radar (e.g., RF sensing signals) and / or LIDAR (e.g., optical sensing signals) to detect nearby vehicles and / or objects. In one or more examples, the vehicles 1202, 1206, 1208 may be capable of transmitting and receiving certain sensing signals (e.g., camera sensing signals, radar sensing signals, and / or LIDAR sensing signals). Some of the equipment network devices (e.g., vehicles 1202, 1206, 1208) may have higher capability sensors (e.g., GPS receivers, cameras, RF antennas, and / or optical lasers and / or optical sensors) than other equipment network devices (e.g., vehicles 1202, 1206, 1208).

[0137] During operation, the equipment network devices (e.g., vehicles 1202, 1206, 1208) may transmit and / or receive sensing signals (e.g., RF and / or optical signals) to sense and detect vehicles (e.g., vehicles 1202, 1204, 1206, 1208) and / or objects (not shown in FIGS. 12A and 12B) located in and around the roadway. The equipment network devices (e.g., vehicles 1202, 1206, 1208) may use the sensing signals to determine characteristics (e.g., movement, size, type, direction of travel, and speed) of the detected vehicles and / or objects.

[0138] In one or more examples, an equipment network device (e.g., vehicle 1202, 1206, 1208) may generate at least one vehicle-based message (e.g., SDSM, BSM, CAM, CPM, etc.) that includes information regarding characteristics of the detected vehicle and / or object. The vehicle-based message may include a specific use case or safety alert (e.g., DNPW or FCW) related to the current state and environment of the equipment network device (e.g., vehicle 1202, 1206, 1208). The vehicle-based message may be in the form of a standard BSM, CAM, CPM, SDSM (e.g., SAE J3224 SDSM), and / or other format.

[0139] 12A and 12B, vehicle configuration 1200 illustrates an example lane change scenario in which vehicle 1202 (HV) wishes to change lanes. Specifically, in FIG. 12A, vehicles 1202, 1204, 1206, and 1208 are all shown traveling in the same direction on a highway. Vehicles 1202 (HV) and 1204 (RV-3) are traveling in the same lane as each other, with vehicle 1202 traveling behind vehicle 1204. And vehicles 1206 (RV-1) and 1208 (RV-2) are traveling in the same lane as each other, with vehicle 1206 traveling behind vehicle 1208. Vehicle 1202 wishes to change lanes to move into the space between vehicles 1206 and 1208. Thus, vehicle 1202 (or the driver of the vehicle) desires to perform a lane change maneuver to move into the space between vehicles 1206 and 1208.

[0140] In one or more examples, vehicle 1202 may use a set of MSCMs to coordinate lane change maneuvers with vehicles 1206 and 1208. The use of MSCMs allows for coordination and sharing of maneuver intent between vehicles for better road coordination. Vehicles (e.g., vehicles 1202, 1206, 1208) affected by a potential maneuver (e.g., lane change) may participate in a handshake session using MSCMs to coordinate maneuvers. The handshake session between vehicles to coordinate maneuvers relies on the exchange of MSCMs and a communication protocol (e.g., basic protocol 1500 of FIG. 15 and emergency protocol 1600 of FIG. 16).

[0141] During operation of employing the MSCM to perform the lane change maneuver of Figures 12A and 12B, vehicle 1202 (HV) may send an intent operation message (e.g., Msg_Intention: lane change request) to vehicles 1206 (RV-1) and 1208 (RV-2) (e.g., shown as signals 1310a, 1310b in Figure 13) to notify vehicles 1206, 1208 of vehicle 1202's intent and request to change lanes and move to a position between vehicles 1206 and 1208. In response, vehicles 1206, 1208 may send a response operation message (e.g., Msg_Response:Land Change Accepted) to vehicle 1202 (e.g., shown as signals 1320a, 1320b in FIG. 13 ) to indicate to vehicle 1202 that they acknowledge and accept vehicle 1202's intention and request to change lanes, and will assist vehicle 1202 with the requested lane change maneuver.

[0142] After receiving the response operation messages (e.g., Msg_Response: Land Change Acceptance) from the vehicles 1206, 1208, the vehicle 1202 may send a confirmation operation message (Msg_Confirmation: Operation Decision) to the vehicles 1206, 1208 to confirm that the vehicle 1202 received their response operation messages (e.g., Msg_Response: Land Change Acceptance) and intends to perform a lane change operation (e.g., shown as signals 1330a, 1330b in FIG. 13 ). The vehicle 1202 may then proceed to perform a lane change operation. After the vehicle 1202 performs a lane change operation, the vehicle 1202 may optionally send a completion operation message (e.g., Msg_Completion) to the vehicles 1206, 1208 to indicate to the vehicles 1206, 1208 that the vehicle 1202 has completed the lane change operation (e.g., shown as signals 1340a, 1340b). It should be noted that this is one example of a series of MSCMs that may be utilized by vehicle 1202 (HV) to coordinate a lane change maneuver, and that more or fewer MSCMs, and / or other MSCMs may be employed to perform the maneuver.

[0143] Figure 14 is a diagram of an example MSCM 1400. Specifically, the MSCM 1400 of Figure 14 is shown as an MSCM format defined by Abstract Syntax Notation One (ASN.1), which is a standard interface description language for defining data structures that can be serialized / deserialized across platforms. In Figure 14, the MSCM 1400 is shown to include multiple fields, which may include, but are not limited to, a message (Msg) timestamp 1402, a HV three-dimensional (3D) position 1404, a position precision 1406, an MSCM type 1408, a source ID 1410, a destination ID 1412, an operation ID 1414, an operation 1416, a reason code 1418, and an operation execution status 1420. In one or more examples, some of the fields of MSCM 1400 may be optional, such as destination ID 1412, operation ID 1414, operation 1416, reason code 1418, and operation execution status 1420. In some examples, the field for operation 1416 may include subfields, which may include, but are not limited to, operation type 1422 and multiple sub-operations 1424a, 1424b.

[0144] As previously mentioned, the MSCM type 1408 of the MSCM 1400 indicates a particular type of the MSCM 1400. The particular type of the MSCM may include, but is not limited to, an intent operation message, a request operation message, a response operation message, a reservation operation message, an HV cancel operation message, an RV cancel operation message, and an execution status operation message.

[0145] In one or more examples, with respect to the source ID 1410 of the MSCM 1400, the source ID of the last BSM sent by the source (e.g., a vehicle, such as an HV, that generates and transmits the MSCM 1400) may be adopted for the source ID 1410 of the MSCM 1400. In some examples, the source ID 1410 of the MSCM 1400 may be associated with the digital certificate of the source (e.g., a digital certificate of the vehicle that generates and transmits the MSCM 1400). In these examples, the encoded digital certificate of the source may be hashed (e.g., utilizing a hash algorithm or a fuzzy hash algorithm) to generate a hash code of the certificate. The hash code of the certificate may be used for the source ID 1410 of the MSCM 1400. It should be noted that as a privacy mechanism, the source ID 1410 may change periodically over time.

[0146] As previously discussed, a maneuver 1416 in MSCM 1400 may include a maneuver type 1422 and multiple sub-maneuvers 1424a, 1424b. The maneuver type 1422 may indicate a particular type of maneuver (e.g., an overtaking maneuver, a merging maneuver, a lane change maneuver, etc.). The maneuver may be divided into multiple sub-maneuvers, and each sub-maneuver (e.g., sub-maneuver 1424a, 1424b) may indicate a particular movement among multiple movements (which may be performed by one or more vehicles, for example) required to accomplish the maneuver.

[0147] The maneuver ID 1414, as described above, is similar to a session ID and is used to specifically identify a particular maneuver (e.g., an overtaking maneuver, a merging maneuver, or a lane change maneuver). The maneuver ID 1414 allows the vehicle to track updates to that particular maneuver. The maneuver ID 1414 should be unique to avoid any possible maneuver ID collisions (e.g., collisions that occur when two or more maneuvers have the same maneuver ID) that may lead to the cancellation of a maneuver. Currently, there are no available solutions for generating unique maneuver IDs or for detecting attacks related to conflicting maneuver IDs that may lead to the cancellation of multiple maneuvers. The disclosed systems and techniques provide a unique maneuver ID for each maneuver (e.g., process 1700 of FIG. 17) and provide fraud detection and reporting (MBDS) for maneuver ID collisions (e.g., process 1800 of FIG. 18).

[0148] FIG. 15 is a diagram of an example base protocol 1500 that may be employed for MSCM. The base protocol 1500 may include a number of different message types that may be utilized in a handshake manner between a source (e.g., HV) and a recipient (e.g., RV) desiring a maneuver during normal operating conditions (e.g., non-emergency situations) by a normal vehicle (e.g., non-emergency vehicle). In FIG. 15, the base protocol 1500 is shown to include a number of different MSCM types (e.g., MSCM type 1408 of FIG. 14) utilized to coordinate a maneuver (e.g., an overtaking maneuver, a merging maneuver, or a lane change maneuver). Specific types of MSCM may include, but are not limited to, operation intent (e.g., MSCM type 0) 1510, operation request (e.g., MSCM type 1) 1511, operation response (e.g., MSCM type 2) 1512, operation reservation (e.g., MSCM type 3) 1513, HV operation cancel (e.g., MSCM type 4) 1514, RV operation cancel (e.g., MSCM type 5) 1515, and operation execution status (e.g., MSCM type 7) 1517. In one or more examples, operation intent (e.g., MSCM type 0) 1510 may be optional for the basic protocol 1500. In these examples, the source (e.g., HV) may initiate the protocol with an operation request (e.g., MSCM type 1) 1511.

[0149] It should be noted that some of the MSCM types of the base protocol 1500 may be specified for the source (e.g., HV) that desires and intends the operation, and other MSCM types may be specified for the recipient (e.g., RV). For example, operation intent (e.g., MSCM type 0) 1510, operation request (e.g., MSCM type 1) 1511, operation reservation (e.g., MSCM type 3) 1513, HV operation cancel (e.g., MSCM type 4) 1514, and operation execution status (e.g., MSCM type 7) 1517 may be specified for the source. Operation response (e.g., MSCM type 2) 1512 and RV operation cancel (e.g., MSCM type 5) 1515 may be specified for the recipient.

[0150] FIG. 16 is a diagram of an example emergency protocol 1600 that may be employed for MSCM. The emergency protocol 1600 may include a number of different message types that may be utilized in a handshake manner between a source (e.g., HV) and a recipient (e.g., RV) during an emergency condition by an emergency vehicle (e.g., police). In FIG. 16, the emergency protocol 1600 is shown to include a number of different MSCM types (e.g., MSCM type 1408 of FIG. 14) utilized to coordinate operations. The specific types of MSCM may include, but are not limited to, operation intent (e.g., MSCM type 0) 1610, emergency operation reservation (e.g., MSCM type 6) 1616, HV operation cancellation (e.g., MSCM type 4) 1614, RV operation cancellation (e.g., MSCM type 5) 1615, and operation execution status (e.g., MSCM type 7) 1617.

[0151] Some of the MSCM types of the emergency protocol 1600 may be specified for the source (e.g., HV) and other MSCM types may be specified for the recipient (e.g., RV). For example, operation intent (e.g., MSCM type 0) 1610, emergency operation reservation (e.g., MSCM type 6) 1616, HV operation cancel (e.g., MSCM type 4) 1614, and operation execution status (e.g., MSCM type 7) 1617 may be specified for the source. RV operation cancel (e.g., MSCM type 5) 1615 may be specified for the recipient.

[0152] There may be several circumstances under which an operation negotiation utilizing either the base protocol 1500 or the emergency protocol 1600 may be aborted (e.g., HV operation cancellation (e.g., MSCM type 4) 1514, 1614, and remote vehicle (RV) operation cancellation (e.g., MSCM type 5) 1515, 1615 of FIGS. 15 and 16). Some circumstances under which an operation negotiation may be aborted include, but are not limited to, absence of response within a certain predetermined time, a fraud attack (e.g., an attacker spoofing the source ID of an operation for an operation session), a malfunctioning device (e.g., a malfunctioning vehicle component) that prevents the operation from occurring, and non-compliance with the sequence outlined in the protocol (e.g., the base protocol 1500 of FIG. 15, or the emergency protocol 1600 of FIG. 16).

[0153] 17 is a flow diagram illustrating an example of a process 1700 for generating a unique operation ID for a communication (e.g., a V2X communication). The process 1700 includes generating a unique operation ID based on a predecessor message transmitted before the operation message (e.g., an MSCM message). The process 1700 may involve different approaches, such as a first approach involving transmission of a safety message (e.g., a BSM) used as the predecessor message, and a second approach involving transmission of an operation message of intent (e.g., an MSCM type 0 indicating intent to perform a potential operation) used as the predecessor message. In one or more examples, the process 1700 for generating a unique operation ID may conform to the SAE J1386 standard.

[0154] In a first approach for generating a unique operation ID, in block 1710, a safety message (e.g., BSM) may be sent by the source (e.g., HV) before sending an intent operation message (e.g., MSCM type 0) or a request operation message (e.g., MSCM type 1). After the safety message (e.g., BSM) is sent, in block 1720, it may be determined whether an intent message (e.g., MSCM type 0) was sent. Because an intent message (e.g., MSCM type 0) was not sent, in block 1730, the safety message (e.g., BSM) may be hashed (e.g., by utilizing a hash algorithm or a fuzzy hash algorithm) to generate a hashed safety message. Then, in block 1750, the hashed safety message may be inserted into the field for the operation ID 1414 for the subsequently sent request operation message (e.g., MSCM type 1).

[0155] In one or more examples (e.g., for the first approach), the source (e.g., HV) may not transmit an intent manipulation message (e.g., MSCM Type 0). The transmission of an intent manipulation message (e.g., MSCM Type 0) may depend on several factors, including, but not limited to, vehicle settings, driving context (e.g., the need to perform the maneuver quickly), and channel bandwidth.

[0156] In a second approach for generating a unique operation ID, in block 1710, an intent operation message (e.g., MSCM type 0) may be sent by the source (e.g., HV) before sending the request operation message (e.g., MSCM type 1). After the intent operation message (e.g., MSCM type 0) is sent, in block 1720, it may be determined whether the intent message (e.g., MSCM type 0) has been sent. Because the intent operation message (e.g., MSCM type zero) has been sent, in block 1740, the intent operation message (e.g., MSCM type 0) may be hashed (e.g., by utilizing a hashing algorithm or a fuzzy hashing algorithm) to generate a hashed intent operation message. Then, in block 1750, the hashed operation message may be inserted into the field for the operation ID 1414 for the subsequently sent request operation message (e.g., MSCM type 1).

[0157] In one or more examples (e.g., for the second approach), the source (e.g., HV) may not transmit a safety message (e.g., BSM) between the two MSCM sessions. The transmission of a safety message (e.g., BSM) between the two MSCM sessions may depend on several factors, including, but not limited to, the occurrence of an emergency, cancellation of the first MSCM session by the RV, and the need to transmit a BSM.

[0158] FIG. 18 is a flow diagram illustrating an example of a process 1800 for a local misconduct detection and reporting (MBDR) scheme to detect manipulation ID and / or source ID collisions for communications (e.g., V2X communications). As previously mentioned, in some aspects, for MBDS for manipulation ID collisions, misconduct detection may include two processes, including a first process (e.g., process A 1830) for determining whether a newly received manipulation ID matches a locally generated manipulation ID (e.g., by using a hash-based technique described above with respect to FIG. 17) and a second process (e.g., process B 1850) for verifying whether an attacker has spoofed the manipulation source ID of the manipulation session. In some cases, the first process (e.g., process A) may include verifying that the manipulation ID was generated by a particular source ID (e.g., generated by a vehicle associated with the manipulation source ID). If misconduct is detected (e.g., for either or both of the processes), a misconduct report including specific details of the detected misconduct may be generated and sent (e.g., transmitted) to nearby vehicles, servers, and / or other systems or devices. In one or more examples, the process 1800 for local MBDR schemes for operation and / or source ID collisions may comply with the European Telecommunications Standards (ETSI) Technical Specification (TS) 103 759 standard or other standards.

[0159] It should be noted that an attacker may launch an attack using a clashing operation ID. For example, an attacker may be able to spoof the operation ID by predicting the operation ID. In such an example, the attacker may know that the next operation ID will be an increment of the previously used operation ID sent by the source (e.g., HV). The attacker may then start the next operation session before the source (e.g., HV) with an operation ID of, for example, 2. The source (e.g., HV) may then start the next operation with the same operation ID, for example with a value of 2. Since both operation IDs contain a value of 2 for the operation, the asynchronous message exchange will cause the cancellation of both operations. The attacker may then repeat the same procedure, but this time using the next operation ID, for example with a value of 3, which again cancels both new operations. The source (e.g., HV) that is the victim of the attack may then be falsely reported as the cheating vehicle (e.g., attacker).

[0160] In process 1800 of Figure 18, multiple MSCMs are collected at block 1810. The multiple MSCMs may or may not include the same source ID 1410. At block 1820, process 1800 includes determining whether any of the collected MSCMs have a new operation ID 1414 (e.g., whether any of the collected MSCMs have a different operation ID than other collected MSCMs).

[0161] If it is determined that at least one of the collected MSCMs has a new operation ID 1414, the process 1800 proceeds to process A 1830. In process A 1830, for each MSCM having a particular type (e.g., MSCM type 1408 of 1), the operation ID 1414 (and in some cases, source ID 1410) is collected. Then, the last transmitted secure message (e.g., BSM) and / or the previously transmitted MSCM (e.g., having MSCM type 1408 of zero (0)) is obtained / checked. Then, the last transmitted secure message (e.g., BSM) and / or the previously transmitted MSCM (e.g., having MSCM type 1408 of 0) is hashed to generate a hashed message (e.g., having a hash code). For example, the process 1800 may utilize a hash algorithm or a fuzzy hash algorithm to generate the hashed message (e.g., having a hash code). The generated hashed message (e.g., hash code) may then be compared to the operation ID of the corresponding MSCM (e.g., having an MSCM type 1408 of 1). Because the operation ID of the corresponding MSCM is also generated using the same hash algorithm of the same preceding message (e.g., a safety message such as a BSM and / or a previously sent MSCM such as an MSCM type 1408 of 0), in the absence of fraudulent activity or errors, the operation IDs should match.

[0162] After process A 1830 is executed, in block 1860, it may be determined whether there is a match between the hash code calculated during process A 1830 and the operation ID of the corresponding MSCM having an MSCM type 1408 of 1. If it is determined that there is a match, in block 1880, process 1800 will simply go idle (e.g., by performing normal operation protocol operations such as those described with respect to FIG. 15 or FIG. 16). However, if it is determined that there is no match, in block 1870, a misconduct report may be generated and sent (e.g., transmitted) to a network, such as a backend server, one or more other vehicles, and / or other devices or systems.

[0163] However, if it is determined in block 1840 that none of the collected MSCMs have a new operation ID 1414 for the collected MSCM with the same source ID 1410 obtained in block 1810, then multiple MSCMs with the same operation ID 1414 are collected. After multiple MSCMs with the same operation ID 1414 are collected, process 1800 proceeds to process B 1850. In process B 1850, for multiple MSCMs with the same operation ID 1414, process 1800 may determine whether the source IDs of the multiple MSCMs match. In some cases, process 1800 may include obtaining or collecting MSCMs with MSCM types 1408 of 1, 3, and 4. Then, the source IDs 1410 of all collected MSCMs with MSCM types 1408 of 1, 2, 3, 4, and 7 may be compared to each other.

[0164] After process B 1850 is executed, in block 1860, it may be determined whether there is a match between all of the source IDs 1410 of all of the collected MSCMs having MSCM types 1408 of 1, 2, 3, 4, and 7. If it is determined that there is a match (e.g., all of the source IDs 1410 are the same), then in block 1880, the process 1800 will become idle (e.g., perform normal operational protocol operations as described with respect to FIG. 15 or 16). However, if it is determined that the source ID of one MSCM is different from the source ID of another MSCM and therefore does not match (e.g., at least one of the source IDs 1410 is different), then in block 1870, a misconduct report is generated (e.g., generated for the MSCMs having different source IDs 1410) and sent (e.g., transmitted) to the network (e.g., a back-end server) and / or to other vehicles.

[0165] In one or more examples, the generated abuse report may include an indication of the type of attack detected (e.g., the conflicting operation ID 1414) and / or an identification of the conflicting MSCM.

[0166] In one or more examples, a number of different types of hash algorithms may be employed for the hashing performed in process 1700 of Figure 17 and process 1800 of Figure 18. The different types of hash algorithms that may be employed may include, but are not limited to, a SHA-256 algorithm, a Merkle-Damgard algorithm, an MD5 algorithm, a SHA-1 algorithm, a SHA-2 algorithm, a RIPEMD-160 algorithm, a Whirlpool algorithm, and a BLAKE 2 algorithm.

[0167] 19 is a flow diagram illustrating an example of a process 1900 for wireless communication in a vehicle (e.g., by the vehicle or by a component or system of the vehicle, e.g., a chipset, a communication system of the vehicle, such as communication system 558 of FIG. 5, a control system of the vehicle, such as control system 552 of FIG. 5, any combination thereof, or other components or systems of the vehicle). The process 1900 can securely manage an operating ID for communications (e.g., V2X communications) in accordance with certain aspects of the disclosure. In some aspects, the vehicle is configured to communicate using a V2X protocol.

[0168] In block 1910, the vehicle (or a component or system thereof) may transmit a message associated with a potential operation by the vehicle. In some cases, the message is a safety message, such as a BSM, as described with respect to FIG. 17. In some cases, the message is an operational message, such as an MSCM. In one exemplary embodiment, the message is an MSCM (e.g., a type 0 MSCM), as shown in FIG. 15 and described with respect to FIG. 17, indicating an intent to perform the potential operation.

[0169] In block 1920, the vehicle (or a component or system thereof) may determine a manipulation identification (ID) for the potential manipulation based on the message. In some aspects, to determine a manipulation ID for the potential manipulation based on the message, the vehicle (or a component or system thereof) may apply a hash algorithm to the message to generate a hashed message, where the manipulation ID includes the hashed message. As discussed herein, different types of hash algorithms may be used. Examples of hash algorithms that may be used may include, but are not limited to, a SHA-256 algorithm, a Merkle-Damgard algorithm, an MD5 algorithm, a SHA-1 algorithm, a SHA-2 algorithm, a RIPEMD-160 algorithm, a Whirlpool algorithm, a BLAKE 2 algorithm, any combination thereof, or other hash algorithms.

[0170] In block 1930, the vehicle (or a component or system thereof) may transmit a first operation message for the potential operation. The first operation message includes an operation ID (e.g., operation ID 1414 in an operation ID field of MSCM 1400 of FIG. 14). In some aspects, the first operation message is an MSCM. In one exemplary embodiment, the message is an MSCM (e.g., a Type 1 MSCM) indicating a request to perform the potential operation, such as shown in FIG. 15 and described with respect to FIG. 17.

[0171] 20 is a flow diagram illustrating an example of a process 1900 for wireless communication in a first vehicle (e.g., by the first vehicle or by a component or system of the first vehicle, e.g., a chipset, a communication system of the vehicle, such as communication system 558 of FIG. 5, a control system of the vehicle, such as control system 552 of FIG. 5, any combination thereof, or other components or systems of the vehicle). The process 2000 can securely manage an operating identity for communication (e.g., V2X communication) in accordance with certain aspects of the disclosure. In some aspects, the first vehicle is configured to communicate using a V2X protocol.

[0172] In block 2010, the first vehicle (or a component or system thereof) may receive a first operation message from the second vehicle. The first operation message includes a first operation ID.

[0173] In block 2020 (e.g., as shown in block 1820 of FIG. 18 ), the first vehicle (or a component or system thereof) may determine that the first operation ID of the first operational message is a new operation ID. For example, the first vehicle (or a component or system thereof) may determine whether the first operational message has a different operation ID than any other message (e.g., MSCM) received or collected.

[0174] In block 2030, the first vehicle (or a component or system thereof) may determine, based on the first operation ID being a new operation ID, whether the first operation ID matches a second operation ID determined based on a previously received message (e.g., as shown in blocks 1830 and 1860 of FIG. 18). For example, in some aspects, the first vehicle (or a component or system thereof) may apply a hash algorithm to the previously received message to generate a hashed message, where the second operation ID includes the hashed message (e.g., the second operation ID is the hashed message). The first vehicle (or a component or system thereof) may then compare the second operation ID to the first operation ID to determine whether the first operation ID and the second operation ID match. As mentioned above, any hash algorithm may be used, such as using the SHA-256 algorithm, the Merkle-Damgard algorithm, the MD5 algorithm, the SHA-1 algorithm, the SHA-2 algorithm, the RIPEMD-160 algorithm, the Whirlpool algorithm, the BLAKE 2 algorithm, any combination thereof, or other hash algorithms. In some aspects, the first manipulation message is a first MSCM and the previously received message is a second MSCM. In some cases, the second MSCM indicates an intent to perform a potential manipulation, such as an MCSM message having a type 0. In some cases, the first manipulation message is an MSCM and the previously received message is a secure message, such as a BSM.

[0175] In one example, the first vehicle (or a component or system thereof) may determine that the first operation ID is different from the second operation ID. The first vehicle (or a component or system thereof) may send a misconduct report to at least one of a backend server or one or more other vehicles (e.g., as shown in block 1870 of FIG. 18 ) based on determining that the first operation ID is different from the second operation ID. In some aspects, the misconduct report includes a type of attack, a collision operation message detected from the operation message, a type of attack and a collision operation message, and / or other information.

[0176] In another example, the first vehicle (or a component or system thereof) may determine that the first operation ID is the same as or matches the second operation ID. The first vehicle (or a component or system thereof) may remain in an idle state (e.g., as shown in block 1880 of FIG. 18 , e.g., by performing normal operation protocol operations such as those described with respect to FIG. 15 or FIG. 16 ) based on determining that the first operation ID is the same as or matches the second operation ID.

[0177] 21 is a flow diagram illustrating an example of a process 2100 for wireless communication in a vehicle (e.g., by the vehicle or by a component or system of the vehicle, e.g., a chipset, a communication system of the vehicle, such as communication system 558 of FIG. 5, a control system of the vehicle, such as control system 552 of FIG. 5, any combination thereof, or other components or systems of the vehicle). The process 2100 can securely manage an operating ID for communication (e.g., V2X communication) in accordance with certain aspects of the disclosure. In some aspects, the first vehicle is configured to communicate using a V2X protocol.

[0178] In block 2110, the vehicle (or a component or system thereof) may receive a plurality of operation messages from one or more vehicles (e.g., as shown in block 1810 of FIG. 18). The plurality of operation messages include the same operation identification (ID) and one or more source IDs (e.g., each operation message of the plurality of operation messages has the same operation ID and has the same or different source IDs). In some aspects, the plurality of operation messages includes a plurality of MSCMs. In some aspects, the plurality of operation messages may include one or more of an operation message indicating a request to perform an operation (e.g., a Type 1 MSCM), an operation message indicating a reservation to perform an operation (e.g., a Type 3 MSCM), or an operation message indicating the host vehicle cancels the performance of the operation (e.g., a Type 5 MSCM).

[0179] In block 2120, the vehicle (or a component or system thereof) may determine whether one or more source IDs of the plurality of operational messages match (e.g., as shown in blocks 1850 and 1860 of FIG. 18). In one example, the vehicle (or a component or system thereof) may determine that a source ID of one operational message from the plurality of operational messages is different from at least one other source ID of at least one other operational message from the plurality of operational messages. The vehicle (or a component or system thereof) may send a misconduct report to a backend server or at least one of the one or more other vehicles (e.g., as shown in block 1870 of FIG. 18) based on determining that the source ID of the operational message is different from at least one other source ID of the at least one other operational message. In some aspects, the misconduct report includes a type of attack, a collision operational message detected from the operational messages, a type of attack and a collision operational message, and / or other information.

[0180] In another example, the first vehicle (or a component or system thereof) may determine that the source IDs of the multiple operational messages are the same or match. The first vehicle (or a component or system thereof) may remain in an idle state (e.g., as shown in block 1880 of FIG. 18 , for example, by performing normal operational protocol operations, such as those described with respect to FIG. 15 or FIG. 16 ) based on determining that the source IDs of the multiple operational messages are the same or match.

[0181] In some aspects, the vehicle (or a component or system thereof) may determine that at least one operation ID of an operation message from the plurality of operation messages is a new operation ID (e.g., as shown in block 1820 of FIG. 18 ). For example, the first vehicle (or a component or system thereof) may determine whether the operation message has an operation ID that is different from any other message (e.g., MSCM) received or collected. The vehicle (or a component or system thereof) may determine whether one or more source IDs of the plurality of operation messages match based on the at least one operation ID being a new operation ID (e.g., perform the operation of block 1830 of FIG. 18 based on determining in block 1820 that the operation ID is new).

[0182] 22 is a diagram 2200 illustrating an example of a hardware implementation of a device 2202. The device 2202 is a UE and includes a cellular baseband processor 2204 (also called a modem) coupled to a cellular RF transceiver 2222 and one or more subscriber identity modules (SIM) cards 2220, an application processor 2206 coupled to a secure digital (SD) card 2208 and a screen 2210, a Bluetooth module 2212, a wireless local area network (WLAN) module 2214, a GNSS module 2216, and a power source 2218. The GNSS module 2216 may include various satellite positioning systems. For example, the GNSS module may be compatible with Global Positioning System (GPS), Global Navigation Satellite System (GLONASS), Galileo, BeiDou Navigation Satellite System (BDS), Wide Area Augmentation System (WAAS), European Geostationary Navigation Overlay Service (EGNOS), GPS Aided GEO Augmented Navigation (GAGAN), Multifunctional Transport Satellite (MTSAT) Satellite Augmentation System (MSAS), Quasi-Zenith Satellite System (QZSS), or Navigation with Indian Constellation (NavIC). The cellular baseband processor 2204 communicates with the UE 104 of FIG. 1 and / or the BS 102 / 180 of FIG.The cellular baseband processor 2204 may include computer readable media / memory. The computer readable media / memory may be non-transitory. The cellular baseband processor 2204 is responsible for general processing, including the execution of software stored on the computer readable media / memory. The software, when executed by the cellular baseband processor 2204, causes the cellular baseband processor 2204 to perform the various functions described above. The computer readable media / memory may also be used to store data that is manipulated by the cellular baseband processor 2204 when executing the software. The cellular baseband processor 2204 further includes a receiving component 2230, a communications manager 2232, and a transmitting component 2234. The communications manager 2232 includes one or more illustrated components, including a detection component 2240 configured to detect one or more objects, and a message component 2242 configured to generate one or more messages (e.g., SDSM, CPM, BSM, etc.). The components in the communications manager 2232 may be stored in a computer readable medium / memory and / or may be configured as hardware in the cellular baseband processor 2204. The cellular baseband processor 2204 may be a component of the UE 350 of FIG. 3A and may include the memory 360 of FIG. 3A and / or at least one of the TX processor 368 of FIG. 3A, the RX processor 356 of FIG. 3A, and the controller / processor 359 of FIG. 3A. In one configuration, the device 2202 may be a modem chip and may include only the baseband processor 2204, while in another configuration, the device 2202 may be an entire UE (e.g., see 350 of FIG. 3A) and may include the additional modules of the device 2202 described above.

[0183] The apparatus may include additional components that perform each of the blocks of the algorithms in the above-described flowcharts of Figures 17, 18, and / or 19. Thus, each block in the above-described flowcharts of Figures 17, 18, and / or 19 may be performed by one component, and the apparatus may include one or more of those components. The components may be one or more hardware components specially configured to perform the described process / algorithm, may be implemented by a processor configured to perform the described process / algorithm, may be stored in a computer-readable medium for implementation by a processor, or some combination thereof.

[0184] In one configuration, the apparatus 2202, particularly the cellular baseband processor 2204, includes means for receiving a message from a first wireless device indicating a threat entity within a threat zone. The threat entity transmits data that interferes with the transmission of the BSM. The apparatus includes means for determining, based at least in part on the message from the first wireless device indicating information about the threat entity, which of the set of candidate resources should be used for transmitting the BSM. The apparatus includes means for transmitting the BSM to at least a third wireless device on the determined candidate resources. The apparatus further includes means for eliminating one or more candidate resources from the set of candidate resources based on a predicted RSRP for each candidate resource in the set of candidate resources exceeding an RSRP threshold to determine a first subset of candidate resources. The apparatus further includes means for ranking the first subset of candidate resources based on a weighted RSSI ranking to obtain a second subset of candidate resources with the lowest weighted RSSI. The second subset of candidate resources is a portion of the first subset of candidate resources. The apparatus further includes a means for selecting a candidate resource from a second subset of candidate resources. The apparatus further includes a means for filtering out one or more substantially sensed candidate resources in the set of candidate resources with RSSI exceeding the pre-filter threshold to obtain a filtered subset of candidate resources that do not exceed the pre-filter threshold. The apparatus further includes a means for filtering out candidate resources in the filtered subset of candidate resources that exceed the RSRP threshold but do not exceed the pre-filter threshold to obtain a second subset of candidate resources that do not exceed the RSRP threshold. The apparatus further includes a means for selecting a candidate resource from the second subset of candidate resources. The above-mentioned means may be one or more of the above-mentioned components of the apparatus 2202 configured to perform the functions recited by the above-mentioned means.

[0185] Although specific details have been given in the above description to provide a thorough understanding of the aspects and examples provided herein, those skilled in the art will appreciate that the present application is not limited thereto. Thus, although illustrative examples of the present application have been described in detail herein, it should be understood that the inventive concept may be embodied and employed in various other ways, and that the appended claims are intended to be construed to include such variations, except as limited by the prior art. The various features and aspects of the present application described above may be used individually or jointly. Moreover, the examples may be used in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of the present specification. Thus, the present specification and drawings should be regarded as illustrative and not restrictive. For illustrative purposes, the methods have been described in a particular order. It should be understood that in alternative examples, the methods may be performed in an order different from that described.

[0186] For clarity of explanation, in some instances, the technology may be presented as including individual functional blocks including devices, device components, and steps or routines in methods embodied in software or a combination of hardware and software. Additional components other than those shown in the figures and / or described herein may be used. For example, circuits, systems, networks, processes, or other components may be shown as components in block diagram form so as not to obscure the examples with unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail so as to avoid obscuring the examples.

[0187] Moreover, those skilled in the art will appreciate that the various exemplary logic blocks, modules, circuits, and algorithm steps described in connection with the aspects disclosed herein may be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability of hardware and software, various exemplary components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the particular application and design constraints imposed on the overall system. Those skilled in the art may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

[0188] Individual embodiments may be described above as a process or method that is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although the flowcharts may describe operations as a sequential process, many of the operations may be performed in parallel or simultaneously. In addition, the order of operations may be rearranged. A process terminates when its operations are completed, but may have additional steps not included in the diagrams. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination may correspond to a return of the function to the calling function or to the main function.

[0189] The processes and methods according to the examples described above may be implemented using computer executable instructions stored on or otherwise available from a computer readable medium. Such instructions may include, for example, instructions and data that cause or configure a general purpose computer, a special purpose computer, or a processing device to perform a particular function or group of functions. Portions of the computer resources used may be accessible over a network. The computer executable instructions may be, for example, binary, intermediate format instructions such as assembly language, firmware, source code, etc. Examples of computer readable media that may be used to store instructions, information used, and / or information created during the methods according to the described examples include magnetic or optical disks, flash memory, USB devices provided with non-volatile memory, network attached storage devices, etc.

[0190] Examples of non-transitory media may include, but are not limited to, magnetic disks or tapes, optical storage media such as compact disks (CDs) or digital versatile disks (DVDs), flash memory, memories, or memory devices. A computer-readable medium may have code and / or machine-executable instructions stored thereon, which may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and / or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means, including memory sharing, message passing, token passing, network transmission, etc. In some examples, computer-readable storage devices, media, and memories may include cable or wireless signals including bit streams, etc. However, when mentioned, non-transitory computer-readable storage media specifically excludes media such as energy, carrier signals, electromagnetic waves, and the signals themselves.

[0191] Those skilled in the art will appreciate that information and signals may be represented using any of a variety of different technologies and techniques. For example, the data, instructions, commands, information, signals, bits, symbols, and chips that may be referred to throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof, depending in part on the particular application, desired design, corresponding technology, etc.

[0192] The various example logical blocks, modules, and circuits described in connection with the aspects disclosed herein may be implemented or performed in hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof, and may take any of a variety of form factors. When implemented in software, firmware, middleware, or microcode, the program code or code segments (e.g., computer program product) performing the necessary tasks may be stored in a computer-readable or machine-readable medium. A processor or processors may perform the necessary tasks. Examples of form factors include laptops, smartphones, mobile phones, tablet devices or other small form factor personal computers, personal digital assistants, rack-mounted devices, standalone devices, and the like. The functionality described herein may also be embodied in a peripheral device or an add-in card. Such functionality may also be implemented on a circuit board among different chips, or on different processes executing in a single device, as further examples.

[0193] The instructions, media for propagating such instructions, computing resources for executing such instructions, and other structures supporting such computing resources are exemplary means for providing the functionality described in this disclosure.

[0194] The techniques described herein may also be implemented in electronic hardware, computer software, firmware, or any combination thereof. Such techniques may be implemented in any of a variety of devices, such as a general purpose computer, a wireless communication device handset, or an integrated circuit device having multiple uses, including applications in wireless communication device handsets and other devices. Any features described as modules or components may be implemented together in an integrated logic device, or separately as separate but interoperable logic devices. If implemented in software, these techniques may be realized at least in part by a computer-readable data storage medium that includes program code that includes instructions that, when executed, perform one or more of the methods, algorithms, and / or operations described above. The computer-readable data storage medium may form part of a computer program product, which may include packaging materials. The computer-readable medium may comprise memory or data storage media, such as random access memory (RAM), such as synchronous dynamic random access memory (SDRAM), read only memory (ROM), non-volatile random access memory (NVRAM), electrically erasable programmable read only memory (EEPROM), FLASH memory, magnetic or optical data storage media, etc. The techniques may additionally or alternatively be realized at least in part by a computer-readable communications medium, such as a propagated signal or wave, that carries or communicates program code in the form of instructions or data structures and that can be accessed, read, and / or executed by a computer.

[0195] The program code may be executed by a processor, which may include one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Such a processor may be configured to perform any of the techniques described in this disclosure. A general-purpose processor may be a microprocessor, but alternatively, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Thus, the term "processor" as used herein may refer to any of the above structures, any combination of the above structures, or any other structure or apparatus suitable for implementing the techniques described herein.

[0196] Those skilled in the art will understand that the less than ("<") and greater than (">") symbols or terminology used herein may be replaced with the less than or equal to ("≦") and greater than or equal to ("≧") symbols, respectively, without departing from the scope of the present specification.

[0197] When a component is described as being "configured to" perform a certain operation, such configuration may be achieved, for example, by designing electronic circuitry or other hardware to perform the operation, by programming a programmable electronic circuitry (e.g., a microprocessor or other suitable electronic circuitry) to perform the operation, or any combination thereof.

[0198] The phrase "coupled to" refers to any component that is physically connected, either directly or indirectly, to another component and / or that is in communication, either directly or indirectly, with another component (e.g., connected to the other component via a wired or wireless connection and / or other suitable communication interface).

[0199] Claim language or other language reciting "at least one of" a set and / or "one or more" of a set indicates that one member of the set or multiple members of the set (in any combination) satisfy the claim. For example, a claim language reciting "at least one of A and B" or "at least one of A or B" means A, B, or A and B. In another example, a claim language reciting "at least one of A, B, and C" or "at least one of A, B, or C" means A, B, C, or A and B, or A and C, or B and C, or A and B and C. The language "at least one of" a set and / or "one or more" of a set does not limit the set to the items listed in the set. For example, a claim language reciting "at least one of A and B" or "at least one of A or B" can mean A, B, or A and B, and can additionally include items not listed in the set of A and B.

[0200] Exemplary aspects of the present disclosure include the following.

[0201] Aspect 1: A method for wireless communication in a vehicle, the method including: transmitting at the vehicle a message associated with a potential operation by the vehicle; determining at the vehicle an operation identification (ID) for the potential operation based on the message; and transmitting at the vehicle a first operation message for the potential operation including the operation ID.

[0202] Embodiment 2: The method of embodiment 1, wherein the message is a safety message.

[0203] Aspect 3: The method of aspect 2, wherein the safety message is a basic safety message (BSM).

[0204] Aspect 4: The method of aspect 1, wherein the message is a second operation message indicating an intention to perform the potential operation.

[0205] Aspect 5: The method of aspect 4, wherein the second operation message is a Operation Shared Coordination Message (MSCM).

[0206] Aspect 6: A method according to any one of aspects 1 to 5, wherein the first operation message is an operation sharing coordination message (MSCM) indicating a request to execute the potential operation.

[0207] Aspect 7: The method of any of aspects 1-6, wherein the vehicle is configured to communicate using a Vehicle-to-Everything (V2X) protocol.

[0208] Aspect 8: The method of any of aspects 1-7, wherein determining an operation ID for a potential operation based on a message, including a hashed message, includes applying a hash algorithm to the message to generate the hashed message.

[0209] Aspect 9: A method for wireless communication in a first vehicle, the method including: receiving a first operation message at the first vehicle from a second vehicle, the first operation message including a first operation identification (ID); determining at the first vehicle that the first operation ID of the first operation message is a new operation ID; and determining at the first vehicle whether the first operation ID matches a second operation ID determined based on a previously received message based on the first operation ID being a new operation ID.

[0210] Aspect 10: The method of aspect 9, wherein determining whether the first operation ID matches the second operation ID includes applying a hash algorithm to the previously received message to generate a hashed message that includes the second operation ID, and comparing the second operation ID to the first operation ID.

[0211] Aspect 11: A method as described in any of aspects 9 or 10, further comprising: determining in the first vehicle that the first operation ID is different from the second operation ID; and, based on determining that the first operation ID is different from the second operation ID, sending a misconduct report in the first vehicle to at least one of a backend server or one or more other vehicles.

[0212] Aspect 12: The method of aspect 11, wherein the misbehavior report includes at least one of a type of attack detected from the first operational message or a colliding operational message.

[0213] Aspect 13: The method of any of aspects 9 to 12, wherein the first operation message is a first operation sharing coordination message (MSCM) and the previously received message is a second MSCM.

[0214] Example 14: The method of example 13, wherein the second MSCM indicates an intent to perform the potential operation.

[0215] Aspect 15: The method of any of aspects 9 to 12, wherein the first operational message is a operational sharing coordination message (MSCM) and the previously received message is a safety message.

[0216] Embodiment 16: The method of embodiment 15, wherein the safety message is a basic safety message (BSM).

[0217] Example 17: The method of any of Examples 9-16, wherein the first vehicle is configured to communicate using a Vehicle-to-Everything (V2X) protocol.

[0218] Aspect 18: A method for wireless communication in a vehicle, the method including: receiving at the vehicle a plurality of operational messages from one or more vehicles, the operational messages including the same operational identification information (ID) and one or more source IDs; and determining at the vehicle whether the one or more source IDs of the plurality of operational messages match.

[0219] Aspect 19: The method of aspect 18, further comprising: determining in the vehicle that a source ID of one operational message from the plurality of operational messages is different from at least one other source ID of at least one other operational message from the plurality of operational messages; and sending an irregularity report in the vehicle to at least one of a backend server or one or more other vehicles based on a determination that the source ID of the operational message is different from the at least one other source ID of the at least one other operational message.

[0220] Aspect 20: The method of aspect 19, wherein at least one other operation message from the plurality of operation messages is at least one of an operation message indicating a request to perform the operation, an operation message indicating a reservation to perform the operation, or an operation message indicating that the host vehicle cancels the execution of the operation.

[0221] Aspect 21: The method of any of aspects 19 or 20, wherein the misbehavior report includes at least one of a type of attack detected from the operational message or a colliding operational message.

[0222] Aspect 22: A method described in any of aspects 18 to 21, further comprising: determining, in the vehicle, that at least one operation ID of an operation message from the plurality of operation messages is a new operation ID; and determining, in the vehicle, whether one or more source IDs of the plurality of operation messages match, based on the at least one operation ID being a new operation ID.

[0223] Example 23: The method of any one of examples 18 to 22, wherein the plurality of operational messages includes a plurality of operational shared coordination messages (MSCMs).

[0224] Example 24: The method of any of Examples 18 to 23, wherein the vehicle is configured to communicate using a Vehicle-to-Everything (V2X) protocol.

[0225] Aspect 25: An apparatus for wireless communication comprising: a memory; and one or more processors (e.g., implemented in circuitry) coupled to the memory, wherein the one or more processors are configured to: transmit a message associated with a potential operation by a vehicle, determine a operation identification (ID) for the potential operation based on the message, and transmit a first operation message for the potential operation including the operation ID.

[0226] Example 26: The apparatus of example 25, wherein the message is a safety message.

[0227] Aspect 27: The apparatus described in aspect 26, wherein the safety message is a basic safety message (BSM).

[0228] Example 28: The apparatus of example 25, wherein the message is a second operation message indicating an intention to perform the potential operation.

[0229] Aspect 29: The apparatus of aspect 28, wherein the second operation message is a operation sharing coordination message (MSCM).

[0230] Aspect 30: The apparatus of any of aspects 25 to 29, wherein the first operation message is an operation sharing coordination message (MSCM) indicating a request to execute the potential operation.

[0231] Example 31: The apparatus of any of Examples 25-30, wherein the apparatus is part of a vehicle and the vehicle is configured to communicate using a Vehicle-to-Everything (V2X) protocol.

[0232] Aspect 32: The apparatus of any of aspects 25 to 31, wherein one or more processors are configured to apply a hash algorithm to the message to determine an operation ID for a potential operation based on the message, including a hashed message.

[0233] Aspect 33: An apparatus for wireless communication comprising: a memory; and one or more processors (e.g., implemented in circuitry) coupled to the memory, wherein the one or more processors are configured to receive a first operation message from a vehicle including a first operation identification (ID), determine that the first operation ID of the first operation message is a new operation ID, and determine whether the first operation ID matches a second operation ID determined based on a previously received message based on the first operation ID being a new operation ID.

[0234] Aspect 34: The apparatus of aspect 33, wherein the one or more processors are configured to apply a hash algorithm to the previously received message to generate a hashed message including the second operation ID, and compare the second operation ID to the first operation ID.

[0235] Aspect 35: An apparatus described in any of aspects 33 or 34, wherein the one or more processors are configured to determine that the first operation ID is different from the second operation ID and, based on determining that the first operation ID is different from the second operation ID, send an irregularity report to at least one of a backend server or one or more other vehicles.

[0236] Aspect 36: The apparatus of aspect 35, wherein the misbehavior report includes at least one of a type of attack detected from the first operational message or a colliding operational message.

[0237] Aspect 37: The apparatus of any of aspects 33 to 36, wherein the first operation message is a first operation sharing coordination message (MSCM) and the previously received message is a second MSCM.

[0238] Example 38: The apparatus of example 37, wherein the second MSCM indicates an intent to perform the potential operation.

[0239] Aspect 39: The apparatus of any of aspects 33 to 36, wherein the first operational message is a operational sharing coordination message (MSCM) and the previously received message is a safety message.

[0240] Aspect 40: The apparatus described in aspect 39, wherein the safety message is a basic safety message (BSM).

[0241] Example 41: The apparatus of any of examples 33-40, wherein the apparatus is part of an additional vehicle configured to communicate using a Vehicle-to-Everything (V2X) protocol.

[0242] Aspect 42: An apparatus for wireless communication comprising: a memory; and one or more processors (e.g., implemented in circuitry) coupled to the memory, wherein the one or more processors are configured to: receive a plurality of operational messages from one or more vehicles, the plurality of operational messages including a same operational identification (ID) and one or more source IDs; and determine whether the one or more source IDs of the plurality of operational messages match.

[0243] Aspect 43: The apparatus of aspect 42, wherein the one or more processors are configured to determine that a source ID of one operational message from the plurality of operational messages is different from at least one other source ID of at least one other operational message from the plurality of operational messages, and to send a fraud report to at least one of a backend server or one or more other vehicles based on a determination that the source ID of the operational message is different from the at least one other source ID of the at least one other operational message.

[0244] Aspect 44: The apparatus of aspect 43, wherein at least one other operation message from the plurality of operation messages is at least one of an operation message indicating a request to perform the operation, an operation message indicating a reservation to perform the operation, or an operation message indicating the host vehicle to cancel performance of the operation.

[0245] Aspect 45: The apparatus of any of aspects 43 or 44, wherein the misbehavior report includes at least one of a type of attack detected from the operational message or a colliding operational message.

[0246] Aspect 46: An apparatus described in any of aspects 42 to 45, wherein one or more processors are configured to determine that at least one operation ID of an operation message from the multiple operation messages is a new operation ID, and determine whether one or more source IDs of the multiple operation messages match based on the at least one operation ID being a new operation ID.

[0247] Aspect 47: The apparatus of any of aspects 42 to 46, wherein the multiple operation messages include multiple operation sharing coordination messages (MSCMs).

[0248] Example 48: The apparatus of any of examples 42-47, wherein the apparatus is part of a vehicle and the vehicle is configured to communicate using a Vehicle-to-Everything (V2X) protocol.

[0249] Aspect 49: A non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform the operations recited in any of aspects 1-8.

[0250] Embodiment 50: An apparatus comprising means for performing the operations recited in any one of embodiments 1 to 8.

[0251] Aspect 51: A non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform the operations recited in any of aspects 9-17.

[0252] Embodiment 52: An apparatus comprising means for performing the operations recited in any one of embodiments 9 to 17.

[0253] Aspect 53: A non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform the operations recited in any of aspects 18-24.

[0254] Embodiment 54: An apparatus comprising means for performing the operations recited in any of embodiments 18 to 24.

[0255] Aspect 53: A non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform any of the operations described in aspects 1 to 8, aspects 9 to 17, and / or aspects 18 to 24.

[0256] Embodiment 54. An apparatus comprising means for performing the operations described in any one of embodiments 1 to 8, embodiments 9 to 17, and / or embodiments 18 to 24.

[0257] The foregoing 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 general principles defined herein may be applied to other aspects. Accordingly, the claims are not intended to be limited to the aspects shown herein, but are to be accorded the widest scope consistent with the language of the claims, and references to elements in the singular do not mean "one and only," unless expressly stated otherwise, but rather "one or more."

Claims

1. 1. A method for wireless communication in a vehicle, comprising: transmitting at the vehicle a message associated with a potential operation by the vehicle; determining at the vehicle a manipulation identification (ID) for the potential manipulation based on the message; transmitting at the vehicle a first operation message for the potential operation, the first operation message including the operation ID; The method includes:

2. The method of claim 1 , wherein the message is a safety message.

3. The method of claim 2 , wherein the safety message is a Basic Safety Message (BSM).

4. The method of claim 1 , wherein the message is a second operation message indicating an intent to perform the potential operation.

5. The method of claim 4 , wherein the second operational message is a Maneuver Shared Coordination Message (MSCM).

6. The method of claim 1 , wherein the first operation message is a Operation Share Coordination Message (MSCM) indicating a request to perform the potential operation.

7. 2. The method of claim 1, wherein the vehicles are configured to communicate using a Vehicle-to-Everything (V2X) protocol.

8. 2. The method of claim 1 , wherein determining the operation ID for the potential operation based on a message, the message including a hashed message, comprises applying a hash algorithm to the message to generate the hashed message.

9. 1. A method for wireless communication in a first vehicle, comprising: receiving a first operation message from a second vehicle at the first vehicle, the first operation message including a first operation identification (ID); determining, in the first vehicle, that the first operation ID of the first operation message is a new operation ID; determining, at the first vehicle, whether the first operation ID matches a second operation ID determined based on a previously received message, based on the first operation ID being a new operation ID; A method comprising:

10. determining whether the first operation ID matches the second operation ID; applying a hash algorithm to the previously received message to generate a hashed message including the second operation ID; comparing the second operation ID with the first operation ID; 10. The method of claim 9, comprising:

11. determining at the first vehicle that the first operation ID is different from the second operation ID; sending a misconduct report at the first vehicle to at least one of a backend server or one or more other vehicles based on determining that the first operation ID is different from the second operation ID; The method of claim 9 further comprising:

12. The method of claim 11 , wherein the misconduct report includes at least one of a type of attack or a colliding operational message detected from the first operational message.

13. 10. The method of claim 9, wherein the first operational message is a first operational sharing coordination message (MSCM) and the previously received message is a second MSCM.

14. The method of claim 13 , wherein the second MSCM indicates an intent to perform a potential operation.

15. 10. The method of claim 9, wherein the first operational message is a Mission Shared Coordination Message (MSCM) and the previously received message is a safety message.

16. The method of claim 15 , wherein the safety message is a Basic Safety Message (BSM).

17. 10. The method of claim 9, wherein the first vehicle is configured to communicate using a Vehicle-to-Everything (V2X) protocol.

18. 1. An apparatus for wireless communication, comprising: Memory, one or more processors coupled to the memory; wherein the one or more processors: Transmitting a message associated with a potential operation by the vehicle; determining an operation identification (ID) for the potential operation based on the message; sending a first operation message for the potential operation including the operation ID. Device.

19. The apparatus of claim 18 , wherein the message is a safety message.

20. 20. The apparatus of claim 19, wherein the safety message is a Basic Safety Message (BSM).

21. The apparatus of claim 18 , wherein the message is a second operation message indicating an intent to perform the potential operation.

22. 22. The apparatus of claim 21, wherein the second operational message is a Maneuver Shared Coordination Message (MSCM).

23. 20. The apparatus of claim 18, wherein the first operation message is a Operation Share Coordination Message (MSCM) indicating a request to perform the potential operation.

24. 20. The apparatus of claim 18, wherein the apparatus is part of the vehicle, the vehicle being configured to communicate using a Vehicle-to-Everything (V2X) protocol.

25. 20. The apparatus of claim 18, wherein to determine the operation ID for the potential operation based on a message, the one or more processors are configured to apply a hash algorithm to the message to generate the hashed message, the hashed message comprising the one or more processors.

26. 1. An apparatus for wireless communication, comprising: Memory, one or more processors coupled to the memory; wherein the one or more processors: receiving a first operation message from a vehicle, the first operation message including a first operation identification (ID); determining that the first operation ID of the first operation message is a new operation ID; determining whether the first operation ID matches a second operation ID determined based on a previously received message based on the first operation ID being a new operation ID; The apparatus is configured to:

27. the one or more processors: applying a hash algorithm to the previously received message to generate a hashed message including the second operation ID; Comparing the second operation ID to the first operation ID; 27. The apparatus of claim 26, configured to:

28. the one or more processors: determining that the first operation ID is different from the second operation ID; sending a misconduct report to at least one of a backend server or one or more other vehicles based on determining that the first operation ID is different from the second operation ID; 27. The apparatus of claim 26, configured to:

29. 30. The apparatus of claim 28, wherein the misconduct report includes at least one of a type of attack detected from the first operational message or a colliding operational message.

30. 27. The apparatus of claim 26, wherein the first operational message is a first operational sharing coordination message (MSCM) and the previously received message is a second MSCM.

31. 31. The apparatus of claim 30, wherein the second MSCM indicates an intent to perform a potential operation.

32. 27. The apparatus of claim 26, wherein the first operational message is a Mission Shared Coordination Message (MSCM) and the previously received message is a safety message.

33. 33. The apparatus of claim 32, wherein the safety message is a Basic Safety Message (BSM).

34. 27. The apparatus of claim 26, wherein the apparatus is part of an additional vehicle configured to communicate using a Vehicle-to-Everything (V2X) protocol.

Images