Misbehavior detection service for sharing connected and sensed objects

Abstract

Systems, apparatuses, processes, and computer-readable media for wireless communications are disclosed. For example, one example process includes, at a first network device, determining an estimated location of a second network device. The process may further include, at the first network device, comparing the estimated location with an expected location of the second network device. The process may include, at the first network device, determining whether the second network device is a misbehaving device based on the comparing. The process may further include, at the first network device, generating a report based on a determination of whether the second device is a misbehaving device.

Description

[Technical Field]

[0001] For example, aspects of the present disclosure relate to a misbehavior detection service for sharing connected and sensed objects using vehicle-to-everything (V2X) communications. [Background technology]

[0002]

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

[0003] These multiple access technologies have been adopted in various telecommunications standards to provide common protocols that enable different 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 ongoing mobile broadband evolution promulgated by the Third Generation Partnership Project (3GPP) to meet new requirements associated with latency, reliability, security, scalability (e.g., for the Internet of Things (IoT)), and other requirements. 5G NR includes services associated with enhanced mobile broadband (eMBB), massive machine type communications (mMTC), and ultra-reliable low latency communications (URLLC). Some aspects of 5G NR may be based on the 4G Long Term Evolution (LTE) standard. Aspects of wireless communication may include direct communication between devices, such as V2X communication, vehicle-to-vehicle (V2V) communication, and / or device-to-device (D2D) communication. Further improvements are needed in 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]

[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 delimiting 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]

[0005] Systems, apparatus, methods, and computer-readable media are disclosed for a misbehavior detection service for sharing connected and sensed objects (e.g., utilizing V2X communications). According to at least one example, a method of wireless communication performed at a first network device is provided. The method includes: determining, at the first network device, an estimated location of a second network device; comparing, at the first network device, the estimated location to an expected location of the second network device; determining, at the first network device, whether the second network device is a misbehaving device based on the comparing; and generating, at the first network device, a report based on a determination of whether the second device is a misbehaving device.

[0006] In another example, an apparatus is provided that executes on a first network device, the apparatus including at least one memory and at least one processor coupled to the at least one memory, wherein the at least one processor is configured to: determine an estimated location of a second network device, compare the estimated location to an expected location of the second network device, determine whether the second network device is a misbehaving device based on the comparing, and generate a report based on a determination of whether the second device is a misbehaving device.

[0007]

[0007] In another example, a non-transitory computer-readable medium is provided having instructions stored thereon that, when executed by one or more processors, cause the one or more processors to determine an estimated location of a second network device, compare the estimated location to an expected location of the second network device, determine whether the second network device is a misbehaving device based on the comparison, and generate a report based on the determination of whether the second device is a misbehaving device.

[0008] In another example, an apparatus is provided that executes on a first network device, the apparatus including: means for determining an estimated location of a second network device; means for comparing the estimated location to an expected location of the second network device; means for determining whether the second network device is a misbehaving device based on the comparing; and means for generating a report based on a determination of whether the second device is a misbehaving device.

[0009] In some aspects, a network device or apparatus described herein includes or is part of a vehicle (e.g., an automobile, truck, etc., or a component or system of an automobile, truck, etc.), a mobile device (e.g., a mobile phone, a 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 server computer, a robotic device, or other device. In some aspects, the apparatus includes a radio detection and ranging (radar) sensor for capturing radio frequency (RF) signals. In some aspects, the apparatus includes one or more light detection and ranging (LIDAR) sensors, radar sensors, or other light-based sensors for capturing other light-based (e.g., light frequency) signals. In some aspects, the apparatus includes a camera or multiple cameras for capturing one or more images. In some aspects, the device further includes a display for displaying one or more images, notifications, and / or other displayable data. In some aspects, the devices described above may include one or more sensors, which may be used to determine the location of the device, the state of the device (e.g., temperature, humidity level, and / or other condition), and / or for other purposes.

[0010]

[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]

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

[0012]

[0012] Exemplary aspects of the present application are described in detail below with reference to the following figures. [Figure 1]

[0013] FIG. 1 illustrates an example wireless communication system in accordance with certain aspects of the present disclosure. [Figure 2]

[0014] FIG. 1 illustrates an example of a decentralized base station architecture that may be employed by the disclosed system for misbehavior detection services for sharing connected and sensed objects in accordance with some aspects of the present disclosure. [Figure 3]

[0015] FIG. 1 illustrates an example of various user equipment (UEs) communicating over a direct communication interface (e.g., a cellular-based PC5 sidelink interface, a DSRC interface defined in 802.11p, or other direct interface) and a wide area network (Uu) interface, in accordance with certain aspects of the present disclosure. [Figure 4]

[0016] FIG. 1 is a block diagram illustrating an example of a vehicle computing system in accordance with some aspects of the present disclosure. [Figure 5]

[0017] FIG. 2 is a block diagram illustrating an example of a computing system of a user device, in accordance with some aspects of the present disclosure. [Figure 6]

[0018] FIG. 1 illustrates an example of devices involved in wireless communication (e.g., sidelink communication) in accordance with certain aspects of the present disclosure. [Figure 7A]

[0019] FIG. 1 illustrates an example of sensor sharing for a cooperative automated driving system in accordance with some aspects of the present disclosure. [Figure 7B]FIG. 1 illustrates an example of sensor sharing for a cooperative automated driving system in accordance with some aspects of the present disclosure. [Figure 7C] FIG. 1 illustrates an example of sensor sharing for a cooperative automated driving system in accordance with some aspects of the present disclosure. [Figure 7D] FIG. 1 illustrates an example of sensor sharing for a cooperative automated driving system in accordance with some aspects of the present disclosure. [Figure 8]

[0020] FIG. 1 illustrates an example of sensor sharing for a cooperative automated driving system, according to some aspects of the present disclosure. [Figure 9]

[0021] FIG. 1 illustrates an example of a system for sensor sharing in wireless communication (e.g., V2X communication) in accordance with certain aspects of the present disclosure. [Figure 10]

[0022] FIG. 1 illustrates an example of a vehicle-based message (depicted as a sensor sharing message) according to some aspects of the present disclosure. [Figure 11]

[0023] FIG. 1 illustrates an example of a vehicle configuration for a non-line of sight (NLoS) scenario, in accordance with some aspects of the present disclosure. [Figure 12A]

[0024] FIG. 1 illustrates an example of a ground truth view from the perspective of a receiver, in accordance with certain aspects of the present disclosure. [Figure 12B]

[0025] FIG. 1 illustrates an example of a Basic Safety Message (BSM) view from the perspective of a receiver, in accordance with certain aspects of the present disclosure. [Figure 12C]

[0026] FIG. 2 illustrates an example of a Collective Perception Message (CPM) view from the perspective of a receiver, in accordance with certain aspects of the present disclosure. [Figure 12D]

[0027] FIG. 1 illustrates an example of a fused object view from the perspective of a receiver, in accordance with certain aspects of the present disclosure. [Figure 13]

[0028] FIG. 1 illustrates an example system for a misbehavior detection service for sharing connected sensed objects when an equipped (e.g., V2X-enabled) network device with multiple sensors visually sees another equipped network device, according to some aspects of the present disclosure. [Figure 14A]

[0029] FIG. 1 illustrates an example system for a misbehavior detection service for sharing connected and sensed objects where a platoon leader visually verifies equipped (e.g., V2X-enabled) network devices, according to some aspects of the present disclosure. [Figure 14B]

[0030] FIG. 1 illustrates an example system for a misbehavior detection service for sharing connected sensed objects where an equipped (e.g., V2X-enabled) network device with a single sensor visually sees another equipped network device (e.g., a vehicle), according to some aspects of the disclosure. [Figure 14C]

[0031] FIG. 1 illustrates an example of a system for misbehavior detection services for sharing connected and sensed objects, in accordance with certain aspects of the present disclosure, where an equipped (e.g., V2X-enabled) network device (e.g., RSU) located within one range visually confirms another equipped network device (e.g., RSU) located within two ranges. [Figure 15A]

[0032] FIG. 1 illustrates an example of signaling of a feedback technique in accordance with certain aspects of the present disclosure. [Figure 15B]

[0033] FIG. 1 illustrates an example of signaling for a request-response approach in accordance with certain aspects of the present disclosure. [Figure 16]

[0034] 1 is a flowchart illustrating an example of a fused data sharing detector (FDSD) process from the perspective of an initial requester, according to some aspects of the present disclosure. [Figure 17]

[0035] 1 is a flowchart illustrating an example of a process for FDSD from the responder's perspective, according to some aspects of the present disclosure. [Figure 18]

[0036] 1 is a flowchart illustrating an example of a process for FDSD from the perspective of a final responder, according to some aspects of the present disclosure. [Figure 19]

[0037] FIG. 1 illustrates an example of a fused data sharing message (FDSM) request, in accordance with certain aspects of the present disclosure. [Figure 20]

[0038] FIG. 1 illustrates an example of an FDSM response, in accordance with some aspects of the present disclosure. [Figure 21]

[0039] 1 is a flowchart illustrating an example of a process for wireless communication in accordance with certain aspects of the present disclosure. [Figure 22]

[0040] 1 illustrates an exemplary computing system according to aspects of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0013]

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

[0014]

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

[0015]

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

[0016]

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

[0017]

[0045] A vehicle is an example of a system that may include wireless communication capabilities. For example, vehicles (e.g., automobiles, autonomous vehicles, aircraft, and watercraft, among others) can communicate with other vehicles and / or other devices that have wireless communication capabilities. Wireless vehicular communication systems encompass vehicle-to-vehicle (V2V) communications, vehicle-to-infrastructure (V2I) communications, vehicle-to-network (V2N) communications, and vehicle-to-pedestrian (V2P) communications, all of which are collectively referred to as vehicle-to-everything (V2X) communications. V2X communications are vehicular communication systems that support the wireless transmission of information from a vehicle to other entities within the transportation system that may affect the vehicle (e.g., other vehicles, pedestrians with smartphones, equipped vulnerable road users (VRUs) such as cyclists, and / or other transportation infrastructure). The main objective of V2X technology is to improve road safety, fuel economy and traffic efficiency.

[0018]

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

[0019]

[0047] As mentioned above, V2X technology includes V2V communication, which may also be referred to as peer-to-peer communication. V2V communication allows vehicles to wirelessly communicate directly with each other while on the road. V2V communication allows vehicles to gain situational awareness by receiving information related to potential road hazards (e.g., unexpected oncoming vehicles, accidents, and road conditions) from other vehicles.

[0020]

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

[0021]

[0049] In one or more cases, a sending network device (e.g., a V2X-enabled vehicle generating and sending a vehicle-based message such as a BSM) may be misbehaving (e.g., operating as a misbehaving vehicle) by sending (e.g., intentionally or unintentionally) a vehicle-based message (e.g., a BSM) that includes inaccurate information. For example, a sending network device may be operating as a misbehaving vehicle if information included in the vehicle-based message identifies an inaccurate location of the sending network device.

[0022]

[0050] In some cases, a sending network device (e.g., a V2X-enabled vehicle generating and sending a vehicle-based message) may be misbehaving (e.g., acting as a misbehaving vehicle) by acting as an attacker by creating invisible V2X ghost objects to disrupt traffic on the road. A ghost V2X object is a V2X object that is not located at the sending network device's location. A ghost V2X object is an object that does not physically exist, such as a simulated vulnerable road user (VRU) or a simulated vehicle. An invisible object is an object that is outside the sensor field-of-view (FoV) or not in the line-of-sight (LoS) (e.g., non-line-of-sight scenario) of a receiving network device (e.g., a V2X-enabled vehicle receiving a vehicle-based message).

[0023]

[0051] An attacker's goal may be to negate the benefit of sensors utilizing V2X communications. In some cases, an attacker may use non-line-of-sight (NLoS) ghost objects. For example, when an object (e.g., a ghost object) is not located within the vehicle's line of sight, sensors associated with the vehicle cannot easily confirm the presence (or absence) of the object. Because the vehicle cannot confirm the presence (or absence) of the object, the vehicle driver may be forced to decelerate (e.g., speed down) to ensure the vehicle does not collide with the object, which may not actually be present and may simply be a ghost object. This effect of forcing drivers to perform unnecessary maneuvers (e.g., slow down) may not only cause driver frustration but also disrupt traffic, resulting in traffic congestion and / or vehicle collisions.

[0024]

[0052] Currently, detectors may be inefficient and / or insufficient to detect attacks. For example, current detectors may have limited range, cannot operate on V2X-enabled objects that are not within the sensed line of sight (e.g., beyond line of sight), and / or cannot be utilized by vehicles without sensors. In some cases, current detectors may be unable to detect attacks if the movement pattern of a ghost object (e.g., a ghost vehicle) is perfect or nearly perfect. Current detectors that use sensors to detect ghost attacks (e.g., ghost V2X attacks) may be inefficient in congested road environments. For example, camera-based detectors cannot detect objects beyond line of sight. In another example, received signal strength indication (RSSI)-based detectors may be affected by signal attenuation caused by obstacles. Current detectors that use sensors to detect ghost attacks (e.g., ghost V2X attacks) are only effective if the network device (e.g., a vehicle) itself has sensors.

[0025]

