Misbehavior detection service for sharing connected and sensed objects

Abstract

Systems, apparatus, processes, and computer-readable media for wireless communication are disclosed. For example, an example of a process includes determining, at a first network device, an estimated location of a second network device. The process may also include comparing, at the first network device, the estimated location to an expected location of the second network device. The process may include determining, at the first network device, whether the second network device is a malfunctioning device based on the comparison. The process may also include generating, at the first network device, a report based on determining whether the second device is a misbehavioral device.

Description

Technical Field

[0001] The present disclosure relates generally to vehicle communications. For example, aspects of the present disclosure relate to misbehavior detection services for sharing connected and sensed objects using vehicle-to-everything (V2X) communications. Background Art

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

[0003] These multiple access technologies have been adopted in various telecommunication standards to provide a public protocol that enables different wireless devices to communicate in municipal, national, regional and even global ranges. An example telecommunication standard is 5G New Radio (NR). 5G NR is a part of the continuous mobile broadband evolution promulgated by the Third Generation Partnership Project (3GPP) to meet new requirements associated with latency, reliability, security, scalability (e.g., through the Internet of Things (IoT)) and other requirements. 5G NR includes services associated with enhanced mobile broadband (eMBB), massive machine type communication (mMTC) and ultra-reliable low latency communication (URLLC). Some aspects of 5G NR may be based on the 4G Long Term Evolution (LTE) standard. Various aspects of wireless communication may include direct communication between devices, such as in V2X, vehicle-to-vehicle (V2V) and / or device-to-device (D2D) communication. V2X, V2V and / or D2D technologies need further improvement. These improvements may also be applicable to other multiple access technologies and telecommunication standards using these technologies. Summary of the invention

[0004] The following presents a simplified summary of the invention related to one or more aspects disclosed herein. Therefore, the following summary of the invention should not be considered as an extensive review related to all expected aspects, nor should the following summary of the invention be considered to identify key or important elements related to all expected aspects or to delineate the scope associated with any particular aspect. Therefore, the following summary of the invention has the following sole purpose: to present certain concepts related to one or more aspects related to the mechanisms disclosed herein in a simplified form to precede the detailed description presented below.

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

[0006] In another example, an apparatus for execution at a first network device is provided, the apparatus comprising at least one memory and at least one processor coupled to the at least one memory. The at least one processor is configured to: determine an estimated location of a second network device; compare the estimated location with 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 determining whether the second device is a misbehaving device.

[0007] In another example, a non-transitory computer-readable medium having instructions stored thereon is provided that, when executed by one or more processors, causes 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 for performing at a first network device is provided. The apparatus includes: means for determining an estimated location of a second network device; means for comparing the estimated location with an expected location of the second network device; means for determining whether the second network device is a misbehaving device based on the comparison; and means for generating a report based on determining whether the second device is a misbehaving device.

[0009] In some aspects, the network device or apparatus described herein is, includes, or is part of a vehicle (e.g., a car, truck, etc., or a component or system of a car, truck, etc.), a mobile device (e.g., a mobile phone or so-called "smart phone" or other mobile device), a wearable device, an extended reality device (e.g., a virtual reality (VR) device, an augmented reality (AR) device, or a mixed reality (MR) device), a personal computer, a laptop computer, a server computer, a robotic device, or other device. In some aspects, the apparatus includes a radio detection and ranging (radar) 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 light-based (e.g., optical frequency) signals. In some aspects, the apparatus includes one or more cameras for capturing one or more images. In some aspects, the apparatus also includes a display for displaying one or more images, notifications, and / or other displayable data. In some aspects, the apparatus may include one or more sensors that can be used to determine the location of the apparatus, the state of the apparatus (e.g., temperature, humidity level, and / or other state), and / or for other purposes.

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

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

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

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

[0014] Figure 2 is a diagram illustrating an example of a decomposed base station architecture that may be employed by the disclosed system for sharing connected and sensed object misbehavior detection services according to some aspects of the present disclosure.

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

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

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

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

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

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

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

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

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

[0024] Fig. 12A is a diagram illustrating an example of a ground truth view from a receiver perspective in accordance with some aspects of the present disclosure.

[0025] Fig. 12B is a diagram illustrating an example of a basic safety message (BSM) view from a receiver's perspective, according to some aspects of the present disclosure.

[0026] Fig. 12C is a diagram illustrating an example of a collective perception message (CPM) view from a receiver perspective, according to some aspects of the present disclosure.

[0027] Fig.12D is a diagram illustrating an example of a fused object view from a receiver perspective, according to some aspects of the present disclosure.

[0028] Fig.13is a diagram illustrating an example of a system for sharing a connected and sensed object misbehavior detection service in accordance with some aspects of the present disclosure, wherein an equipped (e.g., V2X-capable) network device with multiple sensors provides visual confirmation of another equipped network device.

[0029] Fig.14A is a diagram illustrating an example of a system for sharing connected and sensed object misbehavior detection services in accordance with some aspects of the present disclosure, wherein a platoon leader provides visual confirmation of equipped (e.g., V2X-capable) network devices.

[0030] Fig. 14B is a diagram illustrating an example of a system for sharing a connected and sensed object misbehavior detection service in accordance with some aspects of the present disclosure, wherein an equipped (e.g., V2X-capable) network device with a single sensor provides visual confirmation to another equipped network device (e.g., a vehicle).

[0031] Fig. 14C is a diagram illustrating an example of a system for sharing a connected and sensed object misbehavior detection service in accordance with some aspects of the present disclosure, wherein an equipped (e.g., V2X-capable) network device (e.g., RSU) located within one range provides visual confirmation of another equipped network device (e.g., RSU) located within two ranges.

[0032] Fig.15A is a diagram illustrating an example of signaling for a feedback method according to some aspects of the present disclosure.

[0033] Fig. 15B is a diagram illustrating an example of signaling for a request-response approach according to some aspects of the present disclosure.

[0034] Fig.16 is a flow chart illustrating an example of a process for a fused data sharing detector (FDSD) from the perspective of an initial requester side according to some aspects of the present disclosure.

[0035] Fig.17 is a flow chart illustrating an example of a process for FDSD from a responder side perspective according to some aspects of the present disclosure.

[0036] Fig.18 is a flow chart illustrating an example of a process for FDSD from the final responder side perspective according to some aspects of the present disclosure.

[0037] Fig.19 is a diagram illustrating an example of a Converged Data Sharing Message (FDSM) request in accordance with some aspects of the present disclosure.

[0038] Fig. 20 is a diagram illustrating an example of an FDSM response according to some aspects of the present disclosure.

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

[0040] Fig. 22 An example computing system in accordance with aspects of the present disclosure is shown. DETAILED DESCRIPTION

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

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

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

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

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

[0046] In a V2X communication system, information is sent from vehicle sensors (and other sources) over a wireless link to allow the information to be communicated to other vehicles, pedestrians, VRUs, and / or traffic infrastructure. The information may be sent using one or more vehicle-based messages, such as cellular-vehicle-to-everything (C-V2X) messages, which may include sensor data sharing messages (SDSM), basic safety messages (BSM), collaborative awareness messages (CAM), collective perception messages (CPM), decentralized environment messages (DENM), and / or other types of vehicle-based messages. By sharing this information with other vehicles, V2X technology can increase the awareness of vehicles (and drivers) of potential hazards to help reduce collisions with other vehicles and entities. In addition, V2X technology improves traffic efficiency by providing vehicles with traffic warnings about upcoming potential road hazards and obstacles so that vehicles can choose alternative traffic routes.

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

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

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

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

[0051] An attacker's goal may be to eliminate the advantages of sensors that utilize V2X communications. In some cases, an attacker may employ non-line-of-sight (NLoS) ghost objects. For example, when an object (e.g., a ghost object) is not within the vehicle's LoS, 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 driver of the vehicle may be forced to slow down (e.g., reduce speed) in order to ensure that the vehicle does not collide with the object, which may not actually exist but is only a ghost object. This effect of causing the driver to perform unnecessary maneuvers (e.g., slowing down) may lead to driver frustration and traffic disruption, which may lead to traffic congestion and / or vehicle collisions.

