Misbehavior Detection Using Sensor Sharing and Collective Perception

JP2024542174A5Pending Publication Date: 2025-10-14QUALCOMM INC
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
JP2024527212
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Priority Date
2021-11-17
Filing Date
2022-10-19
Publication Date
2025-10-14

AI Technical Summary

Technical Problem

Existing wireless communication systems face challenges in accurately detecting misbehaving devices, particularly in collaborative and automated driving scenarios, where vehicles may inaccurately report the presence or attributes of objects, which can compromise decision-making and safety.

Method used

A system for identifying misreporting of objects by wireless devices using sensor sharing and collective perception, involving the exchange of sensor data and messages to verify the accuracy of reported objects, and implementing redundancy mitigation schemes to address misbehavior.

Benefits of technology

Improves the accuracy and safety of collaborative and automated driving decisions by identifying and mitigating the impact of misbehaving devices, enhancing the reliability of sensor data sharing.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 00000000_0000_ABST
    Figure 00000000_0000_ABST
Patent Text Reader

Abstract

Systems and techniques for verifying object detection are described. For example, an apparatus can obtain sensor data corresponding to a field of view of a vehicle. The apparatus can receive a message from a wireless device. The message includes an indication of at least one object within the field of view of the vehicle and a reported location of the at least one object. The apparatus can further determine whether the wireless device misreported the at least one object based on the sensor data and the message from the wireless device.
Need to check novelty before this filing date? Find Prior Art

Description

[Technical field]

[0001] For example, aspects of the present disclosure relate to an arrangement for detecting misbehaving wireless devices using sensor sharing and collective perception. [Background technology]

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

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

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

[0005] A system, apparatus, method, and computer-readable medium for identifying misbehaving wireless devices are disclosed. According to at least one example, an apparatus for verifying object detection is provided, the apparatus comprising at least one transceiver, at least one memory, and at least one processor coupled to the at least one transceiver and the at least one memory, the at least one processor configured to obtain sensor data corresponding to a field of view of a vehicle, receive via the at least one transceiver a message from a wireless device including an indication of at least one object within the field of view of the vehicle and a reported location of the at least one object, and determine whether the wireless device misreported the at least one object based on the sensor data and the message from the wireless device.

[0006] In another example, a method for verifying object detection is provided that includes acquiring sensor data corresponding to a field of view of a vehicle, receiving a message from a wireless device that includes an indication of at least one object within the field of view of the vehicle and a reported location of the at least one object, and determining whether the wireless device misreported the at least one object based on the sensor data and the message from the wireless device.

[0007] In another example, a non-transitory computer-readable storage medium is provided that includes at least one instruction to cause a computer or processor to obtain sensor data corresponding to a field of view of a vehicle, receive a message from a wireless device including an indication of at least one object within the field of view of the vehicle and a reported location of the at least one object, and determine whether the wireless device misreported the at least one object based on the sensor data and the message from the wireless device.

[0008] In another example, an apparatus is provided for performing location prediction, the apparatus including means for acquiring sensor data corresponding to a field of view of a vehicle, means for receiving a message from a wireless device including an indication of at least one object within the field of view of the vehicle and a reported location of the at least one object, and means for determining whether the wireless device misreported the at least one object based on the sensor data and the message from the wireless device.

[0009] In some aspects, the device is or is a part of a mobile device (e.g., a mobile phone or so-called "smartphone" or other mobile device), a wearable device, an extended reality device (e.g., a virtual reality (VR) device, an augmented reality (AR) device, or a mixed reality (MR) device), a personal computer, a laptop computer, a vehicle, a server computer, a robotic device, or other device. In some aspects, the device includes a camera or cameras for capturing one or more images. In some aspects, the device further includes a display for displaying one or more images, notifications, and / or other displayable data. In some aspects, the devices described above can 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, which subject matter should be understood by reference to the entire specification of this patent, any or all drawings, and appropriate portions of each claim.

[0011] Other objects and advantages associated with the embodiments disclosed herein will be apparent to one of ordinary skill in the art based on the accompanying drawings and detailed description.

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

[0013] [Figure 1]1 is a diagram illustrating an example of a wireless communication system and access network. [Diagram 2] 1 illustrates example aspects of a side link slot configuration in accordance with certain aspects of the present disclosure. [Diagram 3] 1 is a diagram illustrating an example of a first device and a second device engaged in wireless communication (e.g., V2V communication, V2X communication, and / or device-to-device communication) in accordance with certain aspects of the disclosure. [Figure 4] 1 is a diagram illustrating an example of devices involved in wireless communication (e.g., sidelink communication) in accordance with certain aspects of the present disclosure. [Figure 5A] 1 is a diagram illustrating an example of sensor sharing for a cooperative and automated driving system in accordance with some aspects of the disclosure. [Figure 5B] 1 is a diagram illustrating an example of sensor sharing for a cooperative and automated driving system in accordance with some aspects of the disclosure. [Figure 5C] 1 is a diagram illustrating an example of sensor sharing for a cooperative and automated driving system in accordance with some aspects of the disclosure. [Figure 5D] 1 is a diagram illustrating an example of sensor sharing for a cooperative and automated driving system in accordance with some aspects of the disclosure. [Figure 6] 1 is a diagram illustrating an example of sensor sharing for a cooperative and automated driving system in accordance with some aspects of the disclosure. [Figure 7] 1 is a diagram illustrating an example of sensor sharing to identify misbehaving entities, according to some aspects of the disclosure. [Figure 8] 1 is a call flow diagram illustrating an example process for identifying misbehaving entities according to some aspects of the present disclosure. [Figure 9] 1 is a call flow diagram illustrating an example process for reporting a detected misbehaving entity to a remote vehicle, according to some aspects of the disclosure. [Figure 10] 1 is a call flow diagram illustrating an example process for modifying a redundant reporting regime based on detection of a misbehaving entity, in accordance with some aspects of the disclosure. [Figure 11] 1 is a flow diagram illustrating an example process for notifying a remote vehicle of the presence of a misbehaving entity according to some aspects of the disclosure. [Figure 12] 1 is a diagram illustrating an example of a sensor data sharing message structure according to some aspects of the disclosure. [Figure 13] 1 is a diagram illustrating an example of a sensor data sharing message structure according to some aspects of the disclosure. [Figure 14] 1 is a diagram illustrating an example of information elements about detected objects in a sensor data sharing message in accordance with some aspects of the present disclosure. [Figure 15] 1 is a diagram illustrating an example of parameters for a detected object in a sensor data sharing message in accordance with some aspects of the disclosure. [Figure 16] 1 is a flow diagram of an example process for verifying a detected object in accordance with certain aspects of the present disclosure. [Figure 17] 1 is a flow diagram of an example process for verifying a detected object in accordance with certain aspects of the present disclosure. [Figure 18] 1 is a diagram illustrating an example of a hardware implementation of an exemplary apparatus according to some aspects of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

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

[0016] 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" should not necessarily be construed as preferred or advantageous over other aspects. Likewise, the term "aspects of the present disclosure" does not require that all aspects of the present disclosure include the discussed feature, advantage or mode of operation.

[0017] Aspects of the present disclosure relate to features for improving collaborative and automated driving decisions. For example, as described in more detail herein, a vehicle (or other wireless device) may report inaccurate information regarding the presence of a detected object. For example, a vehicle or other wireless device may erroneously report the presence of a non-existent object or may report incorrect attributes for a present object. Some such misreporting cases may be perpetrated by malicious entities, while others may result from perception errors associated with the reporting entity. For example, a malicious entity may execute such attacks to exhaust channel resources and / or effectively launch a Denial-of-Service (DoS) type attack and / or provide false inputs to surrounding vehicles to derail their sensor fusion engine(s). Such attacks may potentially jeopardize the collaborative and automated driving decisions that are the primary goal of sensor sharing and collective perception systems.