[0053] In addition, the collection perception service (CPS) cannot verify the physical existence of ghost objects. Therefore, the CPS needs to track all ghost objects (e.g., all ghost objects indicated by vehicle-based messages such as BSM). Also, the CPS cannot provide V2X data redundancy from the perspective of the receiving network device (e.g., the receiving vehicle). For example, a collection perception message (CPM) cannot include V2X objects perceived by sensors of the sending network device (e.g., the sending vehicle). The CPM can include non-V2X objects perceived by sensors of the sending network device (e.g., the sending vehicle).

[0026]

[0054] An ITS-S approach using an Intelligent Transportation System Station (ITS-S) can detect simulated V2X objects (e.g., ghost objects). The ITS-S's sensors can determine the location of a simulated V2X object (e.g., ghost object) when the simulated V2X object (e.g., ghost object) is located within the ITS-S's field of view. The ITS-S can use the determined location of the object to verify the object's location indicated in a vehicle-based message (e.g., BSM) received from the object. However, this ITS-S approach has several limitations, including but not limited to: it requires a sensor-equipped ITS-S; it cannot detect objects (e.g., V2X objects) that are outside the ITS-S's line of sight (e.g., obstacles obstruct the ITS-S's sensor's field of view); and it may have limited detection range.

[0027]

[0055] Systems, devices, apparatus (e.g., network devices), methods (also referred to as processes), and computer-readable media (collectively referred to herein as “systems and techniques”) are provided for optimizing situational awareness of vehicle misbehavior that may lead to traffic disruptions. These systems and techniques can provide a misbehavior detection service for sharing connected sensed objects (e.g., a V2X security service for sharing V2X sensor objects). In some cases, the disclosed service can utilize the line of sight of a V2X-enabled network device (e.g., a V2X-enabled base station) to confirm the presence of ghost objects located outside the line of sight of other V2X-enabled network devices (e.g., a V2X-enabled base station and / or vehicle). The service can enable the sharing of sensor-V2X detector output (e.g., output from a sensor on a V2X-enabled network device) to a V2X-enabled network device (e.g., a V2X-enabled vehicle) that does not have a sensor. The service can also enable communications (e.g., V2X communications) to network devices (e.g., V2X-enabled vehicles) regarding V2X sensor objects (e.g., physical objects perceived by sensors on a V2X-enabled network device local to the object). Additionally, the service can provide data redundancy to verify consistency between V2X objects (e.g., ghost objects indicated in vehicle-based messages transmitted via V2X communications) and V2X sensor objects (e.g., physical objects perceived by sensors on a V2X-enabled network device local to the object).

[0028]

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

[0029]

[0057] The terms “user equipment” (UE) and “network entity,” as used herein, are not intended to be specific or otherwise limited to any particular radio access technology (RAT) unless otherwise specified. In general, a UE can be any wireless communication device (e.g., a mobile phone, a router, a tablet computer, a laptop computer, and / or a tracking device, etc.), wearable (e.g., a smart watch, smart glasses, a wearable ring, and / or an extended reality (XR) device, such as a virtual reality (VR) headset, an augmented reality (AR) headset or glasses, or a mixed reality (MR) headset), vehicle (e.g., an automobile, a motorcycle, a bicycle, etc.), and / or 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," a "client device," a "wireless device," a "subscriber device," a "subscriber terminal," a "subscriber station," a "user terminal" or "UT," a "mobile device," a "mobile terminal," a "mobile station," or variations thereof. Generally, 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 a 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.).

[0030]

[0058] In some cases, the network entity may be implemented in a centralized or monolithic base station or server architecture, or alternatively, in a non-consolidated base station or server architecture, and may include one or more of a central unit (CU), a distributed unit (DU), a radio unit (RU), a near-real time (NRT) RAN intelligent controller (RIC), or a non-real time (Non-RT) RIC. In some cases, the network entity may include a server device, such as a multi-access edge computing (MEC) device. Depending on the network in which it is deployed, a base station or server (e.g., an aggregated / monolithic base station architecture or a disaggregated base station architecture) 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, Node B (NB), evolved Node B (eNB), next generation eNB (ng-eNB), new radio (NR) Node B (also referred to as gNB or gNode B), etc. Base stations may be primarily used to support wireless access by UEs, including supporting data, voice, and / or signaling connections for supported UEs. In some systems, base stations may provide edge node signaling functions, while in other systems, base stations may provide additional control and / or network management functions. The communication link through which a UE can send signals to a base station is called an uplink (UL) channel (eg, a reverse traffic channel, a reverse control channel, an access channel, etc.).A communication link over which a base station can send signals to a UE is called a downlink (DL) channel or a forward link channel (e.g., a paging channel, a control channel, a broadcast channel, or a forward traffic channel). As used herein, the term traffic channel (TCH) can refer to an uplink channel, a reverse channel, or either a downlink channel and / or a forward traffic channel.

[0031]

[0059] The term "network entity" or "base station" (e.g., having an aggregated / monolithic base station architecture or a disaggregated base station architecture) may refer to a single physical TRP or multiple physical TRPs, which may or may not be collocated. For example, when the term "network entity" or "base station" refers to a single physical TRP, the physical TRP may be an antenna of the base station corresponding to a cell (or several cell sectors) of the base station. When the term "network entity" or "base station" refers to multiple collocated physical TRPs, the physical TRPs may be an array of antennas of the base station (e.g., as in 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 TRPs 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, non-co-located physical TRPs may be serving base stations that receive measurement reports from the UE and neighboring base stations whose reference radio frequency (RF) signals (or simply "reference signals") the UE is measuring. Because 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.

[0032]

[0060] In some implementations that support UE positioning, a network entity or base station may not support wireless access by the UE (e.g., may not support data, voice, and / or signaling connections for the UE), but instead may transmit reference signals to the UE to be measured by the UE and / or may receive and measure signals transmitted by the UE. Such a base station may be referred to as a positioning beacon (e.g., if it transmits signals to the UE) and / or a location measurement unit (e.g., if it receives and measures signals from the UE).

[0033]

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

[0034]

[0062] The RSU can communicate with a communication system of the UE. For example, an intelligent transport system (ITS) of the UE (e.g., a vehicle and / or another UE) can be used to generate and sign messages for transmission to the RSU and to verify messages received from the RSU. The RSU can 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 traffic-related data, the RSU can determine or estimate traffic congestion information (e.g., start of traffic congestion, end of traffic congestion, etc.), travel time, and / or other information about a particular location. In some examples, the RSU can communicate with other RSUs (e.g., via a PC5 interface, a DSRC interface, etc.) to determine traffic-related data. The RSU can 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.

[0035]

[0063] A radio frequency signal or "RF signal" includes electromagnetic waves of a given frequency that transport information through space between a transmitter and a receiver. As used herein, a transmitter may transmit a single "RF signal" or multiple "RF signals" to a receiver. However, due to the propagation characteristics of RF signals through multipath channels, the receiver may receive multiple "RF signals" corresponding to each transmitted RF signal. The same RF signal transmitted over different paths between a transmitter and a receiver is sometimes 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.

[0036]

[0064] According to various aspects, FIG. 1 illustrates an exemplary wireless communication system 100. The wireless communication system 100 (which may also be referred to as a wireless wide area network (WWAN)) may include various base stations 102 and various UEs 104. In some aspects, the base stations 102 may also be referred to as “network entities” or “network nodes.” One or more of the base stations 102 may be implemented in an aggregated base station architecture or a monolithic base station architecture. Additionally or alternatively, one or more of the base stations 102 may be implemented in a non-aggregated base station architecture and may include one or more of a central unit (CU), a distributed unit (DU), a radio unit (RU), a near-real-time (near-RT) RAN intelligent controller (RIC), or a non-real-time (non-RT) RIC. The base stations 102 may include macrocell base stations (high-power cellular base stations) and / or small cell base stations (low-power cellular base stations). In one aspect, the macrocell base stations may include eNBs and / or ng-eNBs when the wireless communication system 100 supports a Long Term Evolution (LTE) network, or gNBs when the wireless communication system 100 supports an NR network, or a combination of both, and the small cell base stations may include femtocells, picocells, microcells, etc.

[0037]

[0065] The base stations 102, collectively forming a RAN, may interface with a core network 170 (e.g., evolved packet core (EPC) or 5G core (5G core, 5GC)) through backhaul links 122, and through the core network 170 to one or more location servers 172 (which may be part of the core network 170 or may reside outside the core network 170). In addition to other functions, the base stations 102 may perform functions related to one or more of forwarding user data, radio channel encryption and decryption, 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, RAN sharing, multimedia broadcast multicast service (MBMS), subscriber and equipment tracing, RAN information management (RIM), paging, positioning, and alert message delivery. The base stations 102 can communicate with each other directly or indirectly (e.g., through EPC or 5GC) via backhaul links 134, which may be wired and / or wireless.

[0038]

[0066] 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. In one aspect, one or more cells may be supported by the base stations 102 within each coverage area 110. A "cell" is a logical communication entity used for communication with a base station (e.g., over some frequency resource, referred to as a carrier frequency, component carrier, carrier, band, etc.) and may be associated with an identifier (e.g., a physical cell identifier (PCI), a virtual cell identifier (VCI), a cell global identifier (CGI)) to distinguish between cells operating over the same or different carrier frequencies. In some cases, different cells may be configured according to different protocol types (e.g., machine-type communication (MTC), narrowband IoT (NB-IoT), enhanced mobile broadband (eMBB), or others) that may provide access to different types of UEs. Because a cell is supported by a particular base station, the term "cell" can refer to either or both of the logical communication entity and the base station that supports it, depending on the context. Additionally, because a TRP is typically the physical transmission point of a cell, the terms "cell" and "TRP" are sometimes used interchangeably. In some cases, the term "cell" can also refer to the geographic coverage area (e.g., sector) of a base station, so long as the carrier frequency can be detected and used for communication within some portion of the geographic coverage area 110.

[0039]

[0067] The geographic coverage areas 110 of neighboring macrocell base stations 102 may partially overlap (e.g., in handover regions), and some of the geographic coverage areas 110 may be significantly overlapped by larger geographic coverage areas 110. For example, a small cell base station 102' may have a coverage area 110' that significantly overlaps with the coverage area 110 of one or more macrocell base stations 102. A network including both small cell and macrocell base stations is sometimes known as a heterogeneous network. A heterogeneous network may also include home eNBs (HeNBs), which may serve closed groups known as closed subscriber groups (CSGs).

[0040]

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

[0041]

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

[0042]

[0070] The small cell base station 102' may operate in a licensed and / or unlicensed frequency spectrum. When operating in an unlicensed frequency spectrum, the small cell base station 102' may employ LTE or NR technology and use the same 5 GHz unlicensed frequency spectrum used by the WLAN AP 150. By employing LTE and / or 5G in the unlicensed frequency spectrum, the small cell base station 102' may enhance coverage to and / or increase capacity of the access network. NR in the unlicensed spectrum may be referred to as NR-U. LTE in the unlicensed spectrum may be referred to as LTE-U, licensed assisted access (LAA), or MultiFire.

[0043]

[0071] The wireless communication system 100 may further include a millimeter wave (mmW) base station 180 in communication with the UE 182, which may operate at millimeter wave (mmW) and / or sub-mmW frequencies. The mmW base station 180 may be implemented in an aggregated or monolithic base station architecture, or alternatively, in a disaggregated base station architecture (e.g., including one or more of a CU, DU, RU, sub-RT RIC, or non-RT RIC). Extremely high frequency (EHF) is a portion of RF in the electromagnetic spectrum. EHF has a range of 30 GHz to 300 GHz and a wavelength of 1 millimeter to 10 millimeters. Radio waves in this band may be referred to as millimeter waves. Sub-mmW may go down to frequencies of 3 GHz with wavelengths of 100 millimeters. The super high frequency (SHF) band ranges from 3 GHz to 30 GHz and is also referred to as centimeter waves. Communications using mmW and / or sub-mmW radio frequency bands have high path loss and relatively short distances. The mmW base station 180 and the UE 182 can utilize beamforming (transmit and / or receive) over the mmW communication link 184 to compensate for the extremely high path loss and short distances. Furthermore, it will be appreciated that in alternative configurations, one or more base stations 102 can also transmit using mmW or quasi-mmW and beamforming. Accordingly, it will be appreciated that the above illustrations are merely examples and should not be construed as limiting various aspects disclosed herein.

[0044]

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

[0045]

[0073] A transmit beam may be quasi-collocated, meaning that the transmit beam appears to a receiver (e.g., a UE) to have the same parameters regardless of whether the network node's transmitting antenna itself is physically collocated. In NR, there are four types of quasi-collocation (QCL) relationships. Specifically, a given type of QCL relationship means that some parameters for a second reference RF signal on a second beam can be derived from information about a source reference RF signal on a source beam. Thus, if the source reference RF signal is QCL Type A, the receiver can use the source reference RF signal to estimate the Doppler shift, Doppler spread, mean delay, and delay spread of the second reference RF signal transmitted on the same channel. If the source reference RF signal is QCL Type B, the receiver can use the source reference RF signal to estimate the Doppler shift and Doppler spread of the second reference RF signal transmitted on the same channel. If the source reference RF signal is QCL Type C, the receiver can use the source reference RF signal to estimate the Doppler shift and average delay of a second reference RF signal transmitted on the same channel. If the source reference RF signal is QCL Type D, the receiver can use the source reference RF signal to estimate spatial reception parameters of a second reference RF signal transmitted on the same channel.

[0046]

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

[0047]

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

[0048]

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

[0049]

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

[0050]

[0078] For example, with continued reference to FIG. 1 , one of the frequencies utilized by the macrocell base station 102 may be an anchor carrier (or “PCell”), and other frequencies utilized by the macrocell base station 102 and / or the mmW base station 180 may be secondary carriers (“SCells”). In carrier aggregation, the base station 102 and / or the UE 104 may use up to Y MHz (e.g., 5, 10, 15, 20, 100 MHz) of bandwidth per carrier for transmission in each direction, for a total of Yx MHz (x component carriers) of spectrum. These component carriers may or may not be adjacent to each other in the frequency spectrum. Carrier allocation may be asymmetric with respect to the downlink and uplink (e.g., the downlink may be allocated more or fewer carriers than the uplink). Simultaneous transmission and / or reception of multiple carriers allows the UE 104 / 182 to significantly increase its data transmission and / or reception rates. For example, two 20 MHz carriers aggregated in a multi-carrier system would theoretically provide a doubling of the data rate (i.e., 40 MHz) compared to the data rate achieved by a single 20 MHz carrier.

[0051]

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

[0052]

[0080] Wireless communications system 100 may further include a UE 164 capable of communicating with macrocell base station 102 via communications link 120 and / or with mmW base station 180 via mmW communications link 184. For example, macrocell base station 102 may support a PCell and one or more SCells for UE 164, and mmW base station 180 may support one or more SCells for UE 164.

[0053]

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

[0054]

[0082] 2 illustrates an example of a decentralized base station architecture that may be employed by the disclosed system for misbehavior detection services for sharing connected and sensed objects, according to some examples. A deployment of a communication system, such as a 5G NR system, may be configured in multiple ways using various components or components. In a 5G NR system or network, one or more units (or one or more components) performing network functions, such as a network node, network entity, network mobility element, radio access network (RAN) node, core network node, network element, or base station (BS), may be implemented in a centralized or decentralized architecture. For example, a BS (e.g., a Node B (NB), evolved NB (eNB), NR BS, 5G NB, AP, transmit / receive point (TRP), or cell) may be implemented as a centralized base station (also known as a standalone BS or monolithic BS) or a decentralized base station.

[0055]

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

[0056]

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

[0057]

[0085] As mentioned above, FIG. 2 shows a diagram illustrating the architecture of an exemplary disaggregated base station 201. The disaggregated base station 201 architecture can include one or more central units (CUs) 211 that can communicate directly with the core network 223 via a backhaul link or indirectly with the core network 223 via one or more separate base station units (e.g., a near-real-time (near-RT) RAN intelligent controller (RIC) 227 via an E2 link, or a non-real-time (non-RT) RIC 217 associated with a Service Management and Orchestration (SMO) framework 207, or both). The CUs 211 can communicate with one or more distributed units (DUs) 231 via respective midhaul links, such as an F1 interface. The DUs 231 can communicate with one or more radio units (RUs) 241 via respective fronthaul links. The RUs 241 can communicate with respective UEs 221 via one or more RF access links. In some implementations, the UE 221 may be served by multiple RUs 241 simultaneously.

[0058]

[0086] Each of the units, i.e., CU211, DU231, RU241, quasi-RT RIC227, non-RT RIC217, and SMO framework 207, may include or be coupled to one or more interfaces configured to receive or transmit signals, data, or information (collectively, signals) via a wired or wireless transmission medium. Each of the units, or an associated processor or controller that provides instructions to the unit's communication interface, may be configured to communicate with one or more of the other units via a transmission medium. For example, a unit may include a wired interface configured to receive or transmit signals to one or more of the other units via a wired transmission medium. In addition, a unit may include a wireless interface, which may include a receiver, transmitter, or transceiver (e.g., an RF transceiver), configured to receive signals from, transmit signals to, or both of, one or more of the other units via a wireless transmission medium.

[0059]

[0087] In some aspects, the CU 211 can host one or more upper layer control functions. Such control functions may include radio resource control (RRC), packet data convergence protocol (PDCP), service data adaptation protocol (SDAP), etc. Each control function may be implemented using an interface configured to communicate signals with other control functions hosted by the CU 211. The CU 211 may be configured to handle user plane functions (i.e., central unit-user plane (CU-UP)), control plane functions (i.e., central unit-control plane (CU-CP)), or a combination thereof. In some implementations, the CU 211 may be logically divided into one or more CU-UP units and one or more CU-CP units. The CU-UP unit, when implemented in an O-RAN configuration, may communicate bidirectionally with the CU-CP unit via an interface, such as an E1 interface. The CU 211 may be implemented to communicate with the DU 131 as needed for network control and signaling.

[0060]

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

[0061]

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

[0062]

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

[0063]

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

[0064]

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

[0065]

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

[0066]

[0094] 3 shows a particular number of vehicles (e.g., two vehicles 304 and 305) communicating with each other and / or with the RSU 303, the BS 302, and / or the user device 307, the present disclosure is not limited thereto. For example, tens or hundreds of such vehicles may be in communication with each other and / or with the RSU 303, the BS 302, and / or the user device 307. At any given time, each such vehicle, RSU 303, the BS 302, and / or the user device 307 may transmit various types of information as messages to other nearby vehicles, such that each vehicle (e.g., vehicles 304 and / or 305), the RSU 303, the BS 302, and / or the user device 307 receives hundreds or thousands of messages per second from other nearby vehicles, RSUs, base stations, and / or other UEs.

[0067]

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

[0068]

[0096] 4 is a block diagram illustrating an example of a vehicle computing system 450 of a vehicle 404. The vehicle 404 is an example of a UE that can communicate with a network (e.g., eNBs, gNBs, positioning beacons, location measurement units, and / or other network entities) over a Uu interface and can communicate with other UEs using V2X communications over a PC5 interface (or other direct device-to-device interface, such as a DSRC interface). As shown, the vehicle computing system 450 can include at least a power management system 451, a control system 452, an infotainment system 454, an intelligent transportation system (ITS) 455, one or more sensor systems 456, and a communication system 458. In some cases, vehicle computing system 450 may include or be implemented using any type of processing device or system, such as one or more central processing units (CPUs), digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), application processors (APs), graphics processing units (GPUs), vision processing units (VPUs), neural network signal processors (NSPs), microcontrollers, dedicated hardware, any combination thereof, and / or other processing devices or systems.