[0052] Currently, detectors may be inefficient and / or inadequate to detect attacks. For example, current detectors may have limited range, may not operate with V2X-capable objects that are not within sensing line of sight (e.g., in non-line of sight), and / or may not be exploited by vehicles without sensors. In some cases, if the movement pattern of a ghosting object (e.g., a ghosting vehicle) is perfect or near-perfect, current detectors may not be able to detect an attack. Current detectors that use sensors to detect ghosting attacks (e.g., ghosting V2X attacks) may be inefficient in cluttered road environments. For example, camera-based detectors cannot detect objects that are NLoS. As another example, detectors based on received signal strength indication (RSSI) may be affected by signal attenuation caused by obstacles. Current detectors that use sensors to detect ghosting attacks (e.g., ghosting V2X attacks) are only effective if the network device (e.g., vehicle) itself has a sensor.

[0053] In addition, the Collective Perception Service (CPS) cannot verify the physical presence of ghost objects. Thus, the CPS will need to track all ghost objects (e.g., all ghost objects indicated by vehicle-based messages (such as BSM)). In addition, from the perspective of the receiving network device (e.g., the receiving vehicle), the CPS cannot provide V2X data redundancy. For example, the Collective Perception Message (CPM) cannot include V2X objects perceived by the sensors of the sending network device (e.g., the sending vehicle). The CPM can include non-V2X objects perceived by the sensors of the sending network device (e.g., the sending vehicle).

[0054] An ITS-S method using an intelligent transportation system station (ITS-S) can detect simulated V2X objects (e.g., ghost objects). When the simulated V2X object (e.g., ghost object) is within the FoV of the ITS-S, the sensors of the ITS-S can determine the position (localization) of the simulated V2X object (e.g., ghost object). The ITS-S can use the determined object position to verify the position of the object indicated in a vehicle-based message (e.g., BSM) received from the object. However, this ITS-S method has several limitations, including but not limited to, the method requires an ITS-S equipped with sensors, the method cannot detect objects (e.g., V2X objects) in the NLoS of the ITS-S (e.g., obstacles block the FoV of the ITS-S sensors), and the detection range of this method is limited.

[0055] Systems, apparatus, devices (e.g., network devices), methods (also referred to as processes), and computer-readable media (collectively referred to herein as "systems and techniques") are provided for optimizing situational awareness of vehicle misbehavior that may cause traffic disruption. The systems and techniques may provide misbehavior detection services for shared connected and sensed objects (e.g., V2X safety services for shared V2X sensor objects). In some cases, the disclosed services may utilize the LoS of a V2X-capable network device (e.g., a V2X-capable base station) to confirm the presence of ghost objects located in the NLoS of other V2X-capable network devices (e.g., V2X-capable base stations and / or vehicles). The service may allow sensor-V2X detector outputs (e.g., outputs from sensors on a V2X-capable network device) to be shared to a V2X-capable network device that does not have a sensor (e.g., a V2X-capable vehicle). The service may also allow communication (e.g., V2X communication) to a network device (e.g., a V2X-capable vehicle) regarding a V2X sensor object (e.g., a physical object sensed by a sensor on a V2X-capable network device that is local to the object). Additionally, the service may provide data redundancy for verifying consistency between V2X objects (e.g., ghost objects indicated in vehicle-based messages sent via V2X communications) and V2X sensor objects (e.g., physical objects sensed by sensors on V2X-capable network devices local to the objects).

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

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

[0058] In some cases, the network entity may be implemented in an aggregated or holistic base station or server architecture, or alternatively, in a decomposed base station or server architecture, and may include one or more of a central unit (CU), a distributed unit (DU), a radio unit (RU), a near real-time (near-RT) RAN intelligent controller (RIC), or a non-real-time (non-RT) RIC. In some cases, the network entity may include a server device, such as a multi-access edge computing (MEC) device. A base station or server (e.g., with an aggregated / holistic base station architecture or a decomposed base station architecture) may operate according to one of several RATs for communicating with UEs, roadside units (RSUs), and / or other devices, depending on the network in which the base station or server is deployed, and may be alternatively referred to as an access point (AP), a network node, a Node B (NB), an evolved Node B (eNB), a next generation eNB (ng-eNB), a new radio (NR) Node B (also referred to as a gNB or gNodeB), etc. A base station may be primarily used to support wireless access for UEs, including supporting data, voice, and / or signaling connections for supported UEs. In some systems, the base station may provide edge node signaling functions, while in other systems, it may provide additional control and / or network management functions. The communication link through which the UE may send a signal to the base station is referred to as an uplink (UL) channel (e.g., a reverse traffic channel, a reverse control channel, an access channel, etc.). The communication link through which the base station may send a signal to the UE is referred to as a downlink (DL) or forward link channel (e.g., a paging channel, a control channel, a broadcast channel, or a forward traffic channel, etc.). As used herein, the term traffic channel (TCH) may refer to an uplink, a reverse or downlink, and / or a forward traffic channel.

[0059] The term "network entity" or "base station" (e.g., having an aggregated / integrated base station architecture or a decomposed base station architecture) may refer to a single physical TRP or to multiple physical TRPs that may or may not be co-located. For example, where the term "network entity" or "base station" refers to a single physical TRP, the physical TRP may be an antenna of the base station, which corresponds to a cell (or several cell sectors) of the base station. Where the term "network entity" or "base station" refers to multiple co-located physical TRPs, the physical TRP may be an antenna array of the base station (e.g., as in a multiple-input multiple-output (MIMO) system or where the base station employs beamforming). Where the term "base station" refers to multiple non-co-located physical TRPs, the physical TRP may be a distributed antenna system (DAS) (a network of spatially separated antennas connected to a common source via a transmission medium) or a remote radio head (RRH) (a remote base station connected to a serving base station). Alternatively, a non-co-located physical TRP may be a serving base station that receives measurement reports from a UE and a neighboring base station whose reference radio frequency (RF) signal (or simply "reference signal") the UE is measuring. Because the TRP is the point from which a base station transmits and receives wireless signals, as used herein, references to transmitting from or receiving at a base station will be understood to refer to the specific TRP of the base station.

[0060] In some embodiments supporting UE positioning, a network entity or base station may not support wireless access for a UE (e.g., may not support data, voice, and / or signaling connections for a UE), but may send signals to the UE for measurement by the UE and / or may receive and measure signals sent by the UE. Such base stations may be referred to as positioning beacons (e.g., when sending signals to the UE) and / or position measurement units (e.g., when receiving and measuring signals from the UE).

[0061] A roadside unit (RSU) is a device that can communicate with a network through a communication link or interface (e.g., a cellular-based sidelink or PC5 interface, an 802.11-based or WiFi-based TM A device that sends and receives messages to and from one or more UEs, other RSUs, and / or base stations (using a dedicated short-range communication (DSRC) interface and / or other interfaces). Examples of messages that an RSU can send and receive include vehicle-to-everything (V2X) messages, which will be described in more detail below. The RSU can be located on various transportation infrastructure systems (including roads, bridges, parking lots, toll booths, and / or other infrastructure systems). In some examples, the RSU can facilitate communication between UEs (e.g., vehicles, pedestrian user equipment, and / or other UEs) and transportation infrastructure systems. In some embodiments, the RSU can communicate with servers, base stations, and / or other systems that can perform centralized management functions.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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) is forming a downlink beam to send a reference signal to a UE, the downlink beam is a transmit beam. However, if the UE is forming a downlink beam, the downlink beam is a receive beam for receiving downlink reference signals. 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) is forming an uplink beam, the uplink beam is an uplink receive beam, and if the UE is forming an uplink beam, the uplink beam is an uplink transmit beam.

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

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

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

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

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

[0082] Figure 2 is a diagram showing an example of a decomposed base station architecture according to some examples, which can be adopted by the disclosed system for sharing connected and sensed object misbehavior detection services. The deployment of a communication system such as a 5G NR system can be arranged in a variety of ways through various components or components. In a 5G NR system or network, a network node, a network entity, a mobile element of a network, a radio access network (RAN) node, a core network node, a network element, or a network device (such as a base station (BS) or one or more units (or one or more components) that perform base station functionality) can be implemented in an aggregated or decomposed architecture. For example, a BS (such as a Node B (NB), an evolved NB (eNB), an NR BS, a 5G NB, an AP, a transmit receive point (TRP) or a cell, etc.) can be implemented as an aggregated base station (also called an independent BS or an integral BS) or a decomposed base station.

[0083] The aggregated base station may be configured to utilize a radio protocol stack physically or logically integrated within a single RAN node. The decomposed base station may be configured to utilize a protocol stack physically or logically distributed between two or more units, such as one or more central or centralized units (CUs), one or more distributed units (DUs), or one or more radio units (RUs). In some aspects, the 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 throughout one or more other RAN nodes. The 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).