[0018] Described herein are systems, apparatus, processes (also referred to as methods), and computer-readable media (collectively referred to herein as systems and techniques) for identifying false reporting of objects by various wireless entities / devices (e.g., vehicles or other wireless devices), and in some cases, for identifying and reporting misbehaving entities / devices. The false object reports may be communicated to other entities, such as other vehicles, and / or cloud infrastructure, such as the Service Control Management Suite (SCMS), and / or other network entities responsible for managing SDSM / CPM misbehavior. Aspects of the disclosed technology provide a collaborative solution for directly and indirectly identifying misbehaving / rogue V2X entities that can improve the accuracy and safety of collaborative and automated driving decisions.

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

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

[0021] Depending on the network being deployed, a base station may operate according to one of multiple RATs to communicate with UEs, road side units (RSUs), and / or other devices, and may alternatively be referred to as an access point (AP), network node, NodeB (NB), evolved NodeB (eNB), next generation eNB (ng-eNB), new radio (NR) NodeB (also referred to as gNB or gNodeB), etc. The base station may be primarily used to support wireless access by UEs, including supporting data, voice, and / or signaling connections for supported UEs. In some systems, the base station may provide edge node signaling functions, while in other systems, it may provide additional control and / or network management functions. The communication link over which a UE may send signals to the base station is referred to as an uplink (UL) channel (e.g., reverse traffic channel, reverse control channel, access channel, etc.). The communication link through which a base station may send signals 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.). The term traffic channel (TCH), as used herein, can refer to either an uplink, a reverse or downlink, and / or a forward traffic channel.

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

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

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

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

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

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

[0028] A base station 102 configured for 4G LTE (collectively referred to as Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network, E-UTRAN) may interface with the EPC 160 through a backhaul link 132 (e.g., an S1 interface). A base station 102 configured for NR (collectively referred to as Next Generation RAN, NG-RAN) may interface with the core network 190 via a backhaul link 184. In addition to other functions, the base stations 102 may perform one or more of the following functions: forwarding user data, encryption and decryption of radio channels, integrity protection, header compression, mobility control functions (e.g., handover, dual connectivity), inter-cell interference coordination, connection setup and release, load balancing, non-access stratum (NAS) message delivery, NAS node selection, synchronization, radio access network (RAN) sharing, multimedia broadcast multicast service (MBMS), subscriber and equipment tracking, RAN information management (RIM), paging, positioning, and alert message delivery. The base stations 102 may communicate with each other directly or indirectly (e.g., through the EPC 160 or the core network 190) via backhaul links 134 (e.g., X2 interfaces). The backhaul links 134 may be wired or wireless.

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

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

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

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

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

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

[0035] The EPC 160 may include a Mobility Management Entity (MME) 162, other MMEs 164, a Serving Gateway 166, a Multimedia Broadcast Multicast Service (MBMS) Gateway 168, a Broadcast Multicast Service Center (BM-SC) 170, and a Packet Data Network (PDN) Gateway 172. The MME 162 may communicate with a Home Subscriber Server (HSS) 174. The MME 162 is a control node that handles signaling between the UE 104 and the EPC 160. In general, the MME 162 provides bearer and connection management. All user Internet protocol (IP) packets are forwarded through the Serving Gateway 166, which is itself connected to the PDN Gateway 172. The PDN Gateway 172 provides allocation of IP addresses for the UEs, as well as other functions. The PDN Gateway 172 and the BM-SC 170 are connected to IP services 176, which may include the Internet, an intranet, an IP Multimedia Subsystem (IMS), PS streaming services, and / or other IP services. The BM-SC 170 may provide functionality for provisioning and delivery of MBMS user services. The BM-SC 170 may act as an entry point for content providers' MBMS transmissions and may be used to authorize and initiate MBMS bearer services in the public land mobile network (PLMN) and may be used to schedule MBMS transmissions.The MBMS Gateway 168 can be used to distribute MBMS traffic to base stations 102 belonging to a Multicast Broadcast Single Frequency Network (MBSFN) area broadcasting a particular service, and may be responsible for session management (start / stop) and collecting eMBMS-related charging information.

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

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

[0038] Some wireless communication networks may include vehicle-based communication devices that may collectively be referred to as vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I) (e.g., from a vehicle-based communication device to a road infrastructure node such as a road side unit (RSU)), vehicle-to-network (V2N) (e.g., from a vehicle-based communication device to one or more network nodes such as a base station), cellular-vehicle-to-everything (C-V2X), enhanced V2X (e-V2X), and / or vehicle-to-anything (V2X) communication capable of communicating from and / or with other devices, as well as combinations thereof.

[0039] Referring again to FIG. 1 , in some aspects, a UE 104, e.g., a transmitting Vehicle User Equipment (VUE) or other UE, may be configured to transmit a message directly to another UE 104. The communication may be based on V2X or other D2D communication, such as Proximity Services (ProSe). The communication based on V2X and / or D2D communication may be transmitted and received by other transmitting / receiving devices, such as a Road Side Unit (RSU) 107. The communication aspect may be based on PC5 or sidelink communication, e.g., as described in connection with the example of FIG. 2 .

[0040] The following description may provide examples of V2X / D2D communications related to 5G NR, however, the concepts described herein may be applicable to other similar domains, such as LTE, LTE-A, CDMA, GSM, and other wireless technologies.

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

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

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

[0044] 3 is a block diagram 300 of a first wireless communication device 310 communicating with a second wireless communication device 350, e.g., via V2V / V2X / or other communication. The device 310 may comprise a receiving device, e.g., a transmitting device, that communicates with the device 350. The communication may be based on a sidelink, e.g., the transmitting device 310 may comprise a UE, an RSU, etc. The receiving device may comprise a UE, an RSU, etc. The packets may be provided to a controller / processor 375 that implements Layer 3 and Layer 2 functionality. Layer 3 includes a radio resource control (RRC) layer, and Layer 2 includes a packet data convergence protocol (PDCP) layer, a radio link control (RLC) layer, and a medium access control (MAC) layer.

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

[0046] In the device 350, each receiver 354RX receives a signal through its respective antenna 352. Each receiver 354RX recovers information modulated onto an RF carrier and provides the information to a receive (RX) processor 356. The TX processor 368 and the RX processor 356 implement Layer 1 functionality related to various signal processing functions. The RX processor 356 may perform spatial processing on the information to recover any spatial streams destined for the device 350. Multiple spatial streams may be combined by the RX processor 356 into a single OFDM symbol stream if destined for the device 350. The RX processor 356 then converts the OFDM symbol stream from the time domain to the frequency domain using a Fast Fourier Transform (FFT). The frequency domain signal includes a separate OFDM symbol stream for each subcarrier of the OFDM signal. The symbols on each subcarrier, as well as the reference signal, are recovered and demodulated by determining the most likely signal constellation point that has been transmitted by the device 310. These soft decisions may be based on channel estimates calculated by a channel estimator 358. The soft decisions are then decoded and deinterleaved to recover the data and control signals originally transmitted by the device 310 on the physical channel. The data and control signals are then provided to a controller / processor 359, which implements Layer 3 and Layer 2 functionality.

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

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

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

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

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

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