[0069]

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

[0070]

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

[0071]

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

[0072]

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

[0073]

[0101] User SIM 462 may be used by communication system 458 to perform wireless network access functions to support user data connectivity (e.g., for calling, messaging, infotainment-related services, among others). In some cases, the user's user device may connect with vehicle computing system 450 via an interface (e.g., PC5, Bluetooth™, WiFI™ (e.g., DSRC), universal serial bus (USB) port, and / or other wireless or wired interface). Once connected, the user device may transfer wireless network access functions from the user device to the vehicle's communication system 458, in which case the user device may cease performing wireless network access functions (e.g., during periods when communication system 458 is performing wireless access functions). Communication system 458 may initiate interactions with base stations to perform one or more wireless communication operations, such as facilitating calls, transmitting and / or receiving data (e.g., messaging, video, audio, etc.), among other operations. In such cases, other components of vehicle computing system 450 may be used to output data received by communication system 458. For example, infotainment system 454 (described below) may display video received by communication system 458 on one or more displays and / or output audio received by communication system 458 using one or more speakers.

[0074]

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

[0075]

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

[0076]

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

[0077]

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

[0078]

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

[0079]

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

[0080]

[0108] The conditions used to determine whether to generate a message may be determined using the CAN information based on safety-related and / or other applications, including road safety, traffic efficiency, infotainment, business-related, and / or other applications. In one illustrative example, the ITS 455 may perform lane change assistance or coordination. For example, using the CAN information, the ITS 455 may determine that the driver of the vehicle 404 is attempting to change lanes from a current lane to an adjacent lane (e.g., based on a turn signal being activated, a user turning or steering into an adjacent lane, etc.). Based on determining that the vehicle 404 is attempting to change lanes, the ITS 455 may determine that a lane change condition has been met that relates to a message to be sent to other vehicles in an adjacent lane near the vehicle. The ITS 455 may cause the ITS stack to generate one or more messages to send to other vehicles, which may be used to coordinate a lane change with the other vehicles. Other example applications include forward collision warning, automatic emergency braking, lane departure warning, pedestrian avoidance or protection (e.g., when pedestrians are detected near the vehicle 404, such as based on V2P communication with the user's UE), and traffic sign recognition, among others.

[0081]

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

[0082]

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

[0083]

[0111] In some examples, the ITS 455 can determine an action (e.g., a V2X-based action) to perform based on a message received from another UE. The action can include safety-related and / or other actions, such as actions for road safety, traffic efficiency, infotainment, business, and / or other applications. In some examples, the action can include causing the vehicle (e.g., the control system 452) to perform automated functions, such as automatic braking, automatic steering (e.g., to maintain heading in a particular lane), and automated lane change negotiation with the other vehicle, among other automated functions. In one illustrative example, a message indicating that the other vehicle is coming to an emergency stop can be received by the communication system 458 from another device (e.g., via a PC5 interface, a DSRC interface, or other direct device-to-device interface). In response to receiving the message, the ITS stack can generate a message or command and send the message or command to the control system 452, which can cause the control system 452 to automatically brake the vehicle 404 to stop before it collides with the other vehicle. In other illustrative examples, the actions may include triggering the display of a message alerting the driver that there is another vehicle in the lane next to the vehicle, a message alerting the driver to stop the vehicle, a message alerting the driver that there is a pedestrian in the crosswalk ahead, a message alerting the driver that a toll booth is within a certain distance (e.g., within one mile) of the vehicle, among other things.

[0084]

[0112] In some examples, the ITS 455 may receive a large number of messages from other UEs (e.g., vehicles, RSUs, etc.), in which case the ITS 455 authenticates (e.g., decrypts and decrypts) each of the messages and / or determines which action to perform. Such a large number of messages may result in a large computational load for the vehicle computing system 450. In some cases, the large computational load may increase the temperature of the computing system 450. The increased temperature of the components of the computing system 450 may adversely affect the computing system 450's ability to process a large number of received messages. Based on the temperature of the vehicle computing system 450 (or its components) exceeding or approaching one or more thermal levels, one or more functions may be transferred from the vehicle 404 to another device (e.g., a user device, an RSU, etc.). Transferring one or more functions may reduce the computational load of the vehicle 404 and help reduce the temperature of the components. A thermal load balancer may be provided that enables the vehicle computing system 450 to perform thermal-based load balancing to control processing load depending on the temperature of the computing system 450 and the processing capabilities of the vehicle computing system 450.

[0085]

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

[0086]

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

[0087]

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

[0088]

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

[0089]

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

[0090]

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

[0091]

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

[0092]

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

[0093]

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

[0094]

[0122] FIG. 6 illustrates an example 600 of wireless communication between devices based on sidelink communication, such as V2X or other D2D communication. The communication may be based on a slot structure. For example, a transmitting UE 602 may transmit a transmission 614, e.g., including a control channel and / or a corresponding data channel, which may be received by receiving UEs 604, 606, and 608. At least one UE may include an autonomous vehicle or 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 occupied resources during data transmission. The number of TTIs and RBs occupied by the data transmission may be indicated in a control message from the transmitting device. Each of the UEs 602, 604, 606, and 608 may be capable of operating as a transmitting device in addition to operating as a receiving device. Thus, the UEs 606 and 608 are shown transmitting transmissions 616 and 620. The transmissions 614, 616, 620 (and 618 by the RSU 607) may be broadcast or multicast to nearby devices. For example, the UE 614 may transmit a communication intended for reception by other UEs within range 601 of the UE 614. Additionally / alternatively, the RSU 607 may receive a communication from and / or transmit a communication 618 to the UEs 602, 604, 606, 608. The UEs 602, 604, 606, 608 or the RSU 607 may comprise a detection component. The UEs 602, 604, 606, 608 or the RSU 607 may also comprise a BSM or mitigation component.

[0095]

[0123] In wireless communication such as V2X communication, a V2X entity may perform sensor sharing with other V2X entities for cooperative automated driving. For example, referring to diagram 700 of FIG. 7A , a host vehicle (HV) 702 may detect several items in its environment. For example, the HV 702 may detect the presence of a non-V2X entity (NV) 706 in block 732. The HV 702 may notify other entities, such as a first remote vehicle (RV1) 704 and / or a roadside unit (RSU) 708, about the presence of the NV 706 if the NV 706 cannot be detected by itself. The HV 702 notifying the RV1 704 and / or the RSU 708 about the NV 706 is sensor information sharing. Referring to diagram 710 in FIG. 7B , HV 702 may detect a physical obstacle 712, such as a pothole, debris, or object, that may be an obstacle in the path of HV 702 and / or RV1 704 that has not yet been detected by RV1 704 and / or RSU 708. HV 702 may notify RV1 and / or RSU 708 about the obstacle 712 so that the obstacle 712 can be avoided. Referring to diagram 720 in FIG. 7C , HV 702 may detect the presence of a vulnerable road user (VRU) 722 and may share the detection of the VRU 722 with RV1 704 and RSU 708 if RSU 708 and / or RV1 704 are unable to detect the VRU 722. Referring to diagram 730 of FIG. 7D, when an HV detects a nearby entity (e.g., an NV, a VRU, an obstacle), it may send a sensor data sharing message (SDSM) 734 to the RV and / or RSU to share the entity's detection. The SDSM 734 may be a broadcast message such that any receiving device within the HV's vicinity can receive the message. In some cases, the shared information may be relayed to other entities, such as the RV. For example, referring to diagram 800 of FIG. 8, an HV 802 may detect the presence of an NV 806 and / or a VRU 822.The HV 802 may broadcast the SDSM 810 to the RSU 808 to report the detection of the NV 806 and / or VRU 822. The RSU 808 may relay the SDSM 810 received from the HV 802 to the remote vehicles so that the remote vehicles are aware of the presence of the NV 806 and / or VRU 822. For example, the RSU 808 may transmit an SDSM 812 to the RV1 804, where the SDSM 812 includes information related to the detection of the NV 806 and / or VRU 822.

[0096]

[0124] FIG. 9 illustrates an example system 900 for sensor sharing in wireless communications (e.g., V2X communications) in accordance with some aspects of the present disclosure. In FIG. 9, system 900 is shown to include multiple equipped (e.g., V2X-enabled) network devices. The multiple equipped network devices include vehicles (e.g., automobiles) 910a, 910b, 910c, and 910d, and an RSU 905. Also shown are multiple unequipped network devices, including an unequipped vehicle 920, a VRU (e.g., a cyclist) 930, and a pedestrian 940. System 900 may include more or fewer equipped network devices and / or more or fewer unequipped network devices than shown in FIG. 9. Additionally, system 900 may include more or fewer different types of equipped network devices (e.g., which may include equipped UEs) and / or more or fewer different types of unequipped network devices (e.g., which may include unequipped UEs) than shown in FIG. 9. Additionally, in one or more examples, the equipped network devices may be equipped with heterogeneous capabilities, which may include, but are not limited to, C-V2X / DSRC capabilities, 4G / 5G cellular connectivity, GPS capabilities, camera capabilities, radar capabilities, and / or LIDAR capabilities.

[0097]

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

[0098]

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

[0099]

[0127] During operation of system 900, equipped network devices (e.g., RSU 905 and / or at least one of vehicles 910a, 910b, 910c, 910d) can transmit and / or receive sensing signals (e.g., RF signals and / or optical signals) to sense and detect vehicles (e.g., vehicles 910a, 910b, 910c, 910d, and 920) and / or objects (e.g., VRU 930 and pedestrian 940) located in and around roads. The equipped network devices (e.g., RSU 905 and / or at least one of vehicles 910a, 910b, 910c, 910d) can then use the sensing signals to determine characteristics (e.g., movement, size, type, direction of travel, speed) of the detected vehicles and / or objects. An equipped network device (e.g., RSU 905 and / or at least one of vehicles 910a, 910b, 910c, 910d) may generate at least one vehicle-based message 915 (e.g., V2X messages such as Sensor Data Sharing Messages (SDSMs), Basic Safety Messages (BSMs), Cooperative Awareness Messages (CAMs), Collective Awareness Messages (CPMs), and / or other types of messages) that includes information related to determined characteristics of the detected vehicle and / or object.

[0100]

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

[0101]

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

[0102]

[0130] In some implementations, the vehicle-based messages 915 may include specific use cases or safety warnings, such as a do-not-pass warning (DNPW) or a forward collision warning (FCW), related to the current state of the equipped network devices (e.g., vehicles 910a, 910b, 910c, 910d). In some examples, the vehicle-based messages 915 may be in the form of a standard Basic Safety Message (BSM), Cooperative Awareness Message (CAM), Collective Awareness Message (CPM), Sensor Data Sharing Message (SDSM) (e.g., SAE J3224 SDSM), and / or other formats.

[0103]

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

[0104]

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

[0105]

[0133] As previously discussed, a sending network device (e.g., a V2X-enabled vehicle generating and sending a vehicle-based message such as a BSM) may be misbehaving (e.g., operating as a misbehaving vehicle) by intentionally or unintentionally sending a vehicle-based message (e.g., a BSM) that includes inaccurate information. A sending network device may be operating as a misbehaving vehicle if, for example, information included in the vehicle-based message (e.g., a BSM) identifies an inaccurate position (or location) of the sending network device.

[0106]

[0134] A sending network device (e.g., a V2X-enabled vehicle generating and sending a vehicle-based message) may be misbehaving (e.g., acting as a misbehaving vehicle) by acting as an attacker by creating invisible V2X ghost objects to disrupt road traffic. A ghost V2X object is a V2X object that is not at the sending network device's location. A ghost V2X object is an object that does not physically exist, such as a simulated vulnerable road user (VRU) or a simulated vehicle. An invisible object is an object that is located outside the sensor field of view (FoV) or not in line of sight (LoS) (e.g., non-line-of-sight scenario) of a receiving network device (e.g., a V2X-enabled vehicle receiving a vehicle-based message).

[0107]

[0135] An attacker's goal may be to eliminate the benefits of utilizing sensors that utilize V2X communications. The attacker may utilize ghost objects that are beyond line of sight (NLoS). For example, when an object (e.g., a ghost object) is not located within the vehicle's line of sight, the sensors associated with the vehicle cannot confirm the presence (or absence) of the object. Because the vehicle cannot confirm the presence (or absence) of the object, the vehicle driver may be forced to slow down (e.g., slow down) the vehicle to ensure that the vehicle does not collide with the object (which may be, for example, a ghost object that does not actually exist). This effect of forcing the driver to perform unnecessary maneuvers (e.g., slowing down the vehicle) may cause driver frustration and disrupt traffic, resulting in traffic congestion and / or vehicle collisions.

[0108]

[0136] 11 is a diagram illustrating an example of a vehicle configuration 1100 for a non-line-of-sight (NLoS) scenario, according to some aspects of the present disclosure. In FIG. 11, several equipped (e.g., V2X-enabled) network devices 1110a, 1110b, 1110c in the form of trucks are shown. FIG. 11 also illustrates an unequipped (e.g., non-V2X-enabled) object 1120 in the form of a pedestrian.

[0109]

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

[0110]

[0138] The equipped network device 1110a (e.g., truck) may not be aware of the unequipped object 1120 (e.g., pedestrian) because the unequipped object 1120 (e.g., pedestrian) is not within line of sight (NLoS) (e.g., not within the field of view) of sensors on the equipped network device 1110a (e.g., truck). In some cases, an attacker (e.g., vehicle) may send a vehicle-based message (e.g., BSM or CAM) to the equipped network device 1110a (e.g., truck) notifying the equipped network device 1110a (e.g., truck) of the unequipped object 1120 (e.g., pedestrian) heading in the direction of line 1130a. However, because the unequipped object 1120 (e.g., a pedestrian) is located outside the line of sight of the equipped network device 1110a (e.g., a truck), the sensors of the equipped network device 1110a (e.g., a truck) cannot detect the unequipped object 1120 (e.g., a pedestrian) and verify whether the unequipped object 1120 (e.g., a pedestrian) is physically present or simply a ghost object.

[0111]

[0139] As previously mentioned, a V2X communication system may transmit information from a vehicle's sensors over a wireless link to communicate the information to other vehicles, pedestrians, VRUs, and / or transportation infrastructure. The information may be transmitted using one or more vehicle-based messages, such as cellular-vehicle-to-everything (C-V2X) messages (e.g., vehicle-based messages), which may include sensor data sharing messages (SDSMs), basic safety messages (BSMs), cooperative awareness messages (CAMs), collective awareness messages (CPMs), distributed environment messages (DENMs), and / or other types of vehicle-based messages.

[0112]

[0140] Current vehicle-based messages (e.g., V2X messages) have their own purposes and limitations. For example, an equipped (e.g., V2X-equipped) network device (e.g., a vehicle) may transmit a CAM or BSM to share the location, kinematic state, and / or dimensions of the equipped network device. A CAM may have the ability to describe (create) ghost objects. In another example, an equipped (e.g., V2X-equipped) network device (e.g., a vehicle) may transmit a CPM or SDSM to share information about all objects perceived by sensors on the equipped network device. However, a CPM cannot include objects (e.g., V2X-enabled objects) that transmit V2X messages (e.g., BSMs and CAMs).

[0113]

[0141] The CPM (e.g., sensor view) and CAM / BSM (e.g., V2X object) do not have redundancy regarding the detected object. For example, a receiving equipped (e.g., V2X-enabled) network device (e.g., vehicle) can recognize the object based on the BSM received from the object. However, the receiving equipped network device may not use the CPM to verify whether the vehicle was detected by the sensors of the equipped (e.g., V2X-enabled) network device (e.g., vehicle) that transmitted the CPM (e.g., as shown in FIG. 12C).

[0114]

[0142] Current vehicle-based messages (e.g., V2X messages) do not include "fused objects." A "fused object" may be defined as an equipped (e.g., V2X-enabled) object (e.g., a vehicle or a pedestrian with a smartphone) perceived by an ITS-S sensor (e.g., as shown in FIG. 12D). A transmitting equipped (e.g., V2X-enabled) network device (e.g., a vehicle) may transmit the fused object as a result of V2X-sensor data fusion. An equipped (e.g., V2X-enabled) network device (e.g., a vehicle) may not combine CPM and BSM for sensor-V2X misbehavior detection.

[0115]

[0143] 12A, 12B, 12C, and 12D illustrate different views from the perspective of a receiving equipped (e.g., V2X-enabled) network device (e.g., a vehicle). In FIGS. 12A, 12B, 12C, and 12D, a sensor field of view 1220 of a sensor on a vehicle 1210 is illustrated in different views. In particular, FIG. 12A illustrates an example of a ground truth view from the perspective of a receiving equipped (e.g., V2X-enabled) network device 1210 (e.g., a vehicle). In FIG. 12A, the sensor field of view 1220 is shown to include an equipped (e.g., V2X-enabled) object 1230a and an unequipped (e.g., non-V2X-enabled) object 1240a. Also illustrated in FIG. 12A is an equipped (e.g., V2X-enabled) object 1230b and an unequipped (e.g., non-V2X-enabled) object 1240b that are not within the sensor field of view 1220.

[0116]

[0144] Figure 12B is a diagram illustrating an example of a Basic Safety Message (BSM) view from the perspective (e.g., of a vehicle) of a receiving equipped (e.g., V2X-enabled) network device 1210. In Figure 12B, the sensor field of view 1220 is shown to include an equipped (e.g., V2X-enabled) object 1230a. Also shown in Figure 12B is an equipped (e.g., V2X-enabled) object 1230b that is not within the sensor field of view 1220.

[0117]

[0145] Figure 12C is a diagram illustrating an example of a collective perception message (CPM) view from the perspective of a receiving equipped (e.g., V2X-enabled) network device 1210 (e.g., a vehicle). In Figure 12C, the sensor field of view 1220 is shown to include an unequipped (e.g., non-V2X-enabled) object 1240a. Figure 12D is a diagram illustrating an example of a "fused object" view from the perspective of a receiving equipped (e.g., V2X-enabled) network device 1210 (e.g., a vehicle). In Figure 12D, the sensor field of view 1220 is shown to include an equipped (e.g., V2X-enabled) object 1230a.

[0118]

[0146] As mentioned above, current detection systems may have problems verifying the physical presence of an object (e.g., an unequipped object or an equipped object) in non-line-of-sight situations. Currently, detectors may be inefficient and / or insufficient to be able to detect attacks (e.g., in non-line-of-sight situations). Current detectors may have limited range, may not work for V2X-enabled objects that are not in line-of-sight to be sensed (e.g., non-line-of-sight), and / or may not be utilized by vehicles without sensors.

[0119]

[0147] In one or more aspects, the present systems and techniques provide misbehavior detection (MBD) services for sharing connected sensed objects (e.g., V2X security services for sharing V2X sensor objects). The system can use the disclosed techniques to enable detection of non-line-of-sight V2X ghost objects. For example, a neighboring ITS-S may have a location that is different from the location of the host vehicle (e.g., an autonomous vehicle). An object (e.g., a ghost) that is non-line-of-sight to the vehicle may be an object (e.g., a ghost object) within line-of-sight to the neighboring ITS-S. The neighboring ITS-S can communicate to the vehicle whether an object is present (e.g., a ghost object).

[0120]

[0148] The disclosed system has several advantages. In one or more aspects, the system has the advantage of providing a solution for detecting ghost objects outside of line-of-sight. This advantage can prevent drivers from braking (e.g., slowing down) and / or becoming stuck in the presence of V2X objects outside of line-of-sight. In some aspects, this solution can be incorporated as part of European Telecommunications Standards Institute (ETSI) 103 759. The system has another advantage of providing a solution for vehicles without sensors to use V2X sensor detectors (sensors) from nearby ITS-Ss. Furthermore, the system has the advantage of sharing “fused objects” with other ITS-Ss. For example, an ITS-S may not have the exact location of an object outside of line-of-sight. A nearby ITS-S may have “top-tier” (high-quality) sensors that can make better measurements, which can benefit other ITS-Ss with “low-tier” (low-quality) sensors.

[0121]

[0149] 13, 14A, 14B, and 14C show example systems 1300, 1400, 1401, and 1402, respectively, for a fused data sharing service (FDSS) that may be employed by V2X. FDSS allows equipped network devices that do not have sensors and / or have suspect objects outside of line-of-sight or visual range to verify whether the suspect object is present or a ghost object.

[0122]

[0150] FIG. 13 illustrates an example system 1300 for a misbehavior detection service for sharing connected sensed objects, in which an equipped (e.g., V2X-enabled) network device A 1340 (e.g., traffic infrastructure such as ITS-s) having multiple sensors 1350a, 1350b visually observes another equipped network device B 1310 (e.g., a vehicle). In FIG. 13, the equipped (e.g., V2X-enabled) network device B 1310 (e.g., a vehicle) is shown traveling on a road surrounded by obstructing buildings 1320a, 1320b and obstacles 1330a, 1330b. The sensor field of view 1370d of the equipped network device B 1310 is shown. The equipped (e.g., V2X-enabled) network device A 1340 (e.g., traffic infrastructure such as ITS-s, stop lights, or RSUs) is also shown in FIG. 13 with its associated sensors 1350a, 1350b. Shown are the sensor fields of view 1370a, 1370b, 1370c of an equipped network device A 1340 and its associated sensors 1350a, 1350b.

[0123]

[0151] During operation of the system 1300, the equipped network device B 1310 (e.g., a vehicle) may receive a BSM from the equipped (e.g., V2X-enabled) network device C 1360 (e.g., an object) that is located outside the line of sight of the equipped network device B 1310. The BSM may indicate the location of the equipped (e.g., V2X-enabled) network device C 1360 (e.g., the object). Because the equipped (e.g., V2X-enabled) network device C 1360 (e.g., the object) is located outside the line of sight of the equipped network device B 1310, the equipped network device B 1310 cannot verify (e.g., using its sensors) the indicated location of the equipped (e.g., V2X-enabled) network device C 1360 (e.g., the object) to determine whether the equipped (e.g., V2X-enabled) network device C 1360 (e.g., the object) is present at the indicated location.

[0124]

[0152] However, equipped (e.g., V2X-enabled) network device C 1360 (e.g., an object) is located within line of sight and within sensor field of view 1370c (e.g., line of sight) of sensor 1350b associated with equipped (e.g., V2X-enabled) network device A 1340. Equipped network device B 1310 (e.g., a vehicle) can send (transmit) a fusion data sharing message (FDSM) request to equipped (e.g., V2X-enabled) network device A 1340 requesting that equipped (e.g., V2X-enabled) network device A 1340 verify the location of equipped (e.g., V2X-enabled) network device C 1360 (e.g., an object). After receiving the FDSM request, equipped (e.g., V2X-enabled) network device A 1340 can verify the location of equipped (e.g., V2X-enabled) network device C 1360 (e.g., an object) using its sensor 1350b. In response, equipped (e.g., V2X-enabled) network device A 1340 may send (transmit) an FDSM response including the verified location to equipped (e.g., V2X-enabled) network device B 1310.

[0125]

[0153] In one or more aspects, during operation of an FDSS, an equipped (e.g., V2X-enabled) network device (e.g., an ITS-S, a vehicle, an RSU, a pedestrian with a smartphone, or a drone) may provide feedback (e.g., regarding ghost objects) to another equipped (e.g., V2X-enabled) network device. In some aspects, during operation of an FDSS, a single equipped (e.g., V2X-enabled) network device (e.g., an ITS-S, a vehicle, an RSU, a pedestrian with a smartphone, or a drone), which may be operating as a platoon leader, may request feedback from another equipped (e.g., V2X-enabled) network device. Figures 14A, 14B, and 14C illustrate examples of FDSS operation in which an equipped network device provides feedback to and requests feedback from another equipped network device.

[0126]

[0154] 14A is a diagram illustrating an example system 1400 for misbehavior detection services for sharing connected sensed objects, where a platoon leader (e.g., equipped network device A 1410a) visually verifies equipped (e.g., V2X-enabled) network device C 1460. In FIG. 14A, equipped (e.g., V2X-enabled) network device A 1410a (e.g., a vehicle), equipped (e.g., V2X-enabled) network device B 1410c (e.g., a vehicle), and equipped (e.g., V2X-enabled) network device 1410c (e.g., a vehicle) are shown traveling on a road. Equipped (e.g., V2X-enabled) network device A 1410a (e.g., a vehicle), equipped (e.g., V2X-enabled) network device B 1410c (e.g., a vehicle), and equipped (e.g., V2X-enabled) network device 1410c (e.g., a vehicle) may all be in a platoon, with equipped (e.g., V2X-enabled) network device A 1410a (e.g., a vehicle) acting as the platoon leader. Also shown in Figure 14 is the sensor field of view 1470b of equipped network device B 1410b and the sensor field of view 1470a of equipped network device A 1410a.

[0127]

[0155] During operation of the system 1400, an equipped network device B 1410b (e.g., a vehicle) may receive a BSM from an equipped (e.g., V2X-enabled) network device C 1460 (e.g., an object) that is located outside the line of sight of the equipped network device B 1410b. The BSM may indicate the location of the equipped (e.g., V2X-enabled) network device C 1460 (e.g., the object). Because the equipped (e.g., V2X-enabled) network device C 1460 (e.g., the object) is located outside the line of sight of the equipped network device B 1410b, the equipped network device B 1410b cannot verify (e.g., using its sensors) the indicated location of the equipped (e.g., V2X-enabled) network device C 1460 (e.g., the object) to determine whether the equipped (e.g., V2X-enabled) network device C 1460 (e.g., the object) is present at the indicated location.

[0128]

[0156] However, equipped (e.g., V2X-enabled) network device C 1460 (e.g., an object) is located within line of sight and within sensor field of view 1470a (e.g., line of sight) of equipped (e.g., V2X-enabled) network device A 1410a (e.g., a vehicle). Equipped network device B 1410b (e.g., a vehicle) can send (transmit) an FDSM request to equipped (e.g., V2X-enabled) network device A 1410a requesting that equipped (e.g., V2X-enabled) network device A 1410a verify the location of equipped (e.g., V2X-enabled) network device C 1460 (e.g., the object). After receiving the FDSM request, equipped (e.g., V2X-enabled) network device A 1410a can use its sensors to verify the location of equipped (e.g., V2X-enabled) network device C 1460 (e.g., the object). In response, equipped (e.g., V2X-enabled) network device A 1410a may send (transmit) an FDSM response including the verified location to equipped (e.g., V2X-enabled) network device B 1410b.

[0129]

[0157] In one or more aspects, if a platoon member (e.g., equipped network device 1410b) can benefit from an FDSS, the platoon leader (e.g., equipped network device 1410a) can send (transmit) an FDSM response without first receiving an FDSM request. In some aspects, system 1400 can include equipped network devices in the form of drones (and / or RSUs) that can send (transmit) an FDSM response without first receiving an FDSM request.

[0130]

[0158] FIG. 14B illustrates an example system 1401 for misbehavior detection services for sharing connected sensed objects, in which an equipped (e.g., V2X-enabled) network device A 1441 (e.g., ITS-S) with a single sensor visually ascertains another equipped network device C 1461 (e.g., an object). In FIG. 14B, an equipped (e.g., V2X-enabled) network device B 1411 (e.g., a vehicle) is shown traveling on a road surrounded by an obstructing building 1421 and obstacles 1431a, 1431b. The sensor field of view 1471b of the equipped network device B 1411 is shown. An equipped (e.g., V2X-enabled) network device A 1441a (e.g., traffic infrastructure such as an ITS-S, stop light, drone, or RSU) is also shown in FIG. 14B. The sensor field of view 1471a of the equipped network device A 1441 is shown.

[0131]

[0159] During operation of the system 1401, the equipped network device B 1411 (e.g., a vehicle) may receive a BSM from the equipped (e.g., V2X-enabled) network device C 1461 (e.g., an object) that is located outside the line of sight of the equipped network device B 1411. The BSM may indicate the location of the equipped (e.g., V2X-enabled) network device C 1461 (e.g., the object). Because the equipped (e.g., V2X-enabled) network device C 1461 (e.g., the object) is located outside the line of sight of the equipped network device B 1411, the equipped network device B 1411 cannot verify (e.g., using its sensors) the indicated location of the equipped (e.g., V2X-enabled) network device C 1461 (e.g., the object) to determine whether the equipped (e.g., V2X-enabled) network device C 1461 (e.g., the object) is present (or not) at the indicated location.

[0132]

[0160] Equipped (e.g., V2X-enabled) network device C 1461 (e.g., an object) is located within line of sight and within sensor field of view 1471a (e.g., line of sight) of equipped (e.g., V2X-enabled) network device A 1441. Equipped network device B 1411 (e.g., a vehicle) can send (transmit) an FDSM request to equipped (e.g., V2X-enabled) network device A 1441 requesting that equipped (e.g., V2X-enabled) network device A 1441 verify the location of equipped (e.g., V2X-enabled) network device C 1461 (e.g., the object). After receiving the FDSM request, equipped (e.g., V2X-enabled) network device A 1441 can use its sensors to verify the location of equipped (e.g., V2X-enabled) network device C 1461 (e.g., the object). Equipped (e.g., V2X-enabled) network device A 1461 may send (transmit) an FDSM response including the verified location to equipped (e.g., V2X-enabled) network device B 1411.

[0133]

[0161] FIG. 14C is a diagram illustrating an example of a system 1402 for a misbehavior detection service for sharing connected sensed objects, in which an equipped (e.g., V2X-enabled) network device A 1442 (e.g., an RSU or drone) located within one range (e.g., range A) visually confirms another equipped network device C 1462 (e.g., an object, RSU, or drone) located within two ranges (e.g., range A and range B). In FIG. 14C, an equipped network device B 1412 (e.g., an RSU) is shown located within one range (e.g., range B). A sensor field of view 1472b of the equipped network device B 1412 (e.g., an RSU) is shown. An equipped (e.g., V2X-enabled) network device A 1442 (e.g., an RSU) is also shown in FIG. 14C. A sensor field of view 1472a of the equipped network device A 1442 is shown.

[0134]

[0162] During operation of the system 1402, the equipped network device B 1412 (e.g., an RSU) may receive a BSM from the equipped (e.g., V2X-enabled) network device C 1462 (e.g., an object) that is located outside the sensor field of view 1472b of the equipped network device B 1412. The BSM may indicate the location of the equipped (e.g., V2X-enabled) network device C 1462 (e.g., the object). Because the equipped (e.g., V2X-enabled) network device C 1462 (e.g., the object) is located outside the sensor field of view 1472b of the equipped network device B 1412, the equipped network device B 1412 cannot verify (e.g., with its sensors) the indicated location of the equipped (e.g., V2X-enabled) network device C 1462 (e.g., the object) to determine whether the equipped (e.g., V2X-enabled) network device C 1462 (e.g., the object) is present (or not) at that location.

[0135]

[0163] Equipped (e.g., V2X-enabled) network device C 1462 (e.g., an object) is located within line of sight and sensor field of view 1472a of equipped (e.g., V2X-enabled) network device A 1442. Equipped network device B 1412 (e.g., an RSU) may send (transmit) an FDSM request to equipped (e.g., V2X-enabled) network device A 1442 requesting the equipped (e.g., V2X-enabled) network device A 1442 to verify the location of equipped (e.g., V2X-enabled) network device C 1462 (e.g., the object). After receiving the FDSM request, equipped (e.g., V2X-enabled) network device A 1442 may use its sensors to verify the location of equipped (e.g., V2X-enabled) network device C 1462 (e.g., the object). Equipped (e.g., V2X-enabled) network device A 1462 may send (transmit) an FDSM response including the verified location to equipped (e.g., V2X-enabled) network device B 1412.

[0136]

[0164] 15A illustrates an example of signaling 1500 for a feedback scheme in an FDSS. During operation of the feedback scheme, an equipped (e.g., V2X-enabled) network device B 1510 (e.g., an ITS-S) may send (transmit) 1515 a vehicle-based message (e.g., a BSM) that may include the location of network device B 1510 to an equipped (e.g., V2X-enabled) network device A 1540 (e.g., an ITS-S). An equipped (e.g., V2X-enabled) object C 1560 (e.g., an object) may send (transmit) 1525 a vehicle-based message (e.g., a BSM) that may include the assumed (or claimed) location of object C 1560 to an equipped (e.g., V2X-enabled) network device A 1540 (e.g., an ITS-S).

[0137]

[0165] After equipped (e.g., V2X-enabled) network device A 1540 (e.g., ITS-S) receives a vehicle-based message (e.g., BSM), equipped (e.g., V2X-enabled) network device A 1540 may determine (detect) 1535 that the vehicle-based message (e.g., BSM) sent from equipped (e.g., V2X-enabled) object C 1560 (e.g., object) is suspicious (e.g., the assumed or claimed location of object C 1560 in the vehicle-based message is suspicious, e.g., because object C 1560 is outside the line of sight of network device B 1510). The equipped (e.g., V2X-enabled) network device A 1540 may then evaluate 1545 whether the FDSS is useful to the equipped (e.g., V2X-enabled) network device B 1510 (e.g., ITS-S), for example, by determining whether the location of object C 1560 may be relevant to the equipped (e.g., V2X-enabled) network device B 1510.

[0138]

[0166] If equipped (e.g., V2X-enabled) network device A 1540 determines that an FDSS is useful, equipped (e.g., V2X-enabled) network device A 1540 may then generate 1555 an FDSM response, which may include information regarding whether equipped (e.g., V2X-enabled) network device A 1540 determined that object C 1560 is present at the expected location. Equipped (e.g., V2X-enabled) network device A 1540 may then send (transmit) 1565 the FDSM response to equipped (e.g., V2X-enabled) network device B 1510.

[0139]

[0167] 15B illustrates an example of signaling 1501 for a request-response technique for FDSS. During operation of the request-response technique, an equipped (e.g., V2X-enabled) network device A 1511 (e.g., an ITS-S) may send (transmit) 1516 a vehicle-based message (e.g., a BSM) to an equipped (e.g., V2X-enabled) network device B 1541 (e.g., an ITS-S), which may include the location and certificate of network device A 1511. After equipped network device B 1541 receives the vehicle-based message from equipped network device A 1511, equipped network device B 1541 may check 1526 the certificate (e.g., in the vehicle-based message from equipped network device A 1511) to determine whether the certificate indicates that equipped network device A 1511 has appropriate authorization (e.g., SSP) for FDSS (e.g., network device A 1511 has authorization to send an FDSM response).

[0140]

[0168] The equipped (e.g., V2X-enabled) object C 1561 (e.g., object) may then send (transmit) 1536 to the equipped (e.g., V2X-enabled) network device B 1541 (e.g., ITS-S) a vehicle-based message (e.g., BSM) that may include the assumed or claimed location of the equipped object C 1561. After the equipped network device B 1541 receives the vehicle-based message from the equipped object C 1561, the equipped network device B 1541 may determine (detect) 1546 that the vehicle-based message (e.g., BSM) sent from the equipped (e.g., V2X-enabled) object C 1561 (e.g., object) is suspicious (e.g., the assumed location of object C 1561 in the vehicle-based message is suspicious because object C 1561 is outside the line of sight of network device B 1541). Equipped (e.g., V2X-enabled) network device B 1541 may then generate 1556 an FDSM request, which may request that equipped network device A 1511 determine whether object C 1561 is present at the expected location. After equipped network device B 1541 generates the FDSM request, equipped network device B 1541 may send 1566 the FDSM request to equipped network device A 1511.

[0141]

[0169] After equipped network device A 1511 receives the FDSM request, equipped network device A 1511 may generate 1576 an FDSM response, which may include information regarding whether equipped (e.g., V2X-enabled) network device A 1541 determined that object C 1561 is present at the expected location. Equipped (e.g., V2X-enabled) network device A 1511 may then send (transmit) 1586 the FDSM response to equipped (e.g., V2X-enabled) network device B 1541.

[0142]

[0170] For communication in the FDSS, a fused data sharing protocol (FDSP) may be adopted. In one or more aspects, when the ITS-S is an RSU, the ITS-S may broadcast the FDSM response so that multiple equipped (e.g., V2X-enabled) network devices (e.g., ITS-Ss and / or vehicles) may receive the FDSM response. Other equipped network devices (e.g., ITS-Ss) may benefit from receiving the FDSM response. For example, all equipped network devices (e.g., vehicles) located behind an equipped network device (e.g., vehicle), such as equipped network device B 1310 in FIG. 13, that are outside the line of sight of the equipped network device (e.g., vehicle) may not be able to determine whether an equipped object, such as equipped object C 1360 in FIG. 13, is suspicious; therefore, these network devices (e.g., vehicles) may need to use the FDSS.

[0143]

[0171] In one or more aspects, the ITS-S can communicate using a groupcast scheme similar to MSCS (e.g., platooning). In some aspects, the ITS-S can communicate using a unicast scheme similar to MSCS (e.g., in a one-to-one situation where there are no vehicles behind the vehicle with the object in line of sight). In one or more aspects, the unicast can be transmitted using a variety of different communication methods, including, but not limited to, DSRC, C-V2X, and / or visible light communication.

[0144]

[0172] In one or more aspects, the protocol for the FDSS can be utilized over an Intelligent Transportation Systems (ITS) stack (e.g., V2V). In some aspects, portions of the protocol (e.g., FDSM interactions) can be achieved through a Transmission Control Protocol / Internet Protocol (TCP / IP) stack (e.g., for communication between RSUs over a network used by a road operator).

[0145]

[0173] Various conditions may be used to trigger an FDSP. In one or more aspects, a suspicious equipped (e.g., V2X-enabled) object is not visible by a sensor of an equipped (e.g., V2X-enabled) network device (e.g., a vehicle) that is located outside the line-of-sight of the equipped object; the suspicious equipped object is located outside the field of view of the equipped network device; the suspicious equipped object is located within the field of view of the equipped network device's sensor but not within the line-of-sight of the equipped network device's sensor; the suspicious equipped object cannot be detected because the equipped network device's sensor is broken or malfunctioning; or the suspicious equipped object cannot be detected because the equipped network device does not have a sensor.

[0146]

[0174] In one or more aspects, the trajectory (e.g., direction of movement) of a suspicious equipped (e.g., V2X-enabled) object may intersect with the trajectory of an equipped (e.g., V2X-enabled) network device (e.g., a vehicle) that is located outside the line of sight of the suspicious equipped object when the direction of travel of the equipped network device intersects with the direction of travel of the suspicious equipped object.

[0147]

[0175] In one or more aspects, a fused data sharing detector (FDSD) may be part of the FDSS. In some aspects, the FDSD may include core data (e.g., generation time and identifier of the equipped network device, such as an ITS-S, that generates the FDSM). The FDSD may also include objects that have been detected by sensors in the equipped network device (e.g., ITS-S) but have not yet sent (transmitted) a vehicle-based message (e.g., BSM). Allowed object types for objects included in the FDSD may be all types of objects defined in vehicle-based message (e.g., BSM and CAM) standards (e.g., vehicles and VRUs). Disallowed object types for objects included in the FDSD may be types of objects not defined in vehicle-based message standards (e.g., trees and road signs).

[0148]

[0176] In some aspects, the FDSD may include an identifier such as a hashed certificate included within a vehicle-based message (e.g., BSM), as well as an identifier of a simulated equipped (e.g., V2X-enabled) object identified by a sensor-V2X detector (e.g., an equipped network device such as an ITS-S).

[0149]

[0177] The FDSD may also include a list of fused objects, which are objects whose location (presence) has been verified and which have transmitted vehicle-based messages (e.g., BSMs). In one or more aspects, objects may be represented in the list by an identifier, such as an identification (ID). In some aspects, objects may be represented in the list by a set of fields, which may include, but are not limited to, ID, location, type, dimensions, and / or kinematic data.

[0150]

[0178] In one or more aspects, if an instrumented object (that transmitted a vehicle-based message) has not been seen by the sensor(s) of the instrumented network device (e.g., ITS-S) and is located outside the field of view of the sensor(s), then the object identifier of that object cannot be inserted into the FDSM. In some aspects, if an instrumented object (that transmitted a vehicle-based message) has not been seen by the sensor(s) of the instrumented network device (e.g., ITS-S) and is located within the field of view of at least one sensor, then the object identifier of that object can be inserted into the FDSM (e.g., as a malicious object).

[0151]

[0179] In one or more aspects, if the equipped object is not sending a vehicle-based message (e.g., a BSM) and the equipped object has a permitted object type, the equipped object can be inserted into the FDSM. In some aspects, if the equipped object is not sending a vehicle-based message (e.g., a BSM) and the equipped object has a permitted object type, the equipped object cannot be inserted into the FDSM.

[0152]

[0180] In some aspects, when an equipped object transmits a vehicle-based message (e.g., a BSM) and is confirmed (e.g., the equipped object's location is verified) by at least one sensor of the equipped network device (e.g., an ITS-S), the object identifier of the equipped object can be inserted into the FDSM (e.g., as a fusion object).

[0153]

[0181] 16, 17, and 18 are flowcharts of fused data sharing detector (FDSD) processes 1600, 1700, and 1800. FIG. 16 is a flowchart illustrating an example of the FDSD process 1600 from the perspective of an initial requester. During process 1600, a requester (e.g., an equipped network device such as an ITS-S) may collect (fuse 1630) all data detected by its sensors 1610. The requester may receive (1620) vehicle-based messages (e.g., BSMs) from equipped (e.g., V2X-enabled) objects (e.g., suspicious objects).

[0154]

[0182] After the requestor has collected all of the sensor data and received vehicle-based messages from the equipped object, the requestor may review the sensor data to check (determine) whether at least one of the sensors detected the equipped object (e.g., the requestor may run a sensor-V2X detector 1640). After the requestor reviews the sensor data, it may collect 1650 the IDs of each suspect equipped object over a given time window of detection. In one or more examples, the collected IDs may be the IDs of the suspect equipped objects that were included in the vehicle-based messages (e.g., BSMs) sent by the suspect equipped objects. In some examples, the duration of the time window may be a static value. In some examples, the duration of the time window may be based on the time remaining before making a decision (e.g., a driving decision such as braking).

[0155]

[0183] After the requester gathers the identities of the suspicious equipped objects and determines that it cannot verify the location of at least one suspicious object, the requester may check (verify) whether it can send (send) a request to the FDSS (1660). In one or more examples, the determination of whether the requester can send a request may depend on the availability of a surrounding equipped network device (e.g., ITS-S) that can provide this service. In some examples, the equipped network device (e.g., ITS-S) may advertise this service in its certificate (which may be included in a vehicle-based message such as a BSM). The certificate may include a set of permissions, such as service-specific permissions (SSPs), that may define the actions that the certificate holder is authorized to perform within the FDSS. If available, the requester may use sensor information included in the vehicle-based message (e.g., CPM) to check whether the equipped object is located within the field of view of the equipped network device (e.g., ITS-S).

[0156]

[0184] If the requester determines that the requester can send a request for an FDSS, the requester may create an FDSM (1670). In one or more examples, the FDSM may request the requester to use an FDSS from a neighboring infrastructure. However, if the requester determines that the requester cannot send a request for an FDSS, the requester may remain idle (1680).

[0157]

[0185] 17 is a flowchart illustrating an example of a process 1700 for FDSD from the responder's perspective. During process 1700, for each vehicle-based message (e.g., BSM) 1710 received from an equipped (e.g., V2X-enabled) object, the responder (e.g., an equipped network device such as an ITS-S) can run a sensor-V2X detector 1730 (e.g., using its sensors 1705 and fusion 1720) to collect a list of fused objects (1735), a list of simulated (fake) equipped (e.g., V2X-enabled) objects (1740), and a list of sensor objects (175).

[0158]

[0186] In one or more examples, the fusion object may be an instrumented (e.g., V2X) object that is perceived (detected) by a responder's sensors and transmits a vehicle-based message (e.g., BSM) that is received by the responder. In some examples, the fusion object may be represented by an object ID. In some examples, the fusion object may be represented by a set of fields, including, but not limited to, the instrumented object's object ID, location, type, dimensions, and kinematic data.

[0159]

[0187] In one or more examples, a simulated (fake) equipped object may be an equipped object that sent a vehicle-based message but cannot be detected by the responder's sensors. The list of simulated (fake) equipped objects may include a hashed certificate included in the vehicle-based message (e.g., BSM) for each simulated (fake) equipped object. Identifiers of the simulated (fake) equipped objects may be reported to the sensor-V2X detector.

[0160]

[0188] In some examples, sensor objects may be equipped objects that have been detected by the responder's sensors but have not yet sent a vehicle-based message. The process filter 1750 may filter these simulated (fake) objects based on ITS-S type (e.g., filter V2X objects 1750). Allowed object types may be all types of objects (e.g., vehicles and VRUs) defined in vehicle-based message (e.g., BSM and CAM) standards. Disallowed object types may be types of objects (e.g., trees and road signs) that are not defined in vehicle-based message standards.

[0161]

[0189] After the responder creates the list, the responder can determine whether to send an FDSM response. If the responder receives a request for an FDSS (e.g., from an equipped network device) or if the responder detects an equipped network device (e.g., a vehicle) that may require an FDSS, the responder may send an FDSM response. For example, an equipped network device (e.g., a vehicle) may require an FDSS if the equipped network device (e.g., a vehicle) is in proximity to a simulated (fake) equipped object and the distance between the equipped network device (e.g., a vehicle) and the simulated (fake) equipped object is less than a distance threshold. In one or more examples, an RSU may send an FDSM to another RSU to confirm the existence of the equipped object.

[0162]

[0190] Thus, the responder may determine whether the responder received a request for an FDSS (1755). If the responder determines that the responder received a request for an FDSS, the responder may generate an FDSM response (1765). However, if the responder determines that the responder received a request for an FDSS, the responder may determine whether the equipped network device (e.g., vehicle) may require an FDSS (1760). If the responder determines that the equipped network device (e.g., vehicle) may require an FDSS, the responder may generate an FDSM response (1765). However, if the responder determines that the equipped network device (e.g., vehicle) does not require an FDSS, the responder may remain idle (1770).

[0163]

[0191] 18 is a flowchart illustrating an example of a process 1800 for FDSD from the perspective of a final responder. During process 1800, upon receiving 1820 an FDSM, a requester (e.g., an equipped network device) may check 1830 whether the equipped object is simulated (fake). In one or more examples, the requester may check 1830 whether the suspect equipped object (in the list of suspect equipped objects 1810) has its ID among the fused or simulated (fake) objects. Because the sensor object does not have a vehicle-based message and therefore does not have a certificate or object ID, the sensor object cannot be used in this process 1800.

[0164]

[0192] In some examples, the requester can check (verify) a match between the features of the vehicle-based message (e.g., BSM) and the features of the fused sensor object. The vehicle-based message (e.g., BSM) of the actual instrumented object matches the contents (e.g., position, speed, heading, and / or dimensions) of the object included in the FDSM. The vehicle-based message (e.g., BSM) of the simulated (fake) object may lead to a mismatch with one of the objects included in the FDSM.

[0165]

[0193] The requester can update the collaborative cognition database (1840) after checking (determining) whether the instrumented object is simulated (fake). If there is a malicious instrumented object reported in the FDSM response, the requester can update the collaborative cognition database to remove the malicious track. The requester can update the collaborative cognition database to update the correct track if the fused object may contain more accurate data (e.g., because the responder may have better sensors).

[0166]

[0194] After the requester updates the collaborative perception database, the requester can generate 1850 a misbehavior report (MBR) for each suspected equipped object (which may be, for example, a vehicle). In one or more examples, the suspected equipped object may be represented as an identifier (e.g., ID) in the MBR. In some examples, the suspected equipped object may be represented as a set of fields (e.g., ID, location, type, dimensions, and kinematic data) in the MBR.

[0167]

[0195] In one or more aspects, the FDSS may be advertised. Before sending a request for the FDSS, the requester needs to know which equipped network devices can provide the FDSS, so the FDSS may need to be advertised. Therefore, a solution is presented on how to inform a requester which nearby equipped network devices (e.g., ITS-S) can provide the FDSS.

[0168]

[0196] In one or more aspects, to advertise an FDSS, an additional permission bit (e.g., for advertising an FDSS) may be added to a digital certificate to indicate whether a network device can provide an FDSS. The permission bit may be a single bit that describes the availability of the FDSS to an equipped network device (e.g., an ITS-S). For example, if the permission bit is set equal to zero (0), the FDSS is available to the equipped network device (e.g., an ITS-S). If the permission bit is set equal to one, the FDSS is not available to the equipped network device (e.g., an ITS-S).

[0169]

[0197] The digital certificate may be included in a vehicle-based message (e.g., a BSM) received by an FDSS participant prior to the FDSM. In one or more examples, the originator of an FDSM (e.g., sending equipped network device) may need to know whether neighboring equipped network devices (e.g., ITS-S) support FDSS and therefore can process the FDSM being sent. In one or more examples, the responder may need the receiver's digital certificate for this response. In some examples, the requester may need the responder's digital certificate before sending a request.

[0170]

[0198] In some aspects, to advertise the FDSS, an additional service (e.g., to advertise the FDSS) may be added to a Wave Service Advertisement (WSA). The WSA approach may be used for an RSU. In one or more examples, the equipped network entity (e.g., ITS-S) that responds to the request for the FDSS should be the RSU. In some examples, the RSU may broadcast a WSA every second. The WSA may include "FDSS" among all services advertised by the RSU.

[0171]

[0199] In one or more aspects, two message types may be employed for the FDSS, including a first message type that is an FDSM used to request an FDSS (e.g., Fusion Data Share Message Request 1910 of FIG. 19 ) and a second message type that is an FDSM used to respond to a request for an FDSS (e.g., Fusion Data Share Message Response 2005 of FIG. 20 ).

[0172]

[0200] FIG. 19 illustrates an example 1900 of a fused data sharing message (FDSM) request 1910. In one or more aspects, the FDSM request 1910 of FIG. 19 can be employed for the request-response approach shown in FIG. 15B. In FIG. 19, the FDSM request 1910 is shown to include multiple fields, which may include a message (msg) timestamp field 1920 (e.g., containing the time of creation of the FDSM), a source container field 1930 (e.g., containing information related to the source), and a malicious object field 1940. The source container field 1930 may include a source identification (ID) field 1950, a three-dimensional (3D) position field 1960, and a position accuracy field 1970. The malicious object field 1940 may include multiple object ID fields 1980a, 1980b (e.g., containing a set of vehicle-based messages such as a BSM, ID, etc.). The FDSM request 1910 can be a V2X message. Fields 1920, 1930, 1940, 1950, 1960, 1970, 1980a, 1980b of the FDSM request 1910 may all be required fields.

[0173]

[0201] In one or more aspects, during operation, a sending equipped (e.g., V2X-enabled) network device may send (transmit) an FDSM request (e.g., FDSM request 1910) to a receiving equipped (e.g., V2X-enabled) network device to inform the receiving equipped (e.g., V2X-enabled) network device of the assumed or claimed location of an object (e.g., a ghost object) that sent a vehicle-based message (e.g., BSM) to the sending equipped (e.g., V2X-enabled) network device. After the receiving equipped (e.g., V2X-enabled) network device receives the FDSM request, the receiving equipped (e.g., V2X-enabled) network device knows the hypothesized location of the object (e.g., from information included in the FDSM request), and can direct its sensor antenna beam(s) toward the object's assumed location to verify whether the object is present (or not) at that location.

[0174]

[0202] FIG. 20 illustrates an example 2000 of an FDSM response 2005. In one or more aspects, the FDSM request 2005 of FIG. 20 can be employed for the feedback and request-response approaches shown in FIGS. 15A and 15B, respectively. In FIG. 20, the FDSM request 2005 is shown to include multiple fields, which may include a message timestamp field 2010 (e.g., containing the time of generation of the FDSM), a source ID field 2015 (e.g., containing the ID of the sending device), and an object container field 2020. The object container field 2020 can include a fused object field 2025 (e.g., containing a set of vehicle-based messages, such as a BSM, and identifiers of objects detected by a sensor that sent the vehicle-based messages), a malicious object field 2030 (e.g., containing a set of vehicle-based messages, such as a BSM, and identifiers of verified ghost objects), and a sensor object field 2035 (e.g., containing a set of vehicle-based messages, such as a BSM, and identifiers of objects detected by a sensor that have not yet sent a vehicle-based message).

[0175]

[0203] The fusion object field 2025 can include multiple BSM object fields 2040a, 2040b. Each BSM object field 2040a, 2040b can include an object ID field 2070, a kinematic data field 2080, and a dimensional data field 2090. The malicious object field 2030 can include multiple object ID fields 2050a, 2050b. The sensor object field 2035 can include multiple CPM object fields 2060a, 2060b.

[0176]

[0204] The FDSM response 2005 may be a V2X message. All of the fields may be mandatory fields except for the kinematic data field 2080 and the dimensional data field 2090, which are both optional fields.

[0177]

[0205] In one or more aspects, the logic for inserting an object into the FDSM is as follows: For a BSM object that has not been seen by the sensors of the ITS-S, if the object is located outside the field of view of all sensors, the object identifier of the object may not be inserted into the FDSM; if the object is within at least one sensor field of view, the object identifier of the object may be inserted into the FDSM (e.g., a ghost object).

[0178]

[0206] For sensor objects that have not sent a BSM, if the object has an allowed object type, the object's object identifier may be inserted into the FDSM. If the object has a disallowed object type, the object's object identifier may not be inserted into the FDSM.

[0179]

[0207] For BSM objects that are confirmed by at least one sensor, the object identifier of the object may be inserted into the FDSM (e.g., a fusion object).

[0180]

[0208] FIG. 21 is a flowchart illustrating an example of a process 2100 for wireless communication. Process 2100 may be performed by a network device such as a vehicle, a roadside unit (RSU), an intelligent transportation system-station (ITS-S), a UE (e.g., a mobile device such as a mobile phone, a drone or unmanned aerial vehicle (UAV), a wearable device such as a network-connected watch, an augmented reality (XR) device such as a virtual reality (VR) or augmented reality (AR) headset or glasses, or another type of UE), or other type of network device, or a component, system, or apparatus (e.g., a chipset) thereof. Operations of process 2100 may be implemented as software components executing and operating on one or more processors of the vehicle (e.g., processor 2210 of FIG. 22 or other processor(s)). Additionally, transmission and reception of signals by the wireless communication device in process 2100 may be enabled, for example, by one or more antennas and / or one or more transceivers (e.g., wireless transceiver(s)) of the vehicle.

[0181]

[0209] At block 2110, the network device (or a component, system, or apparatus thereof) may determine an estimated location of the second network device. In some cases, the first network device and the second network device are capable of vehicle-to-everything (V2X) communication (e.g., transmitting, receiving, and / or processing V2X messages). In some examples, the second network device is a vehicle, an ITS-S, an RSU, a UE, a drone, or a UAE, or another type of network device.

[0182]

[0210] At block 2120, the network device (or a component, system, or apparatus thereof) may compare the estimated location with the assumed location of the second network device. In some aspects, the network device (or a component, system, or apparatus thereof) may receive a vehicle-based message from the second network device. In some cases, the vehicle-based message includes the assumed location of the second network device. In some examples, the vehicle-based message is a Basic Safety Message (BSM), a Cooperative Awareness Message (CAM), a Collective Awareness Message (CPM), a Sensor Data Sharing Message (SDSM), a Distributed Environmental Message (DENM), or other type of vehicle-based message.

[0183]

[0211] At block 2130, the network device (or a component, system, or apparatus thereof) may determine whether the second network device is a misbehaving device based on the comparison.

[0184]

[0212] At block 2140, the network device (or a component, system, or apparatus thereof) may generate a report based on a determination of whether the second device is a misbehaving device. In some aspects, the network device (or a component, system, or apparatus thereof) may output a response including the report for transmission to the third network device. In some cases, the second network device is not located within a field of view (FoV) of a sensor of the third network device and / or is not located within line of sight (LoS) of the third network device. In some examples, the response includes at least one of a message timestamp field, a source identification (ID) field, an object container field, a fused object field, a malicious object field, or a sensor object field.

[0185]

[0213] In some aspects, a network device (or a component, system, or apparatus thereof) may receive a request to share data from a third network device (or other network device). For example, the request to share data may include a message timestamp field, a source field, a malicious object field, or any combination thereof.

[0186]

[0214] In some aspects, a network device (or a component, system, or apparatus thereof) may generate a fused object list, a sensor object list, and a simulated object list. The fused object list, the sensor object list, or the simulated object list may include a second network device (e.g., an identifier or other information associated with the second network device). The fused object list may include a network device that transmits a vehicle-based message and is located within the field of view and / or line of sight of a third network device (or other network device). The sensor object list may include a network device that has not yet transmitted a vehicle-based message and is located within the field of view and / or line of sight of a third network device (or other network device). The simulated object list may include a network device that is a ghost object.

[0187]

[0215] 22 is a block diagram illustrating an example of a computing system 2200 that may be employed by the disclosed system for a fraudulent behavior detection service for sharing connected and sensed objects, according to some aspects of the present disclosure. In particular, FIG. 22 illustrates an example of a computing system 2200, which may be any computing device comprising, for example, an internal computing system, a remote computing system, a camera, or any component thereof, the components of the system communicating with each other using a connection 2205. The connection 2205 may be a physical connection using a bus or a direct connection to a processor 2210, such as in a chipset architecture. The connection 2205 may also be a virtual connection, a network connection, or a logical connection.

[0188]

[0216] In some aspects, computing system 2200 is a distributed system in which the functionality described in this disclosure may be distributed across a data center, multiple data centers, a peer network, etc. In some aspects, one or more of the system components described represent many such components, each performing some or all of the functionality being described. In some aspects, these components may be physical or virtual devices.

[0189]

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

[0190]

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

[0191]

[0219] To enable user interaction, computing system 2200 includes input devices 2245, which may represent any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, a keyboard, a mouse, motion input, speech, etc. Computing system 2200 may also include output devices 2235, which may be one or more of a number of output mechanisms. In some instances, a multimodal system may enable a user to provide multiple types of input / output to communicate with computing system 2200.

[0192]

[0220] The computing system 2200 may include a communications interface 2240 that may generally manage and manage user input and system output.The communication interface may implement or facilitate the receipt and / or transmission of wired or wireless communications using a wired transceiver and / or a wireless transceiver, including audio jacks / plugs, microphone jacks / plugs, universal serial bus (USB) ports / plugs, Apple™ Lightning™ ports / plugs, Ethernet ports / plugs, fiber optic ports / plugs, proprietary wired ports / plugs, 3G, 4G, 5G, and / or other cellular data network wireless signal transmissions, Bluetooth™ wireless signal transmissions, Bluetooth™ low energy (BLE) wireless signal transmissions, IBEACON™ wireless signal transmissions, radio-frequency identification (RFID) wireless signal transmissions, near-field communications (NFC) wireless signal transmissions, dedicated short range communications, and the like. communication (DSRC) wireless signaling, 802.11 Wi-Fi wireless signaling, Wireless Local Area Network (WLAN) signaling, Visible Light Communication (VLC), Worldwide Interoperability for Microwave Access (WiMAX), Infrared (IR) wireless signaling, Public Switched Telephone Network (PSTN) signaling, Integrated Services Digital Network (ISDN) signaling, ad hoc network signaling, radio wave signaling, microwave signaling, infrared signaling, visible light signaling, ultraviolet light signaling, wireless signaling along the electromagnetic spectrum, or any combination thereof.

[0193]

[0221] Communications interface 2240 may also include one or more range sensors (e.g., LIDAR sensors, laser range finders, RF radar, ultrasonic sensors, infrared (IR) sensors) configured to collect data and provide measurements to processor 2210, which may be configured to perform the determinations and calculations necessary to obtain various measurements of the one or more range sensors. In some examples, the measurements may include time of flight, wavelength, azimuth angle, elevation angle, distance, linear velocity, and / or angular velocity, or any combination thereof. Communications interface 2240 may also include one or more Global Navigation Satellite System (GNSS) receivers or transceivers used to determine the location of computing system 2200 based on reception of one or more signals from one or more satellites associated with one or more GNSS systems. GNSS systems include, but are not limited to, the US-based GPS, the Russia-based Global Navigation Satellite System (GLONASS), the China-based BeiDou Navigation Satellite System (BDS), and the Europe-based Galileo GNSS. There is no restriction to operating on any particular hardware configuration, and therefore the basic features herein can be easily substituted for improved hardware or firmware configurations as they are developed.

[0194]

[0222] The storage device 2230 may be a non-volatile and / or non-transitory and / or computer-readable memory device, and may also be a hard disk or other type of computer-readable medium capable of storing data accessible by a computer, such as a magnetic cassette, a flash memory card, a solid-state memory device, a digital versatile disk, a cartridge, a floppy disk, a flexible disk, a hard disk, a magnetic tape, a magnetic strip / stripe, any other magnetic storage medium, a flash memory, a memristor memory, any other solid-state memory, a compact disc read only memory (CD-ROM) optical disk, a rewritable compact disc (CD) optical disk, a digital video disk (DVD) optical disk, a blu-ray disc (BDD) optical disk, a holographic optical disk, other optical media, a secure digital (SD) card, a micro secure digital (microSD) card, a Memory Stick® card, smart card chip, EMV chip, Subscriber Identity Module (SIM) card, Mini / Micro / Nano / Pico SIM card, other Integrated Circuit (IC) chip / card, Random Access Memory (RAM), Static RAM (SRAM), Dynamic RAM (DRAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM),The memory may be an EEPROM, an electrically erasable programmable read-only memory (EEPROM), a flash EPROM (FLASHEPROM), a cache memory (e.g., a level 1 (L1) cache, a level 2 (L2) cache, a level 3 (L3) cache, a level 4 (L4) cache, a level 5 (L5) cache, or other (L#) cache), a resistive random-access memory (RRAM / ReRAM), a phase change memory (PCM), a spin transfer torque RAM (STT-RAM), other memory chips or cartridges, and / or any combination thereof.

[0195]

[0223] The storage devices 2230 may include software services, servers, services, etc., where code defining such software, when executed by the processor 2210, causes the processor to perform functions in the system. In some aspects, hardware services that perform a particular function may include software components stored on computer-readable media in association with hardware components, such as the processor 2210, connections 2205, output devices 2235, etc., necessary to perform the function. The term "computer-readable medium" includes, but is not limited to, portable or non-portable storage devices, optical storage devices, and various other media capable of storing, storing, or conveying instruction(s) and / or data. Computer-readable media may also include non-transitory media that can store data and do not include carrier waves and / or transitory electronic signals propagating wirelessly or over wired connections. 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. Code and / or machine-executable instructions can be stored on a computer-readable medium, which can 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 can 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. can be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.

[0196]

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

[0197]

[0225] For clarity of explanation, in some cases, the technology may be presented as including individual functional blocks, including 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 also 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 aspects 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 aspects.

[0198]

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

[0199]

[0227] Individual aspects 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. While a flowchart may describe operations as a sequential process, many of the operations may be performed in parallel or simultaneously. Moreover, the order of operations may be rearranged. A process terminates when its operations are completed, but may have additional steps not included in the diagram. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination may correspond to a return of the function to the calling function or the main function.

[0200]

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

[0201]

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

[0202]

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

[0203]

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

[0204]

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

[0205]

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

[0206]

[0234] The program code may be executed by a processor, which may include one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Such a processor may be configured to perform any of the techniques described in this disclosure. A general-purpose processor may be a microprocessor, but alternatively, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., 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. Accordingly, 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.

[0207]

[0235] Those skilled in the art will understand that the less than ("<") and greater than (">") symbols or terms used herein can 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.

[0208]

[0236] Where 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 circuit (e.g., a microprocessor or other suitable electronic circuitry) to perform the operation, or any combination thereof.

[0209]

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

[0210]

[0238] Claim language or other language referring to "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) satisfies 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, B, and C. The language of "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 additionally include items not recited within the set of A and B.

[0211]

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

[0212]

[0240] Aspect 1. A method of wireless communications performed at a first network device, the method including: determining, at the first network device, an estimated location of a second network device; comparing, at the first network device, the estimated location with an expected location of the second network device; determining, at the first network device, whether the second network device is a misbehaving device based on the comparing; and generating, at the first network device, a report based on a determination of whether the second device is a misbehaving device.

[0213]

[0241] Aspect 2. The method of aspect 1, further comprising receiving, at the first network device, a vehicle-based message from a second network device.

[0214]

[0242] Aspect 3. The method of aspect 2, wherein the vehicle-based message includes an assumed location of the second network device.

[0215]

[0243] Aspect 4. The method of any of aspects 2 or 3, wherein the vehicle-based message is one of a Basic Safety Message (BSM), a Cooperative Awareness Message (CAM), a Collective Awareness Message (CPM), a Sensor Data Sharing Message (SDSM), or a Distributed Environmental Message (DENM).

[0216]

[0244] Embodiment 5. The method of any of embodiments 1 to 4, further comprising sending, from the first network device, a response to the third network device that includes the report.

[0217]

[0245] Aspect 6. The method of aspect 5, wherein the response includes at least one of a message timestamp field, a source identification (ID) field, an object container field, a fused object field, a malicious object field, or a sensor object field.

[0218]

[0246] Aspect 7. The method of any of aspects 5 or 6, wherein the second network device is at least one of not located within a field of view (FoV) of a sensor of the third network device or not located within line of sight (LoS) of the third network device.

[0219]

[0247] Aspect 8. The method of any of aspects 1 to 7, wherein the first network device and the second network device are capable of vehicle-to-everything (V2X) communication.

[0220]

[0248] Aspect 9. The method of any one of aspects 1 to 8, wherein the first network device and the second network device are each one of an Intelligent Transportation System-Station (ITS-S), a vehicle, a Roadside Unit (RSU), a User Equipment (UE), or a drone.

[0221]

[0249] Embodiment 10. The method of any of embodiments 1 to 9, further comprising, at the first network device, receiving a request for data sharing from a third network device.

[0222]

[0250] Aspect 11. The method of aspect 10, wherein the request to share data includes at least one of a message timestamp field, a source field, or a malicious object field.

[0223]

[0251] Aspect 12. The method of any of aspects 1 to 11, further comprising generating, at the first network device, a fused object list, a sensor object list, and a simulated object list, wherein one of the fused object list, the sensor object list, or the simulated object list includes the second network device.

[0224]

[0252] Aspect 13. The method of aspect 12, wherein the fused object list includes a network device that transmitted a vehicle-based message and is located within at least one of a field of view (FoV) or line of sight (LoS) of a third network device.

[0225]

[0253] Aspect 14. The method of any of aspects 12 or 13, wherein the sensor object list includes a network device that has not yet transmitted a vehicle-based message and that is located within at least one of a field of view (FoV) or line of sight (LoS) of a third network device.

[0226]

[0254] Aspect 15. The method of any of aspects 12 to 14, wherein the simulated object list includes a network device that is a ghost object.

[0227]

[0255] Aspect 16. A first network device for wireless communication, comprising: at least one memory; and at least one processor coupled to the at least one memory, wherein the at least one processor is configured to: determine an estimated location of a second network device; compare the estimated location to an expected location of the second network device; determine whether the second network device is a misbehaving device based on the comparing; and generate a report based on a determination of whether the second device is a misbehaving device.

[0228]

[0256] Aspect 17. The first network device of aspect 16, wherein the at least one processor is configured to receive a vehicle-based message from the second network device.

[0229]

[0257] Aspect 18. The first network device of aspect 17, wherein the vehicle-based message includes an assumed location of the second network device.

[0230]

[0258] Aspect 19. The first network device of any of aspects 16 or 18, wherein the vehicle-based message is one of a Basic Safety Message (BSM), a Cooperative Awareness Message (CAM), a Collective Awareness Message (CPM), a Sensor Data Sharing Message (SDSM), or a Distributed Environmental Message (DENM).

[0231]

[0259] Aspect 20. The first network device of any of aspects 16 to 19, wherein the at least one processor is configured to output a response including the report for transmission to the third network device.

[0232]

[0260] Aspect 21. The first network device of aspect 20, wherein the response includes at least one of a message timestamp field, a source identification (ID) field, an object container field, a fused object field, a malicious object field, or a sensor object field.

[0233]

[0261] Aspect 22. The first network device of aspect 20 or 21, wherein the second network device is at least one of not located within a field of view (FoV) of a sensor of the third network device or not located within a line of sight (LoS) of the third network device.

[0234]

[0262] Aspect 23. The first network device of any of aspects 16 to 22, wherein the first network device and the second network device are capable of vehicle-to-everything (V2X) communication.

[0235]

[0263] Aspect 24. The first network device of any of Aspects 16 to 23, wherein the first network device and the second network device are each one of an Intelligent Transportation System-Station (ITS-S), a vehicle, a Roadside Unit (RSU), a User Equipment (UE), or a drone.

[0236]

[0264] Aspect 25. The first network device of any of Aspects 16 to 24, wherein the at least one processor is configured to receive a request for data sharing from a third network device.

[0237]

[0265] Aspect 26. The first network device of Aspect 25, wherein the request to share data includes at least one of a message timestamp field, a source field, or a malicious object field.

[0238]

[0266] Aspect 27. The first network device of any of Aspects 16 to 26, wherein at least one processor is configured to generate a fused object list, a sensor object list, and a simulated object list, and one of the fused object list, the sensor object list, or the simulated object list includes the second network device.

[0239]

[0267] Aspect 28. The first network device of aspect 27, wherein the fused object list includes a network device that transmitted a vehicle-based message and is located within at least one of a field of view (FoV) or line of sight (LoS) of the third network device.

[0240]

[0268] Aspect 29. A first network device described in either aspect 27 or 28, wherein the sensor object list includes a network device that has not yet transmitted a vehicle-based message and is located within at least one of a field of view (FoV) or line of sight (LoS) of the third network device.

[0241]

[0269] Aspect 30. The first network device of any of aspects 27 to 29, wherein the simulated object list includes a network device that is a ghost object.

[0242]

[0270] Aspect 31. A non-transitory computer-readable medium storing instructions that, when executed by one or more processors, cause the one or more processors to perform operations according to any of Aspects 1-15.

[0243]

[0271] Embodiment 32. An apparatus for wireless communication, comprising means for performing the operations recited in any of embodiments 1 to 15.

[0244]

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

Claims

1. A method of wireless communication performed on a first network device, In the first network device, the estimated location of the second network device is determined, In the first network device, the estimated location is compared with the assumed location of the second network device, In the first network device, based on the comparison, it is determined whether the second network device is a malfunctioning device. In the first network device, a report is generated based on the determination of whether the second device is a malfunctioning device. The first network device transmits the report to the third network device, wherein the second network device is not located within the field of view (FoV) of the sensor of the third network device, or is not located within the line of sight (LoS) of the third network device, Methods that include...

2. The method according to claim 1, further comprising the first network device receiving a vehicle-based message from the second network device.

3. The method according to claim 2, wherein the vehicle-based message includes the assumed location of the second network device.

4. The method according to claim 2, wherein the vehicle-based message is one of the following: Basic Safety Message (BSM), Cooperative Recognition Message (CAM), Collective Recognition Message (CPM), Sensor Data Sharing Message (SDSM), or Distributed Environment Message (DENM).

5. The method according to claim 1, wherein transmitting the report to a third network device includes transmitting at least one of a message timestamp field, a source identification (ID) field, an object container field, a fused object field, a malicious object field, or a sensor object field.

6. The method according to claim 1, wherein the first network device and the second network device are capable of performing vehicle-to-everything (V2X) communication.

7. The method according to claim 1, wherein the first network device and the second network device are each one of an intelligent transport system station (ITS-S), a vehicle, a roadside unit (RSU), a user equipment (UE), or a drone.

8. The method according to claim 1, further comprising the first network device receiving a data sharing request from a third network device.

9. The method according to claim 8, wherein the data sharing request includes at least one of a message timestamp field, a source field, or a malicious object field.

10. The method according to claim 1, further comprising generating a fusion object list, a sensor object list, and a simulated object list in the first network device, wherein one of the fusion object list, the sensor object list, or the simulated object list includes the second network device.

11. The method according to claim 10, wherein the fused object list includes a network device that transmitted a vehicle-based message and is located within at least one of the field of view (FoV) or line of sight (LoS) of a third network device.

12. The method according to claim 10, wherein the sensor object list includes network devices that have not yet transmitted a vehicle-based message and are located within at least one of the field of view (FoV) or line of sight (LoS) of a third network device.

13. The method according to claim 10, wherein the simulated object list includes a network device which is a ghost object.

14. A first network device for wireless communication, At least one memory, The system comprises at least one processor coupled to at least one memory, and the at least one processor is To determine the estimated location of the second network device, The estimated location is compared with the assumed location of the second network device, Based on the above comparison, it is determined whether the second network device is a malfunctioning device, To generate a report based on the determination of whether the second device is a malfunctioning device, Outputting the report for transmission to a third network device, wherein the second network device is not located within the field of view (FoV) of the sensor of the third network device, or not within the line of sight (LoS) of the third network device, It is configured to do, The first network device.

15. The first network device according to claim 14, wherein the at least one processor is further configured to perform the method according to any one of claims 2 to 13.

Images