[0084] Base station type operations or network designs may take into account the aggregated nature of base station functionality. For example, a decomposed base station may be used in an integrated access backhaul (IAB) network, an open radio access network (O-RAN (such as a network configuration sponsored by the O-RAN Alliance)), or a virtualized radio access network (vRAN, also known as a cloud radio access network (C-RAN)). Decomposition may include allocating functionality between two or more units at different physical locations, and allocating functionality to at least one unit virtually, which may enable flexibility in network design. Individual units of a decomposed base station or decomposed RAN architecture may be configured for wired or wireless communication with at least one other unit.

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

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

[0087] In some aspects, CU 211 may host one or more high-level 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 with an interface configured to transmit signals with other control functions hosted by CU 211. CU 211 may be configured to handle user plane functionality (i.e., central unit-user plane (CU-UP)), control plane functionality (i.e., central unit-control plane (CU-CP)) or a combination thereof. In some embodiments, CU 211 may be logically divided into one or more CU-UP units and one or more CU-CP units. The CU-UP unit may communicate bidirectionally with the CU-CP unit via an interface (such as via an E1 interface when implemented in an O-RAN configuration). CU 211 may be implemented to communicate with DU131 as needed for network control and signaling.

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

[0089] The lower layer functionality may be implemented by one or more RUs 241. In some deployments, a RU 241 controlled by a DU 231 may correspond to a logical node that hosts RF processing functions or low PHY layer functions (such as performing Fast Fourier Transform (FFT), Inverse FFT (iFFT), Digital Beamforming, Physical Random Access Channel (PRACH) extraction and filtering, etc.), or both, based at least in part on a functional split such as a lower layer functional split. In such an architecture, the RU 241 may be implemented to handle over-the-air (OTA) communications with one or more UEs 221. In some embodiments, real-time and non-real-time aspects of control and user plane communications with the RU 241 may be controlled by the corresponding DU 231. In some scenarios, this configuration may enable the DU 231 and CU 211 to be implemented in a cloud-based RAN architecture (such as a vRAN architecture).

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

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

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

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

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

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

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

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

[0098] The vehicle computing system 450 also includes a power management system 451. In some embodiments, the power management system 451 may include a power management integrated circuit (PMIC), a backup battery, and / or other components. In some cases, other systems in the vehicle computing system 450 may include one or more PMICs, batteries, and / or other components. The power management system 451 may perform power management functions for the vehicle 404, such as managing the power supply of the computing system 450 and / or other parts of the vehicle. For example, in view of power fluctuations, the power management system 451 may provide a stable power supply such as based on starting the engine of the vehicle. In another example, the power management system 451 may perform thermal monitoring operations such as by checking the environment and / or transistor junction temperature. In another example, the power management system 451 may perform specific functions based on detecting a certain temperature level, such as enabling 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 functionality of the vehicle computing system 450 (e.g., limiting the infotainment system 454 by shutting down one or more displays, disconnecting from a wireless network, etc.), and other functions.

[0099] The vehicle computing system 450 also includes a communication system 458. The communication system 458 may include both software and hardware components for sending and receiving signals to and from a network (e.g., to a gNB or other network entity via a Uu interface) and / or other UEs (e.g., to another vehicle or UE via a PC5 interface, a WiFi interface (e.g., DSRC), a Bluetooth™ interface, and / or other wireless and / or wired interfaces). For example, the communication system 458 is configured to wirelessly send and receive information via any suitable wireless network (e.g., a 3G network, a 4G network, a 5G network, a WiFi network, a Bluetooth™ network, and / or other networks). The communication system 458 includes various components or devices for performing wireless communication functionality, 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 embodiments computing system 450 may have any number of SIMs (e.g., one SIM or more than two SIMs) and any number of modems (e.g., one modem, two modems, or more than two modems).

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

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

[0102] A modem is a device that modulates one or more carrier signals to encode digital information for transmission and demodulates 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 of OEM SIM 460 and / or user SIM 462. In some examples, modem 464 may include a 4G (or LTE) modem, and another modem (not shown) of communication system 458 may include a 5G (or NR) modem. In some examples, communication system 458 may include one or more BluetoothTM modems (e.g., for BluetoothTM low energy (BLE) or other types of Bluetooth communications), one or more WiFiTM modems (e.g., for DSRC communications and / or other WiFi communications), broadband modems (e.g., ultra-wideband (UWB) modems), any combination thereof, and / or other types of modems.

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

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

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

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

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

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

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

[0110] The security layer of ITS 455 can be used to securely sign messages from the ITS stack, which are sent to and verified by other UEs (such as other vehicles, pedestrian UEs, and / or infrastructure systems) configured for V2X communication. The security layer can also verify messages received from such other UEs. In some embodiments, the signing and verification process can be based on the security context of the vehicle. In some examples, the security context can include one or more encryption-decryption algorithms, public and / or private keys for generating signatures using encryption-decryption algorithms, and / or other information. For example, each ITS message generated by ITS 455 can be signed by the security layer of ITS 455. The signature can be derived using a public key and an encryption-decryption algorithm. The vehicle, pedestrian UE, and / or infrastructure system that receives the signed message can verify the signature to ensure that the message comes from an authorized vehicle. In some examples, the one or more encryption-decryption algorithms may include one or more symmetric encryption algorithms (e.g., Advanced Encryption Standard (AES), Data Encryption Standard (DES) and / or other symmetric encryption algorithms), one or more asymmetric encryption algorithms using public and private keys (e.g., Rivest-Shamir-Adleman (RSA) and / or other asymmetric encryption algorithms), and / or other encryption-decryption algorithms.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0130] In some embodiments, vehicle-based messages 915 may include specific use cases or safety warnings related to the current status of the equipped network device (e.g., vehicles 910a, 910b, 910c, 910d), such as Do Not Pass Warning (DNPW) or Forward Collision Warning (FCW). In some examples, vehicle-based messages 915 may be in the form of standard basic safety messages (BSM), collaborative awareness messages (CAM), collective perception messages (CPM), sensor data sharing messages (SDSM) (e.g., SAE J3224 SDSM), and / or other formats.

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

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

[0133] As mentioned above, a sending network device (e.g., a V2X-capable vehicle that generates and sends a vehicle-based message (such as a BSM)) may become misbehaving (e.g., operating as a misbehaving vehicle) by intentionally or unintentionally sending a vehicle-based message (e.g., a BSM) that contains incorrect information. For example, if the information contained within the vehicle-based message (e.g., a BSM) of the sending network device identifies an incorrect location (or position) of the sending network device, the sending network device may be operating as a misbehaving vehicle.

[0134] A sending network device (e.g., a V2X-capable vehicle that generates and sends vehicle-based messages) may misbehave (e.g., operate as a misbehaving vehicle) by creating invisible V2X ghost objects that interfere with road traffic and act as an aggressor. A ghost V2X object is a V2X object that is not at the location of the sending network device. A ghost V2X object is an object that has no physical presence, such as a simulated vulnerable road user (VRU) or a simulated vehicle. An invisible object is an object that is outside the sensor field of view (FoV) of a receiving network device (e.g., a V2X-capable vehicle that receives vehicle-based messages) or is not within the line of sight (LoS) of the receiving network device (e.g., a non-line-of-sight scenario).

[0135] The attacker's goal may be to eliminate any benefit of utilizing sensors using V2X communications. The attacker may exploit non-line-of-sight (NLoS) ghost objects. For example, when an object (e.g., a ghost object) is not within the vehicle's LoS, 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 driver of the vehicle may be forced to slow down the vehicle (e.g., reduce speed) in order to ensure that the vehicle does not collide with the object (e.g., which may be a ghost object that does not actually exist). This effect of causing the driver to perform unnecessary maneuvers (e.g., slowing the vehicle) may lead to driver frustration and traffic disruption, which may lead to traffic congestion and / or vehicle collisions.

[0136] Fig.11 1 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. Fig.11 , several equipped (eg, V2X-capable) network devices 1110a, 1110b, 1110c in the form of a truck are shown. Fig.11 Also shown is an unequipped (eg, non-V2X capable) object 1120 in the form of a pedestrian.

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

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