[0053] FIG. 4 illustrates an example 400 of wireless communication between devices based on sidelink communication, such as V2X or other D2D communication. The communication may be based on a slot configuration including aspects described in connection with FIG. 2. For example, a transmitting UE 402 may transmit a transmission 414 including, for example, a control channel and / or a corresponding data channel, which may be received by a receiving UE 404, 406, 408. At least one of the UEs may comprise an autonomous vehicle or an unmanned aerial vehicle. The control channel may include information for decoding the data channel and may be used by the receiving device to avoid interference by refraining from transmitting on resources occupied during the data transmission. The number of TTIs, as well as the RBs occupied by the data transmission, may be indicated in a control message from the transmitting device. Each of the UEs 402, 404, 406, 408 may be capable of operating as a transmitting device in addition to operating as a receiving device. Thus, the UEs 406, 408 are shown as transmitting transmissions 416, 420. The transmissions 414, 416, 420 (and 418 by the RSU 407) may be broadcast or multicast to nearby devices. For example, the UE 414 may transmit a communication intended for reception by other UEs within range 401 of the UE 414. Additionally / alternatively, the RSU 407 may receive communications from and / or transmit communications 418 to the UEs 402, 404, 406, 408.

[0054] The UE 402, 404, 406, 408, or RSU 407 may include detection components similar to 198 described in connection with FIG. 1. The UE 402, 404, 406, 408, or RSU 407 may include BSM or mitigation components similar to 199 described in connection with FIG.

[0055] In wireless communication such as V2X communication, a V2X entity may perform sensor sharing with other V2X entities for cooperative and automated driving. For example, referring to the diagram 500 of FIG. 5A, a host vehicle (HV) 502 may detect some items in its environment. For example, the HV 502 may detect the presence of a non-V2X entity (NV) 506 in block 532. The HV 502 may notify other entities such as a first remote vehicle (RV1) 504 or a roadside unit (RSU) 508 about the presence of the NV 506 if the RV1 504 and / or the RSU 508 cannot detect the NV 506 by itself. The HV 502 informing the RV1 504 and / or the RSU 508 about the NV 506 is a sharing of sensor information. Referring to diagram 510 of FIG. 5B, HV 502 may detect a physical obstacle 512, such as a pothole, debris, or object that may be an obstacle in the path of HV 502 and / or RV1 504 that has not yet been detected by RV1 504 and / or RSU 508. HV 502 may notify RV1 and / or RSU 508 of the obstacle 512 so that the obstacle 512 can be avoided. Referring to diagram 520 of FIG. 5C, HV 502 may detect the presence of a vulnerable road user (VRU) 522 and may share the detection of the VRU 522 with RV1 504 and RSU 508 in cases where RSU 508 and / or RV1 504 cannot detect the VRU 522. Referring to diagram 530 of FIG. 5D, when an HV detects a nearby entity (e.g., NV, VRU, fault), it may send a sensor data sharing message (SDSM) 534 to the RV and / or RSU to share the detection of the entity. The SDSM 534 may be a broadcast message such that any receiving device within the vicinity of the HV can receive the message. In some instances, the shared information may be relayed to other entities, such as the RV.For example, referring to diagram 600 of FIG. 6, HV 602 may detect the presence of NV 606 and / or VRU 622. HV 602 may broadcast SDSM 610 to RSU 608 to report the detection of NV 606 and / or VRU 622. RSU 608 may relay SDSM 610 received from HV 602 to the remote vehicle so that the remote vehicle is aware of the presence of NV 606 and / or VRU 622. For example, RSU 608 may send SDSM 612 to RV1 604, where SDSM 612 includes information regarding the detection of NV 606 and / or VRU 622.

[0056] In some cases, a vehicle (or other wireless device) may report inaccurate information in the SDSM 612 regarding the presence of a detected object. For example, the SDSM 612 may erroneously report the presence of a non-existent object or may erroneously report attributes regarding a present object. Some such misreporting cases may be perpetrated by malicious entities, while others may be due to perceptual errors associated with the reporting entity. For example, a vehicle with malfunctioning and / or miscalibrated sensors may report erroneous information regarding objects in the environment, even without malicious intent.

[0057] As mentioned above, systems and techniques are described herein for identifying misreporting of objects by various wireless entities / devices, and in some cases, for identifying and reporting misbehaving entities / devices. The misreported objects may be communicated to other entities, such as other vehicles, and / or cloud infrastructure, such as the Service Control Management Suite (SCMS), and / or other network entities responsible for managing SDSM / CPM misbehavior. Aspects of the disclosed technology provide a collaborative solution for directly and indirectly identifying misbehaving / rogue V2X entities that can improve the accuracy and safety of collaborative and automated driving decisions.

[0058] 7 is a diagram illustrating an example environment 700 in which sensor sharing can be used to identify misbehaving entities. In the example environment 700, a remote vehicle (RV) 702 is shown receiving various messages (e.g., SDSM / CPM) transmitted from multiple host vehicles (HVs), e.g., HV1 704, HV2 706, HV3 708, and HV4 710. In the illustrated example, the RV 702 is located too far away (e.g., outside of a coverage area or communication range) to directly sense / measure an environment 714 corresponding to the field-of-view (FOV) of the HVs 704, 706, 708, and 710. In such a case, the RV 702 can utilize the SDSM transmitted by the HVs (704, 706, 708, and 710) to identify objects detected by one or more sensors of the corresponding vehicles. As an example, the SDSMs received from the HVs 704, 706, 708, and 710 may be used by the RV 702 to detect and infer various objects within the environment 700 that cannot be directly perceived by the RV 702's sensors (e.g., one or more Light Detection and Ranging (LiDAR), radar, and / or camera sensors, etc.). However, because the RV 702's understanding of the environment 714 relies on the received SDSMs, messages sent by rogue / misbehaving entities (e.g., reporting non-existent objects or inaccurate object information) may adversely affect the RV 702's ability to accurately infer about the environment 714.

[0059] In some aspects, various HVs may be equipped to identify misreported objects based on received messages, e.g., SDSM / CPM messages. For example, a detected object indicated in a received SDSM may be verified or corroborated using sensor data collected by a verification vehicle, e.g., the receiving vehicle itself. As an example, by comparing the reported object data with sensor data collected by its own vehicle sensors (e.g., LiDAR, radar, camera, etc.), HV1 704 may verify that an object reported by another vehicle is actually an object that exists. In another illustrative example, in a case where a reported object exists, by comparing the reported object data with sensor data collected by its own vehicle sensors, HV1 704 may verify that the reported object attributes (e.g., object location, object type, and / or kinematic features, etc.) were accurately conveyed.

[0060] In some examples, the determination about the validity of the reported object may be used to classify the reporting entity (e.g., as a rogue or misbehaving device) and report the misbehavior to other entities, such as other V2X vehicles (e.g., via one or more SDSM / CPM transmissions). In some examples, the determination about the validity of the reported object may be used to modify a redundancy mitigation regime, e.g., to increase the frequency of detected object data transmitted to other entities / vehicles. For example, reporting of a misbehaving wireless device (e.g., a vehicle) may be performed via direct reporting or indirectly through modifying the frequency of reporting for other objects in the environment.

[0061] 7, HV3 708 may be a misbehaving / malicious entity that reports a non-existent object 712, for example, via one or more messages (SDSM / CPM) broadcast to RV 702, HV1 704, HV3 708, and HV4 710. In the illustrated configuration, for example, RV 702 cannot directly verify the message received from HV3 708 because the non-existent object 712 is outside of RV 702's field of view, but the message received by HV1 704, HV2 706, and HV4 710 can be verified using their respective collected sensor data. Thus, one or more of HV1 704, HV2 706, and HV4 710 may identify inaccuracies in the reported object data received from HV3 708, classify HV3 708 as a misbehaving entity, and report this classification directly to other vehicles, such as RV 702. In some instances, subsequent messages received by RV 702 from HV3 may be filtered and / or ignored based on classifying HV3 708 as a misbehaving entity.

