Sensor improper behavior detection system using communication

Abstract

Systems, apparatus, processes, and computer-readable media for wireless communication are disclosed. For example, an example of a process includes detecting an object based on sensor data from at least one sensor of a network device. The process also includes receiving, by the network device, a vehicle-based message including message data related to the object. The process further includes comparing, by the network device, the sensor data and the message data, and detecting, by the network device, malicious behavior based on the comparison.

Description

Technical Field

[0001] The present disclosure generally relates to vehicle communications. For example, aspects of the present disclosure relate to sensor misbehavior detection systems utilizing communications, such as vehicle-to-everything (V2X) communications. Background Art

[0002] Wireless communication systems are widely deployed to provide a variety of telecommunication services, such as telephony, video, data, messaging, and broadcast. Typical wireless communication systems 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 telecommunication standards to provide a common protocol that enables different wireless devices to communicate at a city, country, region, and even global level. An example telecommunication standard is 5G New Radio (NR). 5G NR is part of the continuous mobile broadband evolution released by the Third Generation Partnership Project (3GPP) to meet new requirements and other requirements associated with latency, reliability, security, scalability (e.g., with the Internet of Things (IoT)). 5G NR includes services associated with enhanced mobile broadband (eMBB), massive machine type communication (mMTC), and ultra-reliable low latency communication (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 in V2X, vehicle to vehicle (V2V), and / or device to device (D2D) communication. There is a need for further improvements in V2X, V2V, and / or D2D technologies. These improvements may also be applicable to other multiple access technologies and telecommunication standards that employ these technologies. Summary of the invention

[0004] A simplified overview of one or more aspects disclosed herein is given below. Therefore, the following overview should not be considered as a broad overview of all intended aspects, nor should it be considered as identifying key or important elements related to all intended aspects or delineating the scope associated with any particular aspect. Therefore, the sole purpose of the following overview is to present certain concepts related to one or more aspects of the mechanisms disclosed herein in a simplified form prior to the detailed description given below.

[0005] Systems, apparatus, methods, and computer-readable media for a V2X-sensor misbehavior detection system are disclosed. According to at least one example, a method for wireless communication at a network device is provided. The method includes: detecting an object based on sensor data from at least one sensor of the network device; receiving, by the network device, a vehicle-based message including message data related to the object; comparing, by the network device, the sensor data and the message data; and detecting malicious behavior, by the network device based on the comparison.

[0006] In another example, an apparatus for wireless communication is provided, the apparatus comprising at least one memory and at least one processor coupled to the at least one memory. The at least one processor is configured to: detect an object based on sensor data from at least one sensor of a network device; receive a vehicle-based message including message data related to the object; compare the sensor data and the message data; and detect malicious behavior based on the comparison.

[0007] In another example, a non-transitory computer-readable medium having instructions stored thereon is provided, which, when executed by one or more processors, causes the one or more processors to: detect an object based on sensor data from at least one sensor of a network device; receive a vehicle-based message including message data related to the object; compare the sensor data and the message data; and detect malicious behavior based on the comparison.

[0008] In another example, an apparatus for wireless communication is provided. The apparatus includes: means for detecting an object based on sensor data from at least one sensor of the network device; means for receiving a vehicle-based message including message data related to the object; means for comparing the sensor data and the message data; and means for detecting malicious behavior based on the comparison.

[0009] In some aspects, the device is a vehicle (e.g., a car, truck, etc., or a component or system of a car, truck, etc.), a mobile device (e.g., a mobile phone or so-called "smart phone" 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 server computer, a robotic device, or other device, or a portion of the above. In some aspects, the device includes a radio detection and ranging (radar) 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 light-based (e.g., optical frequency) signals. In some aspects, the device includes a camera or multiple cameras for capturing one or more images. In some aspects, the device also includes a display for displaying one or more images, notifications, and / or other displayable data. In some aspects, the above-mentioned device may include one or more sensors, which can be used to determine the location of the device, the state of the device (e.g., temperature, humidity level, and / or other state), and / or for other purposes.

[0010] 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. The subject matter should be understood by reference to appropriate portions of the entire specification of this patent, any or all drawings, and each claim.

[0011] Other objects and advantages associated with the aspects disclosed herein will be apparent to those skilled in the art based on the accompanying drawings and detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Illustrative aspects of the present application are described in detail below with reference to the following drawings:

[0013] Figure 1 is a diagram illustrating an example wireless communication system in accordance with some aspects of the present disclosure.

[0014] Figure 2 is a diagram illustrating an example of a disaggregated base station architecture that may be employed by the disclosed V2X-sensor misbehavior detection system in accordance with some aspects of the present disclosure.

[0015] Figure 3 is a diagram showing examples of various user equipment (UE) communicating over a direct communication interface (e.g., a cellular-based PC5 sidelink interface, an 802.11p-defined DSRC interface, or other direct interface) and over a wide area network (Uu) interface according to some aspects of the present disclosure.

[0016] Figure 4is a block diagram illustrating an example of a computing system for a vehicle according to some aspects of the present disclosure.

[0017] Figure 5 is a block diagram illustrating an example of a computing system of a user device according to some aspects of the present disclosure.

[0018] Figure 6 is a diagram illustrating an example of devices involved in wireless communications (eg, sidelink communications) according to some aspects of the present disclosure.

[0019] 7A to 7D is a diagram illustrating an example of sensor sharing for cooperative and autonomous driving systems according to some aspects of the present disclosure.

[0020] Figure 8 is a diagram illustrating an example of sensor sharing for cooperative and autonomous driving systems according to some aspects of the present disclosure.

[0021] Fig. 9 is a diagram illustrating an example of a system for sensor sharing in wireless communications (eg, V2X communications) according to some aspects of the present disclosure.

[0022] Fig.10 is a diagram illustrating an example of a vehicle-based message (shown as a sensor sharing message) according to some aspects of the present disclosure.

[0023] Fig.11 is a diagram illustrating an example of a vehicle configuration for a non-line-of-sight (NLoS) scenario according to some aspects of the present disclosure.

[0024] Fig.12 is a diagram illustrating an example of operations that may be performed by a V2X-sensor misbehavior detection system in accordance with some aspects of the present disclosure.

[0025] Fig.13 is a flow chart illustrating an example of a process for the operation of a detector for detecting ghosted objects using a sensor according to some aspects of the present disclosure, wherein the detector may be used to Fig.12 V2X-sensor detector.

[0026] Fig.14 is a table that may be used to estimate the probability of line-of-sight (LoS) and non-line-of-sight (NLoS) objects in accordance with some aspects of the present disclosure.

[0027] Fig.15 is a diagram illustrating an example of the operation of a detector for detecting simulated (false) free space according to some aspects of the present disclosure, wherein the detector can be used to Fig.12 V2X-sensor detector.

[0028] Fig.16A is a diagram illustrating an example of a ground truth view according to some aspects of the present disclosure.

[0029] Fig. 16B is a diagram illustrating an example of a collective perception messaging (CPM) view according to some aspects of the present disclosure.

[0030] Fig. 16C is a diagram illustrating an example of a receiver (Rx) sensor view according to some aspects of the present disclosure.

[0031] Fig.16D is a diagram illustrating an example of an overall Rx view according to some aspects of the present disclosure.

[0032] Fig.17 is a flow chart illustrating an example process that may be performed by a detector for detecting simulated (false) free space according to some aspects of the present disclosure, wherein the detector may be used to Fig.12 V2X-sensor detector.

[0033] Fig.18 is a flow chart illustrating an example of a process for the operation of a detector for detecting an inconsistent number of CPM objects according to some aspects of the present disclosure, wherein the detector may be used to Fig.12 V2X-sensor detector.

[0034] Fig.19A , 19B , 19C, 19D and 19E are diagrams that together illustrate how some aspects of the present disclosure may be accomplished. Fig.18 Schematic diagram of an example of a process performed by a detector for detecting simulated (false) CPM objects.

[0035] Fig. 20 is a flow chart illustrating an example of a process for the operation of a detector for detecting V2X camera inconsistency according to some aspects of the present disclosure, wherein the detector may be used to Fig.12 V2X-sensor detector.

[0036] Fig.21 is a flow chart illustrating an example of a process for wireless communication according to some aspects of the present disclosure.

[0037] Fig. 22 An example computing system according to aspects of the present disclosure is shown. DETAILED DESCRIPTION

[0038] For the purpose of illustration, some aspects of the present disclosure are provided below. Without departing from the scope of the present disclosure, alternative aspects can be designed. In addition, the known elements of the present disclosure will not be described in detail or will be omitted, so as not to blur the relevant details of the present disclosure. Some aspects described herein can be applied independently, and some of them can be applied in combination, which is obvious to those skilled in the art. In the following description, for the purpose of explanation, specific details are set forth in order to provide a thorough understanding of various aspects of the application. However, it is obvious that various aspects can be practiced without these specific details. The accompanying drawings and descriptions are not intended to be restrictive.

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

[0040] 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. Likewise, the term "aspects of the disclosure" does not require that all aspects of the disclosure include the discussed feature, advantage, or mode of operation.

[0041] Wireless communication systems are deployed to provide a variety of telecommunication services, including telephony, video, data, messaging, broadcasting, and more. Wireless communication systems have evolved over different generations. The fifth generation (5G) mobile standard calls for higher data transmission speeds, a greater number of connections, and better coverage, among other improvements. According to the Next Generation Mobile Networks Alliance, the 5G standard (also known as "New Radio" or "NR") is designed to provide data rates of tens of megabits per second to each of tens of thousands of users.

[0042] A vehicle is an example of a system that may include wireless communication capabilities. For example, a vehicle (e.g., a motor vehicle, an autonomous vehicle, an aircraft, a ship, etc.) may communicate with other vehicles and / or with other devices that have wireless communication capabilities. Wireless vehicle communication systems include vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-network (V2N), and vehicle-to-pedestrian (V2P) communications, all of which are collectively referred to as vehicle-to-everything (V2X) communications. V2X communications are vehicle communication systems that support the wireless transmission of information from a vehicle to other entities located within a traffic system that may affect the vehicle (e.g., other vehicles, pedestrians with smart phones, equipped vulnerable road users (VRUs) such as cyclists, and / or other traffic infrastructure). The main purpose of V2X technology is to improve road safety, fuel savings, and traffic efficiency.

[0043] In a V2X communication system, information is transmitted from vehicle sensors (and other sources) over a wireless link to allow the information to be delivered to other vehicles, pedestrians, VRUs, and / or traffic infrastructure. Information may be transmitted using one or more vehicle-based messages, such as cellular vehicle-to-everything (C-V2X) messages, which may include sensor data sharing messages (SDSMs), basic safety messages (BSMs), collaborative awareness messages (CAMs), collective awareness messages (CPMs), decentralized environment messages (DENMs), and / or other types of vehicle-based messages. By sharing this information with other vehicles, V2X technology improves the vehicle's (and the driver's) awareness of potential hazards to help reduce collisions with other vehicles and entities. In addition, V2X technology improves traffic efficiency by providing vehicles with traffic warnings of potential upcoming road hazards and obstacles, allowing vehicles to choose alternative traffic routes.

[0044] As mentioned earlier, V2X technology includes V2V communication, which can also be referred to as peer-to-peer communication. V2V communication allows vehicles to communicate directly with each other wirelessly on the road. Using V2V communication, vehicles can gain situational awareness by receiving information about upcoming road hazards (e.g., unforeseen upcoming vehicles, accidents, and road conditions) from other vehicles.

[0045] The IEEE 802.11p standard supports (uses) a dedicated short-range communication (DSRC) interface for V2X wireless communications. Features of the IEEE 802.11p-based DSRC interface include low latency and the use of the unlicensed 5.9 gigahertz (GHz) band. C-V2X is adopted as an alternative to wireless communications using the IEEE 802.11p-based DSRC interface. The 5G Automobile Association (5GAA) supports the use of C-V2X technology. In some cases, C-V2X technology uses Long Term Evolution (LTE) as the underlying technology, and the C-V2X functionality is based on LTE technology. C-V2X includes multiple operating modes. One of the operating modes allows direct wireless communication between vehicles via the LTE side link PC5 interface. Similar to the IEEE 802.11p-based DSRC interface, the LTE C-V2X side link PC5 interface operates on the 5.9 GHz band. Vehicle-based messages, such as BSM and CAM as application layer messages, are designed to be broadcast wirelessly over the 802.11p-based DSRC interface and the LTE C-V2X sidelink PC5 interface.

[0046] In one or more situations, a sending network device (e.g., a V2X-capable vehicle that generates and sends a vehicle-based message) may misbehave (e.g., operate as a misbehaving vehicle) by sending (e.g., intentionally or unintentionally) a vehicle-based message that includes incorrect information. For example, a sending network device may operate as a misbehaving vehicle if information contained within a vehicle-based message of the sending network device identifies an incorrect location (position) of the sending network device.

[0047] In some cases, a sending network device (e.g., a V2X-capable vehicle that generates and sends a vehicle-based message) may operate as a misbehaving vehicle or attacker and may misbehave, such as by including false information in a V2X message or creating invisible V2X phantom objects to interfere with traffic on a road. A phantom V2X object is a V2X object (e.g., an object sensed by a V2X-sensor) that is not located at the location indicated by the sending network device. A phantom V2X object is an object that has no physical presence, such as a simulated vulnerable road user (VRU) or a simulated vehicle. An invisible object is an object that is outside the sensor field of view (FoV) or is not in the line of sight (LoS) (e.g., a non-line-of-sight scenario) of a receiving network device (e.g., a V2X-capable vehicle that receives a vehicle-based message).

[0048] In some cases, an attacker may use V2X attacks that are only detectable by sensors. For example, an attacker may create a phantom vehicle that mimics a real vehicle. In another example, an attacker may include false information in a vehicle-based message (e.g., false traffic light information, such as information indicating that a traffic light is lit red at a particular time when the traffic light is actually lit green). The attacker's goal may be to cause the driver to perform unnecessary maneuvers (e.g., slow down), which may cause driver frustration and / or cause traffic disruptions, which may lead to traffic jams and / or vehicle collisions. Attacks that simulate vehicle mobility may be very difficult to detect without the use of sensors (e.g., cameras, radar sensors, LIDAR sensors, and / or other sensors).

[0049] Currently, V2X-sensor solutions are not sufficient to detect such attacks. For example, current solutions may only scan for a single type of message (e.g., CAM or BSM), while attackers may target multiple message types. For another example, current solutions may only rely on a single detector (e.g., a phantom-V2X detector), and therefore, these current solutions can only detect a single V2X attack.

[0050] Systems, apparatus, devices (e.g., network devices), methods (also referred to as processes), and computer-readable media (collectively referred to herein as "systems and techniques") for optimizing situational awareness of vehicle misbehavior that may cause traffic disruptions are provided. The systems and techniques may provide a V2X-sensor misbehavior detection system that utilizes information from sensors (e.g., cameras, radars, and LIDARs) to verify (or validate) information included within vehicle-based messages (e.g., vehicle and / or traffic infrastructure information). In one or more aspects, the systems and techniques may include multiple processes that may include, but are not limited to, data alignment, data association, misbehavior reporting, object detection (e.g., via sensors), spatial and temporal alignment, and estimated probabilities of line-of-sight (LoS) and non-line-of-sight (NLoS) objects.

[0051] In one or more aspects, data alignment can be time-dependent. For example, sensor data and CPM data may not be generated simultaneously (e.g., data such as for vehicle location may be generated with a time difference of 10 seconds, such that sensor data is generated 10 seconds after CPM data is generated). Without using time alignment (e.g., sensor data and CPM data are aligned simultaneously), consistency between sensor data and CPM data cannot be verified (or confirmed). Sensor data and CPM data may be aligned in time by utilizing a mobility estimation algorithm, such as using a least squares temporal mean (LSTM) algorithm or a Kalman filter.

[0052] Additionally or alternatively, in some aspects, data alignment can be spatially related. For example, sensor data and CPM data may not have the same reference frame. In one example, sensor data can rely on polar coordinates or a relative positioning format (e.g., where the sensor data position is an offset of the sensor position). In another instance, a message format (e.g., a CPM format) can use Cartesian coordinates (e.g., based on a global map) or a relative positioning format (e.g., where the sensor of the sending device sending the message is located at the origin). The sensor and message (e.g., CPM) positioning data can have the same reference frame (e.g., the CPM receiver can be located at the origin and Cartesian coordinates) so that the consistency between the sensor data and the message data (e.g., CPM data) can be verified (or confirmed).

[0053] In some cases, distance information may be calculated using distance-based feedback transmissions (e.g., for 5G NR V2X in 3GPP Release 16). For example, a sender (transmitter) may include the sender's location (e.g., it may not be a precise location, but a rough location in a grid) and a minimum communication range (MCR) in signaling information (e.g., Sidelink Control Information (SCI) Part 2). This location and range information related to the sender may not be part of any application layer message (e.g., BSM or SDSM), but may be part of a control message that may accompany any application layer message. A receiver (e.g., which is located within the MCR and is able to decode the control information, but cannot decode the corresponding data) may send (transmit) a negative acknowledgement message (NACK) to the originator (e.g., sender). After receiving the NACK, the originator (e.g., sender) may then retransmit the information.

[0054] In one or more aspects, the estimated probabilities of LoS and NLoS objects (e.g., for 5G NR V2X in 3GPP Release 16) can be used to estimate whether the LoS path is blocked by another vehicle by using, for example, a local dynamic map and a calculation of three-dimensional LoS. To estimate whether the LoS path is blocked by another vehicle, a calculation formula for the probability of LoS (e.g., P(LoS)) can be utilized (e.g., Fig.14 The formulas for the highway 1410 and urban 1420 driving scenarios in Table 1400 of FIG. 1400 are shown in FIG. 1410 , where the distance (d) is between the host vehicle (HV) and the remote vehicle (RV), and the HV and RV should be on the same road. The highway and urban driving scenarios can be determined based on the type of road (which can be determined by using an embedded map, for example), the perceived speed limit of the road, and the average own speed driven over a specific period of time.

[0055] In the current European Telecommunications Standards Institute (ETSI) Technical Specification (TS) 103 759, the first version (V1) includes detectors that do not rely on sensor information. However, the second version (V2) is planned to specify new categories of detectors that can use sensor information. The standard should define V2X-sensor detectors that are able to use sensor information to verify (confirm) information included in vehicle-based messages (e.g., location information). For example, these V2X-sensor detectors may be able to verify (confirm) whether the color (e.g., red) of a traffic light included in a signal, phase, and time (SPaT) message is consistent with the color (e.g., red) of the traffic light perceived by the camera (sensor).

[0056] Additional aspects of the disclosure are described in more detail below.

[0057] As used herein, unless otherwise specified, the terms "user equipment" (UE) and "network entity" are not intended to be specific to or otherwise limited to any particular radio access technology (RAT). 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 device (e.g., a smart watch, smart glasses, 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., a car, 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 certain times) and may communicate with a radio access network (RAN). As used herein, the term "UE" may be interchangeably referred to 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. Typically, the UE can communicate with the core network via the RAN, and through the core network, the UEs can 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 the UE, such as through a wired access network, a wireless local area network (WLAN) network (e.g., based on IEEE 802.11 communication standards, etc.), etc.

[0058] In some cases, the network entity may be implemented in an aggregated or monolithic base station or server architecture, or alternatively, in a disaggregated 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 (near-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., with an aggregated / monolithic base station architecture or a disaggregated base station architecture) may operate according to one of several RATs communicating with UEs, roadside units (RSUs) / or other devices (depending on the network in which it is deployed), and may be alternatively referred to as an access point (AP), a network node, a Node B (NB), an evolved Node B (eNB), a next generation eNB (ng-eNB), a new radio (NR) Node B (also referred to as a gNB or gNodeB), etc. A base station may be primarily used to support wireless access for UEs, including supporting data, voice, and / or signaling connections for supported UEs. In some systems, a base station may provide edge node signaling functionality, while in other systems, it may provide additional control and / or network management functionality. The communication link through which a UE may send a signal to a base station is referred to as an uplink (UL) channel (e.g., a reverse traffic channel, a reverse control channel, an access channel, etc.). The communication link through which a base station may send a signal to a UE is referred to as a downlink (DL) or forward link channel (e.g., a paging channel, a control channel, a broadcast channel, or a forward traffic channel, etc.). As used herein, the term traffic channel (TCH) may refer to an uplink, a reverse or downlink, and / or a forward traffic channel.

[0059] The term "network entity" or "base station" (e.g., having an aggregated / monolithic base station architecture or a disaggregated base station architecture) may refer to a single physical TRP or to multiple physical TRPs that may or may not be co-located. For example, where 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. Where the term "network entity" or "base station" refers to multiple co-located physical TRPs, the physical TRP may be an antenna array of the base station (e.g., as in a multiple-input multiple-output (MIMO) system or where the base station employs beamforming). Where the term "base station" refers to multiple non-co-located 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 transmission medium) or a remote radio head (RRH) (a remote base station connected to a serving base station). Alternatively, the non-co-located physical TRP may be a serving base station that receives measurement reports from the UE and a neighboring base station whose reference radio frequency (RF) signal (or simply "reference signal") the UE is measuring. Because the TRP is the point from which a base station transmits and receives wireless signals, as used herein, references to transmissions from a base station or receptions at a base station should be understood to refer to the specific TRP of the base station.

[0060] In some implementations of supporting positioning of a UE, a network entity or base station may not support wireless access for the UE (e.g., may not support data, voice, and / or signaling connections for the UE), but may instead send a reference signal to the UE to be measured by the UE, and / or may receive and measure a signal sent by the UE. Such a base station may be referred to as a positioning beacon (e.g., when transmitting a signal to the UE) and / or as a position measurement unit (e.g., when receiving and measuring a signal from the UE).

[0061] A roadside unit (RSU) is a device that can communicate with a wireless network through a communication link or interface (e.g., a cellular-based sidelink or PC5 interface, an 802.11-based or WiFi-based TM A device that sends and receives messages to and from one or more UEs, other RSUs, and / or base stations (using a 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 will be described in more detail below. The RSU can be located on various transportation infrastructure systems, including roads, bridges, parking lots, toll booths, and / or other infrastructure systems. In some examples, the RSU can facilitate communications between UEs (e.g., vehicles, pedestrian user equipment, and / or other UEs) and transportation infrastructure systems. In some embodiments, the RSU can communicate with a server, a base station, and / or other systems that can perform centralized management functions.

[0062] The RSU can communicate with the communication system of the UE. For example, the intelligent transportation system (ITS) of the UE (e.g., a vehicle and / or other UE) can be used to generate and sign messages for transmission to the RSU and verify messages received from the RSU. The RSU can communicate with vehicles traveling along roads, bridges, or other infrastructure systems (e.g., through a PC5 interface, a DSRC interface, etc.) to obtain traffic-related data (e.g., the time, speed, location, etc. of the vehicle). In some cases, in response to obtaining traffic-related data, the RSU can determine or estimate traffic congestion information (e.g., the beginning of a traffic congestion, the end of a traffic congestion, etc.), travel time, and / or other information of a specific location. In some examples, the RSU can communicate with other RSUs (e.g., through a PC5 interface, a DSRC interface, etc.) to determine traffic-related data. The RSU can send information (e.g., traffic congestion information, travel time information, and / or other information) to other vehicles, pedestrian UEs, and / or other UEs. For example, the RSU can broadcast or otherwise send information to any UE (e.g., vehicle, pedestrian UE, etc.) within the coverage area of ​​the RSU.

[0063] Radio frequency signals or "RF signals" include electromagnetic waves of a given frequency that transmit information through the 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, due to the propagation characteristics of RF signals through multipath channels, a receiver may receive multiple "RF signals" corresponding to each transmitted RF signal. The same transmitted RF signal on different paths between a transmitter and a receiver may be referred to as a "multipath" RF signal. As used herein, RF signals may also be referred to as "wireless signals" or simply "signals", where it is clear from the context that the term "signal" refers to either wireless signals or RF signals.

[0064] According to various aspects, Figure 1An exemplary wireless communication system 100 is shown. The wireless communication system 100 (which may also be referred to as a wireless wide area network (WWAN)) may include various base stations 102 and various UEs 104. In some aspects, the base stations 102 may also be referred to as "network entities" or "network nodes". One or more of the base stations 102 may be implemented in an aggregated or monolithic base station architecture. Additionally or alternatively, one or more of the base stations 102 may be implemented in a disaggregated base station architecture and may include one or more of a central unit (CU), a distributed unit (DU), a radio unit (RU), a near real-time (near RT) RAN intelligent controller (RIC), or a non-real-time (non-RT) RIC. The base station 102 may include a macrocell base station (high power cellular base station) and / or a small cell base station (low power cellular base station). In one aspect, the macrocell base station may include an eNB and / or ng-eNB in ​​which the wireless communication system 100 corresponds to a long term evolution (LTE) network, or a gNB in ​​which the wireless communication system 100 corresponds to an NR network, or a combination of both, and the small cell base station may include a femtocell, a picocell, a microcell, and the like.

[0065] The base stations 102 may collectively form a RAN and interface with a core network 170 (e.g., an evolved packet core (EPC) or a 5G core (5GC)) through a backhaul link 122, and interface to one or more location servers 172 (which may be part of the core network 170 or may be external to the core network 170) through the core network 170. The base stations 102 may perform, among other functions, functions related to one or more of the following: transmitting user data, wireless channel encryption and decryption, integrity protection, header compression, mobility control functions (e.g., handover, dual connectivity), inter-cell interference coordination, connection establishment and release, load balancing, distribution for non-access stratum (NAS) messages, NAS node selection, synchronization, RAN sharing, multimedia broadcast multicast service (MBMS), subscriber and device tracking, RAN information management (RIM), paging, positioning, and delivery of warning messages. The base stations 102 may communicate with each other directly or indirectly (e.g., through the EPC or 5GC) through a backhaul link 134, which may be wired and / or wireless.

[0066] Base station 102 can communicate wirelessly with UE 104. Each of base stations 102 can provide communication coverage for a corresponding geographic coverage area 110. In one aspect, one or more cells can be supported by base station 102 in each coverage area 110. A "cell" is a logical communication entity used to communicate with a base station (e.g., on a certain frequency resource, which is called a carrier frequency, component carrier, carrier, frequency band, etc.), and can be associated with an identifier (e.g., a physical cell identifier (PCI), a virtual cell identifier (VCI), a cell global identifier (CGI)) used to distinguish cells operating via the same or different carrier frequencies. In some cases, different cells can be configured according to different protocol types (e.g., machine type communication (MTC), narrowband IoT (NB-IoT), enhanced mobile broadband (eMBB) or other protocol types) that can provide access to different types of UEs. Because a cell is supported by a specific base station, depending on the context, the term "cell" can refer to either or both of the logical communication entity and the base station that supports it. In addition, because a TRP is generally a physical transmission point of a cell, the terms "cell" and "TRP" can be used interchangeably. In some cases, the term “cell” may also refer to a geographic coverage area (eg, sector) of a base station, as long as a carrier frequency can be detected and used for communications within some portion of the geographic coverage area 110 .

[0067] Although the geographic coverage areas 110 of adjacent macrocell base stations 102 may partially overlap (e.g., in a handoff region), some geographic coverage areas 110 may be substantially overlapped by a larger geographic coverage area 110. For example, a small cell base station 102' may have a coverage area 110' that substantially overlaps with the coverage area 110 of one or more macrocell base stations 102. A network that includes both small cell base stations and macrocell base stations may be referred to as a heterogeneous network. A heterogeneous network may also include a home eNB (HeNB), which may provide services to a restricted group referred to as a closed subscriber group (CSG).

[0068] The communication link 120 between the base station 102 and the UE 104 may include uplink (also referred to as reverse link) transmissions from the UE 104 to the base station 102 and / or downlink (also referred to as forward link) transmissions from the base station 102 to the UE 104. The communication link 120 may use MIMO antenna technology, including spatial multiplexing, beamforming, and / or transmit diversity. The communication link 120 may be over one or more carrier frequencies. The allocation of carriers may be asymmetric with respect to the downlink and uplink (e.g., more or fewer carriers may be allocated for the downlink compared to the uplink).

[0069] The wireless communication system 100 may further include a WLAN AP 150 that communicates with a WLAN station (STA) 152 via a communication link 154 in an unlicensed spectrum (e.g., 5 gigahertz (GHz)). When communicating in an unlicensed spectrum, the WLAN STAs 152 and / or the WLAN AP 150 may perform a clear channel assessment (CCA) or a listen-before-talk (LBT) process to determine whether a channel is available before communicating. In some examples, the wireless communication system 100 may include a device (e.g., UE, etc.) that communicates with one or more UEs 104, base stations 102, APs 150, etc. using an ultra-wideband (UWB) spectrum. The UWB spectrum may be in the range of 3.1 to 10.5 GHz.

[0070] The small cell base station 102' can operate in licensed and / or unlicensed spectrum. When operating in the unlicensed spectrum, the small cell base station 102' can adopt LTE or NR technology and use the same 5GHz unlicensed spectrum used by the WLAN AP 150. The small cell base station 102' using LTE and / or 5G in the unlicensed spectrum can improve the coverage of the access network and / or increase the capacity of the access network. NR in the unlicensed spectrum can be referred to as NR-U. LTE in the unlicensed spectrum can be referred to as LTE-U, License Assisted Access (LAA) or MulteFire.

[0071] The wireless communication system 100 may also include a millimeter wave (mmW) base station 180 that communicates with the UE 182, which may operate in mmW frequencies and / or near mmW frequencies. The mmW base station 180 may be implemented in an aggregated or monolithic base station architecture, or alternatively, in a disaggregated base station architecture (e.g., including one or more of a CU, DU, RU, near RT RIC, or non-RT RIC). Extremely high frequency (EHF) is part of the RF in the electromagnetic spectrum. EHF has a range of 30 GHz to 300 GHz and a wavelength between 1 mm and 10 mm. The radio waves in this band may be referred to as millimeter waves. Near mmW may extend down to a frequency of 3 GHz with a wavelength of 100 mm. The super high frequency (SHF) band extends between 3 GHz and 30 GHz, also referred to as centimeter waves. Communications using mmW and / or near mmW radio frequency bands have high path loss and a relatively short range. The mmW base station 180 and the UE 182 may utilize beamforming (sending and / or receiving) on ​​the mmW communication link 184 to compensate for the extremely high path loss and short distance. Furthermore, it should be appreciated that in alternative configurations, one or more base stations 102 may also transmit using mmW or near mmW and beamforming.Therefore, it should be appreciated that the foregoing description is merely exemplary and should not be construed as limiting the various aspects disclosed herein.

[0072] Transmit beamforming is a technique for focusing an RF signal in a specific direction. Traditionally, when a network node or entity (e.g., a base station) broadcasts an RF signal, it broadcasts the signal in all directions (omnidirectionally). With transmit beamforming, the network node determines where a given target device (e.g., a UE) is located (relative to the transmitting network node) and projects a stronger downlink RF signal in that specific direction, thereby providing a faster (in terms of data rate) and stronger RF signal to the receiving device. In order to change the directionality of the RF signal when transmitting, the network node can control the phase and relative amplitude of the RF signal at each of the one or more transmitters that are broadcasting the RF signal. For example, the network node can use an antenna array (called a "phased array" or "antenna array") that creates an RF wave beam that can be "steered" to point in different directions without actually moving the antenna. Specifically, the RF current from the transmitter is fed to each antenna in the correct phase relationship so that the radio waves from the separate antennas are added together to increase the radiation in the desired direction while canceling to suppress the radiation in the undesired direction.

[0073] The transmit beams can be quasi-co-located, meaning that they appear to have the same parameters to the receiver (e.g., UE) regardless of whether the transmit antennas of the network nodes themselves are physically co-located. In NR, there are four types of quasi-co-location (QCL) relationships. Specifically, a given type of QCL relationship means that certain parameters about the second reference RF signal on the second beam can be derived from information about the source reference RF signal on the source beam. Therefore, if the source reference RF signal is QCL type A, the receiver can use the source reference RF signal to estimate the Doppler shift, Doppler spread, average delay, and delay spread of the second reference RF signal sent on the same channel. If the source reference RF signal is QCL type B, the receiver can use the source reference RF signal to estimate the Doppler shift and Doppler spread of the second reference RF signal sent on the same channel. If the source reference RF signal is QCL type C, the receiver can use the source reference RF signal to estimate the Doppler shift and average delay of the second reference RF signal sent on the same channel. If the source reference RF signal is QCL type D, the receiver may use the source reference RF signal to estimate spatial reception parameters of a second reference RF signal transmitted on the same channel.

[0074] In receive beamforming, the receiver uses receive beams to amplify RF signals detected on a given channel. For example, the receiver may increase the gain setting of the antenna array and / or adjust the phase setting of the antenna array in a particular direction to amplify (e.g., increase its gain level) the RF signals received from that direction. Thus, when the receiver performs beamforming in a certain direction, it means that the beam gain in that direction is high relative to the beam gain along other directions, or the beam gain in that direction is the highest compared to the beam gains of other beams available to the receiver. This results in a stronger received signal strength (e.g., reference signal received power (RSRP), reference signal received quality (RSRQ), signal to interference plus noise ratio (SINR), etc.) of the RF signals received from that direction.

[0075] The receive beams may be spatially correlated. The spatial relationship means that the parameters of the transmit beam for the second reference signal may be derived from the information about the receive beam for the first reference signal. For example, the UE may use a specific receive beam to receive one or more reference downlink reference signals (e.g., positioning reference signal (PRS), tracking reference signal (TRS), phase tracking reference signal (PTRS), cell-specific reference signal (CRS), channel state information reference signal (CSI-RS), primary synchronization signal (PSS), secondary synchronization signal (SSS), synchronization signal block (SSB), etc.) from a network node or entity (e.g., a base station). The UE may then form a transmit beam based on the parameters of the receive beam for sending one or more uplink reference signals (e.g., uplink positioning reference signal (UL-PRS), sounding reference signal (SRS), demodulation reference signal (DMRS), PTRS, etc.) to the network node or entity (e.g., a base station).

[0076] Note that a "downlink" beam can be a transmit beam or a receive beam, depending on the entity that forms it. For example, if a network node or entity (e.g., a base station) is forming a downlink beam to send a reference signal to a UE, the downlink beam is a transmit beam. However, if the UE is forming a downlink beam, it is a receive beam that receives a downlink reference signal. Similarly, an "uplink" beam can be a transmit beam or a receive beam, depending on the entity that forms it. For example, if a network node or entity (e.g., a base station) is forming an uplink beam, it is an uplink receive beam, and if the UE is forming an uplink beam, it is an uplink transmit beam.

[0077] In 5G, the spectrum on which the wireless network nodes or entities (e.g., base stations 102 / 180, UEs 104 / 182) operate is split into multiple frequency ranges FR1 (from 450 to 6000 megahertz (MHz)), FR2 (from 24250 to 52600 MHz), FR3 (above 52600 MHz), and FR4 (between FR1 and FR2). In a multi-carrier system, such as 5G, one of the carrier frequencies is referred to as a "primary carrier" or "anchor carrier" or "primary serving cell" or "PCell", and the remaining carrier frequencies are referred to as "secondary carriers" or "secondary serving cells" or "SCells". In carrier aggregation, the anchor carrier is a carrier operating on the primary frequency (e.g., FR1) utilized by the UE 104 / 182 and the cell in which the UE 104 / 182 performs an initial radio resource control (RRC) connection establishment procedure or initiates an RRC connection reestablishment procedure. The primary carrier carries all common and UE-specific control channels and can be a carrier in a licensed frequency (however, this is not always the case). A secondary carrier is a carrier operating on a second frequency (e.g., FR2), which can be configured once an RRC connection is established between the UE 104 and the anchor carrier, and can be used to provide additional radio resources. In some cases, the secondary carrier can be a carrier in an unlicensed frequency. The secondary carrier can include only necessary signaling information and signals, for example, those signaling information and signals specific to the UE may not be present in the secondary carrier, because the primary uplink and downlink carriers are usually UE-specific. This means that different UEs 104 / 182 in a cell can have different downlink primary carriers. The same is true for the uplink primary carrier. The network is able to change the primary carrier of any UE 104 / 182 at any time. For example, this is done to balance the load on different carriers. Because a "serving cell" (whether PCell or SCell) corresponds to a carrier frequency and / or component carrier on which a base station is communicating, the terms "cell", "serving cell", "component carrier", "carrier frequency", etc. can be used interchangeably.

[0078] For example, still referring to Figure 1, one of the frequencies utilized by the macrocell base station 102 may be an anchor carrier (or "PCell"), and the other frequencies utilized by the macrocell base station 102 and / or the mmW base station 180 may be secondary carriers ("SCells"). In carrier aggregation, the base station 102 and / or the UE 104 may use spectrum of up to Y MHz (e.g., 5, 10, 15, 20, 100 MHz) bandwidth per carrier, up to a total of Yx MHz (x component carriers) for transmission in each direction. The component carriers may be adjacent or non-adjacent to each other in the spectrum. The allocation of carriers may be asymmetric with respect to the downlink and uplink (e.g., more or fewer carriers may be allocated for the downlink compared to the uplink). The simultaneous transmission and / or reception of multiple carriers enables the UE 104 / 182 to significantly increase its data transmission and / or reception rate. For example, two 20 MHz aggregated carriers in a multi-carrier system would theoretically result in a two-fold increase in data rate (i.e., 40 MHz) compared to the data rate obtained with a single 20 MHz carrier.

[0079] In order to operate on multiple carrier frequencies, the base station 102 and / or the UE 104 are equipped with multiple receivers and / or transmitters. For example, the UE 104 may have two receivers, "receiver 1" and "receiver 2", where "receiver 1" is a multi-band receiver that can be tuned to band (i.e., carrier frequency) 'X' or band 'Y', and "receiver 2" is a single-band receiver that can only be tuned to band 'Z'. In this example, if the UE 104 is served in band 'X', band 'X' will be referred to as the PCell or active carrier frequency, and "receiver 1" will need to tune from band 'X' to band 'Y' (SCell) in order to measure band 'Y' (and vice versa). Conversely, regardless of whether the UE 104 is served in band 'X' or band 'Y', due to the separate "receiver 2", the UE 104 can measure band 'Z' without interrupting the service on band 'X' or band 'Y'.

[0080] The wireless communication system 100 may also include a UE 164, which may communicate with the macrocell base station 102 via a communication link 120 and / or communicate with the mmW base station 180 via a mmW communication link 184. For example, the macrocell base station 102 may support a PCell and one or more SCells for the UE 164, and the mmW base station 180 may support one or more SCells for the UE 164.

[0081] The wireless communication system 100 may also include one or more UEs (e.g., UE 190) that are indirectly connected to one or more communication networks via one or more device-to-device (D2D) or peer-to-peer (P2P) links (referred to as “side links”). Figure 1 In the example of FIG. 1 , UE 190 has a D2D P2P link 192 with one of UEs 104 connected to one of base stations 102 (e.g., through which UE 190 can indirectly obtain cellular connectivity) and a D2D P2P link 194 with a WLAN STA 152 connected to a WLAN AP 150 (through which UE 190 can indirectly obtain WLAN-based Internet connectivity). In an example, D2D P2P links 192 and 194 can be connected using any well-known D2D RAT (such as LTE Direct (LTE-D), Wi-Fi Direct (Wi-Fi-D), etc.) to support.

[0082] Figure 2 is a diagram showing an example of a deaggregated base station architecture that may be employed by the disclosed V2X-sensor misbehavior detection system according to some examples. The deployment of a communication system such as a 5G NR system may be arranged in a variety of ways with various components or constituent parts. In a 5G NR system or network, a network node, a network entity, a mobility element of a network, a radio access network (RAN) node, a core network node, a network element, or a network device (such as a base station (BS) or one or more units (or one or more components) that perform base station functions) may be implemented in an aggregated or deaggregated architecture. For example, a BS (such as a B node (NB), an evolved NB (eNB), an NR BS, a 5G NB, an AP, a transmit receive point (TRP), or a cell, etc.) may be implemented as an aggregated base station (also referred to as an independent BS or a monolithic BS) or a deaggregated base station.

[0083] 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 deaggregated base station may be configured to utilize a protocol stack that is physically or logically distributed between two or more units (e.g., one or more central or centralized units (CUs), one or more distributed units (DUs), 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, may be 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, namely a virtual central unit (VCU), a virtual distributed unit (VDU), or a virtual radio unit (VRU).

[0084] Base station type operations or network designs may take into account the aggregated nature of base station functions. For example, disaggregated base stations may be utilized in an integrated access backhaul (IAB) network, an open radio access network (O-RAN (such as a network configuration sponsored 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 at various physical locations, as well as distributing functions virtually for at least one unit, which may enable flexibility in network design. Individual units of a disaggregated base station or disaggregated RAN architecture may be configured for wired or wireless communication with at least one other unit.

[0085] As mentioned earlier, Figure 2 A diagram illustrating an exemplary disaggregated base station 201 architecture is shown. The disaggregated base station 201 architecture may include one or more central units (CUs) 211, which may communicate directly with a core network 223 via a backhaul link, or indirectly with a core network 223 through one or more disaggregated base station units (e.g., a near real-time (near-RT) RAN intelligent controller (RIC) 227 via an E2 link, or a non-real-time (non-RT) RIC 217 associated with a service management and orchestration (SMO) framework 207, or both). The CU 211 may communicate with one or more distributed units (DUs) 231 via corresponding midhaul links (e.g., an F1 interface). The DU 231 may communicate with one or more radio units (RUs) 241 via corresponding fronthaul links. The RU 241 may communicate with corresponding UEs 221 via one or more RF access links. In some implementations, a UE 221 may be served simultaneously by multiple RUs 241.

[0086] Each of the units (i.e., CU 211, DU 231, RU 241, and near-RT RIC 227, non-RT RIC 217, and SMO framework 207) may include one or more interfaces, or be coupled to one or more interfaces, configured to receive or send signals, data, or information (collectively referred to as signals) via a wired or wireless transmission medium. Each of the units, or an associated processor or controller that provides instructions to the communication interface of the unit, 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 that is configured to receive signals or send signals via a wired transmission medium to one or more other units. In addition, a unit may include a wireless interface that may include a receiver, a transmitter, or a transceiver (such as an RF transceiver) that is configured to receive signals or send signals or both via a wireless transmission medium to one or more other units.

[0087] In some aspects, CU 211 may host one or more higher layer control functions. Such control functions may include radio resource control (RRC), packet data convergence protocol (PDCP), service data adaptation protocol (SDAP), etc. Each control function may be implemented using an interface configured to transmit signals with other control functions hosted by CU 211. CU211 may be configured to process 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, CU 211 may be logically split into one or more CU-UP units and one or more CU-CP units. When implemented in an O-RAN configuration, the CU-UP unit may communicate bidirectionally with the CU-CP unit via an interface (e.g., an E1 interface). CU 211 may be implemented to communicate with DU 131 as needed for network control and signaling.

[0088] DU 231 may correspond to a logical unit including one or more base station functions for controlling the operation of one or more RUs 241. In some aspects, DU 231 may host one or more of a radio link control (RLC) layer, a medium access control (MAC) layer, and one or more high physical (PHY) layers (e.g., modules for forward error correction (FEC) encoding and decoding, scrambling, modulation and demodulation, etc.), depending at least in part on a functional split (e.g., a functional split defined by the Third Generation Partnership Project (3GPP)). In some aspects, DU 231 may also host one or more low PHY layers. Each layer (or module) may be implemented with an interface configured to communicate signals with other layers (and modules) hosted by DU 231 or with control functions hosted by CU 211.

[0089] Lower layer functions may be implemented by one or more RUs 241. In some deployments, a RU 241 controlled by a DU 231 may correspond to a logical node that hosts RF processing functions or low PHY layer functions (e.g., 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 split (e.g., a lower layer functional split). In such an architecture, the RU 241 may be implemented to handle over-the-air (OTA) communications with one or more UEs 221. In some implementations, real-time and non-real-time aspects of control and user plane communications with the RU 241 may be controlled by the corresponding DU 231. In some scenarios, this configuration may enable the DU 231 and the CU 211 to be implemented in a cloud-based RAN architecture, such as a vRAN architecture.

[0090] The SMO framework 207 may be configured to support RAN deployment and to provide non-virtualized and virtualized network elements. For non-virtualized network elements, the SMO framework 207 may be configured to support the deployment of dedicated physical resources for RAN coverage requirements, which may be managed via an operation and maintenance interface, such as an O1 interface. For virtualized network elements, the SMO framework 207 may be configured to interact with a cloud computing platform, such as an open cloud (O-cloud) 291, to perform network element lifecycle management, such as instantiating virtualized network elements, via a cloud computing platform interface, such as an O2 interface. Such virtualized network elements may include, but are not limited to, CU 211, DU 231, RU 241, and near-RT RIC 227. In some implementations, the SMO framework 207 may communicate with hardware aspects of the 4G RAN, such as an open eNB (O-eNB) 213, via an O1 interface. In addition, in some implementations, the SMO framework 207 may communicate directly with one or more RUs 241 via an O1 interface. The SMO framework 207 may also include a non-RT RIC 217 configured to support the functionality of the SMO framework 207 .

[0091] The non-RT RIC 217 may be configured to include logic functions that implement non-real-time control and optimization of RAN elements and resources, artificial intelligence / machine learning (AI / ML) workflows including model training and updating, or policy-based guidance of applications / features in the near-RT RIC 227. The non-RT RIC 217 may be coupled to or communicate with the near-RT RIC 227 (e.g., via an A1 interface). The near-RT RIC 227 may be configured to include logic functions that implement near-real-time control and optimization of RAN elements and resources through data collection and actions via an interface that connects one or more CUs 211, one or more DUs 231, or both, and the O-eNB 213 to the near-RT RIC 227 (e.g., via an E2 interface).

[0092] In some implementations, in order to generate an AI / ML model to be deployed in the near-RT RIC 227, the non-RT RIC 217 may receive parameters or external enrichment information from an external server. Such information may be used by the near-RT RIC 227 and may be received from a non-network data source or from a network function at the SMO framework 207 or the non-RT RIC 217. In some examples, the non-RT RIC 217 or the near-RT RIC 227 may be configured to tune RAN behavior or performance. For example, the non-RT RIC 217 may monitor long-term trends and patterns of performance and employ AI / ML models to perform corrective actions through the SMO framework 207 (such as via reconfiguration of O1) or via the creation of RAN management policies (such as A1 policies).

[0093] Figure 3 Examples of different communication mechanisms used by various UEs are shown. In one example of sidelink communication, Figure 3 Vehicle 304, vehicle 305, and RSU 303 are shown communicating with each other using PC5, DSRC, or other device-to-device direct signaling interfaces. In addition, vehicle 304 and vehicle 305 can communicate with base station 302 (shown as BS 302) using a network (Uu) interface. In some examples, base station 302 can include a gNB. Figure 3 Also shown is a user device 307 that communicates with the base station 302 using a network (Uu) interface. As described below, functionality can be transferred from a vehicle (e.g., vehicle 304) to a user device (e.g., user device 307) based on one or more characteristics or factors (e.g., temperature, humidity, etc.). In one illustrative example, V2X functionality can be transferred from vehicle 304 to user device 307, which can then communicate with other vehicles (e.g., vehicle 305) via a PC5 interface (or other device-to-device direct interface, such as a DSRC interface), as described below. Figure 3 shown.

[0094] Although Figure 3 A specific number of vehicles (e.g., two vehicles 304 and 305) are shown communicating with each other and / or with RSU 303, BS 302, and / or user equipment 307, but the present disclosure is not limited thereto. For example, dozens or hundreds of such vehicles may communicate with each other and / or with RSU 303, BS 302, and / or user equipment 307. At any given point in time, each such vehicle, RSU 303, BS 302, and / or user equipment 307 may transmit various types of information as messages to other nearby vehicles, resulting in each vehicle (e.g., vehicles 304 and / or 305), RSU 303, BS 302, and / or user equipment 307 receiving hundreds or thousands of messages per second from other nearby vehicles, RSUs, base stations, and / or other UEs.

[0095] Although Figure 3 The PC5 interface is shown in the figure, but various UEs (e.g., vehicles, user equipment, etc.) and RSUs can communicate directly using any suitable type of direct interface (e.g., 802.11 DSRC interface, Bluetooth™ interface, and / or other interface). For example, a vehicle can communicate with a user equipment via a direct communication interface (e.g., using PC5 and / or DSRC), a vehicle can communicate with another vehicle via a direct communication interface, a user equipment can communicate with another user equipment via a direct communication interface, a UE (e.g., vehicle, user equipment, etc.) can communicate with an RSU via a direct communication interface, an RSU can communicate with another RSU via a direct communication interface, and the like.

[0096] Figure 4 4 is a block diagram showing an example of a vehicle computing system 450 of a vehicle 404. The vehicle 404 is an example of a UE that can communicate with a network (e.g., eNB, gNB, location beacon, position measurement unit, and / or other network entities) via a Uu interface and communicate with other UEs using V2X communication via a PC5 interface (or other device-to-device direct interface, such as a DSRC interface). As shown, the vehicle computing system 450 may include at least a power management system 451, a control system 452, an infotainment system 454, an intelligent transportation system (ITS) 455, one or more sensor systems 456, and a communication system 458. In some cases, the vehicle computing system 450 may include or may 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), visual processing units (VPUs), neural network signal processors (NSPs), microcontrollers, dedicated hardware, any combination thereof, and / or other processing devices or systems.

[0097] The control system 452 may be configured to control one or more operations of the vehicle 404, the power management system 451, the computing system 450, the infotainment system 454, the ITS 455, and / or one or more other systems of the vehicle 404 (e.g., a braking system, a steering system, a safety system other than the ITS 455, a cabin system, and / or other systems). In some examples, the control system 452 may include one or more electronic control units (ECUs). The ECUs may control one or more of the electrical systems or subsystems in the vehicle. Examples of specific ECUs that may be included as part of the control system 452 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), and the like. In some cases, the control system 452 may receive sensor signals from one or more sensor systems 456 and may communicate with other systems of the vehicle computing system 450 to operate the vehicle 404.

[0098] The vehicle computing system 450 also includes a power management system 451. In some implementations, the power management system 451 may include a power management integrated circuit (PMIC), a backup battery, and / or other components. In some cases, other systems of the vehicle computing system 450 may include one or more PMICs, batteries, and / or other components. The power management system 451 may perform power management functions for the vehicle 404, such as managing the power supply of the computing system 450 and / or other parts of the vehicle. For example, the power management system 451 may provide a stable power supply in view of power fluctuations (such as based on starting the engine of the vehicle). In another example, the power management system 451 may perform thermal monitoring operations such as by checking the ambient temperature and / or the junction temperature of the transistor. In another example, the power management system 451 may perform certain functions based on detecting a certain temperature level, such as causing a cooling system (e.g., one or more fans, an air conditioning system, etc.) to cool certain components of the vehicle computing system 450 (e.g., a control system 452, such as one or more ECUs), shutting down certain functions of the vehicle computing system 450 (e.g., such as limiting the infotainment system 454 by turning off one or more displays, disconnecting from a wireless network, etc.), and other functions.

[0099] The vehicle computing system 450 also includes a communication system 458. The communication system 458 may include software and hardware components for sending and receiving signals to and from a network (e.g., a gNB or other network entity via a Uu interface) and / or from 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 458 is configured to wirelessly send 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 458 includes various components or devices for performing wireless communication functions, including an original equipment manufacturer (OEM) subscriber identity module (referred to as a SIM or SIM card) 460, a user SIM 462, and a modem 464. Although vehicle computing system 450 is shown as having two SIMs and one modem, in some implementations computing system 450 may 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).

[0100] A SIM is a device (e.g., an integrated circuit) that can securely store an International Mobile Subscriber Identity (IMSI) number and associated keys (e.g., encryption-decryption keys) of a particular subscriber or user. The IMSI and keys can be used to identify and authenticate a subscriber on a particular UE. The communication system 458 can use the OEM SIM 460 to establish a wireless connection for vehicle-based operations, such as for emergency call (eCall) functions, for communicating with the vehicle manufacturer's communication system (e.g., for software updates, etc.), and other operations. The OEM SIM 460 may be important for the OEM SIM to support critical services (e.g., eCall for emergency calls in the event of a car accident or other emergency). For example, eCall can include a service that automatically dials 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 and transmits the location of the vehicle to emergency services (e.g., police, fire, etc.).

[0101] The user SIM 462 may be used by the communication system 458 to perform wireless network access functions in order to support user data connections (e.g., for making phone calls, messaging, infotainment-related services, etc.). In some cases, the user's user device may be connected to the vehicle computing system 450 via an interface (e.g., via PC5, Bluetooth™, WiFI™ (e.g., DSRC), a universal serial bus (USB) port, and / or other wireless or wired interfaces). Once connected, the user device may transfer the wireless network access functions from the user device to the vehicle's communication system 458, in which case the user device may stop performing the wireless network access functions (e.g., during the period when the communication system 458 is performing the wireless access functions). The communication system 458 may begin interacting with a base station to perform one or more wireless communication operations, such as facilitating phone calls, sending and / or receiving data (e.g., messaging, video, audio, etc.), and other operations. In this case, other components of the vehicle computing system 450 may be used to output data received by the communication system 458. For example, infotainment system 454 (described below) may display video received by communication system 458 on one or more displays and / or may output audio received by communication system 458 using one or more speakers.

[0102] A modem is a device that modulates one or more carrier signals to encode digital information for transmission and demodulates the signal to decode the transmitted information. Modem 464 (and / or one or more other modems of communication system 458) can be used for data communication of OEM SIM 460 and / or user SIM 462. In some examples, modem 464 may include a 4G (or LTE) modem, and another modem (not shown) of communication system 458 may include a 5G (or NR) modem. In some examples, communication system 458 may include one or more Bluetooth TM modems (e.g., for Bluetooth TM Low Energy (BLE) or other types of Bluetooth communications), one or more WiFi TM modems (e.g., for DSRC communications and / or other WiFi communications), broadband modems (e.g., ultra-wideband (UWB) modems), any combination thereof, and / or other types of modems.

[0103] In some cases, modem 464 (and / or one or more other modems of communication system 458) may be used to perform V2X communications (e.g., V2V communications with other vehicles, D2D communications with other devices, V2I communications with infrastructure systems, V2P communications with pedestrian UEs, etc.). In some examples, communication system 458 may include a V2X modem for performing V2X communications (e.g., sidelink communications via 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 via a network / Uu interface and / or sidelink communications other than V2X communications).

[0104] In some examples, the communication system 458 may be or may include a telematics control unit (TCU). In some implementations, the TCU may include a network access device (NAD) (also referred to as a network control unit or NCU in some cases). The NAD may include a modem 464, Figure 4 460, user SIM 462, and / or other components for wireless communication not shown in the figure. In some examples, communication system 458 may include a global navigation satellite system (GNSS). In some cases, GNSS may be part of one or more sensor systems 456, as described below. GNSS may provide vehicle computing system 450 with the ability to perform one or more location services, navigation services, and / or other services that may utilize GNSS capabilities.

[0105] In some cases, the communication system 458 may also include one or more wireless interfaces for sending and receiving wireless communications (e.g., including one or more transceivers and one or more baseband processors for each wireless interface), one or more wired interfaces for performing communications via one or more hardwired connections (e.g., a serial interface such as a Universal Serial Bus (USB) input, a lighting connector, and / or other wired interfaces), and / or other components that may allow the vehicle 404 to communicate with a network and / or other UEs.

[0106] The vehicle computing system 450 may also include an infotainment system 454 that can control the content and one or more output devices of the vehicle 404 that can be used to output the content. The infotainment system 454 may also be referred to as an in-vehicle infotainment (IVI) system or an in-vehicle 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), and 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 tactile feedback devices (e.g., one or more devices configured to vibrate seats, steering wheels, and / or other parts of the vehicle 404), and / or other output devices.

[0107] In some examples, computing system 450 may include intelligent transportation system (ITS) 455. In some examples, ITS 455 may be used to implement V2X communication. For example, the ITS stack of ITS 455 may generate V2X messages based on information from the application layer of the ITS. In some cases, the application layer may determine whether certain conditions have been met to generate messages for use by ITS 455 and / or generate messages to be sent to other vehicles (for V2V communication), to be sent to pedestrian UEs (for V2P communication), and / or to be sent to infrastructure systems (for V2I communication). In some cases, communication system 458 and / or ITS 455 may obtain car access network (CAN) information (e.g., obtained from other components of the vehicle via a CAN bus). In some examples, communication system 458 (e.g., TCU NAD) may obtain CAN information via a CAN bus and may send the CAN information to the PHY / MAC layer of ITS 455. ITS 455 may provide CAN information to the ITS stack of ITS 455. The CAN information may include vehicle-related information, such as the vehicle's heading, the vehicle's speed, braking information, and other information. The CAN information may be provided to the ITS 455 continuously or periodically (eg, every 1 millisecond (ms), every 10 ms, etc.).

[0108] The conditions for determining whether to generate a message can be determined based on safety-related applications and / or other applications using CAN information, including applications related to road safety, traffic efficiency, infotainment, business, and / or other applications. In an illustrative example, ITS 455 can perform lane change assistance or negotiation. For example, using CAN information, ITS 455 can determine that the driver of vehicle 404 is trying to change the lane from the current lane to an adjacent lane (e.g., based on the signal light being activated, based on the user suddenly turning or turning to an adjacent lane, etc.). Based on determining that vehicle 404 is trying to change lanes, ITS455 can determine that a lane change condition has been met, which is associated with a message to be sent to other vehicles near the vehicle in the adjacent lane. ITS 455 can trigger the ITS stack to generate one or more messages for transmission to other vehicles, which can be used to negotiate lane changes with other vehicles. Other examples of applications include forward collision warning, automatic emergency braking, lane departure warning, pedestrian avoidance or protection (e.g., when a pedestrian is detected near vehicle 404, such as based on V2P communication with the user's UE), traffic sign recognition, etc.

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

[0110] The security layer of ITS 455 can be used to securely sign messages from the ITS stack that are sent to and verified by other UEs (such as other vehicles, pedestrian UEs, and / or infrastructure systems) configured for V2X communications. The security layer can also verify messages received from such other UEs. In some implementations, the signing and verification process can be based on the security context of the vehicle. In some examples, the security context can include one or more encryption-decryption algorithms, public and / or private keys for generating signatures using encryption-decryption algorithms, and / or other information. For example, each ITS message generated by ITS 455 can be signed by the security layer of ITS 455. The signature can be derived using a public key and an encryption-decryption algorithm. The vehicle, pedestrian UE, and / or infrastructure system that receives the signed message can verify the signature to ensure that the message comes 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.

[0111] In some examples, the ITS 455 can determine certain operations to be performed (e.g., V2X-based operations) based on messages received from other UEs. The operations can include safety-related and / or other operations, such as operations for road safety, traffic efficiency, infotainment, business, and / or other applications. In some examples, the operations can include causing the vehicle (e.g., the control system 452) to perform automatic functions, such as automatic braking, automatic steering (e.g., to maintain a forward direction in a particular lane), automatic lane change negotiation with other vehicles, and other automatic functions. In an illustrative example, the communication system 458 can receive a message from another vehicle (e.g., via a PC5 interface, a DSRC interface, or other device-to-device direct interface) indicating that the other vehicle is about to stop suddenly. In response to receiving the message, the ITS stack can generate a message or instruction, and can send the message or instruction to the control system 452, which can cause the control system 452 to automatically brake the vehicle 404 so that the vehicle 404 stops before colliding with the other vehicle. In other illustrative examples, operations may include triggering the display of a message warning the driver that another vehicle is in the lane alongside the vehicle, a message warning the driver to stop the vehicle, a message warning the driver that pedestrians are in an upcoming crosswalk, a message warning the driver that a toll booth is within a certain distance of the vehicle (e.g., within 1 mile), and the like.

[0112] In some examples, ITS 455 may receive a large number of messages from other UEs (e.g., vehicles, RSUs, etc.), in which case ITS 455 will authenticate (e.g., decode and decrypt) each message and / or determine which operations to perform. Such a large number of messages may result in a large computational load on the vehicle computing system 450. In some cases, the large computational load may result in an increase in the temperature of the computing system 450. The increased temperature of the components of the computing system 450 may adversely affect the ability of the computing system 450 to handle a large number of incoming messages. Based on the temperature of the vehicle computing system 450 (or its components) exceeding or approaching one or more thermal levels, one or more functions may be transferred from the vehicle 404 to another device (e.g., user equipment, RSU, etc.). Transferring one or more functions may reduce the computational load on the vehicle 404, thereby helping to reduce the temperature of the components. A thermal load balancer may be provided that enables the vehicle computing system 450 to perform thermal-based load balancing to control the processing load according to the temperature of the computing system 450 and the processing capacity of the vehicle computing system 450.

[0113] The computing system 450 also includes one or more sensor systems 456 (e.g., a first sensor system to an Nth sensor system, where N is a value equal to or greater than 0). When multiple sensor systems are included, the sensor systems 456 may include different types of sensor systems that may be arranged on or in different parts of the vehicle 404. The sensor systems 456 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 systems (GNSS) receiver systems (e.g., one or more global positioning system (GPS) receiver systems), accelerometers, gyroscopes, inertial measurement units (IMUs), infrared sensor systems, laser rangefinder systems, ultrasonic sensor systems, infrasound 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 450 of the vehicle 404.

[0114] Although vehicle computing system 450 is shown as including certain components and / or systems, one of ordinary skill will appreciate that vehicle computing system 450 may include more than Figure 4. For example, the vehicle computing system 450 may also include one or more input devices and one or more output devices (not shown). In some implementations, the vehicle computing system 450 may also include (e.g., as part of or separate from the control system 452, the infotainment system 454, the communication system 458, and / or the sensor system 456) at least one processor and at least one memory having computer executable instructions executed by the at least one processor. The at least one processor communicates with and / or is electrically connected to (referred to as "coupled to" or "communicatively coupled to") 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, a read-only memory (ROM), a random access memory (RAM) (e.g., a static RAM (SRAM)), an electrically erasable programmable read-only memory (EEPROM), a flash memory, one or more buffers, one or more databases, and / or other memories. Computer-executable instructions stored in or on at least one memory may be executed to perform one or more of the functions or operations described herein.

[0115] Figure 5 An example of a computing system 570 of a user device 507 is shown. The user device 507 is an example of a UE that can be used by an end user. For example, the user device 507 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 the user to communicate through a wireless communication network. The computing system 570 includes software and hardware components that can be electrically coupled or communicatively coupled (or can communicate in other ways as appropriate) via a bus 589. For example, the computing system 570 includes one or more processors 584. The one or more processors 584 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. The bus 589 may be used by one or more processors 584 to communicate between multiple cores and / or to communicate with one or more memory devices 586.

[0116] The computing system 570 may also include one or more memory devices 586, one or more digital signal processors (DSPs) 582, one or more SIMs 574, one or more modems 576, one or more wireless transceivers 578, an antenna 587, one or more input devices 572 (e.g., a camera, a mouse, a keyboard, a touch-sensitive screen, a touchpad, a keypad, a microphone, and / or other), and one or more output devices 580 (e.g., a display, a speaker, a printer, and / or other).

[0117] The one or more wireless transceivers 578 can receive wireless signals (e.g., signal 588) via antenna 587 from one or more other devices, such as other user devices, vehicles (e.g., the above Figure 4 The vehicle 404), network equipment (e.g., base stations such as eNBs and / or gNBs, WiFI routers, etc.), cloud networks, etc. In some examples, the computing system 570 may include multiple antennas. The wireless signal 588 may be sent via 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 networks. In some examples, one or more wireless transceivers 578 may include an RF front end, which includes one or more components, such as an amplifier, a mixer for down-converting a signal (also called a signal multiplier), 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, and other components. The RF front end can typically handle the selection of the wireless signal 588 and the conversion to baseband or intermediate frequency, and can convert the RF signal to the digital domain.

[0118] In some cases, computing system 570 may include an encoding-decoding device (or codec) configured to encode and / or decode data transmitted and / or received using one or more wireless transceivers 578. In some cases, computing system 570 may include an encryption-decryption device or component configured to encrypt and / or decrypt data transmitted and / or received by one or more wireless transceivers 578 (e.g., in accordance with the AES and / or DES standards).

[0119] One or more SIMs 574 can each securely store an IMSI number and associated keys assigned to a user of the user device 507. As described above, the IMSI and keys can be used to identify and authenticate the subscriber when accessing a network provided by a network service provider or operator associated with one or more SIMs 574. One or more modems 576 can modulate one or more signals to encode information for transmission using one or more wireless transceivers 578. One or more modems 576 can also demodulate signals received by one or more wireless transceivers 578 to decode the transmitted information. In some examples, one or more modems 576 can include a 4G (or LTE) modem, a 5G (or NR) modem, a modem configured for V2X communication, and / or other types of modems. One or more modems 576 and one or more wireless transceivers 578 can be used to transmit data for one or more SIMs 574.

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

[0121] In various aspects, the functionality may be stored as one or more computer program products (e.g., instructions or code) in the memory device 586 and executed by the one or more processors 584 and / or the one or more DSPs 582. The computing system 570 may also include software elements (e.g., located within the one or more memory devices 586) including, for example, an operating system, device drivers, executable libraries, and / or other code, such as one or more applications, which may include a computer program that implements the functionality provided by various aspects, and / or may be designed to implement methods and / or configure systems, as described herein.

[0122] Figure 6An example 600 of wireless communication between devices based on sidelink communication (such as V2X or other D2D communication) is shown. Communication can be based on a time slot structure. For example, a transmitting UE 602 can send a transmission 614 that can be received by a receiving UE 604, 606, 608, for example, including a control channel and / or a corresponding data channel. At least one UE may include an autonomous vehicle or an unmanned aerial vehicle. The control channel may include information for decoding the data channel and may also be used by the receiving device to avoid interference by suppressing transmission on occupied resources during data transmission. The number of TTIs and the RBs to be occupied by the data transmission may be indicated in a control message from the transmitting device. In addition to operating as a receiving device, the UE 602, 604, 606, 608 may each be capable of operating as a transmitting device. Therefore, the UE 606, 608 is shown as sending transmissions 616, 620. Transmissions 614, 616, 620 (and 618 of RSU 607) may be broadcast or multicast to nearby devices. For example, UE 614 may transmit communications intended to be received by other UEs within range 601 of UE 614. Additionally / alternatively, RSU 607 may receive communications from and / or transmit communications 618 to UE 602, 604, 606, 608. UE 602, 604, 606, 608 or RSU 607 may include a detection component. UE 602, 604, 606, 608 or RSU 607 may also include a BSM or mitigation component.

[0123] In wireless communications such as V2X communications, a V2X entity may perform sensor sharing with other V2X entities for cooperation and autonomous driving. Fig. 7A 700, a host vehicle (HV) 702 may detect multiple items within its environment. For example, the HV 702 may detect the presence of a non-V2X entity (NV) 706 at block 732. If the RV1 704 and / or RSU 708 cannot detect the NV 706 themselves, the HV 702 may notify other entities (such as the first remote vehicle (RV1) 704 or the roadside unit (RSU) 708) of the presence of the NV 706. The HV 702 notifying the RV1 704 and / or RSU 708 of the NV 706 is a sharing of sensor information. Reference Figure 7B 710, HV 702 may detect a physical obstacle 712, such as a pothole, debris, or an object that may be an obstacle in the path of HV 702 and / or RV1 704, which has not yet been detected by RV1 704 and / or RSU 708. HV 702 may notify RV1 and / or RSU 708 of the obstacle 712 so that the obstacle 712 may be avoided. Figure 7C720, the HV 702 can detect the presence of a vulnerable road user (VRU) 722 and can share the detection of the VRU 722 with the RV1 704 and the RSU 708 in situations where the RSU 708 and / or RV1 704 may not be able to detect the VRU 722. Fig.7D 730, the HV, upon detecting a nearby entity (e.g., NV, VRU, obstacle), may send a sensor data sharing message (SDSM) 734 to the RV and / or RSU to share the detection of the entity. The SDSM 734 may be a broadcast message such that any receiving device in the vicinity of the HV may receive the message. In some instances, the shared information may be relayed to other entities, such as the RV. For example, referring to Figure 8 800, the HV 802 may detect the presence of the NV 806 and / or the VRU 822. The HV 802 may broadcast the SDSM 810 to the RSU 808 to report the detection of the NV 806 and / or the VRU 822. The RSU 808 may relay the SDSM 810 received from the HV 802 to the remote vehicle so that the remote vehicle is aware of the presence of the NV 806 and / or the VRU 822. For example, the RSU 808 may send the SDSM 812 to the RV1 804, wherein the SDSM 812 includes information related to the detection of the NV 806 and / or the VRU 822.

[0124] Fig. 9 is a diagram illustrating an example of a system 900 for sensor sharing in wireless communications (eg, V2X communications) according to some aspects of the present disclosure. Fig. 9 In FIG. 1 , system 900 is shown as including a plurality of equipped (e.g., V2X-capable) network devices. The plurality of equipped network devices include vehicles (e.g., cars) 910a, 910b, 910c, 910d, and RSU 905. Also shown are a plurality of unequipped network devices, including unequipped vehicles 920, VRUs (e.g., cyclists) 930, and pedestrians 940. System 900 may include, for example, Fig. 9 More or fewer equipped network devices and / or more or fewer unequipped network devices are shown. In addition, system 900 may include, for example Fig. 9 More or fewer different types of equipped network devices (e.g., which may include equipped UEs) and / or more or fewer different types of unequipped network devices (e.g., which may include unequipped UEs) as shown in the examples. Additionally, in one or more examples, the equipped network devices may be equipped with heterogeneous 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.

[0125] Multiple equipped network devices may be able to perform V2X communications. In addition, at least some of the equipped network devices are configured to send and receive sensing signals for radar (e.g., RF sensing signals) and / or LIDAR (e.g., optical sensing signals) to detect nearby vehicles and / or objects. Additionally or alternatively, in some cases, at least some of the equipped network devices are configured to use one or more cameras to detect nearby vehicles and / or objects (e.g., by processing images captured by one or more cameras to detect vehicles / objects). In one or more examples, vehicles 910a, 910b, 910c, 910d and RSU 905 may be configured to send and receive certain sensing signals (e.g., radar and / or LIDAR sensing signals).

[0126] In some examples, some of the equipped network devices may have higher-capability sensors (e.g., GPS receivers, cameras, RF antennas, and / or optical lasers and / or optical sensors) than other equipped network devices of system 900. For example, vehicle 910b may be a luxury vehicle and therefore have more expensive, higher-capability sensors than other vehicles that are economy vehicles. In an illustrative example, vehicle 910b may have one or more LIDAR sensors (e.g., high-capability optical lasers and optical sensors) that are higher-capable than other equipped network devices in system 900. In an illustrative example, the LIDAR of vehicle 910b may be able to detect VRUs (e.g., cyclists) 930 and / or pedestrians 940 with a great deal of confidence (e.g., seventy percent confidence). In another example, vehicle 910b may have a radar (e.g., a high-capability RF antenna) that is higher-capable than other equipped network devices in system 900. For example, the radar of vehicle 910b may be able to detect VRU (e.g., cyclist) 930 and / or pedestrian 940 with a certain confidence level (e.g., eighty-five percent confidence level). In another example, vehicle 910b may have a higher-capable camera (e.g., having higher resolution capabilities, higher frame rate capabilities, better lenses, etc.) than other equipped network devices in system 900.

[0127] During operation of the system 900, the equipped network devices (e.g., RSU 905 and / or at least one of the vehicles 910a, 910b, 910c, 910d) may send and / or receive sensing signals (e.g., RF and / or optical signals) to sense and detect vehicles (e.g., vehicles 910a, 910b, 910c, 910d, and 920) and / or objects (e.g., VRU 930 and pedestrian 940) located in and around the road. The equipped network devices (e.g., RSU 905 and / or at least one of the vehicles 910a, 910b, 910c, 910d) may then use the sensing signals to determine the characteristics (e.g., motion, size, type, heading, and speed) of the detected vehicles and / or objects. An equipped network device (e.g., RSU 905 and / or at least one of vehicles 910a, 910b, 910c, 910d) may generate at least one vehicle-based message 915 (e.g., a V2X message such as a sensor data sharing message (SDSM), a basic safety message (BSM), a collaborative awareness message (CAM), a collective awareness message (CPM), and / or other types of messages) that includes information related to determined characteristics of detected vehicles and / or objects.

[0128] The vehicle-based message 915 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 in which the vehicle or object is traveling, and / or other information related to the vehicle or object), traffic conditions (e.g., low-speed and / or dense traffic, high-speed traffic, information related to an accident, etc.), weather conditions (e.g., rain, snow, etc.), message type (e.g., emergency message, non-emergency or "regular" 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 915 may also include information about the preferences of the equipped network device for receiving vehicle-based messages from certain other equipped network devices. In some cases, the vehicle-based message 915 may include the current capabilities of the equipped network device (e.g., vehicles 910a, 910b, 910c, 910d), such as the sensing capabilities of the equipped network device (which may affect the accuracy of the equipped network device in sensing vehicles and / or objects), processing capabilities, thermal conditions of the equipped network device (which may affect the vehicle's ability to process data), and the health status of the equipped network device.

[0129] In some aspects, the vehicle-based message 915 may include a dynamic neighbor list (also referred to as a local dynamic map (LDM) or dynamic surrounding map) for each of the equipped network devices (e.g., vehicles 910a, 910b, 910c, 910d, and RSU 905). For example, each dynamic neighbor list may include a list of all vehicles and / or objects located within a specific predetermined distance (or distance radius) away from the corresponding equipped network device. In some cases, each dynamic neighbor list includes a map of all vehicles and / or objects located within a specific predetermined distance (or distance radius) away from the corresponding equipped network device, which may include road and terrain topology.

[0130] In some implementations, the vehicle-based message 915 may include a specific use case or safety warning related to the current status of the equipped network device (e.g., vehicles 910a, 910b, 910c, 910d), such as a do not pass warning (DNPW) or a forward collision warning (FCW). In some examples, the vehicle-based message 915 may be in the form of a standard basic safety message (BSM), a collaborative awareness message (CAM), a collective awareness message (CPM), a sensor data sharing message (SDSM) (e.g., SAE J3224 SDSM), and / or other formats.

[0131] Fig.10 is a vehicle-based message (e.g., Fig. 9 1000 is a diagram of an example of a vehicle-based message 915 of FIG. 1000. The vehicle-based message 915 is shown as a sensor sharing message (e.g., SDSM), but may include a BSM, CAM, CPM, or other vehicle-based message as described herein. Fig.10, the vehicle-based message 915 is shown to include host data (HostData) 1020 and detected object data (Detected Object Data) 1010a, 1010b. The host data 1020 of the vehicle-based message 915 may include information related to the sending device of the vehicle-based message 915 (e.g., a sending equipped network entity, such as RSU 905 or an onboard unit (OBU), such as on vehicles 910a, 910b, 910c, 910d). The detected object data 1010a, 1010b of the vehicle-based message 915 may include information related to the detected vehicle or object (e.g., static or dynamic characteristics related to the detected vehicle or object, and / or other information related to the detected vehicle or object). The detected object data 1010a, 1010b may specifically include detected object common data (Detected Object CommonData), detected object vehicle data (Detected Object VehicleData), detected object VRU data (Detected Object VRUData), detected obstacle obstacle data (Detected Obstacle ObstacleData) and detected object misbehaving vehicle data (Detected Object MisbehavingVehicleData).

[0132] These vehicle-based messages 915 are beneficial because they can send messages to equipped network devices (e.g., Fig. 9 The vehicles 910a, 910b, 910c, 910d) provide awareness and understanding of upcoming potential road hazards (e.g., unforeseen oncoming vehicles, accidents, and road conditions).

[0133] As previously described, a sending network device (e.g., a V2X-capable vehicle that generates and sends a vehicle-based message) may misbehave (e.g., operate as a misbehaving vehicle) by sending (e.g., intentionally or unintentionally) a vehicle-based message that contains incorrect (erroneous) information. For example, if the information contained within the sending network device's vehicle-based message identifies an incorrect location (position) of the sending network device, the sending network device may operate as a misbehaving vehicle.

[0134] In one or more cases, a sending network device (e.g., a V2X-capable vehicle that generates and sends vehicle-based messages) may misbehave (e.g., operate as a misbehaving vehicle) by creating invisible V2X phantom objects to disrupt traffic on a road while operating as an attacker. A phantom V2X object is a V2X object (e.g., an object perceived by a V2X-sensor) that is not located at a location (position) indicated by the sending network device. A phantom V2X object is an object that has no physical presence, such as a simulated vulnerable road user (VRU) or a simulated vehicle. An invisible object is an object that is outside the sensor field of view (FoV) or is not in the line of sight (LoS) (e.g., a non-line-of-sight scenario) of a receiving network device (e.g., a V2X-capable vehicle that receives the vehicle-based message).

[0135] In some cases, an attacker can use V2X attacks that are only detectable by sensors. For example, an attacker can create a phantom vehicle that mimics a real vehicle. In another example, an attacker can include false traffic light information in a vehicle-based message (e.g., stating that a traffic light is lit red at a specific time, when the traffic light is actually lit green). The attacker's goal may be to cause the driver to perform unnecessary maneuvers (e.g., slow down), which may cause driver frustration and cause traffic disruptions, which may lead to traffic jams and / or vehicle collisions. Attacks that simulate vehicle mobility may be difficult to detect without the use of sensors (e.g., cameras, radar, and LIDAR).

[0136] Fig.11 1 is a diagram illustrating an example of a vehicle configuration 1100 for a non-line-of-sight (NLoS) scenario in accordance with some aspects of the present disclosure. Fig.11 , several equipped (eg, V2X-capable) network devices 1110a, 1110b, 1110c in the form of a truck are shown. Fig.11 Also shown is an unequipped (eg, non-V2X capable) object 1120 in the form of a pedestrian.

[0137] exist Fig.11 , equipped network devices 1110a, 1110b, 1110c (e.g., trucks) are all shown traveling in the same direction on the road. Specifically, equipped network device 1110a (e.g., truck) is shown traveling in the direction of line 1130b. Unequipped object 1120 (e.g., pedestrian) is shown starting to cross the road in the direction of line 1130a. Thus, the paths of equipped network device 1110a (e.g., truck) and unequipped object 1120 (e.g., pedestrian) should intersect where the two lines 1130a, 1130b intersect on the road.

[0138] The equipped network device 1110a (e.g., a truck) may not be aware of the unequipped object 1120 (e.g., a pedestrian) because the unequipped object 1120 (e.g., a pedestrian) is not in the line of sight (NLoS) of the sensors on the equipped network device 1110a (e.g., a truck) (e.g., not in FoV). In some cases, an attacker (e.g., a vehicle) may send a vehicle-based message (e.g., a BSM or a CAM) to the equipped network device 1110a (e.g., a truck) to notify the equipped network device 1110a (e.g., a truck) that the unequipped object 1120 (e.g., a pedestrian) is heading in the direction of the route 1130a. However, since the unequipped object 1120 (e.g., a pedestrian) is in the NLoS of the equipped network device 1110a (e.g., a truck), the sensors of the equipped network device 1110a (e.g., a truck) cannot sense the unequipped object 1120 (e.g., a pedestrian) to verify whether the unequipped object 1120 (e.g., a pedestrian) has a physical presence or is merely a phantom object.

[0139] As mentioned previously, current V2X-sensor solutions are not adequate to detect certain multiple V2X attacks. For example, current solutions may only scan for a single type of message (e.g., CAM or BSM), while attackers may target multiple message types. For another example, current solutions may rely on only a single detector (e.g., a phantom-V2X detector), and therefore, these current solutions can only detect a single V2X attack.

[0140] In one or more aspects, systems and techniques are provided for optimizing situational awareness of vehicle misbehavior that may cause traffic disruption. The systems and techniques provide a V2X-sensor misbehavior detection system that can utilize information from sensors (e.g., cameras, radars, and LIDARs) to verify (confirm) information (e.g., vehicle and / or traffic infrastructure information) contained within vehicle-based messages (e.g., V2X messages). In one or more aspects, the disclosed system may include multiple processes (e.g., for detectors) that may include, but are not limited to, data alignment, data association, misbehavior reporting, object detection (e.g., via sensors), spatial and temporal alignment, and estimated probabilities of LoS and NLoS objects.

[0141] In some aspects, the systems and techniques may provide a V2X-sensor detector and a management system for the V2X-sensor detector. The systems and techniques may also provide interaction between a misbehavior detection system (MBDS) and the V2X-sensor detector, and interaction between sensor fusion and the V2X-sensor detector. The systems and techniques may be implemented as part of a network device such as a vehicle.

[0142] Fig.12 1200 is a diagram illustrating an example of operations that may be performed by a V2X-sensor misbehavior detection system of a network device, such as a vehicle. For example, diagram 1200 illustrates operations performed by a management system of a V2X-sensor detector (e.g., detector management engine 1215). Diagram 1200 also illustrates the interaction between an MBDS (e.g., fusion / sensor MBDS 1225) and a V2X-sensor detector (e.g., V2X-sensor detector 1230) and between sensor fusion (e.g., fusion / sensor detection engine 1220) and a V2X-sensor detector (e.g., V2X-sensor detector 1230). Fig.12 1200 , a V2X message is received at box 1205 .

[0143] like Fig.12 As shown in Figure 1200, a sensor status check engine 1210 can update and / or check (e.g., periodically update and / or check) the status of one or more sensors of a network device (e.g., a vehicle). For example, the sensor status can depend on whether a sensor of the network device is damaged or blind, and / or can depend on whether weather (e.g., fog or rain) may result in limited sensing capabilities of the sensor. For example, without using a working camera (as an example of a sensor), it may be impossible to check the color of a traffic light contained in a vehicle-based message (e.g., a V2X message).

[0144] In some cases, depending on the sensor state, the sensor (or the sensor state check engine 1210) can create a profile that can include a confidence level in the sensor's sensing capabilities (e.g., for successful sensing within a specific sensing range (such as a 50-meter range)). The confidence level of the sensor can depend on the type of sensor. For example, unlike the performance of a camera, the performance of a radar sensor may not be affected by fog. In some cases, the confidence level of the sensor can range from 0% (e.g., no confidence in the sensor's sensing capabilities within a specific range (such as a 50-meter range)) to 100% (e.g., complete confidence in the sensor's sensing capabilities within a specific range (such as a 50-meter range)). The profile can be sent to the detector management engine 1215.

[0145] After the detector management engine 1215 receives the configuration file from the sensor (or the sensor status check engine 1210), the detector management engine 1215 may know the sensing capability of the sensor and may apply a weight to the sensor data (or sensing information) obtained from the sensor based on the confidence level of the sensor (e.g., 80%). For example, if the configuration file indicates that the sensor has a zero confidence level (e.g., 0%) for sensing within a specific range (e.g., a 50-meter range), the detector management engine 1215 may assign a weight of zero (0) to the sensor data received from the sensor, and therefore, the V2X-sensor detector 1230 may not utilize the sensor data. In this way, depending on the confidence level of the configuration file of the sensor, the detector management engine 1215 may control (e.g., by changing detector parameters) how the V2X-sensor detector 1230 perceives the sensor data obtained from the sensor.

[0146] In one or more cases, the detector management engine 1215 can change parameters (e.g., detector parameters) of the V2X-sensor detector 1230. For example, the detector management engine 1215 can change the maximum detection range of sensor fusion (e.g., the range of sensor data collected by the fusion / sensor detection engine 1220) and / or the maximum azimuth of sensor fusion (e.g., the maximum azimuth of the sensor of sensor data collected by the fusion / sensor detection engine 1220). In some cases, such as extreme weather conditions where a sensor has a zero confidence level (e.g., 0%) for sensing within a specific range (e.g., a 50-meter range), the detector management engine 1215 can simply disable the sensor from sensing (e.g., disable the sensor from obtaining sensor data).

[0147] The fusion / sensor detection engine 1220 may collect (e.g., perform "fusion") sensor data obtained for a specific scenario from at least one sensor (e.g., from multiple sensors). By collecting sensor data from multiple sensors for a specific scenario, rather than collecting sensor data from a single sensor for a specific scenario, it allows the scenario to be detected even if one sensor fails. After the fusion / sensor detection engine 1220 collects (e.g., performs "fusion") sensor data from at least one sensor for a specific scenario, the fusion / sensor detection engine 1220 may send this collected sensor data to the fusion sensor / sensor MBDS 1225.

[0148] After the fusion sensor / sensor MBDS 1225 receives the sensor data from the fusion / sensor detection engine 1220, the fusion sensor / sensor MBDS 1225 may detect and remove simulated sensor objects (e.g., false sensor objects) contained within the sensor data (e.g., by filtering out information or data associated with simulated or facial sensor objects from the sensor data). For example, a simulated (false) pedestrian may simply be an image (e.g., a picture) of a pedestrian projected (displayed) on the road. The fusion sensor / sensor MBDS 1225 may remove any detected simulated (false) objects in the sensor data. Removing simulated (false) objects in the sensor data may allow for a reduction in erroneous assumptions about the presence of objects made based on the sensor data. After the fusion sensor / sensor MBDS 1225 removes any detected simulated (false) objects in the sensor data, the fusion sensor / sensor MBDS 1225 may send the filtered sensor data to the V2X-sensor detector 1230.

[0149] The V2X-sensor detector 1230 may receive the V2X message at block 1205, the detector parameters from the detector management engine 1215, the filtered sensor data from the fused sensor / sensor MBDS 1225, and in some cases a map. The map may include global navigation satellite system (GNSS) data and a local map 1235. After the V2X-sensor detector 1230 receives these inputs, the V2X-sensor detector 1230 may analyze (compare) these inputs to determine if there is malicious behavior (e.g., incorrect information contained in the V2X message). In one or more aspects, the V2X-sensor detector 1230 may include a plurality of different detectors, which may include, but are not limited to, Fig.13 detectors for detecting phantom objects, Fig.15 A detector for detecting simulated (false) free space, and Fig.18 Detector for detecting inconsistent number of CPM objects.

[0150] After the V2X-sensor detector 1230 analyzes (compares) the inputs to determine whether malicious behavior exists, the V2X-sensor detector 1230 may send its results to the detector aggregator 1240. The detector aggregator 1240 may aggregate (combine) the results received from the V2X-sensor detector 1230. Then, based on the aggregated results, it may be determined at block 1245 (e.g., by at least one processor) whether malicious behavior has been detected. If it is determined that malicious behavior has not been detected, the V2X application may continue at block 1250. However, if it is determined that malicious behavior has been detected, the detected misbehavior may be reported to a misbehavior server of a misbehavior authority at block 1255, for example, in a misbehavior report (MBR).

[0151] Fig.13 is a flow chart illustrating an example of a process 1300 for the operation of a detector for detecting ghosted objects using a sensor, wherein the detector may be used to Fig.12 The V2X-sensor detector 1230. Fig.13 In process 1300 of FIG. 1 , the detector may collect V2X data (e.g., information contained within a V2X message) at block 1305. After the detector collects the V2X data, the detector may check the sensor FoV at block 1310 to determine whether the sensor can detect a V2X object (e.g., within the collected V2X data) (e.g., whether the V2X object is within the sensor's FoV, which may be defined by X and Y coordinates and a Z coordinate (such as height)). If the detector determines that the V2X object is not within the sensor's FoV (a no decision at block 1315), the detector may simply remain idle 1355.

[0152] However, if the detector determines that the V2X object is within the sensor's FoV (a yes decision at block 1315), the NLoS aggregator 1325 may aggregate the collected V2X data with non-V2X data 1320 (e.g., map information related to the V2X object). After the NLoS aggregator 1325 has aggregated the data, the detector may determine whether the V2X object is in the sensor's NLoS at block 1330. If the detector determines that the V2X object is in the sensor's NLoS, the detector may simply remain idle at block 1355.

[0153] At block 1335, the detector may collect sensor / fusion data (e.g., sensor data from at least one sensor for a particular scene related to the V2X object). If the detector determines that the V2X object is not in the NLoS of the sensor, the detector may determine whether there is an association between the sensor object (e.g., within the collected sensor / fusion data) and the V2X object (at block 1340) (e.g., whether the sensor object confirms the presence of the V2X object) by using the collected sensor / fusion data.

[0154] The detector may then determine whether malicious behavior has been detected (e.g., when there is no sensor object that can confirm the presence of the V2X object, malicious behavior exists) at block 1345. If the detector determines that malicious behavior has not been detected (e.g., there is a sensor object that can confirm the presence of the V2X object), the detector may simply remain idle 1355. However, if it is determined that malicious behavior has been detected (e.g., there is no sensor object that can confirm the presence of the V2X object), the detector may generate an inappropriate behavior report 1350 reporting the inappropriate behavior (e.g., a ghost object).

[0155] In one or more aspects, the NLoS aggregator 1325 can rely on a set of techniques to determine whether a V2X object is located within the NLoS or LoS of a sensor of an equipped (e.g., V2X-capable) network device (e.g., a vehicle). The output of the NLoS aggregator 1325 can be based on aggregating the output from each NLoS technique. In some cases, the aggregation technique can be a majority vote.

[0156] The techniques utilized by the NLoS aggregator 1325 may include computational geometry techniques. As previously described, the estimated probabilities of LoS and NLoS objects may be used to estimate whether the LoS path is blocked by another vehicle by using, for example, a local dynamic map (e.g., an embedded map) and a calculation of a three-dimensional LoS. To estimate whether the LoS path is blocked by another vehicle, a calculation formula for the LoS probability (e.g., P(LoS)) may be utilized (e.g., Fig.14 The formulas for highway and urban driving scenarios in Table 1400 of ) are provided, where the distance (d) is between the HV (e.g., vehicle) and the RV (e.g., V2X object), and the HV and RV should be on the same road. In some cases, the HV and RV may be on different roads (e.g., if the HV and RV are still close to each other). The vehicle's embedded maps and sensors may each provide the location of non-V2X obstacles. Highway and urban driving scenarios may be determined based on the type of road (e.g., which may be determined by using an embedded map), the perceived speed limit of the road, and the average own speed driven over a particular time period.

[0157] In one or more aspects, the distance (d) may be the difference between the location of an equipped (e.g., V2X-capable) network device (e.g., a vehicle) and the location of the V2X object (e.g., a location within a vehicle-based message such as a BSM), or may be determined by a received signal strength indicator (RSSI) based on a vehicle-based message (e.g., a BSM). In some aspects, an embedded map and the location of the V2X object (e.g., a location within a vehicle-based message such as a BSM) may be used to make a same road determination (e.g., whether the V2X object is located on the same road as the vehicle). In one or more aspects, an environment determination (e.g., whether it is a highway or an urban scenario) may be made using road infrastructure (e.g., traffic sign) sensors, an embedded map, and / or an average own speed (e.g., of the vehicle) over a period of time. In some aspects, a single threshold approach may be used for state determination (e.g., whether the V2X object is located in the NLoS or LoS of the vehicle's sensors), such as if the probability of LoS (P(LoS)) is greater than a probability threshold, then the V2X object is determined to be located within the vehicle's LoS.

[0158] Fig.15 is a diagram 1500 showing an example of the operation of a detector for detecting simulated (false) free space, where the detector may be used Fig.12 The V2X-sensor detector 1230. Fig.15 As shown in FIG. 1500 of FIG. 1505 , the detector may collect a V2X message, such as a CPM. After the detector collects the V2X message (e.g., CPM), the detector may check an identification (ID) of the V2X message at block 1510. After the detector checks the V2X ID, the detector may determine whether the ID of the V2X message is a bad (e.g., invalid) ID at block 1515. If the detector determines that the V2X ID is bad (a yes decision at block 1515), the detector may report misbehavior at block 1560 (e.g., reporting that the V2X message has an invalid ID). If the detector determines that the V2X ID is valid or not bad (a no decision at block 1515), operations may proceed to operation 1540, as described below.

[0159] The sensor status check engine 1520 may include Fig.12 For example, the sensor status check engine 1520 can update and / or check (e.g., periodically update and / or check) the sensor status of one or more sensors to generate a configuration file, which is sent to the detector management engine 1525. The detector management engine 1525 can receive the configuration file and can be similar to Fig.12The detector management engine 1215 operates to generate detector parameters, which are sent to the V2X-sensor detector 1540.

[0160] The sensor detection engine 1530 may operate similarly to the fusion / sensor detection engine 1220 to collect all sensor data obtained for a particular scenario from at least one sensor (e.g., from multiple sensors). The sensor detection engine 1530 may send the collected sensor data to the sensor MBDS 1535. The sensor MBDS 1535 may receive the collected sensor data and operate similarly to the fusion sensor / sensor MBDS 1225 to detect and remove (filter out) simulated (false) sensor objects contained in the sensor data. The sensor MBDS 1535 may send the filtered sensor data to the V2X-sensor detector 1540.

[0161] If the detector determines at block 1515 that the V2X ID is valid or not bad, the V2X-sensor detector 1540 may receive detector parameters from the detector management engine 1525 and filtered sensor data from the sensor MBDS 1535. The V2X-sensor detector 1540 may analyze (compare) these inputs to determine if there is malicious behavior (e.g., the sensor object is actually located in the "free space" indicated in the CPM). In some cases, the V2X-sensor detector 1540 may send the detector results to a detector aggregator 1545, which may be similar to the detector aggregator 1240. The detector aggregator 1545 may aggregate (combine) the results received from the V2X-sensor detector 1540. In this case, based on the aggregated results, it may be determined at block 1550 (e.g., by at least one processor) whether malicious behavior has been detected. If the V2X-sensor detector 1540 (or the detector aggregator 1545) determines that there is no malicious behavior (e.g., the sensor object is not located in the "free space" indicated in the CPM, and therefore, the indicated "free space" is actually free space), the V2X application can continue at block 1555. However, if the V2X-sensor detector 1540 (or the detector aggregator 1545) determines that there is malicious behavior (e.g., the sensor object is actually located in the "free space" indicated in the CPM, and therefore, the indicated "free space" is not actually free space), the detector can report the improper behavior at block 1560 (e.g., report that the sensor object is actually located in the "free space" indicated in the CPM).

[0162] Fig.16A , Fig. 16B , Fig. 16C and Fig.16DEach shows an example of a different view 1600, 1601, 1602, 1603. Specifically, Fig.16A is a diagram showing an example of a ground truth view 1600. Fig.16A , a network device 1610a (e.g., a vehicle) that sends equipment (e.g., having V2X capabilities) and a network device 1610b (e.g., a vehicle) that receives equipment (e.g., having V2X capabilities) are shown. The network device 1610a (e.g., a vehicle) that sends equipment (e.g., having V2X capabilities) may send a CPM to the network device 1610b (e.g., a vehicle) that receives equipment (e.g., having V2X capabilities). Fig.16A Depicted is a ground truth view relevant to this use case.

[0163] exist Fig.16A 16 shows a sensor FoV 1620a of a transmitting (e.g., V2X-capable) network device 1610a (e.g., a vehicle) and a sensor FoV 1620b of a receiving (e.g., V2X-capable) network device 1610b (e.g., a vehicle). V2X objects 1640 are in both FoVs 1620a, 1620b. Non-V2X objects 1630 are located in the LoS of both the transmitting (e.g., V2X-capable) network device 1610a (e.g., a vehicle) and the receiving (e.g., V2X-capable) network device 1610b (e.g., a vehicle). In this way, the ground truth view 1600 can include both V2X objects (e.g., V2X objects 1640) and non-V2X objects (e.g., non-V2X objects 1630).

[0164] Fig. 16B 16 is a diagram showing an example of a collective awareness message (CPM) view 1601. Fig. 16B , a transmitting network device 1610a (e.g., a vehicle) is shown. Fig. 16B A CPM view of a CPM emitted (sent) by a transmitting equipped (e.g., V2X-capable) network device 1610a (e.g., a vehicle) is shown. The CPM view does not include any objects sensed by a sensor that is a V2X-sensor, and therefore, the CPM view should not include any V2X objects.

[0165] "Free space" as indicated in CPM is shown (e.g., free space in CPM 1621). CPM object (Tx) 1641 as perceived by sensors of a transmitting (e.g., V2X-capable) network device 1610a (e.g., vehicle) is also shown. Shaded space 1631 depicts an area that is not visible to sensors of a transmitting (e.g., V2X-capable) network device 1610a (e.g., vehicle) because the CPM object (Tx) 1641 blocks (obstructs) the field of view of the transmitting (e.g., V2X-capable) network device 1610a (e.g., vehicle).

[0166] Fig. 16C 1602 is a diagram illustrating an example of a receiver (Rx) sensor view 1602. Fig. 16C , a transmitting equipped (e.g., V2X capable) network device 1610a (e.g., vehicle) and a receiving equipped (e.g., V2X capable) network device 1610b (e.g., vehicle) are shown. The sensor FoV 1622 of the receiving equipped (e.g., V2X capable) network device 1610b (e.g., vehicle) is shown to include sensor objects (Rx) 1632a, 1632b sensed by sensors of the receiving equipped (e.g., V2X capable) network device 1610b (e.g., vehicle). The Rx sensor view may include both non-V2X objects and V2X objects.

[0167] Fig.16D 1603 is a diagram showing an example of the overall Rx view 1603. Fig.16D , a network device 1610a (e.g., a vehicle) that transmits equipment (e.g., having V2X capabilities) and a network device 1610b (e.g., a vehicle) that receives equipment (e.g., having V2X capabilities) are shown. In particular, Fig.16D An example of a detector checking for inconsistencies in free space is shown. For example, a receiving-equipped (e.g., V2X-capable) network device 1610b (e.g., a vehicle) may check for inconsistencies in a CPM sent (transmitted) by a transmitting-equipped (e.g., V2X-capable) network device 1610a (e.g., a vehicle).

[0168] Free space in CPM 1633 (e.g., an area indicated as free space in the CPM) is shown as including shadow space 1643. A sensor of a receiving equipped (e.g., V2X-capable) network device 1610b (e.g., a vehicle) may detect two objects in free space in CPM 1633 (e.g., within sensor FoV 1623). FoV 1623 may include object 1653, which may be a CPM object (Tx) (e.g., an object indicated in a transmitted CPM) and a sensor object (Rx) (e.g., an object sensed by a sensor on receiving vehicle 1610b). Since object 1653 is both a CPM object (Tx) and a sensor object (Rx), object 1653 has been verified.

[0169] FoV 1623 may also include object 1663, which may be a sensor object (Rx) (e.g., an object sensed by a sensor on receiving vehicle 1610b) and a V2X object (e.g., an object sensed by a V2X-sensor). V2X objects should not be included in CPM. Since CPM has defined the area of ​​object 1663 as "free space", but object 1663 has been detected by a sensor on receiving vehicle 1610b, there is an inconsistency of object 1663. Since there is an inconsistency of object 1663, an alert may be generated regarding simulated (false) "free space" in the area of ​​object 1663.

[0170] Fig.17 is a flow chart illustrating an example process 1700 that may be performed by a detector for detecting simulated (false) free space, wherein the detector may be used to Fig.12 The V2X-sensor detector 1230. Fig.17 In process 1700, the detector may receive an incoming CPM at block 1710. After the detector receives the CPM, at block 1720, the detector may perform data alignment at block 1730 to align (e.g., in time and space) the "free space" data in the CPM and the object data from the sensor / fusion object (e.g., object data obtained from the sensor).

[0171] After the detector has aligned the "free space" data in the CPM and the object data from the sensor / fusion object, the detector may determine at box 1750 whether there is any positional overlap (e.g., any overlap of positions) of the sensor object (e.g., based on the length and width of the object, which may have its area represented in the form of a square or rectangular shape) at box 1740 in the CPM "free space". If the detector does not determine that there is any positional overlap of the sensor object in the CPM "free space", the detector may remain idle at box 1770 and may output an output in the form of a Boolean indicator (e.g., an output of zero to indicate "no"). However, if the detector determines that there is some positional overlap of the sensor object in the CPM "free space", the detector may generate a misbehavior report (MBR) at box 1760 and output an output in the form of a Boolean indicator (e.g., an output of 1 to indicate "yes"). The detector may transmit (send) the misbehavior report to a misbehavior authority. The misbehavior report may indicate the detector that triggered (e.g., the specific detector that generated the misbehavior report) and contain evidence of misbehavior (e.g., CPM and sensor data).

[0172] Fig.18 is a flow chart illustrating an example of a process 1800 of operation of a detector for detecting inconsistent numbers of CPM objects, wherein the detector may be used to Fig.12 The V2X-sensor detector 1230. Fig.18 In process 1800, the detector may receive an incoming CPM at block 1810, which may include CPM object (CPMO) data. At block 1820, the detector may collect required V2X-sensor fusion object (VSFO) data. In one or more aspects, the VSFO data may include the position, velocity, and heading of a V2X-sensor fusion object (e.g., an object sensed by a V2X-sensor).

[0173] After the detector receives the CPM and VSFO, the detector may perform data alignment to align (e.g., in time and space) the CPMO data and the VSFO data at block 1830. After the detector aligns the CPMO data and the VSFO data, the detector may perform association to associate objects in the CPMO data with objects in the VSFO data at block 1840. After the detector associates objects in the CPMO data with objects in the VSFO data, at block 1850, the detector may determine whether there are any unassociated objects in the CPMO data or in the VSFO data.

[0174] If the detector determines that there are no unassociated objects in the CPMO data or the VSFO data, the detector may simply remain idle 1890. However, if the detector determines that there is at least one unassociated object in the CPMO data or in the VSFO data, the detector may determine at box 1860 whether the unassociated object is a CMPO or a VSFO. If the detector determines that the unassociated object is a CMPO, the detector may generate a misbehavior report at box 1880. However, if the detector determines that the unassociated object is a VSFO, at box 1870, the detector may determine whether the unassociated VSFO has been announced in the past CPM. If the detector determines that the VSFO object has been announced in the past (previous) CPM, the detector will remain idle at box 1890. However, if the detector determines that the VSFO object has been announced in the past (previous) CPM, the detector may generate a misbehavior report at box 1880. In one or more aspects, the generation and transmission of the misbehavior report at box 1880 may be performed as specified in ETSI TS103 759.

[0175] Fig.19A , 19B , 19C, 19D and 19E are shown together to show that Fig.18 Figure 1900, 1901, 1902, 1903, 1904, an example of the process performed by the detector for detecting simulated (false) CPM objects. Fig.19A , Fig.19B , Fig.19C , Fig.19D and Fig.19E , a network device 1910a (e.g., a vehicle) that is transmitting equipment (e.g., having V2X capabilities) and a network device 1910b (e.g., a vehicle) that is receiving equipment (e.g., having V2X capabilities) are shown. Fig.19A , Fig.19B , Fig.19C , Fig.19D and Fig.19E 1 shows free space in a CPM 1920 for a network device 1910a (e.g., a vehicle) equipped to transmit (e.g., with V2X capabilities), and a sensor FoV 1930 for a network device 1910b (e.g., a vehicle) equipped to receive (e.g., with V2X capabilities).

[0176] Fig.19A An example of a process for collecting a desired VSFO is shown (e.g., Fig.18 1820). Fig.19A, CPM objects (Tx) 1940a, 1940b (e.g., objects contained in the CPM transmitted by the transmitting vehicle 1910a) and VSFO (Rx) 1980a, 1980b, 1980c (e.g., VSFO detected by the receiving vehicle 1910b) are shown. Fig.19A , a shadow space (CPM) 1950 (eg, a space that is undetectable by the sending vehicle 1910a) and a shadow space (sensor) 1995 (eg, a space that is undetectable by the receiving vehicle 1910b) are shown.

[0177] Also shown in object 1990, it can be associated with both a CPM object (Tx) (e.g., an object contained within a CPM sent by a sending vehicle 1910a) and a VSFO object (Rx) (e.g., a VSFO detected by a receiving vehicle 1910b). Since object 1990 can be associated with both a CPM object (Tx) and a VSFO object (Rx), object 1990 can be verified.

[0178] exist Fig.19A , a V2X object 1970 is shown, as well as an object 1960 that may be associated with both a V2X object and a VSFO object (Rx). Since CPM only contains objects that are non-V2X objects (e.g., CPM cannot include V2X objects), they should be removed (deleted). Fig.19A Therefore, any object in the V2X object should be Fig.19A Removed objects 1970 and 1960.

[0179] Fig.19B , 19C and 19D show an example of the association process (e.g., Fig.18 1840). Fig.19B Similar to Fig.19A , except that objects 1970 and 1960 have been removed. Fig.19B , object 1980b is shown as not being within the field of view of free space in CPM 1920. Since object 1980b is not within the field of view of free space in CPM 1920, object 1980b should be removed (deleted) so that only objects that can be sensed by the transmitting equipped (e.g., V2X-capable) network device 1910a (e.g., a vehicle) remain.

[0180] Fig.19C Similar to Fig.19B , except that object 1980b has been removed. Fig.19C, object 1940a is shown as not being within the FoV 1930 of the receiving-equipped (e.g., V2X-capable) network device 1910b (e.g., vehicle). Since object 1940a is not within the FoV 1930, object 1940a should be removed (deleted) so that only objects that can be sensed by the receiving-equipped (e.g., V2X-capable) network device 1910b (e.g., vehicle) are retained.

[0181] Fig.19D Similar to Fig.19C , except that object 1940a has been removed (deleted). Fig.19D , object 1940b is obscured from the view of receiving-equipped (e.g., V2X-capable) network device 1910b (e.g., vehicle) because object 1990 is located in front of object 1940b. Object 1980a is obscured from the view of transmitting-equipped (e.g., V2X-capable) network device 1910a (e.g., vehicle) because object 1990 is located in front of object 1980a. Since objects 1940b and 1980a are obscured objects, objects 1940b and 1980a should be removed (deleted).

[0182] Fig.19E The association process (e.g., Fig.18 1840) and the process of generating a misconduct report (e.g., Fig.18 An example of box 1880). Fig.19E Similar to Fig.19D , except that objects 1940b and 1980a have been removed. As previously described, object 1990 can be associated with both a CPM object (Tx) (e.g., an object contained within a CPM sent by a sending vehicle 1910a) and a VSFO object (Rx) (e.g., a VSFO detected by a receiving vehicle 1910b). Thus, since object 1990 can be associated with both a CPM object (Tx) and a VSFO object (Rx), object 1900 can be verified.

[0183] However, object 1980c is a sensor object (Rx) that also does not have a CPM object (Tx) associated with it. Since object 1980c also does not have a CPM object (Tx) associated with it, a misbehavior report can be generated to alert object 1980c. Therefore, a misbehavior report can be generated for objects that are sensor objects (Rx) that also do not have an associated CPM object (Tx). For these situations, the malicious sender may have removed the CPM object from the CPM.

[0184] In some cases, misbehavior reports may also be generated for CPM objects (Tx) that have not yet been associated, such as with sensor objects (Rx). For these cases, a malicious sender may have added simulated (fake) CPM objects to the CPM.

[0185] Fig. 20 is a flow chart illustrating an example of a process 2000 for the operation of a detector for detecting a V2X camera inconsistency, wherein the detector may be used to Fig.12 The V2X-sensor detector 1230. Fig. 20 In process 2000, the detector may receive incoming SPaT and map data (SPaT / MAP) (2010). At block 2040, the detector may associate the information included in the SPaT / MAP with camera (sensor) data (2020) and map data (e.g., GNSS data and local map data) (2030). For example, the detector may associate a traffic light detected with a camera with corresponding lane information in the map data. In some examples, the detector may convert the coordinates of a lane ID, a traffic light ID, and / or the coordinates of a traffic light from a MAP or SPaT to local map coordinates.

[0186] After the detector has associated the information included in the SPaT / MAP with the camera data and the map data, the detector may check (2050) whether the data announced in the SPaT or MAP message (e.g., related to a traffic light) matches the data detected by the camera (e.g., related to a traffic light). For example, the detector may check (verify) whether the number of lanes in the road (e.g., where the vehicle is located) announced by the MAP message matches the number of lanes perceived by the camera and / or the number of lanes contained in the local map.

[0187] After the detector has checked to verify whether the data announced within the SPaT or MAP message matches the data detected by the camera, the detector can determine whether misbehavior has been detected (2060). If the detector does not determine that misbehavior has been detected, the detector can remain idle (2080). However, if the detector determines that misbehavior has been detected, the detector can generate a misbehavior report (2070). In one or more examples, the detector can generate a misbehavior report in the absence of a match. For example, if the detector cannot associate the information included within the SPaT / MAP with the camera (and / or other sensor) data and map data (e.g., GNSS data and / or local map data), the detector may not generate a misbehavior report.

[0188] Fig.2121 is a flow chart illustrating an example of a process 2100 for wireless communication. The process 2100 may be performed by a network device or by a component or system of a network device (e.g., an onboard unit (OBU) of the network device, a chipset of the network device, or other component or system of the network device). For example, the network device may be a vehicle, a user equipment (UE), a roadside unit (RSU), transportation infrastructure, a drone (or an unmanned aerial vehicle (UAE)), or other network device. The network device may be capable of sending, receiving, and processing vehicle-based communications, such as vehicle-to-everything (V2X) communications (e.g., V2X messages). The operations of the process 2100 may be implemented as one or more processors (e.g., Fig. 22 The software components executed and run on the processor 2210 or other processors of the wireless communication device. In addition, the sending and receiving of signals by the wireless communication device in the process 2100 can be implemented, for example, through one or more antennas and / or one or more transceivers (e.g., wireless transceivers) of the network device.

[0189] At block 2110, the network device (or a component, system, or apparatus thereof) may detect an object based on sensor data from at least one sensor of the network device. The at least one sensor may be a camera, a radar sensor, a light detection and ranging (LIDAR) sensor, any combination thereof, and / or other sensor. In some cases, the network device (or a component, system, or apparatus thereof) may remove simulated objects from the sensor data (e.g., using fusion / sensor MBDS 1225).

[0190] At block 2120, the network device (or a component, system, or apparatus thereof) may receive a vehicle-based message including message data associated with an object. The vehicle-based message may be a basic safety message (BSM), a collaborative awareness message (CAM), a collective awareness message (CPM), a sensor data sharing message (SDSM), a decentralized environment message (DENM), a signal, phase, and time (SPaT) message, and / or other types of vehicle-based messages.

[0191] At block 2130, the network device (or a component, system, or apparatus thereof) may compare the sensor data and the message data (e.g., using the detector management engine 1215 and / or the V2X-sensor detector 1230). In some cases, to compare the sensor data and the message data, the network device (or a component, system, or apparatus thereof) may compare the sensor data and the message data with map data. As described herein, the map data may include satellite data, local maps, or both.

[0192] At box 2140, the network device (or its component, system, or device) may detect malicious behavior based on the comparison (e.g., using V2X-sensor detector 1230). In some examples, as described herein, the malicious behavior may be based on the inclusion of incorrect information contained within a vehicle-based message. For example, a misbehaving vehicle or other network device may send a vehicle-based message with incorrect information (e.g., information indicating that a traffic light is red instead of green). In some examples, as further described herein, the incorrect information may include at least one of a phantom object or simulated free space within the vehicle-based message. In some aspects, the network device (or its component, system, or device) may generate a misbehavior report including information associated with the malicious behavior. The network device (or its component, system, or device) may send the misbehavior report to a misbehavior authority (e.g., a server of the misbehavior authority) (or may output the misbehavior report for transmission).

[0193] In some cases, the network device (or a component, system, or apparatus thereof) may disable or enable the first sensor (e.g., using the sensor management engine 1215) based on a state of a first sensor of the at least one sensor, a capability of the first sensor, a characteristic of an environment in which the network device is located, any combination thereof, and / or other factors. The characteristic of the environment may include weather in the environment (e.g., fog, rain, etc.).

[0194] Additionally or alternatively, in some aspects, a network device (or a component, system, or apparatus thereof) may assign or adjust weights of sensor data based on a capability of at least one sensor (e.g., using the detector management engine 1215). Additionally or alternatively, in some aspects, a network device (or a component, system, or apparatus thereof) may adjust a detection range of at least one sensor based on a capability of at least one sensor (e.g., using the detector management engine 1215). The capability of the at least one sensor may be related to the operability of the at least one sensor during a weather condition experienced by the at least one sensor in an environment in which the network device is located.

[0195] Fig. 22 is a block diagram illustrating an example of a computing system 2200 that may be employed by the disclosed V2X-sensor misbehavior detection system according to some aspects of the present disclosure. In particular, Fig. 22 An example of a computing system 2200 is shown, which may be any computing device, for example, constituting an internal computing system, a remote computing system, a camera, or any component thereof, wherein the components of the system communicate with each other using a connection 2205. The connection 2205 may be a physical connection using a bus, or a direct connection into the processor 2210, such as in a chipset architecture. The connection 2205 may also be a virtual connection, a networked connection, or a logical connection.

[0196] In some aspects, the computing system 2200 is a distributed system in which the functionality described in the present disclosure may be distributed across a data center, multiple data centers, a peer-to-peer network, etc. In some aspects, one or more of the described system components represent a number of such components, each component performing some or all of the functionality for which the component is described. In some aspects, a component may be a physical or virtual device.

[0197] The example system 2200 includes at least one processing unit (CPU or processor) 2210 and connections 2205 that communicatively couple various system components including system memory 2215, such as read-only memory (ROM) 2220, and random access memory (RAM) 2225 to the processor 2210. The computing system 2200 may include a cache 2212 of high-speed memory directly connected to the processor 2210, in close proximity to the processor 2210, or integrated as part of the processor 2210.

[0198] Processor 2210 may include any general purpose processor and hardware services or software services, such as services 2232, 2234, and 2236 stored in storage device 2230, which are configured to control processor 2210 as well as special purpose processors where the software instructions are incorporated into the actual processor design. Processor 2210 may essentially be a completely independent computing system including multiple cores or processors, buses, memory controllers, caches, etc. Multi-core processors may be symmetric or asymmetric.

[0199] To enable user interaction, the computing system 2200 includes an input device 2245, which can represent any number of input mechanisms, such as a microphone for voice, a touch-sensitive screen for gesture or graphic input, a keyboard, a mouse, motion input, voice, etc. The computing system 2200 may also include an output device 2235, which may be one or more of a plurality of output mechanisms. In some cases, a multimodal system may enable a user to provide multiple types of input / output to communicate with the computing system 2200.

[0200] The computing system 2200 may include a communication interface 2240, which may generally govern and manage user input and system output. The communication interface may use a wired and / or wireless transceiver to perform or facilitate receiving and / or sending wired or wireless communications, including using an audio jack / plug, a microphone jack / plug, a Universal Serial Bus (USB) port / plug, an Apple TM Lightning TM Ports / plugs, Ethernet ports / plugs, Fiber optic ports / plugs, Proprietary wired ports / plugs, 3G, 4G, 5G and / or other cellular data network wireless signal transmission, BluetoothTM Wireless signal transmission, Bluetooth TM Low energy (BLE) wireless signal transmission, IBEACON TM Wireless signal transmission, radio frequency identification (RFID) wireless signal transmission, near field communication (NFC) wireless signal transmission, dedicated short range communication (DSRC) wireless signal transmission, 802.11 Wi-Fi wireless signal transmission, wireless local area network (WLAN) signal transmission, visible light communication (VLC), world interoperability for microwave access (WiMAX), infrared (IR) communication wireless signal transmission, public switched telephone network (PSTN) signal transmission, integrated services digital network (ISDN) signal transmission, self-organizing network signal transmission, radio wave signal transmission, microwave signal transmission, infrared signal transmission, visible light signal transmission, ultraviolet light signal transmission, wireless signal transmission along the electromagnetic spectrum, or some combination thereof.

[0201] The communication interface 2240 may also include one or more distance sensors (e.g., LIDAR sensors, laser rangefinders, RF radars, ultrasonic sensors, and infrared (IR) sensors) configured to collect data and provide measurements to the processor 2210, whereby the processor 2210 may be configured to perform the determinations and calculations required to obtain various measurements of the one or more distance sensors. In some examples, the measurements may include flight time, wavelength, azimuth, elevation, range, linear velocity, and / or angular velocity, or any combination thereof. The communication interface 2240 may also include one or more global navigation satellite systems (GNSS) receivers or transceivers for determining the location of the computing system 2200 based on one or more signals received from one or more satellites associated with one or more GNSS systems. GNSS systems include, but are not limited to, the US-based GPS, the Russian-based Global Navigation Satellite System (GLONASS), the China-based Beidou Navigation Satellite System (BDS), and the European-based Galileo GNSS. There is no limitation on operating on any particular hardware arrangement, and therefore the basic features here may be easily replaced with improved hardware or firmware arrangements when improved hardware or firmware arrangements are developed.

[0202] The storage device 2230 may be a non-volatile and / or non-temporary and / or computer-readable memory device and may be a hard disk or other type of computer-readable medium that can store data accessible by a computer, such as a magnetic tape cartridge, a flash memory card, a solid-state memory device, a digital versatile disk, a cassette, a floppy disk, a flexible disk, a hard disk, a magnetic tape, a magnetic stripe, any other magnetic storage medium, a flash memory, a memristor memory, any other solid-state memory, a compact disk read-only memory (CD-ROM) disc, a rewritable compact disk (CD) disc, a digital video disk (DVD) disc, a Blu-ray disc (BDD) disc, a holographic disc, another optical medium, a secure digital (SD) card, a micro secure digital (microSD) card, a Memory Card, or a memory card. card, a smart card chip, an EMV chip, a subscriber identity module (SIM) card, a mini / micro / nano / pico SIM card, another integrated circuit (IC) chip / card, a random access memory (RAM), a static RAM (SRAM), a dynamic RAM (DRAM), a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a flash EPROM (FLASH EPROM), a cache memory (e.g., a level 1 (L1) cache, a level 2 (L2) cache, a level 3 (L3) cache, a level 4 (L4) cache, a level 5 (L5) cache, or other (L#) cache), a resistive random access memory (RRAM / ReRAM), a phase change memory (PCM), a spin transfer torque RAM (STT-RAM), another memory chip or box, and / or a combination thereof.

[0203] Storage device 2230 may include software services, servers, services, etc., which, when the code defining such software is executed by processor 2210, enables the system to perform a function. In some aspects, a hardware service that performs a particular function may include a software component stored in a computer-readable medium, which is combined with the necessary hardware components (e.g., processor 2210, connection 2205, output device 2235, etc.) to perform the function. The term "computer-readable medium" includes, but is not limited to, portable or non-portable storage devices, optical storage devices, and various other media capable of storing, containing or carrying instructions and / or data. Computer-readable media may include non-transitory media in which data may be stored and does not include carrier waves and / or transient electronic signals propagated wirelessly or via a wired connection. Examples of non-transitory media may include, but are not limited to, magnetic disks or tapes, optical storage media (e.g., compact disks (CDs) or digital versatile disks (DVDs)), flash memory, memory, or storage devices. The computer readable medium may have stored thereon code and / or machine executable instructions, which may represent a process, function, subprogram, program, routine, subroutine, module, software package, category, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or hardware circuit by transmitting and / or receiving information, data, independent variables, parameters, or memory contents. Information, independent variables, parameters, data, etc. may be transmitted, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.

[0204] Specific details are provided in the above description to provide a thorough understanding of the aspects and examples provided herein, but those skilled in the art will recognize that the present application is not limited thereto. Therefore, although the illustrative aspects of the present application have been described in detail herein, it should be understood that the inventive concept can be implemented and adopted differently in other ways, and the appended claims are intended to be interpreted as including such variations, except being limited by the prior art. The various features and aspects of the above-mentioned application can be used individually or in combination. In addition, without departing from the broader scope of this specification, various aspects can be utilized in any number of environments and applications outside the environment and application described herein. Therefore, the description and the accompanying drawings are considered to be illustrative rather than restrictive. For the purpose of illustration, the method is described in a specific order. It should be understood that in alternative aspects, the method can be performed in an order different from the described order.

[0205] For clarity, in some cases, the present technology may be presented as including separate functional blocks, which include devices, device components, steps or routines in the method embodied in software or a combination of hardware and software. In addition to those components shown in the drawings and / or described in this article, additional components may be used. For example, circuits, systems, networks, processes and other components may be shown as components in block diagram form to avoid obscuring these aspects with unnecessary details. In other examples, known circuits, processes, algorithms, structures and techniques may be shown without unnecessary details to avoid obscuring these aspects.

[0206] In addition, those skilled in the art will appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in conjunction 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 illustrative components, blocks, modules, circuits, and steps have been generally described above in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. Those skilled in the art may implement the described functionality in different ways for each specific application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

[0207] Various aspects may be described above as a process or method depicted as a flowchart, flow diagram, data flow diagram, structure diagram, or block diagram. Although a flowchart may describe an operation as a sequential process, many operations may be performed in parallel or simultaneously. In addition, the order of the operations may be rearranged. A process terminates when its operations are completed, but may have additional steps not included in the figure. A process may correspond to a method, function, procedure, subroutine, subprogram, etc. When a process corresponds to a function, its termination may correspond to the function returning to a calling function or a main function.

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

[0209] In some aspects, computer readable storage devices, media, and memories may include cables or wireless signals including bit streams, etc. However, when referred to, non-transitory computer readable storage media explicitly excludes media such as energy, carrier signals, electromagnetic waves, and signals themselves.

[0210] 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, in some cases, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltage, current, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof, depending in part on the specific application, in part on the desired design, in part on the corresponding technology, etc.

[0211] The various illustrative logic blocks, modules, and circuits described in conjunction with the aspects disclosed herein may be implemented or executed using hardware, software, firmware, middleware, microcode, hardware description language, or any combination thereof, and may adopt any of the various form factors. When implemented in software, firmware, middleware, or microcode, the program code or code segments (e.g., computer program products) for performing the necessary tasks may be stored in a computer-readable or machine-readable medium. (One or more) processors may perform the necessary tasks. Examples of form factors include laptop computers, smart phones, mobile phones, tablet devices, or other small form factor personal computers, personal digital assistants, rack-mounted devices, stand-alone devices, etc. The functions described herein may also be embodied in peripheral devices or add-on cards. As another example, such functions may also be implemented between different chips or different processes executed in a single device on a circuit board.

[0212] The instructions, the medium for transmitting such instructions, the computing resources for executing them, and other structures for supporting such computing resources are example means for providing the functions described in this disclosure.

[0213] 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 general-purpose computers, wireless communication device handsets, or integrated circuit devices, which have multiple uses for applications including wireless communication device handsets and other devices. Any features described as modules or components may be implemented together in an integrated logic device, or individually as discrete but interoperable logic devices. If implemented in software, the techniques may be implemented at least in part by a computer-readable data storage medium including a program code, the program code including instructions for executing one or more of the methods, algorithms, and / or operations described above when executed. A computer-readable data storage medium may form part of a computer program product, which may include packaging materials. A computer-readable medium may include a memory or data storage medium, such as a random access memory (RAM) (e.g., synchronous dynamic random access memory (SDRAM)), a read-only memory (ROM), a non-volatile random access memory (NVRAM), an electrically erasable programmable read-only memory (EEPROM), a flash memory, a magnetic or optical data storage medium, and the like. Additionally or alternatively, the techniques may be implemented at least in part by a computer-readable communication medium 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, such as a propagated signal or wave.

[0214] 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 circuits. This processor may be configured to perform any of the techniques described in the present invention. A general-purpose processor may be a microprocessor; however, in an alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, a plurality of microprocessors, a combination of one or more microprocessors and a DSP core, or any other such configuration. Therefore, the term "processor" as used herein may refer to any of the aforementioned structures, any combination of the aforementioned structures, or any other structure or device suitable for implementing the techniques described herein.

[0215] One of ordinary skill will understand that the less than ("<") and greater than (">") symbols used herein may be replaced by less than or equal to ("≤") and greater than or equal to ("≥") symbols, respectively, without departing from the scope of the present specification.

[0216] Where a component is described as being “configured to” perform certain operations, such configuration may be achieved, for example, by designing electronic circuits or other hardware to perform the operations, by programming programmable electronic circuits (e.g., a microprocessor or other suitable electronic circuits) to perform the operations, or any combination thereof.

[0217] The phrases “coupled to” or “communicatively coupled to” refer to any component that is physically connected to another component, directly or indirectly, and / or any component that communicates directly or indirectly with another component (e.g., connected to other components via a wired or wireless connection and / or other suitable communication interface).

[0218] 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 a set or multiple members of a set (in any combination) satisfy the claim. For example, 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, 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, claim language reciting "at least one of A and B" or "at least one of A or B" may mean A, B, or A and B, and may additionally include items not listed in the set of A and B.

[0219] Illustrative aspects of the disclosure include:

[0220] Aspect 1: A method for wireless communication at a network device, the method comprising: detecting an object based on sensor data from at least one sensor of the network device; receiving, by the network device, a vehicle-based message including message data related to the object; comparing, by the network device, the sensor data and the message data; and detecting malicious behavior by the network device based on the comparison.

[0221] Aspect 2: A method according to Aspect 1, wherein the vehicle-based message is one of the following: a basic safety message (BSM), a collaborative awareness message (CAM), a collective awareness message (CPM), a sensor data sharing message (SDSM), a decentralized environment message (DENM), or a signal, phase and time (SPaT) message.

[0222] Aspect 3: The method according to any one of Aspects 1 to 2 further comprises generating, by the network device, a misbehavior report comprising information associated with the malicious behavior.

[0223] Aspect 4: The method according to Aspect 3 further comprises sending, by the network device, the misconduct report to a misconduct authority.

[0224] Aspect 5: The method according to any one of aspects 1 to 4, wherein the malicious behavior includes incorrect information contained in the vehicle-based message.

[0225] Aspect 6: The method of aspect 5, wherein the incorrect information includes at least one of a phantom object or simulated free space within the vehicle-based message.

[0226] Aspect 7: The method according to any one of aspects 1 to 6 further comprises disabling or enabling the first sensor based on at least one of a state of the first sensor of the at least one sensor, a capability of the first sensor, or a characteristic of an environment in which the network device is located.

[0227] Aspect 8: The method according to aspect 7, wherein the characteristic of the environment includes weather in the environment.

[0228] Aspect 9: The method according to any one of aspects 1 to 8, further comprising allocating or adjusting weights of sensor data based on capabilities of at least one sensor.

[0229] Aspect 10: The method of aspect 9, wherein the capability of the at least one sensor is related to operability of the at least one sensor during weather conditions experienced by the at least one sensor in an environment in which the network device is located.

[0230] Aspect 11: The method according to any one of aspects 1 to 10, further comprising adjusting a detection range of at least one sensor based on a capability of the at least one sensor.

[0231] Aspect 12: The method of aspect 11, wherein the capability of the at least one sensor is related to operability of the at least one sensor during weather conditions experienced by the at least one sensor in an environment in which the network device is located.

[0232] Aspect 13: The method according to any one of aspects 1 to 12 further comprises removing simulated objects from the sensor data.

[0233] Aspect 14: The method according to any one of aspects 1 to 13, wherein the comparing further comprises comparing the sensor data and the message data with the map data.

[0234] Aspect 15: The method according to aspect 14, wherein the map data includes at least one of satellite data or a local map.

[0235] Aspect 16: The method according to any one of aspects 1 to 15, wherein the at least one sensor is at least one of a camera, a radar sensor, or a light detection and ranging (LIDAR) sensor.

[0236] Aspect 17: A method according to any one of Aspects 1 to 16, wherein the network device is one of a vehicle, a user equipment (UE), a roadside unit (RSU), a traffic infrastructure, or a drone.

[0237] Aspect 18: A method according to any one of Aspects 1 to 17, wherein the network device is capable of vehicle-to-everything (V2X) communication.

[0238] Aspect 19: An apparatus for wireless communication, comprising at least one memory and at least one processor (e.g., implemented in a circuit) coupled to the at least one memory. The at least one processor is configured to: detect an object based on sensor data from at least one sensor of a network device; receive, by the network device, a vehicle-based message including message data related to the object; compare, by the network device, the sensor data and the message data; and detect malicious behavior, by the network device, based on the comparison.

[0239] Aspect 20: An apparatus according to Aspect 19, wherein the vehicle-based message is one of the following: a basic safety message (BSM), a collaborative awareness message (CAM), a collective awareness message (CPM), a sensor data sharing message (SDSM), a decentralized environment message (DENM), or a signal, phase and time (SPaT) message.

[0240] Aspect 21: An apparatus according to any one of Aspects 19 to 20, wherein the at least one processor is configured to generate a misconduct report including information associated with the malicious behavior.

[0241] Aspect 22: The apparatus according to Aspect 21, wherein the at least one processor is configured to: output a misconduct report to be sent to a misconduct authority.

[0242] Aspect 23: An apparatus according to any one of Aspects 19 to 22, wherein the malicious behavior includes incorrect information contained within a vehicle-based message.

[0243] Aspect 24: The apparatus of aspect 23, wherein the incorrect information comprises at least one of a phantom object or simulated free space within the vehicle-based message.

[0244] Aspect 25: An apparatus according to any one of Aspects 19 to 24, wherein at least one processor is configured to disable or enable the first sensor based on at least one of a state of the first sensor of the at least one sensor, a capability of the first sensor, or a characteristic of an environment in which the network device is located.

[0245] Aspect 26: The apparatus according to Aspect 25, wherein the characteristic of the environment includes weather in the environment.

[0246] Aspect 27: The apparatus according to any one of aspects 19 to 26, wherein at least one processor is configured to assign or adjust the weight of the sensor data based on the capability of at least one sensor.

[0247] Aspect 28: The apparatus of aspect 27, wherein the capability of the at least one sensor is related to operability of the at least one sensor during weather conditions experienced by the at least one sensor in an environment in which the network device is located.

[0248] Aspect 29: The apparatus according to any one of aspects 19 to 28, wherein the at least one processor is configured to adjust the detection range of the at least one sensor based on the capability of the at least one sensor.

[0249] Aspect 30: The apparatus of aspect 29, wherein the capability of the at least one sensor is related to operability of the at least one sensor during weather conditions experienced by the at least one sensor in an environment in which the network device is located.

[0250] Aspect 31: An apparatus according to any one of aspects 19 to 30, wherein at least one processor is configured to remove simulated objects from the sensor data.

[0251] Aspect 32: An apparatus according to any one of Aspects 19 to 31, wherein, in order to compare the sensor data and the message data, at least one processor is configured to perform the comparison.

[0252] Aspect 33: The apparatus of aspect 32, wherein the map data comprises at least one of satellite data or a local map.

[0253] Aspect 34: An apparatus according to any one of aspects 19 to 33, wherein at least one sensor is at least one of a camera, a radar sensor, or a light detection and ranging (LIDAR) sensor.

[0254] Aspect 35: An apparatus according to any one of Aspects 19 to 34, wherein the network device is one of a vehicle, a user equipment (UE), a roadside unit (RSU), a traffic infrastructure, or a drone.

[0255] Aspect 36: An apparatus according to any one of Aspects 19 to 35, wherein the network device is capable of vehicle-to-everything (V2X) communication.

[0256] Aspect 37: An apparatus according to any one of aspects 19 to 36, wherein the apparatus is implemented as the network device and further comprises at least one transceiver configured to receive a vehicle-based message.

[0257] Aspect 38: A non-transitory computer-readable storage medium comprising instructions stored thereon, which, when executed by one or more processors, cause the one or more processors to perform the operations according to any one of Aspects 1 to 18.

[0258] Aspect 39: An apparatus for wireless communication, comprising one or more components for performing the operations according to any one of Aspects 1 to 18.

[0259] The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects. Therefore, the claims are not intended to be limited to the aspects shown herein, but to be consistent with the full scope of the language claims, wherein, unless otherwise specified, references to singular elements are not intended to mean "one and only one", but "one or more".

Claims

1. A method for wireless communication at a network device, the method comprising: detecting an object based on sensor data from at least one sensor of the network device; receiving, by the network device, a vehicle-based message, the vehicle-based message including message data associated with the object; comparing, by the network device, the sensor data and the message data; as well as Malicious behavior is detected by the network device based on the comparison.

2. The method according to claim 1, wherein: The vehicle-based message is one of: a basic safety message (BSM), a collaborative awareness message (CAM), a collective awareness message (CPM), a sensor data sharing message (SDSM), a decentralized environment message (DENM), or a signal, phase and time (SPaT) message.

3. The method according to claim 1, further comprising: A misbehavior report is generated by the network device including information associated with the malicious behavior.

4. The method according to claim 3, further comprising: The misconduct report is sent by the network device to a misconduct authority.

5. The method according to claim 1, wherein: The malicious behavior includes incorrect information contained within the vehicle-based message.

6. The method according to claim 5, wherein: The incorrect information includes at least one of a ghosted object or simulated free space within the vehicle-based message. 7 . The method of claim 1 , further comprising disabling or enabling a first sensor of the at least one sensor based on at least one of a state of the first sensor, a capability of the first sensor, or a characteristic of an environment in which the network device is located.

8. The method according to claim 7, wherein: The characteristics of the environment include weather in the environment. 9 . The method of claim 1 , further comprising assigning or adjusting a weight for the sensor data based on a capability of the at least one sensor.

10. The method according to claim 9, wherein: The capability of the at least one sensor is related to operability of the at least one sensor during weather conditions experienced by the at least one sensor in an environment in which the network device is located.

11. The method of claim 1 , further comprising adjusting a detection range of the at least one sensor based on a capability of the at least one sensor.

12. The method according to claim 11, wherein: The capability of the at least one sensor is related to operability of the at least one sensor during weather conditions experienced by the at least one sensor in an environment in which the network device is located.

13. The method of claim 1, further comprising removing simulated objects from the sensor data.

14. The method according to claim 1, wherein: The comparing further includes comparing the sensor data and the message data to map data.

15. The method according to claim 14, wherein: The map data includes at least one of satellite data or a local map.

16. The method according to claim 1, wherein: The at least one sensor is at least one of a camera, a radar sensor, or a Light Detection and Ranging (LIDAR) sensor.

17. The method according to claim 1, wherein: The network device is one of a vehicle, a user equipment (UE), a road side unit (RSU), a traffic infrastructure or a drone.

18. The method according to claim 1, wherein: The network devices are capable of vehicle-to-everything (V2X) communications.

19. An apparatus for wireless communication, comprising: at least one memory; as well as At least one processor coupled to at least one memory and configured to: detecting an object based on sensor data from at least one sensor of a network device; receiving a vehicle-based message, the vehicle-based message including message data associated with the object; comparing the sensor data and the message data; as well as Malicious behavior is detected based on the comparison.

20. The device according to claim 19, wherein The vehicle-based message is one of: a basic safety message (BSM), a collaborative awareness message (CAM), a collective awareness message (CPM), a sensor data sharing message (SDSM), a decentralized environment message (DENM), or a signal, phase and time (SPaT) message.

21. The device according to claim 19, wherein The at least one processor is configured to generate a misconduct report including information associated with the malicious behavior.

22. The device according to claim 21, wherein The at least one processor is configured to output the misconduct report for transmission to a misconduct authority.

23. The device according to claim 19, wherein: The malicious behavior includes incorrect information contained within the vehicle-based message.

24. The device according to claim 23, wherein: The incorrect information includes at least one of a ghosted object or simulated free space within the vehicle-based message.

25. The device according to claim 19, wherein The at least one processor is configured to disable or enable a first sensor of the at least one sensor based on at least one of a state of the first sensor, a capability of the first sensor, or a characteristic of an environment in which the network device is located.

26. The apparatus of claim 25, wherein the characteristic of the environment comprises weather in the environment.

27. The device according to claim 19, wherein The at least one processor is configured to assign or adjust a weight for the sensor data based on capabilities of the at least one sensor.

28. The apparatus of claim 27, wherein the capability of the at least one sensor is related to operability of the at least one sensor during weather conditions experienced by the at least one sensor in an environment in which the network device is located.

29. The device according to claim 19, wherein The at least one processor is configured to adjust a detection range of the at least one sensor based on a capability of the at least one sensor.

30. The device according to claim 29, wherein: The capability of the at least one sensor is related to operability of the at least one sensor during weather conditions experienced by the at least one sensor in an environment in which the network device is located.

31. The device of claim 19, wherein the at least one processor is configured to remove simulated objects from the sensor data.

32. The apparatus of claim 19, wherein: To compare the sensor data and the message data, the at least one processor is configured to compare the sensor data and the message data with map data.

33. The device according to claim 32, wherein: The map data includes at least one of satellite data or a local map.

34. The apparatus of claim 19, wherein: The at least one sensor is at least one of a camera, a radar sensor, or a Light Detection and Ranging (LIDAR) sensor.

35. The apparatus of claim 19, wherein the network device is one of a vehicle, a user equipment (UE), a roadside unit (RSU), a traffic infrastructure, or a drone.

36. The apparatus of claim 19, wherein: The network devices are capable of vehicle-to-everything (V2X) communications.

37. The apparatus of claim 19, wherein: The apparatus is implemented as the network device, and further comprises: At least one transceiver is configured to receive the vehicle-based message.

Images