[0139] As mentioned above, in a V2X communication system, information may be sent from vehicle sensors over a wireless link to allow the information to be communicated to other vehicles, pedestrians, VRUs, and / or traffic infrastructure. The information may be sent 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), collaborative awareness messages (CAMs), collective perception messages (CPMs), decentralized environment messages (DENMs), and / or other types of vehicle-based messages.

[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 send a CAM or BSM to share the location, kinematic state, and / or size of the equipped network device. The CAM may be able to depict (create) ghost objects. As another example, an equipped (e.g., V2X-equipped) network device (e.g., a vehicle) may send a CPM or SDSM to share information about all objects sensed by sensors on the equipped network device. However, CPM does not include objects (e.g., objects with V2X capabilities) that send V2X messages (e.g., BSM and CAM).

[0141] There is no redundancy between CPM (e.g., sensor view) and CAM / BSM (e.g., V2X object) for detected objects. For example, an equipped receiving (e.g., V2X-capable) network device (e.g., vehicle) may perceive an object based on a BSM received from the object. However, the equipped receiving network device may not use CPM to verify whether the sensor of the equipped (e.g., V2X-capable) network device (e.g., vehicle) sending the CPM has detected the vehicle (e.g., Fig. 12C ).

[0142] Current vehicle-based messages (e.g., V2X messages) do not contain "fused objects". A "fused object" may be defined as an equipped (e.g., V2X-capable) object (e.g., a vehicle or pedestrian with a smartphone) sensed by the sensors of the ITS-S (e.g., Fig.12D ). A network device (e.g., a vehicle) that is equipped to transmit (e.g., V2X-capable) may transmit a fusion object resulting from V2X-sensor data fusion. A network device (e.g., a vehicle) that is equipped (e.g., V2X-capable) may not be able to combine CPM and BSM for sensor V2X misbehavior detection.

[0143] Fig. 12A , Fig. 12B , Fig. 12C and Fig.12D Different views are shown from the perspective of a receiving (e.g., V2X-capable) equipped network device (e.g., a vehicle). Fig. 12A , Fig. 12B , Fig. 12C and Fig.12D , the sensor FoV 1220 of the vehicle 1210 for different views is shown. Specifically, Fig. 12A is a diagram illustrating an example of a ground truth view from the perspective of a receiving (e.g., V2X-capable) equipped network device 1210 (e.g., a vehicle). Fig. 12A , the sensor FoV 1220 is shown as including equipped (eg, V2X-capable) objects 1230a and unequipped (eg, non-V2X-capable) objects 1240a. Fig. 12A Also shown in FIG. 12 are equipped (eg, V2X-capable) objects 1230 b and unequipped (eg, non-V2X-capable) objects 1240 b that are not within the sensor FoV 1220 .

[0144] Fig. 12B is a diagram illustrating an example of a basic safety message (BSM) view from the perspective of a receiving (e.g., V2X-capable) equipped network device 1210 (e.g., a vehicle). Fig. 12B , the sensor FoV 1220 is shown as including an equipped (e.g., V2X-capable) object 1230a. Fig. 12B Also shown in FIG. 12 is an equipped (eg, V2X-capable) object 1230 b that is not within the sensor FoV 1220 .

[0145] Fig. 12C is a diagram illustrating an example of a collective perception message (CPM) view from the perspective of a receiving (e.g., V2X-capable) equipped network device 1210 (e.g., a vehicle). Fig. 12C , the sensor FoV 1220 is shown as including an unequipped (e.g., non-V2X capable) object 1240a. Fig.12D is a diagram showing an example of a “fused object” view from the perspective of a receiving (e.g., V2X-capable) equipped network device 1210 (e.g., a vehicle). Fig.12D , the sensor FoV 1220 is shown as including an equipped (e.g., V2X-capable) object 1230a.

[0146] As previously described, current detection systems may have problems verifying the physical presence of an object (e.g., an unequipped object or an equipped object) in an NLoS situation. Currently, detectors may be inefficient and / or inadequate to detect attacks (in an NLoS situation). Current detectors may have limited range, may not operate with V2X-capable objects that are not within the sensing line of sight (e.g., in non-line-of-sight), and / or may not be utilized by vehicles without sensors.

[0147] In one or more aspects, systems and techniques provide misbehavior detection (MBD) services for shared connected and sensed objects (e.g., V2X safety services for shared V2X sensor objects). The system can allow the use of the disclosed techniques to detect NLoS V2X ghost objects. For example, the location of a neighboring ITS-S may be different from the location of an ego vehicle (e.g., an autonomous vehicle). The vehicle's NLoS object (e.g., a ghost) may be a LoS object (e.g., a ghost object) of a neighboring ITS-S. The neighboring ITS-S can communicate to the vehicle whether the object exists (e.g., whether it is a ghost object).

[0148] The disclosed system has multiple benefits. In one or more aspects, the system has the benefit of providing a solution for detecting NLoS ghost objects. This benefit can prevent the driver from braking (e.g., slowing down) and / or being unable to move in the presence of an NLoS V2X object. In some aspects, the solution can be incorporated as part of European Telecommunications Standards Institute (ETSI) 103 759. Another benefit of the system is that it provides a solution for vehicles without sensors to use V2X sensor detectors (sensors) from neighboring ITS-Ss. In addition, the system also has the benefit of sharing "fused objects" with other ITS-Ss. For example, an ITS-S may not have the exact location of an NLoS object. Neighboring ITS-Ss may have "top-level" (higher quality) sensors that are able to make better measurements, which may benefit other ITS-Ss with "low-level" (lower quality) sensors.

[0149] Fig.13 , Fig.14A , Fig. 14B and Fig. 14C Each shows an example system 1300, 1400, 1401, 1402 for converged data sharing service (FDSS) that can be employed by V2X. FDSS allows network devices without sensors and / or equipment that are in NLoS or out of FoV range with suspicious objects to verify whether a suspicious object exists or is a ghost object.

[0150] Fig.13 is a diagram illustrating an example of a system 1300 for sharing a connected and sensed object misbehavior detection service, wherein an equipped (e.g., V2X-capable) network device A 1340 (e.g., transportation infrastructure such as ITS-s) having multiple sensors 1350a, 1350b provides visual confirmation of another equipped network device B 1310 (e.g., a vehicle). Fig.13 , a network device B 1310 (e.g., a vehicle) equipped (e.g., with V2X capabilities) is shown traveling along a road defined by obstructing buildings 1320a, 1320b and obstacles 1330a, 1330b. A sensor Fov 1370d of the equipped network device B 1310 is shown. Fig.13 Also shown in FIG. 1 is an equipped (e.g., V2X-capable) network device A 1340 (e.g., traffic infrastructure such as ITS-S, traffic lights, or RSU) along with its associated sensors 1350a, 1350b. Sensor FoVs 1370a, 1370b, 1370c for the equipped network device A 1340 and its associated sensors 1350a, 1350b are shown.

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

[0152] However, the equipped (e.g., V2X-capable) network device C 1360 (e.g., an object) is located within the LoS and within the sensor FoV 1370c of the sensor 1350b associated with the equipped (e.g., V2X-capable) network device A 1340 (e.g., within the LoS). The equipped network device B 1310 (e.g., a vehicle) may send (transmit) a fused data sharing message (FDSM) request to the equipped (e.g., V2X-capable) network device A 1340 to request the equipped (e.g., V2X-capable) network device A 1340 to verify the location of the equipped (e.g., V2X-capable) network device C 1360 (e.g., the object). After receiving the FDSM request, the equipped (e.g., V2X-capable) network device A 1340 may use its sensor 1350b to verify the location of the equipped (e.g., V2X-capable) network device C 1360 (e.g., the object). In response, the equipped (eg, V2X-capable) network device A 1340 may send (transmit) a FDSM response including the verified location to the equipped (eg, V2X-capable) network device B 1310 .

[0153] In one or more aspects, during operation of the FDSS, an equipped (e.g., V2X-capable) network device (e.g., an ITS-S, a vehicle, an RSU, a pedestrian with a smartphone, or a drone) may provide feedback (e.g., feedback about a ghosting object) to another equipped (e.g., V2X-capable) network device. In some aspects, during operation of the FDSS, a single equipped (e.g., V2X-capable) network device (e.g., an ITS-S, a vehicle, an RSU, a pedestrian with a smartphone, or a drone) that may serve as a formation leader may request feedback from another equipped (e.g., V2X-capable) network device. Fig.14A , Fig. 14B and Fig. 14C An example of the operation of the FDSS is shown, where an equipped network device provides feedback to another equipped network device, and an equipped network device requests feedback from another equipped network device.

[0154] Fig.14A is a diagram illustrating an example of a system 1400 for sharing a connected and sensed object misbehavior detection service, wherein a formation leader (e.g., equipped network device A 1410a) provides visual confirmation of an equipped (e.g., V2X-capable) network device C 1460. Fig.14A , equipped (e.g., V2X-capable) network device A 1410a (e.g., a vehicle), equipped (e.g., V2X-capable) network device B 1410c (e.g., a vehicle), and equipped (e.g., V2X-capable) network device 1410c (e.g., a vehicle) are shown traveling along a road. Equipped (e.g., V2X-capable) network device A 1410a (e.g., a vehicle), equipped (e.g., V2X-capable) network device B 1410c (e.g., a vehicle), and equipped (e.g., V2X-capable) network device 1410c (e.g., a vehicle) may all be in a formation, with equipped (e.g., V2X-capable) network device A 1410a (e.g., a vehicle) acting as a formation leader. FIG. 14 also shows a sensor Fov 1470b of the equipped network device B 1410b and a sensor Fov 1470a of the equipped network device A 1410a.

[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-capable) network device C 1460 (e.g., an object) that is located within the NLoS of the equipped network device B 1410b. The BSM may indicate the location of the equipped (e.g., V2X-capable) network device C 1460 (e.g., the object). Since the equipped (e.g., V2X-capable) network device C 1460 (e.g., the object) is located within the NLoS of the equipped network device B 1410b, the equipped network device B 1410b (e.g., using its sensors) may not be able to verify the indicated location of the equipped (e.g., V2X-capable) network device C 1460 (e.g., the object) to determine whether the equipped (e.g., V2X-capable) network device C 1460 (e.g., the object) is present at the indicated location.

[0156] However, the equipped (e.g., V2X-capable) network device C 1460 (e.g., an object) is located within the LoS and is located at the sensor Fov 1470a of the equipped (e.g., V2X-capable) network device A 1410a (e.g., a vehicle) (e.g., within the LoS). The equipped network device B 1410b (e.g., a vehicle) may send (transmit) an FDSM request to the equipped (e.g., V2X-capable) network device A 1410a to request the equipped (e.g., V2X-capable) network device A 1410a to verify the location of the equipped (e.g., V2X-capable) network device C 1460 (e.g., an object). After receiving the FDSM request, the equipped (e.g., V2X-capable) network device A 1410a may use its sensors to verify the location of the equipped (e.g., V2X-capable) network device C 1460 (e.g., an object). In response, equipped (eg, V2X-capable) network device A 1410a may send (transmit) an FDSM response including the verified location to equipped (eg, V2X-capable) network device B 1410b.

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

[0158] Fig. 14Bis a diagram illustrating an example of a system 1401 for sharing a connected and sensed object misbehavior detection service, wherein an equipped (e.g., V2X-capable) network device A 1441 (e.g., ITS-S) with a single sensor provides visual confirmation of another equipped network device C 1461 (e.g., object). Fig. 14B , a network device B 1411 (e.g., a vehicle) equipped (e.g., with V2X capabilities) is shown traveling along a road defined by an obstacle building 1421 and obstacles 1431a, 1431b. A sensor Fov 1471b of the equipped network device B 1411 is shown. Fig. 14B Also shown in FIG. 14 is an equipped (e.g., V2X-capable) network device A 1441a (e.g., traffic infrastructure such as ITS-S, traffic lights, drones, or RSUs). A sensor FoV 1471a for the equipped network device A 1441 is shown.

[0159] During operation of the system 1401, an equipped network device B 1411 (e.g., a vehicle) may receive a BSM from an equipped (e.g., V2X-capable) network device C 1461 (e.g., an object) that is located within the NLoS of the equipped network device B 1411. The BSM may indicate a location (position) of the equipped (e.g., V2X-capable) network device C 1461 (e.g., the object). Since the equipped (e.g., V2X-capable) network device C 1461 (e.g., the object) is located within the NLoS of the equipped network device B 1411, the equipped network device B 1411 (e.g., using its sensors) may not be able to verify the indicated location (position) of the equipped (e.g., V2X-capable) network device C 1461 (e.g., the object) to determine whether the equipped (e.g., V2X-capable) network device C 1461 (e.g., the object) is present (or not present) at the indicated location.

[0160] The equipped (e.g., V2X-capable) network device C 1461 (e.g., an object) is located within the LoS and is located at the sensor Fov 1471a (e.g., within the LoS) of the equipped (e.g., V2X-capable) network device A 1441. The equipped network device B 1411 (e.g., a vehicle) may send (transmit) an FDSM request to the equipped (e.g., V2X-capable) network device A 1441 to request the equipped (e.g., V2X-capable) network device A 1441 to verify the location of the equipped (e.g., V2X-capable) network device C 1461 (e.g., the object). After receiving the FDSM request, the equipped (e.g., V2X-capable) network device A 1441 may use its sensors to verify the location of the equipped (e.g., V2X-capable) network device C 1461 (e.g., the object). The equipped (eg, V2X-capable) network device A 1461 may send (transmit) an FDSM response including a verified position (positioning) to the equipped (eg, V2X-capable) network device B 1411 .

[0161] Fig. 14C is a diagram illustrating an example of a system 1402 for sharing a connected and sensed object misbehavior detection service, wherein an equipped (e.g., V2X-capable) network device A 1442 (e.g., an RSU or a drone) located within one range (e.g., range A) provides visual confirmation of another equipped network device C 1462 (e.g., an object, RSU, or a drone) located within two ranges (e.g., ranges A and B). Fig. 14C , an equipped network device B 1412 (e.g., an RSU or a drone) is shown as being located in a range (e.g., range B). A sensor FoV 1472b of the equipped network device B 1412 (e.g., an RSU) is shown. Fig. 14C Also shown in FIG. 14 is an equipped (eg, V2X-capable) network device A 1442 (eg, RSU). A sensor FoV 1472a for the equipped network device A 1442 is shown.

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

[0163] The equipped (e.g., V2X-capable) network device C 1462 (e.g., an object) is located within the LoS and at the sensor Fov 1472a of the equipped (e.g., V2X-capable) network device A 1442. The equipped network device B 1412 (e.g., an RSU) may send (transmit) an FDSM request to the equipped (e.g., V2X-capable) network device A 1442 to request the equipped (e.g., V2X-capable) network device A 1442 to verify the location of the equipped (e.g., V2X-capable) network device C 1462 (e.g., the object). After receiving the FDSM request, the equipped (e.g., V2X-capable) network device A 1442 may use its sensors to verify the location of the equipped (e.g., V2X-capable) network device C 1462 (e.g., the object). The equipped (eg, V2X-capable) network device A 1462 may send (transmit) an FDSM response including a verified position (location) to the equipped (eg, V2X-capable) network device B 1412 .

[0164] Fig.15A1500 is a diagram illustrating an example of signaling 1500 for a feedback method for FDSS. During operation of the feedback method, an equipped (e.g., V2X-capable) network device B 1510 (e.g., ITS-S) may send (transmit) 1515 a vehicle-based message (e.g., BSM) to an equipped (e.g., V2X-capable) network device A 1540 (e.g., ITS-S), which may include the location of the network device B 1510. An equipped (e.g., V2X-capable) object C 1560 (e.g., object) may send (transmit) 1525 a vehicle-based message (e.g., BSM) to an equipped (e.g., V2X-capable) network device A 1540 (e.g., ITS-S), which may include the expected (or claimed) location of the object C 1560.

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

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

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

[0168] Then, the equipped (e.g., V2X-capable) object C 1561 (e.g., object) may send (transmit) 1536 a vehicle-based message (e.g., BSM) to the equipped (e.g., V2X-capable) network device B 1541 (e.g., ITS-S), which may include the expected 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) that the vehicle-based message (e.g., BSM) sent from the equipped (e.g., V2X-capable) object C 1561 (e.g., object) is suspicious 1546 (e.g., the expected location of the object C 1561 in the vehicle-based message is suspicious because, for example, the object C 1561 is in the NLoS of the network device B 1541). The equipped (e.g., V2X-capable) network device B 1541 may then generate 1556 a FDSM request, which may request the equipped network device A 1511 to determine whether object C 1561 is present at the expected location. After the equipped network device B 1541 has generated the FDSM request, the equipped network device B 1541 may send (transmit) the FDSM request 1566 to the equipped network device A 1511.

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