[0062] In some examples, object validation may be performed on an object-by-object basis, e.g., some objects reported by HV3 may be reported accurately, while others may be reported inaccurately. Thus, messages generated by other HVs (e.g., HV1 704, HV2 706, and HV4 710) may indicate further details about the objects and / or object attributes reported by HV3 708, just as messages broadcast by HV1 704, HV2 706, and / or HV4 710 for HV3 may indicate reported inaccuracies (such as inaccuracies in location, object type, etc.), as well as object information directly observed by the validating HVs. Information about inaccurate object reporting by misbehaving devices (e.g., HV3 708) may be included in one or more SDSM extension fields, as described in further detail below with respect to FIGS. 12-14.

[0063] In some aspects, the identification of a misbehaving entity may be reported indirectly, for example, through modifications to a redundant reporting scheme implemented in response to detection of inaccurate object reports by other vehicles. In such implementations, the frequency of environmental object reporting may be increased so that entities / vehicles outside the reporting field of view, such as the RV 702, can make their own inferences regarding the accuracy of object data reported by other entities. Further discussion of mitigating redundant reporting regimes is provided below with respect to Figures 10 and 11.

[0064] FIG. 8 is a call flow diagram 800 of an exemplary process for identifying misbehaving entities. In the example of FIG. 8, multiple wireless devices, e.g., HV1 802, HV2 804, HV3 806, and HV4 808, are configured to wirelessly communicate data about a surrounding environment, such as environment 714 described above with respect to FIG. 7. Further in the example of FIG. 7, some or all of the devices (e.g., HV1 802, HV2 804, HV3 806, and HV4 808) may share a common field of view such that their respective sensors may perceive / measure properties of objects in a common location. In block 810, HV3 806 sends a message (e.g., SDSM / CPM) indicating the presence of a first object in a field of view shared by one or more of HV1 802, HV2 804, and / or HV4 808. The messages broadcast by HV3 806 may indicate the presence of the object and possibly one or more other object attributes, such as the reported object's location, the object type, the object's kinematic attributes, any combination thereof, and / or other attributes.

[0065] At block 812, HV1 802 compares the message received from HV3 806 to the sensor data collected for the field of view that is supposed to include the reported object. Similar comparisons may be made by each entity that receives a message from HV3 806, such as HV2 804 and HV4 808, as shown in the example of FIG. 8. At block 814, HV1 802 may determine whether HV3 806 is misreporting a first object. For example, HV1 802 may determine whether the first object is indicated in the sensor data collected / received directly by HV1 802. In instances where the reported object is present, HV1 802 may also verify the accuracy of the object attributes reported by HV3 806. In some instances, inaccuracies in the object reporting by HV3 806 may automatically result in a determination by HV1 802 that HV3 806 is misbehaving. For example, in the case where HV3 806 reports a non-existent object, HV1 802 may automatically determine that HV3 806 is a rogue or misbehaving wireless device. In such instances, messages received by other entities may be used to facilitate such a determination. For example, if a message received by HV1 802 from HV2 804 and / or HV4 808 indicates the presence of the reported object, HV1 802 may determine that HV3 806 is not a misbehaving device. In such a scenario, HV1 802 may instead diagnose / identify a defect in one or more of its own sensors or perception capabilities. In another example, HV3 806 may determine that its sensors are faulty based on messages from HV2 804 and / or HV4 808 due to an indication by HV1 802 that the object is a present object. For example, if a sensor of HV3 806 is faulty, the misreported object may be present, but the reported location / characteristics detected by the sensor(s) of HV3 806 may likely not be accurate.Correcting redundancy mitigation (e.g., reducing redundancy mitigation to send more messages), the reported object details can help identify faulty on-board sensors of a device (e.g., HV3 806). In some aspects, if HV3 806 determines that one or more of its sensors are faulty, HV3 806 can recalibrate the faulty sensor or sensors (if possible) and / or disable messaging services (e.g., temporarily disable SDSM services), such as by alerting the driver of HV3 806 to disable messaging services (e.g., SDSM services).

[0066] In some aspects, HV3 806 can track the number of occurrences of neighboring vehicles (e.g., HV2 804, HV4 808, or other vehicles) or other devices “mismatching” it regarding the characteristics of a detected object. The more times HV3 806 receives messages indicating that other vehicles or devices do not match the information reported by HV3 806 regarding the object, the more likely HV3 806 will determine that its own sensor is faulty. When different sets of neighboring devices disagree over time, HV3 806 can build a confidence score regarding the failure of that sensor. Such a solution can help avoid cases where a group of hostile misbehaving vehicles attempt to trick HV3 806 into determining that its sensor is faulty.

[0067] In other examples, inaccuracies in object reporting by HV3 806 may not be determined to constitute misbehavior by HV3 806. For example, if HV3 806 correctly reports the presence of an object but reports incorrect or inaccurate attributes, such as an inaccurate object location, the amount of reported error may be taken into account in determining whether HV3 806 is misbehaving. As an example, inaccuracies in the reported object location may be due to acceptable sensor error and may not result in a determination that HV3 806 is misbehaving. In such instances, a threshold may be used to determine the limit of acceptable error. For example, if the error in the reported object location exceeds a predetermined threshold (e.g., exceeds the magnitude of sensor noise or standard sensor measurement error), HV1 802 may determine that HV3 806 is a misreporting wireless device. As shown in the example of FIG. 8, a similar determination may be performed by one or more of the other wireless devices, e.g., HV2 804 and / or HV4 808.

[0068] If, at block 816, it is determined that HV3 806 is misbehaving, HV1 802 may report the misbehaving device in one or more SDSM / CPMs that are sent to other entities, such as, for example, other vehicles in the same geographic vicinity. In some cases, the detected misbehavior may be reported to, for example, one or more remote vehicles (RVs) that are too far away to directly verify the accuracy of the object report received from HV3 806. Further details regarding scenarios involving remote vehicles are described below with respect to Figures 9, 10, and 11.

[0069] FIG. 9 is a call flow diagram 900 of an example process for reporting a detected misbehaving entity to a remote vehicle (RV). In the example of FIG. 9, the remote vehicle (RV) 902 may represent a wireless device / vehicle that is unable to observe a field of view accessible to other devices in the vicinity, such as HV1 802, HV2 804, and / or HV3 806. Similar to the examples described above with respect to FIG. 7 and FIG. 8, the RV 902 is configured to receive messages (SDSM / CPM) from other devices to identify objects outside its field of view. In the example of FIG. 9, HV1 802 has determined that HV3 is misreporting the detection of a second object (block 904). In some instances, a similar determination may be made by other similarly situated devices, such as HV2 804. In some examples, the detected misreport by HV3 806 may be broadcast by HV1 802 to other devices, e.g., RV902, HV2 804, and HV3 806 (block 906). In some examples, the reported misbehavior of HV3 806 may include information identifying the fraudulent / misbehaving device as well as information related to the misreported information. For example, when reporting the misbehavior of HV3 806, HV1 802 may include data identifying the reporting error including object type, object location, and / or other misreported attributes. As described in more detail below, information detailing the nature of the misreported object may be included in one or more extension fields of the transmitted SDSM / CPM.

[0070] Based on the described misbehavior of HV3 806 by HV1 802 and / or HV2 804, RV902 may implement a filter on the SDSM / CPM reports received from HV3 806 (block 908). In some aspects, RV902 may ignore all messages originating from HV3 806. In other aspects, RV902 may selectively filter / ignore reports for certain objects.

[0071] FIG. 10 is a call flow diagram of an example process 1000 for modifying (e.g., mitigating) a redundant reporting mitigation regime based on detection of a misbehaving entity. For example, accurate knowledge of road conditions and road users is a prerequisite for V2X entities (e.g., RSUs, vehicles, VRUs, etc.) to make safe and efficient driving decisions. The SAE J3224 standard enhances the situational awareness of V2X entities by defining application layer message structures and information elements (IEs) for exchanging information about detected objects and / or road obstacles to improve cooperative and automated driving decisions. Redundant sharing of information about the same detected object may increase resource utilization and network channel load, thus degrading overall system performance. Redundant reporting mitigation (also referred to as sensor sharing redundancy mitigation) is generally used to reduce or limit the number of V2X entities (e.g., vehicles, RSUs, VRUs, etc.) that are transmitting redundant information about the same object.

[0072] Various schemes for redundant reporting mitigation are available. In one example, self-announcement (SA) and frequency-based rules may be used for redundant reporting mitigation. According to self-announcement and frequency-based rules, for all objects within the range of a V2X entity (e.g., a V2X-enabled vehicle), the V2X entity may determine whether each object is a non-V2X object. For example, the V2X entity may include information in a message called SA (e.g., SDSM) only for non-V2X objects. SA may be used to filter out information about V2X-enabled entities or objects, since V2X-enabled entities may be expected to share their own information (e.g., via Basic Safety Messages (BSMs) but not SDSMs). The V2X entity may then apply frequency-based rules to determine whether it has received more than T reports for a given non-V2X object from neighboring V2X entities in their report messages (e.g., SDSMs) over a window of a given length (e.g., length Y milliseconds (ms)). If the V2X entity determines that it has received more than T reports for a non-V2X object over a time window in a reporting message (e.g., SDSM) of a neighboring V2X entity, the V2X entity does not include information for the given non-V2X object in its reporting message (e.g., SDSM). Otherwise, the V2X entity includes information for the given non-V2X object in its SDSM.

[0073] Another example redundant reporting mitigation scheme includes SA and distance-based rules. In addition to SA (e.g., reporting information about only non-V2X objects), a V2X entity may apply distance-based rules to determine what information to exclude from its report message (e.g., SDSM). The V2X entity may apply distance-based rules to determine whether it receives a report from a neighboring V2X entity that is closer to the V2X entity than a threshold distance (e.g., Euclidean distance) over a time window (e.g., Y milliseconds), and if so, the V2X entity does not include the information in its own report message (e.g., SDSM). For example, a V2X entity may include information about a non-V2X object in its report message only if the neighboring V2X entity (which has already reported information about the same non-V2X object) is farther away from the V2X entity than a threshold distance.

[0074] Another example redundant reporting mitigation scheme includes SA and dynamics-based rules: In addition to SA (e.g., reporting information only about non-V2X objects), a V2X entity may apply dynamics-based rules to determine to include information about a non-V2X entity in its reporting message (e.g., SDSM) only if the position of the non-V2X entity (e.g., as reported in a SDSM previously received from a neighboring V2X entity) has changed by more than a certain distance (e.g., 4 meters or other distance) or if the speed of the non-V2X entity has changed by more than a certain speed threshold (e.g., more than 45 meters per second or other speed threshold).

[0075] According to aspects described herein (e.g., with respect to FIG. 10), modifying (e.g., mitigating) the redundant reporting mitigation regime may include sending messages more frequently than would be sent under the redundant reporting mitigation regime. In the example of FIG. 10, HV1 determines that HV3 has misreported a third object that is not within the field of view (FOV) of RV 1002 (block 1004). In some examples, the misreporting may correspond to an indication by HV3 806 of a non-existent object. In other examples, the misreporting may correspond to incorrect or inaccurate information (e.g., location information) about a present object. In some approaches, in response to the detected misreporting by HV3 806, other wireless devices (e.g., HV1 802 and / or HV2 804) may mitigate the redundancy mitigation scheme being implemented. For example, in response to identifying HV3 806 as a potential misbehaving wireless device, HV1 802 and / or HV2 804 may increase the frequency of object reports that would otherwise be less frequent due to redundancy mitigation (1006). By increasing the reporting of objects within the FOV of HV1 802 and / or HV2 804, RV1002 may receive more frequent updates about objects within the FOV, allowing it to infer about the misbehavior of various wireless devices (e.g., HV3 806) in the environment. For example, if HV1 802 and HV2 804 send regular SDSM / CPM messages about objects within their respective fields of view, reports of objects that do not exist within the same FOV may be inferred by RV1002 through a comparison of all received SDSM / CPM object data. In some aspects, such inference may be based on a comparison of object data from multiple received SDSM / CPMs, where RV1002 may infer the correctness of the object information using a majority voting algorithm. For example, the RV 1002 may evaluate object data that is reported more frequently as being more reliable than object data that is reported less frequently.

[0076] In some aspects, modifications to the frequency of object reporting via SDSM / CPM by a given wireless device (e.g., mitigating redundancy mitigation schemes) may be based on the frequency with which a given object is observed to be reported by other devices. As an example, if HV1 802 receives reports of an object with a lower reporting frequency, for example, for a given duration, HV1 802 may add data about that object to an SDSM candidate list, such that it may report the object more frequently in its own SDSM / CPM. In other aspects, modifications to the frequency of object reporting may be based on distance rules. For example, the frequency of object reporting may be increased for objects observed by originating devices / entities that are farther away from the own vehicle / device.

[0077] In some cases, if HV1 802 and / or HV2 804 identify HV3 806 as a misbehaving vehicle, HV1 802, HV2 804, and / or RV1002 may take appropriate actions, such as according to the device's misbehavior detection configuration. For example, the actions may include ignoring and / or filtering messages from the identified vehicle (e.g., at a lower layer of the stack, such as the MAC layer or other lower layer) and reporting the misbehaving vehicle to a network-based entity (e.g., a server-based or cloud entity, SCMS, or other network-based entity) responsible for managing misreporting devices (e.g., vehicles or other devices that report incorrect information in SDSM, CPM, or other messages). In one illustrative example, RV1002 may ignore messages or specific object reports from HV3 at block 1008.

[0078] In some cases, in block 1010, HV3 806 detects a potential sensor malfunction and / or calibration problem by determining that its sensor is or may be failing. For example, as described above, if a message received by HV3 807 from HV2 804 and / or HV4 808 indicates that a reported object is actually present or that a location reported by HV3 806 is accurate, HV3 806 may diagnose / identify a failure of one or more of its own sensors or perception capabilities. If HV3 806 determines that its sensors are failing, HV3 806 may recalibrate the faulty sensor or sensors and / or disable messaging services (e.g., temporarily disable SDSM services). In one example, HV3 806 may send an alert (e.g., by displaying an alert, outputting a sound accompanied by an alert, vibrating the seat, steering wheel, or other component of the vehicle, any combination thereof, and / or outputting other alerts) to the driver of HV3 806 to disable a messaging service (e.g., an SDSM service).

[0079] FIG. 11 is a flow diagram of an example process 1100 for notifying a remote vehicle of the presence of a misbehaving entity. In block 1104, the host vehicle (or other wireless device) determines whether it observes a misreported object. If a misreported object is not detected, the process 1100 proceeds to block 1106, and the HV continues with normal redundancy mitigation (e.g., to reduce possible channel congestion). If the HV instead observes a misreported object, the process 1100 proceeds to block 1112. In block 1112, the HV can determine whether to directly report the detected misbehavior. If the HV determines to directly notify the remote vehicle (RV) of the detected misbehavior, the process 1100 proceeds to block 1108.