[0170] A converged data sharing protocol (FDSP) may be used for communication of the FDSS. In one or more aspects, if the ITS-S is an RSU, the ITS-S may broadcast an FDSM response so that multiple equipped (e.g., V2X-capable) network devices (e.g., ITS-S and / or vehicles) may receive the FDSM response. Other equipped network devices (e.g., ITS-S) may benefit from receiving the FDSM response. For example, a network device (e.g., a vehicle) located at an equipped network device (e.g., such as Fig.13 All equipped network devices (e.g., vehicles) behind the equipped network device B 1310 will not be able to determine the equipped object (e.g., Fig.13 Whether the equipped object C 1360 in is suspicious in the NLoS of the equipped network devices (e.g., vehicles), and thus, these network devices (e.g., vehicles) will need to use FDSS.

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

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

[0173] Various conditions may be employed to trigger the FDSP. In one or more aspects, a suspected equipped (e.g., V2X-capable) object is located outside the FoV of an equipped network device (e.g., a vehicle) if the suspected equipped (e.g., V2X-capable) object is not visible to a sensor of an equipped (e.g., V2X-capable) network device (e.g., a vehicle) that is in the NLoS of the equipped object; the suspected equipped object is located within the FoV of the equipped network device's sensor but not within the LoS of the equipped network device's sensor; the suspected equipped object cannot be detected because the equipped network device's sensor is damaged or malfunctioning, or the suspected equipped object cannot be detected because the equipped network device does not have any sensors.

[0174] In one or more aspects, if the heading of the equipped network device intersects the heading of the suspected equipped object, the trajectory (e.g., movement direction) of the suspected equipped (e.g., V2X-capable) object may intersect the trajectory of an equipped (e.g., V2X-capable) network device (e.g., vehicle) located in the NLoS of the suspected equipped object.

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

[0176] In some aspects, the FDSD may include identifiers, such as hashed certificates contained within a vehicle-based message (e.g., a BSM), and identifiers of simulated equipped (e.g., V2X-capable) objects identified by a sensor-V2X detector (e.g., an equipped network device such as an ITS-S).

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

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

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

[0180] In some aspects, if an equipped object has sent a vehicle-based message (e.g., a BSM) and has been confirmed by at least one sensor of an equipped network device (e.g., an ITS-S) (e.g., the location of the equipped object has been verified), then the object identifier of the equipped object can be inserted into the FDSM (e.g., as a fused object).

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

[0182] After the requester has collected all sensor data and has received vehicle-based messages from the equipped objects, the requester may review the sensor data to check (determine) whether at least one of the sensors detects the equipped object (e.g., the requester may run a sensor-V2X detector 1640). After the requester has reviewed the sensor data, the requester may collect the ID of each suspected equipped object 1650 for a given sensing time window. In one or more examples, the collected IDs may be the IDs of the suspected equipped objects contained in the vehicle-based messages (e.g., BSMs) sent by the suspected 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 remaining time before a decision is made (e.g., a driving decision, such as braking).

[0183] After the requester has collected the IDs of the suspicious equipped objects and the requester determines that it cannot verify the location of at least one suspicious object, the requester can check (verify) whether the requester can send (transmit) a request for FDSS1660. In one or more examples, the decision on whether the requester can send a request can depend on the availability of surrounding equipped network devices (e.g., ITS-S) that can provide such services. In some examples, the equipped network device (e.g., ITS-S) can announce the service in its certificate (e.g., which can be included in a vehicle-based message such as a BSM). The certificate can contain a set of permissions, such as service-specific permissions (SSP), which can define the actions that the certificate owner is allowed to perform within the FDSS. If available, the requester can use the sensor information contained in the vehicle-based message (e.g., CPM) to check whether the equipped object is located within the FoV of the equipped network device (e.g., ITS-S).

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

[0185] Fig.171700 is a flow chart showing an example of a process 1700 for FDSD from the responder side perspective. During the process 1700, for each vehicle-based message (e.g., BSM) 1710 received from an equipped (e.g., V2X-capable) object, the responder (e.g., an equipped network device such as an ITS-S) may run a sensor-V2X detector 1730 (e.g., using its sensors 1705 and fusion 1720) to collect a fused object list 1735, a simulated (fake) equipped (e.g., V2X-capable) object list 1740, and a sensor object list 1745.

[0186] In one or more examples, the fused object can be an equipped (e.g., V2X) object that is sensed (detected) by a sensor of the responder and has sent a vehicle-based message (e.g., BSM) that is received by the responder. In some examples, the fused object can be represented by an object ID. In some examples, the fused object can be represented by a set of fields that can include, but are not limited to, the object ID, location, type, size, and kinematic data of the equipped object.

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

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

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

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

[0191] Fig.18 1800 is a flow chart showing an example of a process 1800 for FDSD from the perspective of the final responder side. During the process 1800, upon receiving the FDSM 1820, the requester (e.g., the equipped network device) can check 1830 (verify) whether the equipped object is simulated (fake). In one or more examples, the requester can check (verify) whether the suspected equipped object (within the suspected equipped object list 1810) has its ID in the fused object or the simulated (fake) object. Sensor objects cannot be used in the process 1800 because sensor objects do not have vehicle-based messages and therefore do not have certificates or object IDs.

[0192] In some examples, the requester can check (verify) a match between vehicle-based message (e.g., BSM) features and fused and sensor object features. A vehicle-based message (e.g., BSM) of a real equipped object will match the content (e.g., position, velocity, heading, and / or size) of the object contained in the FDSM. A vehicle-based message (e.g., BSM) of a simulated (fake) object may result in a mismatch with one of the objects contained in the FDSM.

[0193] After the requester checks (determines) whether the equipped object is simulated (fake), the requester can update the collaborative sensing database 1840. If the FDSM response has reported the existence of a malicious equipped object, the requester can update the collaborative sensing database to delete the malicious track. If the fused object may contain more accurate data (for example, because the responder may have a better sensor), the requester can update the collaborative sensing database to update the correct track.

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

[0195] In one or more aspects, the FDSS may be announced. The FDSS may need to be announced because before sending a request for the FDSS, the request will need to know which equipped network device can provide the FDSS. Therefore, a solution is proposed on how to communicate to the requester which neighboring equipped network devices (e.g., ITS-S) can provide the FDSS.

[0196] In one or more aspects, to advertise the FDSS, an additional permission bit (e.g., for advertising the FDSS) may be added to the digital certificate to indicate whether the network device can provide the FDSS. The permission bit may be a single bit that describes the availability of the FDSS in the equipped network device (e.g., 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., ITS-S). If the permission bit is set equal to one (1), the FDSS is not available to the equipped network device (e.g., ITS-S).

[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 sender of the FDSM (e.g., an equipped sending network device) may need to know whether an adjacent equipped network device (e.g., an ITS-S) supports FDSS and is therefore able to process the FDSM being sent. In one or more examples, the responder may require the digital certificate of the recipient to make the response. In some examples, the requester may require the digital certificate of the responder before sending the request.

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

[0199] In one or more aspects, the FDSS may employ two message types. The two message types include a first message type (e.g., Fig.19 of the fused data sharing message request 1910 and a second message type (eg, Fig. 20 The first message type is a FDSM for requesting FDSS, and the second message type is a FDSM for responding to a FDSS request.

[0200] Fig.19 is a diagram illustrating an example 1900 of a Fusion Data Sharing Message (FDSM) request 1910. In one or more aspects, Fig.19 The FDSM request 1910 can be used to Fig. 15B The request-response approach shown 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 generation time of the FDSM), a source container field 1930 (e.g., including 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., including a set of vehicle-based messages, such as BSM, ID). The FDSM request 1910 may be a V2X message. The fields 1920, 1930, 1940, 1950, 1960, 1970, 1980a, 1980b of the FDSM request 1910 may all be mandatory fields.

[0201] In one or more aspects, during operation, an equipped (e.g., V2X-capable) transmitting network device may send (transmit) an FDSM request (e.g., FDSM request 1910) to an equipped (e.g., V2X-capable) receiving network device to notify the equipped (e.g., V2X-capable) receiving network device of an expected or claimed location of an object (e.g., a ghost object) that sends a vehicle-based message (e.g., BSM) to the equipped (e.g., V2X-capable) transmitting network device. After the equipped (e.g., V2X-capable) receiving network device receives the FDSM request, because the equipped (e.g., V2X-capable) receiving network device is now aware of the object's claimed location (e.g., from information contained within the FDSM request), the equipped (e.g., V2X-capable) receiving network device may orient its (multiple) sensor antenna beams toward the object's expected location to verify whether the object is (or is not) present at that location.

[0202] Fig. 20 is a diagram illustrating an example 2000 of an FDSM response 2005. In one or more aspects, Fig. 20 The FDSM request 2005 can be used to Fig.15A and Fig. 15B The feedback method and request-response method shown in . Fig. 20 , the FDSM request 2005 is shown to include a plurality of fields, which may include a message timestamp field 2010 (e.g., including the generation time of the FDSM), a source ID field 2015 (e.g., including the ID of the sending device), and an object container field 2020. The object container field 2020 may include a fused object field 2025 (e.g., including a set of vehicle-based messages, such as BSMs, identifiers of objects that have been detected by sensors and have sent vehicle-based messages), a malicious object field 2030 (e.g., including a set of vehicle-based messages, such as BSMs, identifiers of verified ghost objects), and a sensor object field 2035 (e.g., including a set of vehicle-based messages, such as BSMs, identifiers of objects that have been detected by sensors and have not yet sent vehicle-based messages).

[0203] The fused object field 2025 may include a plurality of BSM object fields 2040a, 2040b. Each BSM object field 2040a, 2040b may include an object ID field 2070, a kinematic data field 2080, and a size data field 2090. The malicious object field 2030 may include a plurality of object ID fields 2050a, 2050b. The sensor object field 2035 may include a plurality of CPM object fields 2060a, 2060b.

[0204] The FDSM response 2005 may be a V2X message. Except for the kinematics data field 2080 and the dimension data field 2090 which are optional fields, all fields may be mandatory fields.

[0205] In one or more aspects, the logic for inserting an object into the FDSM is as follows. For BSM objects that have not been confirmed by the sensors of the ITS-S, if the object is outside the FoV of all sensors, the object identifier of the object may not be inserted into the FDSM. If the object is in at least one sensor FoV, the object identifier of the object may be inserted into the FDSM (e.g., a ghost object).

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

[0207] For a BSM object that has been confirmed by at least one sensor, an object identifier of the object may be inserted into the FDSM (eg, a fused object).

[0208] Fig.21 21 is a flow chart illustrating an example of a process 2100 for wireless communication. The 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 an unmanned aerial vehicle (UAV), a wearable device such as a connected watch, an extended reality (XR) device such as a virtual reality (VR) or augmented reality (AR) headset or glasses, or other type of UE), or other type of network device or component, system, or apparatus thereof (e.g., a chipset). The operations of the process 2100 may be implemented as a process performed on one or more processors of a vehicle (e.g., Fig. 22 The software components are executed and run on the processor 2210 or other processors of the vehicle. In addition, the sending and receiving of signals by the wireless communication device in the process 2100 can be implemented, for example, through one or more antennas and / or one or more transceivers (e.g., wireless transceivers) of the vehicle.

[0209] At block 2110, the network device (or a component, system, or apparatus thereof) may determine an estimated location of a second network device. In some cases, the first network device and the second network device are capable of vehicle-to-everything (V2X) communications (e.g., sending, 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 UAE, or other types of network devices.

[0210] At block 2120, the network device (or a component, system, or apparatus thereof) may compare the estimated location to the expected 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 expected location of the second network device. In some examples, the vehicle-based message is a basic safety message (BSM), a collaborative awareness message (CAM), a collective perception message (CPM), a sensor data sharing message (SDSM), a decentralized environmental message (DENM), or other types of vehicle-based messages.

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

[0212] At block 2140, the network device (or its component, system, or apparatus) may generate a report based on determining whether the second device is a misbehaving device. In some aspects, the network device (or its component, system, or apparatus) may output a response including the report for transmission to a third network device. In some cases, the second network device is not within a field of view (FoV) of a sensor of the third network device and / or is not within a 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.

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

[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 network devices that send vehicle-based messages and are within the FoV and / or LoS of a third network device (or other network devices). The sensor object list may include network devices that have not yet sent any vehicle-based messages and are within the FoV and / or LoS of a third network device (or other network devices). The simulated object list may include network devices that are ghost objects.

[0215] Fig. 222200, which may be employed by the disclosed system for sharing connected and sensed object misbehavior detection services, according to some aspects of the present disclosure. Specifically, Fig. 22 An example of a computing system 2200 is shown, which may be any computing device, for example, constituting an internal computing system, a remote computing system, a camera, or any components thereof, wherein the components of the system communicate with each other using connection 2205. Connection 2205 may be a physical connection using a bus, or a direct connection such as in a chipset architecture into processor 2210. Connection 2205 may also be a virtual connection, a networked connection, or a logical connection.

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

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

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

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

[0220] The computing system 2200 may include a communication interface 2240, which may generally control and manage user input and system output. The communication interface may use a wired and / or wireless transceiver to perform or facilitate receiving and / or transmitting wired or wireless communications, including wired or wireless communications that take advantage of the following: audio jacks / plugs, microphone jacks / plugs, Universal Serial Bus (USB) ports / plugs, Apple TM Lightning TM Ports / plugs, Ethernet ports / plugs, fiber optic ports / plugs, dedicated wired ports / plugs, 3G, 4G, 5G and / or other cellular data network wireless signal transmission, Bluetooth TM Wireless signal transmission, Bluetooth TM Low energy (BLE) wireless signal transmission, IBEACON TM Wireless signal transmission, radio frequency identification (RFID) wireless signal transmission, near field communication (NFC) wireless signal transmission, dedicated short range communication (DSRC) wireless signal transmission, 802.11 Wi-Fi wireless signal transmission, wireless local area network (WLAN) signal transmission, visible light communication (VLC), Worldwide Interoperability for Microwave Access (WiMAX), infrared (IR) communication wireless signal transmission, public switched telephone network (PSTN) signal transmission, integrated services digital network (ISDN) signal transmission, ad hoc network signal transmission, radio wave signal transmission, microwave signal transmission, infrared signal transmission, visible light signal transmission, ultraviolet light signal transmission, wireless signal transmission along the electromagnetic spectrum, or some combination thereof.

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

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

[0223] Storage device 2230 may include software services, servers, services, etc., which enable the system to perform functions when the code defining such software is executed by processor 2210. In some aspects, hardware services that perform specific functions may include a combination of software components stored in a computer-readable medium and necessary hardware components (such as processor 2210, connection 2205, output device 2235, etc.) to perform the function. The term "computer-readable medium" includes, but is not limited to, portable or non-portable storage devices, optical storage devices, and various other media capable of storing, containing or carrying instructions and / or data. Computer-readable media may include non-transitory media in which data may be stored and does not include carrier waves and / or transient electronic signals propagated wirelessly or through wired connections. Examples of non-transitory media may include, but are not limited to, disks or tapes, optical storage media such as compact discs (CDs) or digital versatile disks (DVDs), flash memory, memory, or memory devices. Computer-readable media may store code and / or machine-executable instructions thereon, which may represent programs, functions, subroutines, programs, routines, subroutines, modules, software packages, categories, or any combination of instructions, data structures, or program statements. A code segment can be coupled to another code segment or hardware circuit by passing and / or receiving information, data, independent variables, parameters, or memory contents. Information, independent variables, parameters, data, etc. can be passed, forwarded, or sent via any suitable means, including memory sharing, message passing, token passing, network transmission, etc.

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

[0225] For clarity of explanation, in some cases, the present technology can be presented as including individual functional blocks, which include devices, device components, steps or routines in the method embodied in software or a combination of hardware and software. Additional components other than those shown in the figures and / or described herein can be used. For example, circuits, systems, networks, processes and other components can be shown as components in block diagram form to avoid confusing various aspects in unnecessary details. In other cases, known circuits, processes, algorithms, structures and techniques can be shown without unnecessary details to avoid confusing various aspects.

[0226] In addition, it will be appreciated by those skilled in the art that the various illustrative logic blocks, modules, circuits and algorithmic steps described in conjunction with the aspects disclosed herein can be implemented as electronic hardware, computer software or a combination of the two. In order to clearly illustrate this interchangeability of hardware and software, various illustrative components, frames, modules, circuits and steps have been generally described above in terms of their functions. Whether this functionality is implemented as hardware or software depends on specific applications and the design constraints imposed on the entire system. The technician can implement the described functionality in different ways for each specific application, but this implementation decision should not be interpreted as causing a departure from the scope of the present disclosure.

[0227] The above text can describe various aspects as a process or method, and the process or method is depicted as a flow chart, a flow diagram, a data flow diagram, a structure diagram or a block diagram. Although the flow chart can describe the operation as a sequential process, many operations can be performed in parallel or simultaneously. In addition, the order of operations can be rearranged. The process terminates when its operation is completed, but may have additional steps not included in the figure. The process can correspond to a method, a function, a program, a subroutine, a subprogram, etc. When the process corresponds to a function, its termination can correspond to the function returning to the calling function or the main function.

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

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

[0230] Those skilled in the art will appreciate that any of a variety of different technologies and techniques may be used to represent information and signals. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be mentioned throughout the above description may be represented by voltage, current, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof, depending in some cases on the specific application, in part on the desired design, in part on the corresponding technology, etc.

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

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

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

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

[0235] A person of ordinary skill in the art will understand that the less than ("<") and greater than (">") symbols or terms used herein may be replaced with less than or equal to ("≤") and greater than or equal to ("≥") symbols, respectively, without departing from the scope of the present specification.

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

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

[0238] Claim language or other language reciting "at least one" of a set and / or "one or more" of a set indicates that one member of the set or multiple members of the set (in any combination) 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. In another example, claim language reciting "at least one of A, B, and C" or "at least one of A, B, or C" means A, B, C, or A and B, or A and C, or B and C, or A and B and C. The language "at least one" of a set and / or "one or more" of a set does not limit the set to the items listed in the set. For example, claim language reciting "at least one of A and B" or "at least one of A or B" may mean A, B, or A and B, and may additionally include items not listed in the set of A and B.

[0239] Illustrative aspects of the disclosure include:

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

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

[0242] Aspect 3. A method according to aspect 2, wherein the vehicle-based message includes an expected location of the second network device.

[0243] Aspect 4. A method according to any one of Aspects 2 or 3, wherein the vehicle-based message is one of a basic safety message (BSM), a collaborative awareness message (CAM), a collective perception message (CPM), a sensor data sharing message (SDSM), or a decentralized environmental message (DENM).

[0244] Aspect 5. The method according to any one of aspects 1 to 4 further comprises sending a response including the report from the first network device to a third network device.

[0245] Aspect 6. The method according to 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.

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

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

[0248] Aspect 9. A method according to 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.

[0249] Aspect 10. The method according to any one of aspects 1 to 9 further comprises receiving, at the first network device, a data sharing request from a third network device.

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

[0251] Aspect 12. The method according to any one of Aspects 1 to 11 further includes generating a fusion object list, a sensor object list, and a simulation object list at the first network device, wherein one of the fusion object list, the sensor object list, or the simulation object list includes the second network device.

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

[0253] Aspect 14. A method according to any one of Aspects 12 or 13, wherein the sensor object list includes network devices that have not sent any vehicle-based messages and are located within at least one of a field of view (FoV) or a line of sight (LoS) of a third network device.

[0254] Aspect 15. The method according to any one of aspects 12 to 14, wherein the simulation object list includes network devices as ghost objects.

[0255] Aspect 16. A first network device for wireless communication, comprising: at least one memory; and at least one processor, the at least one processor being coupled to the at least one memory and configured to: determine an estimated location of a second network device; compare the estimated location with 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 determining whether the second device is a misbehaving device.

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

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

[0258] Aspect 19. A first network device according to any one of Aspects 16 or 18, wherein the vehicle-based message is one of a basic safety message (BSM), a collaborative awareness message (CAM), a collective perception message (CPM), a sensor data sharing message (SDSM), or a decentralized environmental message (DENM).

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

[0260] Aspect 21. A first network device according to 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.

[0261] Aspect 22. The first network device according to 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.

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

[0263] Aspect 24. A first network device according to any one 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.

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

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

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

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

[0268] Aspect 29. A first network device according to any one of Aspects 27 or 28, wherein the sensor object list includes network devices that have not sent any vehicle-based messages and are located within at least one of the field of view (FoV) or line of sight (LoS) of the third network device.

[0269] Aspect 30. The first network device according to any one of Aspects 27 to 29, wherein the simulation object list includes network devices that are ghost objects.

[0270] Aspect 31. A non-transitory computer-readable medium having instructions stored thereon, the instructions, when executed by one or more processors, causing the one or more processors to perform the operations according to any one of aspects 1 to 15.

[0271] Aspect 32. An apparatus for wireless communication, comprising: means for performing the operations of any one of aspects 1 to 15.

[0272] The above description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects. Therefore, the claims are not intended to be limited to the aspects shown herein, but to conform to the full scope consistent with the language claims, wherein reference to an element in the singular is not intended to mean "one and only one" (unless specifically stated so), but rather "one or more".

Claims

1. A wireless communication method performed at a first network device, the method comprising: 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 comparison; as well as A report is generated at the first network device based on determining whether the second device is a misbehaving device.

2. The method according to claim 1, further comprising: A vehicle-based message is received at the first network device from the second network device.

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

4. The method according to claim 2, wherein: The vehicle-based message is one of a basic safety message (BSM), a collaborative awareness message (CAM), a collective perception message (CPM), a sensor data sharing message (SDSM), or a decentralized environmental message (DENM).

5. The method according to claim 1, further comprising: A response including the report is sent from the first network device to a third network device.

6. The method according to claim 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.

7. The method according to claim 5, 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.

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

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

10. The method according to claim 1, further comprising: A data sharing request is received at the first network device from a third network device.

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

12. The method according to claim 1, further comprising: A fusion object list, a sensor object list, and a simulation object list are generated at the first network device, wherein one of the fusion object list, the sensor object list, or the simulation object list includes the second network device.

13. The method according to claim 12, wherein: The fused object list includes network devices that send vehicle-based messages and are located within at least one of a field of view (FoV) or a line of sight (LoS) of a third network device.

14. The method according to claim 12, wherein: The sensor object list includes network devices that have not sent any vehicle-based messages and are within at least one of a field of view (FoV) or a line of sight (LoS) of a third network device.

15. The method according to claim 12, wherein: The simulation object list includes network devices as ghost objects.

16. A first network device for wireless communication, comprising: at least one memory; as well as at least one processor coupled to at least one memory and configured to: determining an estimated location of a second network device; comparing the estimated location to an expected location of the second network device; determining whether the second network device is a misbehaving device based on the comparing; and A report is generated based on determining whether the second device is a misbehaving device.

17. The first network device according to claim 16, wherein: The at least one processor is configured to receive a vehicle-based message from the second network device.

18. The first network device according to claim 17, wherein: The vehicle-based message includes an expected location of the second network device.

19. The first network device according to claim 17, wherein: The vehicle-based message is one of a basic safety message (BSM), a collaborative awareness message (CAM), a collective perception message (CPM), a sensor data sharing message (SDSM), or a decentralized environmental message (DENM).

20. The first network device according to claim 16, wherein: The at least one processor is configured to output a response including the report for transmission to a third network device.

21. The first network device according to claim 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.

22. The first network device according to claim 20, 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.

23. The first network device according to claim 16, wherein: The first network device and the second network device are capable of vehicle-to-everything (V2X) communication.

24. The first network device according to claim 16, wherein: The first network device and the second network device are each one of an intelligent transportation system station (ITS-S), a vehicle, a road side unit (RSU), a user equipment (UE), or a drone.

25. The first network device according to claim 16, wherein: The at least one processor is configured to receive a data sharing request from a third network device.

26. The first network device according to claim 25, wherein: The data sharing request includes at least one of a message timestamp field, a source field, or a malicious object field.

27. The first network device according to claim 16, wherein: The at least one processor is configured to generate a fusion object list, a sensor object list, and a simulation object list, wherein one of the fusion object list, the sensor object list, or the simulation object list includes the second network device.

28. The first network device according to claim 27, wherein: The fused object list includes network devices that send vehicle-based messages and are located within at least one of a field of view (FoV) or a line of sight (LoS) of a third network device.

29. The first network device according to claim 27, wherein: The sensor object list includes network devices that have not sent any vehicle-based messages and are located within at least one of a field of view (FoV) or a line of sight (LoS) of a third network device.

30. The first network device according to claim 27, wherein: The simulation object list includes network devices as ghost objects.

Images