[0080] In block 1108, the HV identifies the misbehaving entity and the detected object, and / or object attributes of the misbehaving entity and / or the detected object. For example, the HV may send a message (e.g., an SDSM, CPM, or other message directly to the RV in block 1110) including attributes of the misbehaving entity and / or attributes of one or more detected objects. In some aspects, as described above, the misreported behavior may be indicated in one or more extension fields of the SDSM / CPM message sent by the HV, as shown with respect to FIG. 12 and FIG. 13 (described below). In some instances, attributes of the misreport (e.g., indicative of the nature of the erroneous report) may be included in the SDSM / CPM message alone or in conjunction with the corrected or accurate object data. In some examples, the attributes may include characteristics of the object detected by the misbehaving vehicle (or other V2X entity) that resulted in the vehicle being classified as misbehaving. For example, the attributes may include an object identifier (ID) that identifies the object, an object type that indicates the type of object, one or more locations for the object, a size of the object, a color of the object, and / or other attributes of the non-existent or incorrectly reported actual object(s). In some cases, the one or more locations for the object may include a "claimed" location of the object claimed by a misbehaving vehicle, a true or actual location of the object, and / or other locations. For example, in the case of a non-existent object, the attributes included in the message may include a "claimed" object location or location (as reported by a misbehaving V2X entity).In the case of erroneous information about a present object, both the claimed location or position (reported by the misbehaving V2X entity) and the estimated true object position (e.g., estimated by the sender or originator of the message, such as HV1 802, HV2 804, and / or HV3 806) can be included in the message as attributes. In some cases, indicating or marking a misbehaving V2X entity as misbehaving may require that the misbehaving entity has correctly reported its own position, and possibly a subset of other objects in its neighbors or vicinity.

[0081] In such an approach, the RV is directly notified about the misbehaving entity. In such a case, the RV can start filtering / ignoring subsequent messages received from the misbehaving entity.

[0082] If, instead, at block 1112, the HV determines not to directly notify the RV about the misbehaving entity, process 1100 proceeds to block 1114 where the redundancy mitigation regime is mitigated. The mitigation of redundancy mitigation can trigger an increase in the frequency of object reporting by the HV (e.g., compared to the number of objects reported under one or more redundancy mitigation schemes). As explained above, the reporting frequency can be based on a frequency rule regarding the number of times an object observation is reported within a given time frame. In addition, the reporting frequency by the HV can be based on other attributes, such as the distance of the message originator from the HV's location, in which case the reporting frequency can be increased when the message originator is located at a greater distance rather than a shorter distance.

[0083] By increasing the reporting frequency (e.g., by reducing redundancy mitigation), the RV can receive more frequent SDSM / CPM transmissions and make better inferences about the accuracy of the received object reports, as well as any misconduct by other devices in its environment. In block 1116, the RV can indirectly learn about the misbehaving RV.

[0084] 12 and 13 show examples of Sensor Data Sharing Messages (SDSMs). In the example SDSM 1200 shown in FIG. 12, the source data 1202 may include information related to a reporting device, such as a host vehicle (HV) 806, and the detected object data 1204 may include information related to an object reported by a misbehaving device, such as information related to a misreported object and / or object attributes reported by the misbehaving device (e.g., the information element or field labeled "DetectedMisbehavingVehicleData" in FIG. 12). For example, the object data 1204 may include information related to a non-existent object or attributes of a misreported object (e.g., an object reported with incorrect location information) reported by a misbehaving vehicle. In one example, in a case where a misbehaving vehicle reports information related to a non-existent object, the object data 1204 may include information indicating attributes of the non-existent object, such as an incorrectly claimed object location, object type, and / or other information. In instances where a misbehaving vehicle incorrectly reports information (e.g., an incorrect location, etc.) related to an object in which a misbehaving vehicle resides, the object data 1204 may include information identifying the correct attributes, information indicating the incorrect attributes incorrectly reported by the misbehaving device, and / or other information. For example, in such instances, the object data 1204 may include information identifying an actual (correct) object location as determined by a particular HV (e.g., HV 806) reporting the object data 1204, an incorrect or claimed object location reported by the misbehaving vehicle or device, and / or other information. In some instances, the object data 1204 may include true / correct information regarding other object attributes, as well as one or more corresponding (claimed) attributes incorrectly reported by the misbehaving device.For example, the object data 1204 may include actual (correct) and / or claimed (incorrect) attribute information regarding one or more of an object ID that identifies the object, an object type that indicates the type of object, an object size, an object color, and / or other attributes of the actual object(s) that do not exist or that were incorrectly reported.

[0085] Referring to diagram 1300 of FIG. 13, detected object data 1302 may include data regarding physical obstacles 1304 (e.g., potholes, VRUs, non-V2X vehicles) and may also include data 1306 regarding attributes of non-existent objects or incorrectly reported objects (e.g., objects reported with incorrect timing and / or location information) reported by misbehaving vehicles.

[0086] Figure 14 is a diagram illustrating an example of an information element for a detected object in a sensor data sharing message, such as the sensor data sharing messages of Figures 12 and 13. With reference to diagram 1400 of Figure 14, a top-level information element (IE) 1402 for a detected object may include certain detected characteristics of the detected object. For example, data element 1404 may include non-V2X vehicle data, VRU data, physical obstacle data, while data element 1406 may include misbehaving vehicle data.

[0087] Figure 15 is a diagram illustrating an example of parameters for a detected object in a sensor data sharing message, such as the sensor data sharing messages of Figures 12 and 13. For example, diagram 1500 of Figure 15 provides an example of parameters 1502 for a detected object. For example, parameters 1502 may include a position, speed, and heading of a detected object. In the case of a DoS attack, parameters 1502 may include a position, speed, or heading.

[0088] 16 is a flow diagram illustrating an example process 1600 for verifying a detected object. At block 1602, the process 1600 includes acquiring sensor data corresponding to a field of view (FOV) of the vehicle. As described above, the sensor data may include data received from a number of sensors, including, but not limited to, one or more of a LiDAR sensor, a radar sensor, a camera, and / or an accelerometer. In some aspects, the sensor data may include data corresponding to an environment surrounding the collection device (vehicle), such as objects proximate to the vehicle.

[0089] At block 1604, process 1600 includes receiving a message from a wireless device, the message including an indication of at least one object (e.g., a reported object) located within the FOV of the vehicle. In some aspects, the message may be received using a V2X communication protocol. In some aspects, the message may be (or may include) one or more SDSM / CPM transmissions.

[0090] At block 1606, the process 1600 includes determining whether the wireless device misreported at least one object based on the sensor data and the message from the wireless device. In some aspects, verifying the presence or accuracy (e.g., location and / or description) of the object includes comparing the sensor data corresponding to the reported object with the object data included in the received message. As an example, it may be determined that the object is not represented in the sensor data acquired by the vehicle. In such an instance, the wireless device may be classified as a misbehaving device. In another example, it may be determined that the object is represented in the sensor data, in which case various attributes (such as location) of the reported object may be compared to attributes known from the sensor data. In some aspects, the wireless device may be classified as a misbehaving object if the reported object attributes are significantly different from those indicated by the sensor data. For example, the wireless device may be classified as a misbehaving device if the reported location of the object differs from the location indicated by the sensor data by an amount that exceeds a predetermined threshold.

[0091] In some examples, once a wireless device has been classified as a misbehaving device, it is reported directly to one or more other devices, such as, for example, one or more RSUs or other vehicles. By way of example, data indicative of the misbehavior of the wireless device may be included in an extension field, such as a Sensor Data Sharing Message (SDSM) / Collective Perception Message (CPM) and / or a Basic Safety Message (BSM).

[0092] In some examples, detection of a misbehaving wireless device may trigger a change to the frequency of object reporting performed by the vehicle. For example, the vehicle may increase the frequency of object reporting via the SDSM, for example by relaxing a redundancy mitigation regime.

[0093] 17 is a flow diagram illustrating an example process 1700 for verifying detected objects. At block 1702, the process 1700 includes receiving a first message from a wireless device including object data corresponding to one or more objects reported by the wireless device to be within the field of view of the apparatus.

[0094] At block 1704, the process 1700 includes determining whether the wireless device misreported at least one of the one or more objects based on the detected data. As described above, the message (e.g., the first message) received from the wireless device may be or may include a sensor data sharing message (SDSM). In some aspects, the apparatus (e.g., the vehicle) may transmit a second (SDSM) message indicating that the wireless device misreported at least one of the one or more objects. In some aspects, the second message may be sent to a remote vehicle (RV), such as the RV702 and RV902 described above with respect to FIG. 7 and FIG. 9. In some aspects, data indicating the misreporting by the wireless device may be included in at least one SDSM extension field of the second message. By way of example, the data may include information indicating an identification of the wireless device, a location of the wireless device, and / or information about the misreporting of the wireless device, as described above with respect to FIG. 13, FIG. 14, and FIG. 15 described above. In some examples, the object data included in the second message may include data identifying one or more of a vulnerable road user (VRU), a physical obstacle, a wireless obstacle, a detected vehicle, or any combination thereof.

[0095] 18 is a diagram 1800 illustrating an example of a hardware implementation of a device 1802. The device 1802 is a UE and includes a cellular baseband processor 1804 (also referred to as a modem) coupled to a cellular RF transceiver 1822 and one or more subscriber identity modules (SIM) cards 1820, an application processor 1806 coupled to a secure digital (SD) card 1808 and a screen 1810, a Bluetooth module 1812, a wireless local area network (WLAN) module 1814, a GNSS module 1816, and a power source 1818. The GNSS module 1816 may include various satellite positioning systems. For example, the GNSS module may correspond to a Global Positioning System (GPS), a Global Navigation Satellite System (GLONASS), Galileo, a BeiDou Navigation Satellite System (BDS), a Wide Area Augmentation System (WAAS), a European Geostationary Navigation Overlay Service (EGNOS), a GPS Aided GEO Augmented Navigation (GAGAN), a Multifunctional Transport Satellites (MTSAT) Satellite Augmentation System (MSAS), a Quasi-Zenith Satellite System (QZSS), or a Navigation with Indian Constellation (NavIC).The cellular baseband processor 1804 communicates with the UE 104 and / or the BS 102 / 180 through the cellular RF transceiver 1822. The cellular baseband processor 1804 may include a computer-readable medium / memory. The computer-readable medium / memory may be non-transitory. The cellular baseband processor 1804 is responsible for general processing, including the execution of software stored on the computer-readable medium / memory. The software, when executed by the cellular baseband processor 1804, causes the cellular baseband processor 1804 to perform various functions described above. The computer-readable medium / memory may also be used to store data that is manipulated by the cellular baseband processor 1804 when executing the software. The cellular baseband processor 1804 further includes a receiving component 1830, a communication manager 1832, and a transmitting component 1834. The communications manager 1832 includes one or more illustrated components, including a detection component 1840 configured to detect one or more objects, and a message component 1842 configured to generate one or more messages (e.g., SDSM, CPM, BSM, etc.). The components in the communications manager 1832 may be stored in a computer-readable medium / memory and / or configured as hardware in the cellular baseband processor 1804. The cellular baseband processor 1804 may be a component of the UE 350 and may include the memory 360 and / or at least one of the TX processor 368, the RX processor 356, and the controller / processor 359. In one configuration, the apparatus 1802 may be a modem chip and include only the baseband processor 1804, and in another configuration, the apparatus 1802 may be an entire UE (e.g., see 350 in FIG. 3) and include the aforementioned additional modules of the apparatus 1802.

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

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

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

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

[0100] Moreover, those skilled in the art will appreciate that the various exemplary logic blocks, modules, circuits, and algorithm steps described in connection with the aspects disclosed herein may be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability of hardware and software, the various exemplary 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 particular application and design constraints imposed on the overall system. Those skilled in the art may implement the described functionality in various ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

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

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

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

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

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

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

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

[0108] 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 circuit configurations. Such a processor may be configured to perform any of the techniques described in this disclosure. A general purpose processor may be a microprocessor, but alternatively, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, such as, for example, a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Thus, the term "processor" as used herein may refer to any of the above structures, any combination of the above structures, or any other structure or apparatus suitable for implementing the techniques described herein.

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

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

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

[0112] Claim language or other language reciting "at least one" of a set and / or "one or more" of a set indicates that one member of the set or multiple members of the set (in any combination) satisfy the claim. For example, 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. As 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" can mean A, B, or A and B, and can, in addition, include unrecited items in the sets of A and B.

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

[0114] Aspect 1: An apparatus for verifying object detection, comprising: at least one transceiver, at least one memory, and at least one processor coupled to the at least one transceiver and the at least one memory, wherein the at least one processor is configured to acquire sensor data corresponding to a field of view of a vehicle, receive via the at least one transceiver a message from a wireless device including an indication of at least one object within the field of view of the vehicle and a reported location of the at least one object, and determine whether the wireless device misreported the at least one object based on the sensor data and the message from the wireless device.

[0115] Aspect 2: The apparatus of aspect 1, wherein to determine whether the wireless device has misreported at least one object, the at least one processor is configured to determine that the at least one object is not represented in sensor data acquired by the vehicle, and classify the wireless device as a misbehaving device based on the at least one object not being represented in the sensor data.

[0116] Aspect 3: The apparatus of any one of aspects 1 or 2, wherein to determine whether the wireless device has misreported the at least one object, at least one processor is configured to determine that the at least one object is represented in sensor data acquired by the vehicle, and to determine a location of the at least one object using the sensor data.

[0117] Aspect 4: The apparatus of aspect 3, wherein at least one processor is configured to determine a difference between a location of at least one object determined using sensor data and a reported location of at least one object indicated by a message from the wireless device, and classify the wireless device as a misbehaving device based on a determination that the difference between the location and the reported location exceeds a predetermined threshold.

[0118] Aspect 5: The apparatus of any one of aspects 1 to 4, wherein at least one processor is configured to transmit, via the at least one transceiver, a misbehavior report to a remote management entity based on a determination that the wireless device has misreported at least one object.

[0119] Aspect 6: The apparatus of any one of aspects 1 to 5, wherein at least one processor is configured to transmit, via the at least one transceiver, a erroneous behavior report to one or more remote vehicles based on a determination that the wireless device has erroneously reported at least one object.

[0120] Aspect 7: The apparatus of aspect 6, wherein at least one processor is configured to transmit a misbehavior report via one or more extension fields in at least one Sensor Data Sharing Message (SDSM), a Collective Perception Message (CPM), a Basic Safety Message (BSM), or any combination thereof.

[0121] Aspect 8: The apparatus of any one of aspects 1 to 7, wherein at least one processor is configured to increase a frequency of sensor data sharing message (SDSM) transmissions based on a determination that the wireless device has misreported at least one object.

[0122] Aspect 9: The apparatus of any one of aspects 1 to 8, wherein the message comprises a sensor data sharing message (SDSM), a collective perception message (CPM), a basic safety message (BSM), or any combination thereof.

[0123] Aspect 10: The apparatus of any one of aspects 1 to 9, wherein the sensor data includes data collected from at least one of a light detection and ranging (LiDAR) sensor, a radar sensor, a camera sensor, or a combination thereof.

[0124] Aspect 11: A method for verifying object detection, the method including: acquiring sensor data corresponding to a field of view of a vehicle; receiving a message from a wireless device including an indication of at least one object within the field of view of the vehicle and a reported location of the at least one object; and determining whether the wireless device misreported the at least one object based on the sensor data and the message from the wireless device.

[0125] Aspect 12: The method of aspect 11, wherein determining whether the wireless device has misreported at least one object further includes determining that the at least one object is not represented in the sensor data, and classifying the wireless device as a misbehaving device based on the at least one object being not represented in the sensor data.

[0126] Aspect 13: The method of any one of aspects 11 to 12, wherein determining whether the wireless device has misreported at least one object further includes determining that the at least one object is represented in the sensor data and determining a location of the at least one object using the sensor data.

[0127] Aspect 14: The method of aspect 13, further comprising: determining a difference between a location of at least one object determined using the sensor data and a reported location of at least one object indicated by a message from the wireless device; and classifying the wireless device as a misbehaving device based on a determination that the difference between the location and the reported location exceeds a predetermined threshold.

[0128] Aspect 15: The method of any one of aspects 11 to 14, further comprising: sending a misbehavior report to a remote management entity based on a determination that the wireless device misreports at least one object.

[0129] Aspect 16: The method of any one of aspects 11 to 15, further comprising transmitting an erroneous behavior report to one or more remote vehicles based on a determination that the wireless device has erroneously reported at least one object.

[0130] Aspect 17: The method of aspect 16, wherein the misbehavior report is transmitted via one or more extension fields in at least one sensor data sharing message (SDSM), a collective perception message (CPM), a basic safety message (BSM), or any combination thereof.

[0131] Aspect 18: The method of any one of aspects 11 to 17, further comprising increasing a frequency of sensor data sharing message (SDSM) transmissions based on a determination that the wireless device misreported at least one object.

[0132] Aspect 19: The method of any one of aspects 11 to 18, wherein the message comprises a sensor data sharing message (SDSM), a collective perception message (CPM), a basic safety message (BSM), or any combination thereof.

[0133] Aspect 20: The method of any one of aspects 11 to 19, wherein the sensor data includes data collected from at least one of a light detection and ranging (LiDAR) sensor, a radar sensor, a camera sensor, or a combination thereof.

[0134] Aspect 21: A non-transitory computer-readable storage medium comprising at least one instruction for causing a computer or processor to perform an operation according to any one of aspects 1 to 20.

[0135] Example 22: An apparatus for verifying object detection, comprising means for performing the operations according to any one of examples 1 to 20.

[0136] The foregoing description is provided to enable those skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects. Accordingly, the claims are not intended to be limited to the aspects shown herein, but are to be accorded the widest scope consistent with the language of the claims, and references to elements in the singular do not mean "one and only," unless expressly stated otherwise, but rather "one or more."

Claims

1. 1. An apparatus for verifying object detection, comprising: at least one transceiver; at least one memory; at least one processor coupled to the at least one transceiver and the at least one memory, wherein the at least one processor: acquiring sensor data corresponding to the vehicle's field of view; receiving, via the at least one transceiver, from a wireless device, a message including an indication of at least one object within the field of view of the vehicle and a reported location of the at least one object; determining whether the wireless device misreported the at least one object based on the sensor data and the message from the wireless device; an apparatus configured to increase a frequency at which the apparatus transmits messages including information about objects within a field of view of the vehicle based on a determination that the wireless device has misreported the at least one object;

2. To determine whether the wireless device misreported the at least one object, the at least one processor: determining that the at least one object is not represented in the sensor data acquired by the vehicle; The apparatus of claim 1 , configured to classify the wireless device as a misbehaving device based on the at least one object not being represented in the sensor data.

3. To determine whether the wireless device misreported the at least one object, the at least one processor: determining that the at least one object is represented in the sensor data acquired by the vehicle; The device of claim 1 , configured to determine a location of the at least one object using the sensor data.

4. the at least one processor: determining a difference between the location of the at least one object determined using the sensor data and the reported location of the at least one object indicated by the message from the wireless device; The apparatus of claim 3 , configured to classify the wireless device as a misbehaving device based on a determination that the difference between the location and the reported location exceeds a predetermined threshold.

5. the at least one processor:

10. The apparatus of claim 1, configured to transmit, via the at least one transceiver, a misbehavior report to a remote management entity based on a determination that the wireless device has misreported the at least one object.

6. the at least one processor:

10. The apparatus of claim 1, configured to transmit, via the at least one transceiver, an erroneous behavior report to one or more remote vehicles based on a determination that the wireless device has erroneously reported the at least one object.

7. 7. The apparatus of claim 6, wherein the at least one processor is configured to transmit the misbehavior report via one or more extension fields in at least one Sensor Data Sharing Message (SDSM), Collective Perception Message (CPM), Basic Safety Message (BSM), or any combination thereof.

8. The device of claim 1, wherein increasing the frequency at which the device transmits messages containing information about objects within the vehicle's field of view includes increasing the frequency of sensor data sharing message (SDSM) transmissions.

9. The message comprises a Sensor Data Sharing Message (SDSM), a Collective Perception Message (CPM), a Basic Safety Message (BSM), or any combination thereof; or The apparatus of claim 1 , wherein the sensor data comprises data collected from at least one of a Light Detection and Ranging (LiDAR) sensor, a radar sensor, a camera sensor, or a combination thereof.

10. 1. A method for verifying object detection, comprising: acquiring sensor data corresponding to a field of view of a vehicle; receiving a message from a wireless device, the message including an indication of at least one object within the field of view of the vehicle and a reported location of the at least one object; determining whether the wireless device misreported the at least one object based on the sensor data and the message from the wireless device; and increasing a frequency at which the apparatus transmits messages including information about objects within a field of view of the vehicle based on a determination that the wireless device has misreported the at least one object.

11. determining whether the wireless device misreported the at least one object; determining that the at least one object is not represented in the sensor data; and classifying the wireless device as a misbehaving device based on the at least one object not being represented in the sensor data; or determining that the at least one object is represented in the sensor data; and determining a location of the at least one object using the sensor data; determining a difference between the location of the at least one object determined using the sensor data and the reported location of the at least one object indicated by the message from the wireless device; 11. The method of claim 10, further comprising: classifying the wireless device as a misbehaving device based on a determination that the difference between the location and the reported location exceeds a predetermined threshold.

12. sending a misbehavior report to a remote management entity based on a determination that the wireless device has misreported the at least one object; or transmitting an erroneous behavior report to one or more remote vehicles based on a determination that the wireless device erroneously reported the at least one object.

11. The method of claim 10, further comprising: wherein the misbehavior report is transmitted via one or more extension fields in at least one Sensor Data Sharing Message (SDSM), Collective Perception Message (CPM), Basic Safety Message (BSM), or any combination thereof.

13. The method of claim 10, wherein increasing the frequency at which the device transmits messages containing information about objects within the vehicle's field of view includes increasing the frequency of sensor data sharing message (SDSM) transmissions.

14. The message comprises a Sensor Data Sharing Message (SDSM), a Collective Perception Message (CPM), a Basic Safety Message (BSM), or any combination thereof; or The method of claim 10 , wherein the sensor data comprises data collected from at least one of a Light Detection and Ranging (LiDAR) sensor, a radar sensor, a camera sensor, or a combination thereof.

15. To a computer or processor, acquiring sensor data corresponding to a field of view of the vehicle; receiving a message from a wireless device, the message including an indication of at least one object within the field of view of the vehicle and a reported location of the at least one object; determining whether the wireless device misreported the at least one object based on the sensor data and the message from the wireless device; A non-transitory computer-readable storage medium comprising at least one instruction for increasing a frequency at which an apparatus transmits messages including information about objects within a field of view of the vehicle based on a determination that the wireless device has misreported the at least one object.