Filtering V2X sensor data messages

Abstract

Techniques for filtering object detection information provided via a V2X communication link are provided. An example method for filtering detected object data includes receiving a sensor data sharing message associated with a first vehicle including host data and detected object data, where the detected object data is organized into one or more data sets, and the host data includes index information associated with the one or more data groups; determining an operating context of the second vehicle; and filtering the one or more data sets based at least in part on the operating context of the second vehicle and the index information associated with the one or more data sets.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. patent application No. 17 / 879,877, filed on August 3, 2022, entitled “FILTERING V2X SENSOR DATAMESSAGES,” which is assigned to the assignee of this application, and the entire contents of which are hereby incorporated herein by reference for all purposes. Technical Field

[0002] The following relates generally to wireless communications, and more particularly to filtering sensor data sharing messages (SDSMs) and / or collective perception messages (CPMs) sent via a vehicle-to-everything (V2X) communication link. Background Art

[0003] Wireless communication systems are widely deployed to provide various types of communication content, such as voice, video, packet data, messaging, broadcasting, and the like. These systems may be able to support communication with multiple users by sharing available system resources (e.g., time, frequency, and power). Examples of such multiple access systems include fourth generation (4G) systems (such as long term evolution (LTE) systems, advanced LTE (LTE-A) systems, or LTE-A Pro systems) and fifth generation (5G) systems (which may be referred to as new radio (NR) systems). These systems may employ various technologies, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal frequency division multiple access (OFDMA), or discrete Fourier transform spread OFDM (DFT-S-OFDM). A wireless multiple access communication system may include multiple base stations or network access nodes, each of which simultaneously supports communication of multiple communication devices (which may be referred to as user equipment (UE) in other aspects).

[0004] In some wireless communication systems (such as distributed wireless networks), wireless devices (e.g., UEs) may communicate directly with each other (e.g., via sidelink communications) and may support various radio frequency and / or baseband capabilities. In some cases, direct communication between wireless devices may include direct communication between vehicles, and systems using such communication may sometimes be referred to as vehicle-to-everything (V2X) communication systems. For example, a V2X communication link may be configured to convey important information between vehicles regarding object and vehicle detection, road conditions, and / or activities of nearby vehicles. V2X communication systems may also be used by autonomous or semi-autonomous vehicles (e.g., self-driving vehicles or vehicles providing driver assistance) and may provide additional information beyond the scope of the vehicle's existing systems. Such V2X communication links may provide certain safety-related information (e.g., location, direction of travel, speed, object detection, etc.) in unencrypted messages so that other vehicles may receive such information. As the number of V2X vehicles increases, there is a need to improve the processes for handling the associated increase in V2X-related messaging. Summary of the invention

[0005] An example method for providing detected object data according to the present disclosure includes: detecting one or more objects near a vehicle; organizing information associated with the one or more detected objects near the vehicle into one or more data groups; generating a sensor data sharing message including host data and detected object data based on the information associated with the one or more detected objects near the vehicle, wherein the detected object data is organized based on the one or more data groups, and the host data includes index information associated with the one or more data groups; and sending the sensor data sharing message.

[0006] An example method for filtering detected object data according to the present disclosure includes: receiving a sensor data sharing message associated with a first vehicle including host data and detected object data, wherein the detected object data is organized into one or more data groups, and the host data includes index information associated with the one or more data groups; determining an operating context of a second vehicle; and filtering the one or more data groups based at least in part on the operating context of the second vehicle and the index information associated with the one or more data groups.

[0007] An example method for filtering detected object data according to the present disclosure includes: receiving a basic safety message and one or more sensor data sharing messages from a vehicle; determining the relevance of the basic safety message based at least in part on a location of the vehicle; and decoding or discarding the one or more sensor data sharing messages based on the relevance of the basic safety message.

[0008] An example method for partially filtering a sensor data sharing message according to the present disclosure includes: receiving a sensor data sharing message from a vehicle; decoding a first portion of the sensor data sharing message to determine an area of ​​interest associated with the vehicle; determining a relative position of the area of ​​interest; and decoding or discarding a second portion of the sensor data sharing message based on the relative position of the area of ​​interest.

[0009] The items and / or technologies described herein may provide one or more of the following capabilities and other capabilities not mentioned. Manned vehicles and autonomous vehicles may be equipped with various sensors, such as radio detection and ranging, light detection and ranging, and other technologies, to enable vehicles to detect nearby objects. Vehicles may provide V2X messages, such as basic safety messages (BSM) and sensor data sharing messages (SDSM), to share object detection information with neighboring vehicles. The onboard unit (OBU) in the vehicle may be configured to receive BSM and SDSM from multiple vehicles and filter relevant object detection information. In one example, the SDSM may be discarded based on an association with the BSM. The group of detected objects may be defined using information elements in the host data of the SDSM, and the detected object data in the SDSM may be partially filtered based on host data parameters. The relevant groups of detected object information may be decoded, and irrelevant groups may be discarded (ie, not decoded). Filtering the detected object data may reduce processing requirements and timelines, and improve power consumption and thermal considerations. Other capabilities may be provided, and not every specific implementation according to the present disclosure must provide any of the capabilities discussed, let alone all of the capabilities. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 is a simplified diagram of an example wireless communication system.

[0011] Figure 2 is a block diagram of components of an example user equipment or in-vehicle unit.

[0012] Figure 3 is a block diagram of the components of an example send / receive point.

[0013] Figure 4 is a block diagram of the components of a server.

[0014] Figure 5 is a system diagram illustrating various entities configured to utilize a V2X communication link.

[0015] Figure 6 is a diagram of an example use case for providing BSM and SDSM to vehicles and other stations via V2X messaging.

[0016] Figure 7Figure 1 is an example diagram of an Intelligent Transport System (ITS) stack reference architecture.

[0017] Figure 8 is a diagram of an example use case for sending safety and object detection messages between vehicles.

[0018] 9A to 9C is a diagram of an example scenario for determining related BSM and SDSM messages.

[0019] Fig.10 is the Abstract System Notation (ASN) representation of the example SDSM.

[0020] Fig.11A and Fig. 11B is a diagram of example relative positions between vehicles and areas of interest.

[0021] Fig.12 is a diagram illustrating an example group-based object detection scheme.

[0022] Fig.13 is an ASN representation of an example host data portion of an SDSM with additional information elements to enable group-based object detection filtering.

[0023] Fig.14 is a process flow message of an example method for filtering SDSMs based on association with BSMs.

[0024] Fig.15 is a process flow of an example method for partially filtering an SDSM.

[0025] Fig.16 is a process flow of an example method for providing detected object data.

[0026] Fig.17 is a process flow of an example method for filtering a portion of detected object data based on a data group. DETAILED DESCRIPTION

[0027] This article discusses techniques for filtering object detection information provided via a V2X communication link. V2X, including cellular V2X (C-V2X) technology, enables radio frequency (RF) communications between vehicles and other wireless nodes, such as other vehicles, roadside units (RSUs), vulnerable road users (VRUs), and cellular networks. Vehicles can be configured to send V2X messages, such as basic safety messages (BSMs) and / or dedicated short-range communications (DSRC) messages, to nearby vehicles and stations (e.g., RSUs). The BSM may include information elements such as current location (e.g., latitude, longitude, altitude, location accuracy) and other status information associated with the vehicle (e.g., transmission and speed, heading, braking system status, etc.). Many vehicles and other wireless nodes configured for V2X communications may also include one or more sensors configured to detect nearby objects such as pedestrians, vehicles, obstacles, and other roadside objects. For example, a vehicle may include radar, lidar, optical, and other sensor technologies to detect the location of nearby objects and then utilize V2X messaging (e.g., SDSM, CPM) to provide object detection information to neighboring stations and / or vehicles. The number of detected objects (e.g., non-V2X vehicles, obstacles, VSUs) and corresponding SDSM / CPM messages will continue to increase as the number of vehicles supporting V2X increases. The techniques provided herein enable effective filtering of SDSMs to improve processing load and timelines and to facilitate power / thermal considerations. Filtering SDSMs may include decoding or discarding portions of data included in SDSMs. In one example, SDSM filtering may be based on additional information in the SDSM, and / or by associating a BSM with an SDSM sent from a vehicle and utilizing BSM information to filter decisions. The entire SDSM sent from a vehicle may be filtered based on the relevance of the source data or the BSM sent by the vehicle. A subset of objects detected in the SDSM may be filtered based on source data including additional information elements. These techniques are examples, however, other message configurations may also be used.

[0028] This specification may refer to a sequence of actions to be performed by, for example, an element of a computing device. Each action described herein can be performed by a dedicated circuit (e.g., an application specific integrated circuit (ASIC)), by program instructions being executed by one or more processors, or by a combination of the two. The sequence of actions described herein may be embodied in a non-transitory computer-readable medium having stored thereon a corresponding set of computer instructions that, when executed, will cause an associated processor to perform the functionality described herein. Thus, the various aspects described herein may be implemented in a number of different forms, all of which fall within the scope of the present disclosure, including the claimed subject matter.

[0029] As used herein, the terms "user equipment" (UE) and "base station" are not dedicated to or otherwise limited to any particular radio access technology (RAT), unless otherwise specified. Generally speaking, such UE can be any wireless communication device (e.g., mobile phone, router, tablet computer, laptop computer, consumer asset tracking device, Internet of Things (IoT) device, on-board unit (OBU), etc.) used by a user to communicate on a wireless communication network. The UE can be mobile or can be stationary (e.g., at certain times) and can communicate with a radio access network (RAN). As used herein, the term "UE" can be interchangeably referred to as an "access terminal" or "AT", "client device", "wireless device", "subscriber equipment", "subscriber terminal", "subscriber station", "user terminal" or UT, "mobile terminal", "mobile station", "mobile device" or their variations. A UE set in a vehicle can be referred to as an on-board unit (OBU). In general, the UE can communicate with the core network via the RAN, and through the core network, the UE can connect to external networks such as the Internet and other UEs. Of course, other mechanisms for connecting to the core network and / or the Internet are also possible for the UE, such as through a wired access network, a WiFi network (eg, based on IEEE (Institute of Electrical and Electronics Engineers) 802.11, etc.), and the like.

[0030] Depending on the network in which the base station is deployed, the base station may operate according to one of several RATs when communicating with the UE. Examples of base stations include access points (APs), network nodes, Node Bs, evolved Node Bs (eNBs), or generalized Node Bs (gNodeBs, gNBs). In addition, in some systems, the base station may only provide edge node signaling functions, while in other systems, the base station may provide additional control functions and / or network management functions.

[0031] The UE may be implemented by any of a variety of types of devices, including but not limited to a printed circuit (PC) card, a compact flash device, an external or internal modem, a wireless or wired phone, a smart phone, a tablet device, a consumer asset tracking device, an asset tag, etc. The communication link through which the UE can transmit signals to the RAN is called an uplink channel (e.g., a reverse traffic channel, a reverse control channel, an access channel, etc.). The communication link through which the RAN can transmit signals to the UE is called a downlink or forward link channel (e.g., a paging channel, a control channel, a broadcast channel, a forward traffic channel, etc.). As used herein, the term "traffic channel (TCH)" may refer to an uplink / reverse traffic channel or a downlink / forward traffic channel.

[0032] As used herein, depending on the context, the term "cell" or "sector" may correspond to one of the multiple cells of a base station or to the base station itself. The term "cell" may refer to a logical communication entity used to communicate with a base station (e.g., on a carrier), and may be associated with an identifier to distinguish adjacent cells operating via the same carrier or different carriers (e.g., physical cell identifier (PCID), virtual cell identifier (VCID)). In some examples, a carrier may support multiple cells, and different cells may be configured according to different protocol types that may provide access to different types of devices (e.g., machine type communication (MTC), narrowband Internet of Things (NB-IoT), enhanced mobile broadband (eMBB), or other protocol types). In some examples, the term "cell" may refer to a portion of a geographic coverage area (e.g., a sector) on which the logical entity operates.

[0033] refer to Figure 1 , an example of a communication system 100 includes UE 105, UE 106, a radio access network (RAN) (here, fifth generation (5G) next generation (NG) RAN (NG-RAN) 135), a 5G core network (5GC) 140, and a server 150. UE 105 and / or UE 106 may be, for example, an IoT device, a location tracker device, a cellular phone, a vehicle (e.g., a car, truck, bus, ship, etc.), or other devices. A 5G network may also be referred to as a new radio (NR) network; NG-RAN 135 may be referred to as a 5G RAN or an NR RAN; and 5GC 140 may be referred to as an NG core network (NGC). Standardization of NG-RAN and 5GC is ongoing in the 3rd Generation Partnership Project (3GPP). Therefore, NG-RAN 135 and 5GC 140 may follow current standards or future standards from 3GPP for 5G support. NG-RAN 135 may be another type of RAN, for example, a 3G RAN, a 4G Long Term Evolution (LTE) RAN, etc. UE 106 may be similarly configured and coupled to UE 105 to transmit and / or receive signals to and / or from similar other entities in system 100, but for simplicity of the drawings, the UE 106 is not shown in FIG. Figure 1105. Similarly, for simplicity, the discussion focuses on the UE 105. The communication system 100 can utilize information from a constellation 185 of satellite vehicles (SVs) 190, 191, 192, 193 of a satellite positioning system (SPS) (e.g., a global navigation satellite system (GNSS)) such as the Global Positioning System (GPS), the Global Navigation Satellite System (GLONASS), the Galileo system, or the BeiDou system or some other local or regional SPS (such as the Indian Regional Navigation Satellite System (IRNSS), the European Geostationary Navigation Overlay Service (EGNOS), or the Wide Area Augmentation System (WAAS)). Additional components of the communication system 100 are described below. The communication system 100 may include additional or alternative components.

[0034] like Figure 1 As shown in FIG. 1 , the NG-RAN 135 includes NR Node Bs (gNBs) 110a, 110b and a next generation eNodeB (ng-eNB) 114, and the 5GC 140 includes an access and mobility management function (AMF) 115, a session management function (SMF) 117, a location management function (LMF) 120, and a gateway mobile location center (GMLC) 125. The gNBs 110a, 110b, and the ng-eNB 114 are communicatively coupled to each other, each configured for bidirectional wireless communication with the UE 105, and each communicatively coupled to the AMF 115 and configured for bidirectional communication with the AMF. The gNBs 110a, 110b, and the ng-eNB 114 may be referred to as base stations (BSs). The AMF 115, the SMF 117, the LMF 120, and the GMLC 125 are communicatively coupled to each other, and the GMLC is communicatively coupled to the external client 130. The SMF 117 may serve as an initial contact point with a service control function (SCF) (not shown) to create, control, and delete media sessions. A base station (such as gNB 110a, 110b and / or ng-eNB 114) may be a macro cell (e.g., a high-power cellular base station) or a small cell (e.g., a low-power cellular base station) or an access point (e.g., a short-range base station configured to communicate with a short-range technology (e.g., WiFi, WiFi Direct (WiFi-D), Bluetooth ® ,Bluetooth ® Low Energy (BLE), Zigbee, etc.) for communication). One or more base stations (e.g., one or more of gNB 110a, 110b, and / or ng-eNB 114) may be configured to communicate with UE 105 via multiple carriers. Each of gNB 110a, 110b, and / or ng-eNB 114 may provide communication coverage for a corresponding geographic area (e.g., a cell). Each cell may be divided into multiple sectors according to the base station antenna.

[0035] Figure 1 A generalized illustration of various components is provided, wherein any or all of the components may be utilized as appropriate, and each of the components may be repeated or omitted as desired. Specifically, although one UE 105 is illustrated, many UEs (e.g., hundreds, thousands, millions, etc.) may be utilized in the communication system 100. Similarly, the communication system 100 may include a greater (or smaller) number of SVs (i.e., more or less than the four SVs 190-193 shown), gNBs 110a, 110b, ng-eNBs 114, AMFs 115, external clients 130, and / or other components. The illustrated connections connecting the various components in the communication system 100 include data and signaling connections, which may include additional (intermediate) components, direct or indirect physical and / or wireless connections, and / or additional networks. In addition, the components may be rearranged, combined, separated, replaced, and / or omitted depending on the desired functionality.

[0036] Although Figure 1 A 5G-based network is illustrated, but similar network implementations and configurations may be used for other communication technologies, such as 3G, Long Term Evolution (LTE), etc. Implementations described herein (which are used for 5G technology and / or for one or more other communication technologies and / or protocols) may be used to send (or broadcast) directional synchronization signals, receive and measure directional signals at a UE (e.g., UE 105), and / or provide location assistance to UE 105 (via GMLC 125 or other location server), and / or calculate the position of UE 105 at a device with positioning capabilities, such as UE 105, gNB 110a, 110b, or LMF 120, based on measurements received at UE 105 for such directionally transmitted signals. The gateway mobile location center (GMLC) 125, the location management function (LMF) 120, the access and mobility management function (AMF) 115, the SMF 117, the ng-eNB (eNodeB) 114 and the gNB (gNodeB) 110a, 110b are examples and may be replaced by or include various other location server functionalities and / or base station functionalities, respectively, in various embodiments.

[0037] The system 100 is capable of wireless communications in that the components of the system 100 may communicate with each other (at least sometimes using wireless connections), directly or indirectly, for example, via gNBs 110a, 110b, ng-eNBs 114, and / or 5GCs 140 (and / or one or more other devices not shown, such as one or more other transceiver base stations). For indirect communications, the communications may be altered during transmission from one entity to another, for example, to change header information of a data packet, change format, etc. The UE 105 may include multiple UEs and may be a mobile wireless communications device, but may communicate wirelessly as well as via a wired connection. The UE 105 may be any of a variety of devices, such as a smartphone, a tablet computer, a vehicle-based device, etc., but these devices are examples in that the UE 105 need not be any of these configurations and other configurations of UEs may be used. Other UEs may include wearable devices (e.g., smart watches, smart jewelry, smart glasses, or headphones, etc.). Other UEs may also be used, whether currently existing or developed in the future. In addition, other wireless devices (whether mobile or not) may be implemented within the system 100 and may communicate with each other and / or with the UE 105, the gNBs 110a, 110b, the ng-eNBs 114, the 5GC 140, and / or the external clients 130. For example, such other devices may include Internet of Things (IoT) devices, medical devices, home entertainment and / or automation devices, etc. The 5GC 140 may communicate with the external client 130 (e.g., a computer system), for example, to allow the external client 130 to request and / or receive location information about the UE 105 (e.g., via the GMLC 125).

[0038] The UE 105 or other device may be configured to communicate in various networks and / or for various purposes and / or using various technologies (e.g., 5G, Wi-Fi communication, multi-frequency Wi-Fi communication, satellite positioning, one or more types of communication (e.g., GSM (Global System for Mobile), CDMA (Code Division Multiple Access), LTE (Long Term Evolution), V2X (Vehicle to Vehicle, e.g., V2P (vehicle to pedestrian), V2I (vehicle to infrastructure), V2V (vehicle to vehicle), etc.), IEEE802.11p, etc.). V2X communication may be cellular (Cellular-V2X (C-V2X)) and / or WiFi-based (e.g., DSRC (Dedicated Short Range Connection)). The system 100 may support operation on multiple carriers (waveform signals of different frequencies). A multi-carrier transmitter may send modulated signals simultaneously on multiple carriers. Each modulated signal may be a code division multiple access (CDMA) signal, a time division multiple access (TDMA) signal, an orthogonal frequency division multiple access (OFDMA) signal, a single carrier frequency division multiple access (SC-FDMA) signal, or the like. Each modulated signal may be transmitted on a different carrier and may carry pilots, overhead information, data, or the like. UEs 105, 106 may communicate with each other through UE-to-UE sidelink communication by transmitting on one or more sidelink (SL) channels such as a physical sidelink synchronization channel (PSSCH), a physical sidelink broadcast channel (PSBCH), or a physical sidelink control channel (PSCCH).

[0039] UE 105 may include and / or may be referred to as a device, a mobile device, a wireless device, a mobile terminal, a terminal, a mobile station (MS), a secure user plane location (SUPL) enabled terminal (SET), or some other name. In addition, UE 105 may correspond to a cellular phone, a smart phone, a laptop, a tablet device, a PDA, a consumer asset tracking device, a navigation device, an Internet of Things (IoT) device, a health monitor, a security system, a smart city sensor, a smart meter, a wearable tracker, or some other portable or mobile device. Typically, although not necessarily, UE 105 supports wireless communications using one or more radio access technologies (RATs), such as Global System for Mobile Communications (GSM), Code Division Multiple Access (CDMA), Wideband CDMA (WCDMA), LTE, High Rate Packet Data (HRPD), IEEE 802.11 WiFi (also known as Wi-Fi), Bluetooth ®(BT), Worldwide Interoperability for Microwave Access (WiMAX), 5G New Radio (NR) (e.g., using NG-RAN 135 and 5GC 140), etc. UE 105 may use a wireless local area network (WLAN) to support wireless communications, which may be connected to other networks (e.g., the Internet) using, for example, a digital subscriber line (DSL) or packet cable. Using one or more of these RATs may allow UE 105 (e.g., via elements of 5GC 140 ( Figure 1 125) and / or allow the external client 130 to receive location information about the UE 105 (eg, via the GMLC 125).

[0040] UE 105 may include a single entity or may include multiple entities, such as in a personal area network, where users may employ audio, video and / or data I / O (input / output) devices and / or body sensors and separate wired or wireless modems. The estimate of the location of UE 105 may be referred to as location, location estimate, location fix, fix, position, position estimate, or position fix, and may be geographic, providing location coordinates (e.g., latitude and longitude) about UE 105, which may or may not include an altitude component (e.g., height above sea level; height above or depth below ground level, floor level, or basement level). Alternatively, the location of UE 105 may be expressed as a municipal location (e.g., a postal address or a designation of a point or smaller area in a building, such as a specific room or floor). The location of UE 105 may be expressed as an area or volume (geographically or municipally defined) within which UE 105 is expected to be located with a certain probability or confidence level (e.g., 67%, 95%, etc.). The location of the UE 105 may be expressed as a relative position including, for example, a distance and direction relative to a known location. The relative position may be expressed as relative coordinates (e.g., X, Y (and Z) coordinates) defined relative to some origin at a known location, which may be defined, for example, geographically, in municipal form, or with reference to a point, area, or volume indicated, for example, on a map, floor plan, or building plan. In the description contained herein, the use of the term location may include any of these variations unless otherwise indicated. When calculating the location of the UE, the local x-coordinate, y-coordinate, and possibly z-coordinate are typically solved, and the local coordinates are then converted (if necessary) into absolute coordinates (e.g., with respect to latitude, longitude, and altitude above or below mean sea level).

[0041] UE 105 may be configured to communicate with other entities using one or more of a variety of technologies. UE 105 may be configured to be indirectly connected to one or more communication networks via one or more device-to-device (D2D) peer-to-peer (P2P) links. D2D P2P links may be supported using any suitable D2D radio access technology (RAT), such as LTE Direct (LTE-D), WiFi Direct (WiFi-D), Bluetooth ® Etc. One or more UEs in a group of UEs utilizing D2D communication may be located within a geographic coverage area of ​​a transmit / receive point (TRP), such as one or more of gNB 110a, gNB 110b, and / or ng-eNB 114. Other UEs in such a group may be outside such geographic coverage area or may be unable to receive transmissions from a base station for other reasons. A group of UEs communicating via D2D communication may utilize a one-to-many (1:M) system, in which each UE may transmit to other UEs in the group. A TRP may facilitate the scheduling of resources for D2D communication. In other cases, D2D communication may be performed between UEs without involving a TRP. One or more UEs in a group of UEs utilizing D2D communication may be located within a geographic coverage area of ​​a TRP. Other UEs in such a group may be outside such geographic coverage area or may be unable to receive transmissions from a base station for other reasons. A group of UEs communicating via D2D communication may utilize a one-to-many (1:M) system, in which each UE may transmit to other UEs in the group. The TRP may facilitate the scheduling of resources for D2D communication. In other cases, D2D communication may be performed between UEs without involving a TRP.

[0042] Figure 1 The base stations (BSs) in the NG-RAN 135 shown in the figure include NR B nodes (referred to as gNB 110a and gNB 110b). Each pair of gNBs 110a, 110b in the NG-RAN 135 may be connected to each other via one or more other gNBs. Access to the 5G network is provided to the UE 105 via wireless communications between the UE 105 and one or more of the gNBs 110a, 110b, which may provide wireless communications access to the 5GC 140 on behalf of the UE 105 using 5G. Figure 1 , it is assumed that the serving gNB for UE 105 is gNB 110a, but another gNB (e.g., gNB 110b) may serve as the serving gNB if UE 105 moves to another location, or may serve as a secondary gNB to provide additional throughput and bandwidth to UE 105.

[0043] Figure 1The base stations (BSs) in the NG-RAN 135 shown in the figure may include an ng-eNB 114, which is also referred to as a next generation evolved Node B. The ng-eNB 114 may be connected to one or more of the gNBs 110a, 110b in the NG-RAN 135 via one or more other gNBs and / or one or more other ng-eNBs. The ng-eNB 114 may provide LTE wireless access and / or evolved LTE (eLTE) wireless access to the UE 105. One or more of the gNBs 110a, 110b and / or the ng-eNB 114 may be configured to function as a positioning-only beacon, which may transmit signals to assist in determining the location of the UE 105, but may not be able to receive signals from the UE 105 or other UEs.

[0044] The gNBs 110a, 110b, and / or the ng-eNB 114 may each include one or more TRPs. For example, each sector within a cell of a BS may include a TRP, but multiple TRPs may share one or more components (e.g., a shared processor but with separate antennas). The system 100 may include only a macro TRP, or the system 100 may have different types of TRPs, such as a macro TRP, a pico TRP, and / or a femto TRP, among others. A macro TRP may cover a relatively large geographic area (e.g., a radius of several kilometers) and may allow unrestricted access to terminals with service subscriptions. A pico TRP may cover a relatively small geographic area (e.g., a pico cell) and may allow unrestricted access to terminals with service subscriptions. A femto or home TRP may cover a relatively small geographic area (e.g., a femto cell) and may allow restricted access to terminals associated with the femto cell (e.g., terminals of users in a home).

[0045] Each of the gNBs 110a, 110b, and / or ng-eNB 114 may include a radio unit (RU), a distributed unit (DU), and a central unit (CU). For example, the gNB 110b includes a RU 111, a DU 112, and a CU 113. The RU 111, the DU 112, and the CU 113 divide the functionality of the gNB 110b. Although the gNB 110b is shown as having a single RU, a single DU, and a single CU, the gNB may include one or more RUs, one or more DUs, and / or one or more CUs. The interface between the CU 113 and the DU 112 is referred to as an F1 interface. The RU 111 is configured to perform digital front end (DFE) functions (e.g., analog-to-digital conversion, filtering, power amplification, transmission / reception) and digital beamforming, and includes a portion of the physical (PHY) layer. The RU 111 may perform DFE using massive multiple input / multiple output (MIMO) and may be integrated with one or more antennas of the gNB 110b. DU 112 hosts the radio link control (RLC), medium access control (MAC), and physical layers of gNB 110b. One DU can support one or more cells, and each cell is supported by a single DU. The operation of DU 112 is controlled by CU 113. CU 113 is configured to perform functions for transmitting user data, mobility control, radio access network sharing, positioning, session management, etc., although some functions are only assigned to DU 112. CU 113 hosts the radio resource control (RRC), service data adaptation protocol (SDAP), and packet data convergence protocol (PDCP) protocols of gNB 110b. UE 105 can communicate with CU 113 via the RRC layer, SDAP layer, and PDCP layer, communicate with DU 112 via the RLC layer, MAC layer, and PHY layer, and communicate with RU 111 via the PHY layer.

[0046] As mentioned, although Figure 1 Nodes configured to communicate according to a 5G communication protocol are depicted, but nodes configured to communicate according to other communication protocols (such as an LTE protocol or an IEEE 802.11x protocol) may also be used. For example, in an evolved packet system (EPS) that provides LTE wireless access to UE 105, the RAN may include an evolved universal mobile telecommunications system (UMTS) terrestrial radio access network (E-UTRAN), which may include base stations with evolved Node Bs (eNBs). The core network for the EPS may include an evolved packet core (EPC). The EPS may include the E-UTRAN plus the EPC, where the E-UTRAN corresponds to Figure 1 The NG-RAN 135 in the figure and the EPC correspond to the 5GC 140 in the figure.

[0047] The gNB 110a, gNB 110b, and ng-eNB 114 may communicate with the AMF 115; for positioning functionality, the AMF communicates with the LMF 120. The AMF 115 may support mobility of the UE 105, including cell changes and handovers, and may participate in supporting signaling connections with the UE 105 and possible data bearers and voice bearers for the UE 105. The LMF 120 may communicate directly with the UE 105, or directly with the gNB 110a, 110b, and / or ng-eNB 114, for example, via wireless communications. The LMF 120 may support positioning of the UE 105 when the UE 105 accesses the NG-RAN 135, and may support various positioning procedures / methods, such as Assisted GNSS (A-GNSS), Observed Time Difference of Arrival (OTDOA) (e.g., downlink (DL) OTDOA or uplink (UL) OTDOA), Round Trip Time (RTT), Multi-cell RTT, Real-Time Kinematics (RTK), Precise Point Positioning (PPP), Differential GNSS (DGNSS), Enhanced Cell ID (E-CID), Angle of Arrival (AoA), Angle of Departure (AoD), and / or other positioning methods. The LMF 120 may process a location service request for the UE 105 received from, for example, the AMF 115 or the GMLC 125. The LMF 120 may be connected to the AMF 115 and / or the GMLC 125. The LMF 120 may be referred to by other names, such as a Location Manager (LM), a Location Function (LF), a Commercial LMF (CLMF), or a Value-Added LMF (VLMF). A node / system implementing LMF 120 may additionally or alternatively implement other types of location support modules, such as an enhanced serving mobile location center (E-SMLC) or a secure user plane location (SUPL) location platform (SLP). At least a portion of the positioning functionality (including the derivation of the location of UE 105) may be performed at UE 105 (e.g., using signal measurements obtained by UE 105 for signals sent by wireless nodes (such as gNB 110a, 110b and / or ng-eNB 114) and / or assistance data provided to UE 105 by LMF 120, for example). AMF 115 may serve as a control node for handling signaling between UE 105 and 5GC 140, and may provide QoS (quality of service) flow and session management. AMF 115 may support mobility of UE 105 (including cell changes and handovers), and may participate in supporting signaling connections to UE 105.

[0048] The server 150 (e.g., a cloud server) is configured to obtain a location estimate for the UE 105 and provide the location estimate to the external client 130. The server 150 may, for example, be configured to run a microservice / service that obtains a location estimate for the UE 105. The server 150 may, for example, obtain a location estimate from the UE 105, one or more of the gNBs 110a, 110b (e.g., via the RU 111, DU 112, and CU 113), and / or the ng-eNB 114, and / or the LMF 120 (e.g., by transmitting a location request to them). As another example, the UE 105, one or more of the gNBs 110a, 110b (e.g., via the RU 111, DU 112, and CU 113), and / or the LMF 120 may push the location estimate of the UE 105 to the server 150.

[0049] The GMLC 125 may support location requests for the UE 105 received from the external client 130 via the server 150, and may forward such location requests to the AMF 115 for forwarding by the AMF 115 to the LMF 120, or may forward the location requests directly to the LMF 120. A location response (e.g., containing a location estimate of the UE 105) from the LMF 120 may be returned to the GMLC 125 directly or via the AMF 115, and the GMLC 125 may then return the location response (e.g., containing the location estimate) to the external client 130 via the server 150. The GMLC 125 is shown as being connected to both the AMF 115 and the LMF 120, but may not be connected to either the AMF 115 or the LMF 120 in some implementations.

[0050] like Figure 1 As further illustrated in FIG. 1 , LMF 120 may communicate with gNB 110a, 110b and / or ng-eNB 114 using a new radio positioning protocol A (which may be referred to as NPPa or NRPPa), which may be defined in 3GPP Technical Specification (TS) 38.455. NRPPa may be the same as, similar to, or an extension of LTE Positioning Protocol A (LPPa) defined in 3GPP TS 36.455, wherein NRPPa messages are transmitted between gNB 110a (or gNB 110b) and LMF 120 and / or between ng-eNB 114 and LMF 120 via AMF 115. Figure 1As further illustrated, the LMF 120 and the UE 105 may communicate using the LTE Positioning Protocol (LPP), which may be defined in 3GPP TS 36.355. The LMF 120 and the UE 105 may additionally or alternatively communicate using a new radio positioning protocol (which may be referred to as NPP or NRPP), which may be the same as, similar to, or an extension of the LPP. Here, LPP messages and / or NPP messages may be transmitted between the UE 105 and the LMF 120 via the AMF 115 and the serving gNB 110a, 110b or the serving ng-eNB 114 of the UE 105. For example, the LPP messages and / or NPP messages may be transmitted between the LMF 120 and the AMF 115 using the 5G Location Service Application Protocol (LCS AP), and may be transmitted between the AMF 115 and the UE 105 using the 5G Non-Access Stratum (NAS) protocol. The LPP protocol and / or the NPP protocol may be used to support positioning of the UE 105 using UE-assisted and / or UE-based positioning methods such as A-GNSS, RTK, OTDOA, and / or E-CID. The NRPPa protocol may be used to support positioning of the UE 105 using a network-based positioning method such as E-CID (e.g., in conjunction with measurements obtained by the gNB 110a, 110b, or ng-eNB 114) and / or may be used by the LMF 120 to obtain location-related information from the gNB 110a, 110b, and / or ng-eNB 114, such as parameters defining directional SS or PRS transmissions from the gNB 110a, 110b, and / or ng-eNB 114. The LMF 120 may be co-located or integrated with the gNB or TRP, or may be located remotely from the gNB and / or TRP and configured to communicate directly or indirectly with the gNB and / or TRP.

[0051] Using UE-assisted positioning methods, UE 105 may obtain location measurements and transmit the measurements to a location server (e.g., LMF 120) for use in calculating a location estimate for UE 105. For example, the location measurements may include one or more of received signal strength indication (RSSI), round trip signal propagation time (RTT), reference signal time difference (RSTD), reference signal received power (RSRP), and / or reference signal received quality (RSRQ) of gNB 110a, 110b, ng-eNB 114, and / or WLAN AP. The location measurements may additionally or alternatively include measurements of GNSS pseudoranges, code phases, and / or carrier phases of SVs 190-193.

[0052] Using the UE-based positioning method, the UE 105 can obtain a position measurement (e.g., the position measurement can be the same or similar to the position measurement for the UE-assisted positioning method), and the position of the UE 105 can be calculated (e.g., with the aid of auxiliary data received from a location server (such as LMF 120) or broadcast by the gNB 110a, 110b, ng-eNB 114 or other base station or AP).

[0053] With network-based positioning methods, one or more base stations (e.g., gNBs 110a, 110b and / or ng-eNB 114) or APs may obtain location measurements (e.g., measurements of RSSI, RTT, RSRP, RSRQ, or time of arrival (ToA) of signals sent by UE 105) and / or may receive measurements obtained by UE 105. The one or more base stations or APs may transmit the measurements to a location server (e.g., LMF 120) for use in computing a location estimate for UE 105.

[0054] The information provided to LMF 120 by gNB 110a, 110b and / or ng-eNB 114 using NRPPa may include timing and configuration information and location coordinates for directional SS or PRS transmission. LMF 120 may provide some or all of this information to UE 105 as assistance data in an LPP message and / or an NPP message via NG-RAN 135 and 5GC 140.

[0055] The LPP message or NPP message transmitted from LMF 120 to UE 105 may instruct UE 105 to do any of a variety of things depending on the desired functionality. For example, the LPP message or NPP message may include instructions for UE 105 to obtain measurements for GNSS (or A-GNSS), WLAN, E-CID, and / or OTDOA (or some other positioning method). In the case of E-CID, the LPP message or NPP message may instruct UE 105 to obtain one or more measurements (e.g., beam ID measurements, beam width measurements, average angle measurements, RSRP measurements, RSRQ measurements) of directional signals transmitted within a particular cell supported by one or more of gNBs 110a, 110b, and / or ng-eNB 114 (or supported by some other type of base station (such as an eNB or WiFi AP)). The UE 105 may transmit the measurement quantity back to the LMF 120 in an LPP message or an NPP message (e.g., within a 5G NAS message) via the serving gNB 110a (or serving ng-eNB 114) and the AMF 115.

[0056] As noted, although the communication system 100 is described with respect to 5G technology, the communication system 100 may be implemented to support other communication technologies (such as GSM, WCDMA, LTE, etc.) for supporting and interacting with mobile devices such as UE 105 (e.g., to implement voice, data, positioning, and other functionality). In some such embodiments, the 5GC 140 may be configured to control different air interfaces. For example, the non-3GPP interworking function (N3IWF, Figure 1 115). The 5GC 140 may be connected to the WLAN by the N3IWF (not shown). For example, the WLAN may support IEEE 802.11 WiFi access for the UE 105 and may include one or more WiFi APs. Here, the N3IWF may be connected to the WLAN and other elements in the 5GC 140, such as the AMF 115. In some embodiments, both the NG-RAN 135 and the 5GC 140 may be replaced by one or more other RANs and one or more other core networks. For example, in the EPS, the NG-RAN 135 may be replaced by an E-UTRAN including an eNB, and the 5GC 140 may be replaced by an EPC including a mobility management entity (MME) replacing the AMF 115, an E-SMLC replacing the LMF 120, and a GMLC that may be similar to the GMLC 125. In such an EPS, the E-SMLC may use LPPa instead of NRPPa to transmit location information to and receive location information from the eNB in ​​the E-UTRAN, and may use LPP to support positioning of the UE 105. In these other embodiments, positioning of UE 105 using directional PRS may be supported in a manner similar to that described herein for 5G networks, with the difference that the functions and processes described herein for gNB 110a, 110b, ng-eNB 114, AMF 115, and LMF 120 may in some cases be applied alternatively to other network elements, such as eNBs, WiFi APs, MMEs, and E-SMLCs.

[0057] As mentioned, in some embodiments, positioning functionality may be implemented at least in part using directional SS beams or directional PRS beams transmitted by a base station (such as gNB 110a, 110b and / or ng-eNB 114) at a UE (e.g., Figure 1 In some instances, the UE may use directional SS beams or directional PRS beams from multiple base stations (such as gNB 110a, 110b, ng-eNB 114, etc.) to calculate the positioning of the UE.

[0058] Also refer to Figure 2UE 200 is an example of one of UEs 105, 106, and includes a computing platform including a processor 210, a memory 211 including software (SW) 212, one or more sensors 213, a transceiver interface 214 for a transceiver 215 (the transceiver includes a wireless transceiver 240 and a wired transceiver 250), a user interface 216, a satellite positioning system (SPS) receiver 217, a camera 218, and a positioning device (PD) 219. The processor 210, the memory 211, the sensor 213, the transceiver interface 214, the user interface 216, the SPS receiver 217, the camera 218, and the positioning device 219 may be communicatively coupled to each other via a bus 220 (the bus may be configured, for example, for optical communication and / or electrical communication). One or more of the devices shown (e.g., the camera 218, the positioning device 219, and / or one or more of the sensors 213, etc.) may be omitted from the UE 200. The processor 210 may include one or more intelligent hardware devices, such as a central processing unit (CPU), a microcontroller, an application specific integrated circuit (ASIC), etc. The processor 210 may include multiple processors, including a general / application processor 230, a digital signal processor (DSP) 231, a modem processor 232, a video processor 233, and / or a sensor processor 234. One or more of the processors 230-234 may include multiple devices (e.g., multiple processors). For example, the sensor processor 234 may include, for example, a processor for RF (radio frequency) sensing (where one or more (cellular) wireless signals and reflections sent are used to identify, map, and / or track objects), a laser radar, and / or ultrasound, etc. The modem processor 232 may support dual SIM / dual connectivity (or even more SIMs). For example, a SIM (subscriber identity module or subscriber identity module) may be used by an original equipment manufacturer (OEM), and another SIM may be used by a terminal user of the UE 200 to obtain connectivity. The memory 211 is a non-transitory storage medium that may include a random access memory (RAM), a flash memory, an optical disk memory, and / or a read-only memory (ROM), etc. Memory 211 stores software 212, which may be processor-readable, processor-executable software code containing instructions that are configured to cause processor 210 to perform various functions described herein when executed. Alternatively, software 212 may not be directly executable by processor 210, but may be configured to cause processor 210 to perform the functions, for example, when compiled and executed. The description may refer to processor 210 performing the functions, but this includes other implementations, such as implementations in which processor 210 executes software and / or firmware. The description may refer to processor 210 performing the functions as shorthand for one or more of processors 230-234 performing the functions.The description may refer to UE 200 performing a function as shorthand for one or more appropriate components of UE 200 performing the function. Processor 210 may include memory with stored instructions in addition to and / or in lieu of memory 211. The functionality of processor 210 is discussed more fully below.

[0059] Figure 2 The configuration of UE 200 shown in is an example and is not intended to limit the present disclosure (including the claims), and other configurations may be used. For example, an example configuration of the UE includes one or more of the processors 230-234 in the processor 210, a memory 211, and a wireless transceiver 240. Other example configurations include one or more of the processors 230-234 in the processor 210, a memory 211, a wireless transceiver, and one or more of the following: a sensor 213, a user interface 216, an SPS receiver 217, a camera 218, a PD 219, and / or a wired transceiver.

[0060] The UE 200 may include a modem processor 232 capable of performing baseband processing of signals received and down-converted by the transceiver 215 and / or the SPS receiver 217. The modem processor 232 may perform baseband processing of signals to be up-converted for transmission by the transceiver 215. Additionally or alternatively, the baseband processing may be performed by the general / application processor 230 and / or the DSP 231. However, other configurations may be used to perform baseband processing.

[0061] UE 200 may include a sensor 213, which may include, for example, one or more of various types of sensors, such as one or more inertial sensors, one or more magnetometers, one or more environmental sensors, one or more optical sensors, one or more weight sensors, and / or one or more radio frequency (RF) sensors, etc. An inertial measurement unit (IMU) may include, for example, one or more accelerometers (e.g., collectively responsive to acceleration of UE 200 in three dimensions) and / or one or more gyroscopes (e.g., three-dimensional gyroscopes). Sensor 213 may include one or more magnetometers (e.g., three-dimensional magnetometers) to determine orientation (e.g., relative to magnetic north and / or true north), which may be used for any of a variety of purposes (e.g., to support one or more compass applications). Environmental sensors may include, for example, one or more temperature sensors, one or more air pressure sensors, one or more ambient light sensors, one or more camera imagers, and / or one or more microphones, etc. Sensor 213 may generate analog and / or digital signals, indications of which may be stored in memory 211 and processed by DSP 231 and / or general / application processor 230 to support one or more applications (such as, for example, applications involving positioning operations and / or navigation operations).

[0062] The sensor 213 may be used for relative position measurement, relative position determination, motion determination, etc. The information detected by the sensor 213 may be used for motion detection, relative displacement, dead reckoning, sensor-based position determination, and / or sensor-assisted position determination. The sensor 213 may be used to determine whether the UE 200 is fixed (stationary) or moving and / or whether to report certain useful information related to the mobility of the UE 200 to the LMF 120. For example, based on the information obtained / measured by the sensor 213, the UE 200 may notify / report to the LMF 120 that the UE 200 has detected movement or that the UE 200 has moved, and report the relative displacement / distance (e.g., via dead reckoning or sensor-based position determination or sensor-assisted position determination implemented by the sensor 213). In another example, for relative positioning information, the sensor / IMU may be used to determine the angle and / or orientation of another device relative to the UE 200, etc.

[0063] The IMU may be configured to provide measurements of the direction of motion and / or speed of motion of the UE 200, which may be used for relative position determination. For example, one or more accelerometers and / or one or more gyroscopes of the IMU may detect the linear acceleration and rotational speed of the UE 200, respectively. The linear acceleration measurements and rotational speed measurements of the UE 200 may be integrated over time to determine the instantaneous direction of motion and displacement of the UE 200. The instantaneous direction of motion and displacement may be integrated to track the position of the UE 200. For example, the reference position of the UE 200 at a certain moment may be determined, for example, using the SPS receiver 217 (and / or by some other components), and the measurements obtained from the accelerometers and gyroscopes after that moment may be used for dead reckoning to determine the current position of the UE 200 based on the movement (direction and distance) of the UE 200 relative to the reference position.

[0064] The magnetometer may determine the magnetic field strength in different directions, which may be used to determine the orientation of the UE 200. For example, the orientation may be used to provide a digital compass for the UE 200. The magnetometer may include a two-dimensional magnetometer configured to detect magnetic field strength in two orthogonal dimensions and provide an indication of the magnetic field strength. The magnetometer may include a three-dimensional magnetometer configured to detect magnetic field strength in three orthogonal dimensions and provide an indication of the magnetic field strength. The magnetometer may provide a component for sensing a magnetic field and providing an indication of the magnetic field, for example, to the processor 210.

[0065] The transceiver 215 may include a wireless transceiver 240 and a wired transceiver 250 configured to communicate with other devices via wireless connections and wired connections, respectively. For example, the wireless transceiver 240 may include a wireless transmitter 242 and a wireless receiver 244 coupled to an antenna 246 for transmitting (e.g., on one or more uplink channels and / or one or more sidelink channels) and / or receiving (e.g., on one or more downlink channels and / or one or more sidelink channels) wireless signals 248 and converting signals from the wireless signals 248 to wired signals (e.g., electrical signals and / or optical signals) and from wired signals (e.g., electrical signals and / or optical signals) to the wireless signals 248. The wireless transmitter 242 includes appropriate components (e.g., a power amplifier and a digital-to-analog converter). The wireless receiver 244 includes appropriate components (e.g., one or more amplifiers, one or more frequency filters, and an analog-to-digital converter). The wireless transmitter 242 may include multiple transmitters, which may be discrete components or combined / integrated components, and / or the wireless receiver 244 may include multiple receivers, which may be discrete components or combined / integrated components. The wireless transceiver 240 may be configured to communicate signals (e.g., with the TRP and / or one or more other devices) according to various radio access technologies (RATs), such as 5G New Radio (NR), GSM (Global System for Mobile), UMTS (Universal Mobile Telecommunications System), AMPS (Advanced Mobile Phone System), CDMA (Code Division Multiple Access), WCDMA (Wideband CDMA), LTE (Long Term Evolution), LTE Direct (LTE-D), 3GPP LTE-V2X (PC5), IEEE 802.11 (including IEEE802.11p), WiFi, WiFi Direct (WiFi-D), Bluetooth ® , Zigbee, etc. The new radio may use millimeter wave frequencies and / or frequencies below 6 GHz. The wired transceiver 250 may include a wired transmitter 252 and a wired receiver 254 configured for wired communication, for example, a network interface that may be used to communicate with the NG-RAN 135 to transmit communications to the NG-RAN 135 and receive communications from the NG-RAN. The wired transmitter 252 may include a plurality of transmitters that may be discrete components or combined / integrated components, and / or the wired receiver 254 may include a plurality of receivers that may be discrete components or combined / integrated components. The wired transceiver 250 may be configured, for example, for optical communication and / or electrical communication. The transceiver 215 may be communicatively coupled to the transceiver interface 214, for example, via an optical connection and / or an electrical connection. The transceiver interface 214 may be at least partially integrated with the transceiver 215. Wireless transmitter 242, wireless receiver 244 and / or antenna 246 may include multiple transmitters, multiple receivers and / or multiple antennas, respectively, for transmitting and / or receiving appropriate signals, respectively.

[0066] The user interface 216 may include one or more devices such as, for example, a speaker, a microphone, a display device, a vibration device, a keyboard, a touch screen, etc. The user interface 216 may include any device more than one of these devices. The user interface 216 may be configured to enable a user to interact with one or more applications hosted by the UE 200. For example, the user interface 216 may store an indication of an analog signal and / or a digital signal in the memory 211 in response to an action from the user to be processed by the DSP 231 and / or the general / application processor 230. Similarly, an application hosted on the UE 200 may store an indication of an analog signal and / or a digital signal in the memory 211 to present an output signal to the user. The user interface 216 may include an audio input / output (I / O) device including, for example, a speaker, a microphone, a digital-to-analog circuit, an analog-to-digital circuit, an amplifier, and / or a gain control circuit (including any device more than one of these devices). Other configurations of audio I / O devices may be used. Additionally or alternatively, the user interface 216 may include one or more touch sensors that respond to touch and / or pressure on, for example, a keyboard and / or a touch screen of the user interface 216 .

[0067] The SPS receiver 217 (e.g., a global positioning system (GPS) receiver) can receive and acquire the SPS signal 260 via the SPS antenna 262. The SPS antenna 262 is configured to convert the SPS signal 260 from a wireless signal to a wired signal (e.g., an electrical signal or an optical signal) and can be integrated with the antenna 246. The SPS receiver 217 can be configured to process the acquired SPS signal 260 in whole or in part to estimate the position of the UE 200. For example, the SPS receiver 217 can be configured to determine the position of the UE 200 by performing trilateration using the SPS signal 260. The general / application processor 230, the memory 211, the DSP 231, and / or one or more dedicated processors (not shown) can be utilized in conjunction with the SPS receiver 217 to process the acquired SPS signal in whole or in part and / or calculate the estimated position of the UE 200. The memory 211 may store indications (e.g., measurements) of the SPS signals 260 and / or other signals (e.g., signals obtained from the wireless transceiver 240) for use in performing positioning operations. The general / application processor 230, the DSP 231, and / or one or more dedicated processors and / or the memory 211 may provide or support a location engine for processing measurements to estimate the location of the UE 200.

[0068] UE 200 may include a camera 218 for capturing still or moving images. Camera 218 may include, for example, an imaging sensor (e.g., a charge coupled device or a CMOS (complementary metal oxide semiconductor) imager), a lens, analog-to-digital circuits, a frame buffer, etc. Additional processing, conditioning, encoding, and / or compression of signals representing captured images may be performed by general / application processor 230 and / or DSP 231. Additionally or alternatively, video processor 233 may perform conditioning, encoding, compression, and / or manipulation of signals representing captured images. Video processor 233 may decode / decompress stored image data for presentation on a display device (not shown) (e.g., of user interface 216).

[0069] The positioning device (PD) 219 may be configured to determine the location of the UE 200, the movement of the UE 200, and / or the relative location of the UE 200, and / or the time. For example, the PD 219 may communicate with the SPS receiver 217 and / or include some or all of the SPS receivers. The PD 219 may work appropriately with the processor 210 and the memory 211 to perform at least a portion of one or more positioning methods, but the description herein may refer to the PD 219 being configured to perform according to the positioning method or the PD performing according to the positioning method. The PD 219 may be additionally or alternatively configured to: use ground-based signals (e.g., at least some wireless signals 248) for trilateration, assist in obtaining and use SPS signals 260, or both to determine the location of the UE 200. The PD 219 may be configured to determine the location of the UE 200 based on the cell of the serving base station (e.g., cell center) and / or another technology (such as E-CID). The PD 219 may be configured to determine the location of the UE 200 using one or more images from the camera 218 and image recognition combined with known locations of landmarks (e.g., natural landmarks (such as mountains) and / or artificial landmarks (such as buildings, bridges, streets), etc.). The PD 219 may be configured to determine the location of the UE 200 using one or more other techniques (e.g., relying on the UE's self-reported location (e.g., part of the UE's location beacon)), and may use a combination of techniques (e.g., SPS and ground positioning signals) to determine the location of the UE 200. The PD 219 may include one or more sensors (e.g., gyroscopes, accelerometers, magnetometers, etc.) in the sensor 213, which may sense the orientation and / or movement of the UE 200 and provide an indication of the orientation and / or movement, and the processor 210 (e.g., the general / application processor 230 and / or the DSP 231) may be configured to use the indication to determine the movement of the UE 200 (e.g., velocity vector and / or acceleration vector). PD 219 may be configured to provide an indication of uncertainty and / or error in the determined position and / or motion. The functionality of PD 219 may be provided in a variety of ways and / or configurations, such as by general / application processor 230, transceiver 215, SPS receiver 217, and / or another component of UE 200, and may be provided by hardware, software, firmware, or various combinations thereof.

[0070] Also refer to Figure 3, an example of a TRP 300 for a gNB 110a, 110b, and / or ng-eNB 114 includes a computing platform including a processor 310, a memory 311 including software (SW) 312, and a transceiver 315. The processor 310, the memory 311, and the transceiver 315 may be communicatively coupled to one another via a bus 320 (which may be configured, for example, for optical communication and / or electrical communication). One or more of the illustrated devices (e.g., a wireless transceiver) may be omitted from the TRP 300. The processor 310 may include one or more intelligent hardware devices, such as a central processing unit (CPU), a microcontroller, an application specific integrated circuit (ASIC), etc. The processor 310 may include a plurality of processors (e.g., including a general / application processor, a DSP, a modem processor, a video processor, and / or a sensor processor, such as Figure 2 ). The memory 311 is a non-transitory storage medium that may include random access memory (RAM), flash memory, optical disk memory, and / or read-only memory (ROM), etc. The memory 311 stores software 312, which may be a processor-readable, processor-executable software code containing instructions that are configured to cause the processor 310 to perform various functions described herein when executed. Alternatively, the software 312 may not be directly executable by the processor 310, but may be configured to cause the processor 310 to perform the function, for example, when compiled and executed.

[0071] The description may refer to processor 310 performing a function, but this includes other specific implementations, such as a specific implementation in which processor 310 executes software and / or firmware. The description may refer to processor 310 performing a function as shorthand for one or more of the processors included in processor 310 performing the function. The description may refer to TRP 300 performing a function as shorthand for one or more appropriate components (e.g., processor 310 and memory 311) of TRP 300 (and therefore one of gNB 110a, 110b and / or ng-eNB 114) performing the function. Processor 310 may include a memory with stored instructions in addition to and / or in lieu of memory 311. The functionality of processor 310 is discussed more fully below.

[0072] The transceiver 315 may include a wireless transceiver 340 and / or a wired transceiver 350 configured to communicate with other devices via wireless connections and wired connections, respectively. For example, the wireless transceiver 340 may include a wireless transmitter 342 and a wireless receiver 344 coupled to one or more antennas 346 for transmitting (e.g., on one or more uplink channels and / or one or more downlink channels) and / or receiving (e.g., on one or more downlink channels and / or one or more uplink channels) wireless signals 348 and converting signals from the wireless signals 348 to wired signals (e.g., electrical signals and / or optical signals) and from wired signals (e.g., electrical signals and / or optical signals) to the wireless signals 348. Thus, the wireless transmitter 342 may include multiple transmitters that may be discrete components or combined / integrated components, and / or the wireless receiver 344 may include multiple receivers that may be discrete components or combined / integrated components. The wireless transceiver 340 may be configured to communicate in accordance with a plurality of radio access technologies (RATs) such as 5G New Radio (NR), GSM (Global System for Mobile Communications), UMTS (Universal Mobile Telecommunications System), AMPS (Advanced Mobile Phone System), CDMA (Code Division Multiple Access), WCDMA (Wideband CDMA), LTE (Long Term Evolution), LTE Direct (LTE-D), 3GPP LTE-V2X (PC5), IEEE 802.11 (including IEEE 802.11p), WiFi, WiFi Direct (WiFi-D), Bluetooth ® , Zigbee, etc.) to communicate signals (e.g., with UE 200, one or more other UEs, and / or one or more other devices). The wired transceiver 350 may include a wired transmitter 352 and a wired receiver 354 configured for wired communication, for example, a network interface that can be used to communicate with the NG-RAN 135 to transmit communications to, for example, the LMF 120 and / or one or more other network entities and receive communications therefrom. The wired transmitter 352 may include multiple transmitters that may be discrete components or combined / integrated components, and / or the wired receiver 354 may include multiple receivers that may be discrete components or combined / integrated components. The wired transceiver 350 may be configured, for example, for optical communication and / or electrical communication.

[0073] Figure 3The configuration of the TRP 300 shown in is an example and is not intended to limit the present disclosure (including the claims), and other configurations may be used. For example, the description herein discusses that the TRP 300 is configured to perform several functions or that the TRP performs several functions, but one or more of these functions may be performed by the LMF 120 and / or the UE 200 (i.e., the LMF 120 and / or the UE 200 may be configured to perform one or more of these functions). In one example, the RSU may include some or all of the components of the TRP 300.

[0074] Also refer to Figure 4 , the server 400 (LMF 120 is an example of the server) includes a computing platform including a processor 410, a memory 411 including software (SW) 412, and a transceiver 415. The processor 410, the memory 411, and the transceiver 415 may be communicatively coupled to each other via a bus 420 (the bus may be configured, for example, for optical communication and / or electrical communication). One or more of the devices shown (e.g., a wireless transceiver) may be omitted from the server 400. The processor 410 may include one or more intelligent hardware devices, such as a central processing unit (CPU), a microcontroller, an application specific integrated circuit (ASIC), etc. The processor 410 may include a plurality of processors (e.g., including a general / application processor, a DSP, a modem processor, a video processor, and / or a sensor processor, such as Figure 2 ). Memory 411 is a non-transitory storage medium that may include random access memory (RAM), flash memory, optical disk memory, and / or read-only memory (ROM), etc. Memory 411 stores software 412, which may be a processor-readable, processor-executable software code containing instructions that are configured to cause processor 410 to perform various functions described herein when executed. Alternatively, software 412 may not be directly executable by processor 410, but may be configured to cause processor 410 to perform the function, for example, when compiled and executed. The description may refer to processor 410 performing a function, but this includes other specific implementations, such as specific implementations in which processor 410 executes software and / or firmware. The description may refer to processor 410 performing a function as a shorthand for one or more of the processors included in processor 410 performing the function. The description may refer to server 400 performing a function as a shorthand for one or more appropriate components of server 400 performing the function. Processor 410 may include a memory with stored instructions as a supplement and / or alternative to memory 411. The functionality of processor 410 is discussed more fully below.

[0075] The transceiver 415 may include a wireless transceiver 440 and / or a wired transceiver 450 configured to communicate with other devices via wireless connections and wired connections, respectively. For example, the wireless transceiver 440 may include a wireless transmitter 442 and a wireless receiver 444 coupled to one or more antennas 446 for transmitting (e.g., on one or more downlink channels) and / or receiving (e.g., on one or more uplink channels) wireless signals 448 and converting signals from the wireless signals 448 to wired signals (e.g., electrical signals and / or optical signals) and from wired signals (e.g., electrical signals and / or optical signals) to the wireless signals 448. Thus, the wireless transmitter 442 may include multiple transmitters that may be discrete components or combined / integrated components, and / or the wireless receiver 444 may include multiple receivers that may be discrete components or combined / integrated components. The wireless transceiver 440 may be configured to operate in accordance with a plurality of radio access technologies (RATs) such as 5G New Radio (NR), GSM (Global System for Mobile Communications), UMTS (Universal Mobile Telecommunications System), AMPS (Advanced Mobile Phone System), CDMA (Code Division Multiple Access), WCDMA (Wideband CDMA), LTE (Long Term Evolution), LTE Direct (LTE-D), 3GPP LTE-V2X (PC5), IEEE 802.11 (including IEEE 802.11p), WiFi, WiFi Direct (WiFi-D), Bluetooth ® , Zigbee, etc.) to communicate signals (e.g., with UE 200, one or more other UEs, and / or one or more other devices). The wired transceiver 450 may include a wired transmitter 452 and a wired receiver 454 configured for wired communication, for example, a network interface that can be used to communicate with the NG-RAN 135 to transmit communications to, for example, the TRP 300 and / or one or more other network entities and receive communications therefrom. The wired transmitter 452 may include multiple transmitters that may be discrete components or combined / integrated components, and / or the wired receiver 454 may include multiple receivers that may be discrete components or combined / integrated components. The wired transceiver 450 may be configured, for example, for optical communication and / or electrical communication.

[0076] The description herein may refer to processor 410 performing a function, but this includes other implementations, such as implementations in which processor 410 executes software (stored in memory 411) and / or firmware. The description herein may refer to server 400 performing a function as shorthand for one or more appropriate components of server 400 (e.g., processor 410 and memory 411) performing that function.

[0077] Figure 4The configuration of the server 400 shown in is an example and is not intended to limit the present disclosure (including the claims), and other configurations may be used. For example, the wireless transceiver 440 may be omitted. Additionally or alternatively, the description herein discusses that the server 400 is configured to perform several functions or that the server performs several functions, but one or more of these functions may be performed by the TRP 300 and / or the UE 200 (i.e., the TRP 300 and / or the UE 200 may be configured to perform one or more of these functions).

[0078] For terrestrial positioning of UEs in cellular networks, techniques such as Advanced Forward Link Trilateration (AFLT) and Observed Time Difference of Arrival (OTDOA) typically operate in a "UE-assisted" mode, where measurements of reference signals (e.g., PRS, CRS, etc.) transmitted by base stations are acquired by the UE and then provided to a location server. The location server then calculates the position of the UE based on the measurements and the known positions of the base stations. Since these techniques use a location server (rather than the UE itself) to calculate the position of the UE, these positioning techniques are not frequently used in applications such as automotive or cell phone navigation, which instead typically rely on satellite-based positioning.

[0079] UEs can use a satellite positioning system (SPS) (Global Navigation Satellite System (GNSS)) to use Precise Point Positioning (PPP) or Real-Time Kinematics (RTK) techniques for high accuracy positioning. These techniques use assistance data, such as measurements from ground-based stations. LTE Release 15 allows the data to be encrypted so that only UEs subscribed to the service can read the information. Such assistance data changes over time. As a result, a UE subscribed to the service may not be able to easily "crack the encryption" for other UEs by passing the data to other UEs that have not paid for the subscription. This transfer needs to be repeated each time the assistance data changes.

[0080] In UE-assisted positioning, the UE transmits measurements (e.g., TDOA, Angle of Arrival (AoA), etc.) to a positioning server (e.g., LMF / eSMLC). The positioning server has a base station almanac (BSA) that contains multiple "entries" or "records", one record per cell, where each record contains a geographic cell location, but may also include other data. An identifier of a "record" among multiple "records" in the BSA may be referenced. The BSA and the measurements from the UE may be used to calculate the positioning of the UE.

[0081] In conventional UE-based positioning, the UE calculates its own position, avoiding the transmission of measurements to the network (e.g., a location server), which in turn improves latency and scalability. The UE uses the relevant BSA record information from the network (e.g., the location of the gNB (more broadly, the base station)). The BSA information can be encrypted. However, since the BSA information changes much less frequently than, for example, the PPP or RTK assistance data described previously, it may be easier (compared to PPP or RTK information) to make the BSA information available to UEs that are not subscribed and have not paid for decryption keys. The transmission of reference signals by the gNB makes the BSA information potentially accessible to crowdsourcing or driving attacks, essentially enabling the BSA information to be generated based on in-the-field observations and / or over-the-top observations.

[0082] Positioning techniques may be characterized and / or evaluated based on one or more criteria, such as positioning determination accuracy and / or latency. Latency is the time elapsed between an event that triggers the determination of positioning-related data and the availability of the data at a positioning system interface (e.g., an interface of LMF 120). At the time of initialization of the positioning system, the latency for the availability of positioning-related data is called the time to first fix (TTFF) and is greater than the latency after the TTFF. The inverse of the time elapsed between two consecutive positioning-related data availabilities is called the update rate, i.e., the rate at which positioning-related data is generated after the first fix. Latency may depend on (e.g., UE's) processing capabilities. For example, assuming a 272 PRB (physical resource block) allocation, a UE may report the processing capability of the UE as the duration (in time units (e.g., milliseconds) of a DL PRS symbol that the UE can process per T amount of time (e.g., Tms). Other examples of capabilities that may affect latency are the number of TRPs from which the UE can process PRSs, the number of PRSs that the UE can process, and the bandwidth of the UE.

[0083] One or more of many different positioning techniques (also referred to as positioning methods) may be used to determine the location of an entity (such as one of the UEs 105, 106). For example, known positioning determination techniques include RTT, multi-RTT, OTDOA (also referred to as TDOA and including UL-TDOA and DL-TDOA), enhanced cell identification (E-CID), DL-AoD, UL-AoA, etc. RTT uses the time it takes for a signal to travel from one entity to another and back to determine the distance between the two entities. This distance plus the known position of the first of the entities and the angle (e.g., azimuth) between the two entities may be used to determine the position of the second of the entities. In multi-RTT (also referred to as multi-cell RTT), multiple distances from one entity (e.g., UE) to other entities (e.g., TRP) and the known positions of the other entities may be used to determine the position of the one entity. In TDOA techniques, the travel time difference between one entity and the other entities may be used to determine the relative distance to the other entities, and the relative distance combined with the known positions of the other entities may be used to determine the position of the one entity. The angle of arrival and / or angle of departure can be used to help determine the location of an entity. For example, the angle of arrival or angle of departure of a signal combined with the distance between devices (the distance determined using the signal (e.g., the travel time of the signal, the received power of the signal, etc.)) and the known position of one of the devices can be used to determine the location of the other device. The angle of arrival or angle of departure can be an azimuth relative to a reference direction (such as true north). The angle of arrival or angle of departure can be a zenith angle relative to directly upward from the entity (i.e., relative to radially outward from the center of the earth). E-CID uses the identity of the serving cell, the timing advance (i.e., the difference between the reception time and the transmission time at the UE), the estimated timing and power of the detected neighbor cell signals, and possible angles of arrival (e.g., the angle of arrival of the signal from the base station at the UE, or vice versa) to determine the location of the UE. In TDOA, the difference in the arrival time of signals from different sources at the receiving device together with the known positions of these sources and the known offsets of the transmission times from these sources are used to determine the location of the receiving device.

[0084] In network-centric RTT estimation, the serving base station commands the UE to scan / receive RTT measurement signals (e.g., PRS) on the serving cells of two or more neighboring base stations (and typically the serving base station, since at least three base stations are required). The one or more base stations send the RTT measurement signals on low reuse resources (e.g., resources used by the base station to send system information) allocated by the network (e.g., a location server, such as LMF 120). The UE records the arrival time (also known as reception time, received time, received time, or arrival time (ToA)) of each RTT measurement signal relative to the current downlink timing of the UE (e.g., as derived by the UE from the DL signal received from its serving base station), and (e.g., when instructed by its serving base station) sends a common or individual RTT response message (e.g., an SRS (sounding reference signal) for positioning, i.e., UL-PRS) to the one or more base stations, and may calculate the time difference between the ToA of the RTT measurement signal and the transmission time of the RTT response message. (i.e., UE T Rx-Tx or UE Rx-Tx ) is included in the payload of each RTT response message. The RTT response message will include a reference signal from which the base station can infer the ToA of the RTT response. By comparing the difference between the transmission time of the RTT measurement signal from the base station and the ToA of the RTT response at the base station Time difference with UE report , the base station can infer the propagation time between the base station and the UE, from which the base station can determine the distance between the UE and the base station by assuming the speed of light during the propagation time.

[0085] UE-centric RTT estimation is similar to the network-based approach, except that the UE sends an uplink RTT measurement signal (e.g., when commanded by a serving base station), which is received by multiple base stations in the vicinity of the UE. Each base station involved responds with a downlink RTT response message, which may include in the RTT response message payload the time difference between the ToA of the RTT measurement signal at the base station and the transmission time of the RTT response message from the base station.

[0086] For both the network-centric process and the UE-centric process, the side performing the RTT calculation (the network or the UE) typically (but not always) sends a first message or signal (e.g., an RTT measurement signal), and the other side responds with one or more RTT response messages or signals, which may include the difference between the ToA of the first message or signal and the sending time of the RTT response message or signal.

[0087] Multi-RTT techniques may be used to determine positioning. For example, a first entity (e.g., a UE) may transmit one or more signals (e.g., unicast, multicast, or broadcast from a base station), and a plurality of second entities (e.g., other TSPs, such as base stations and / or UEs) may receive signals from the first entity and respond to the received signals. The first entity receives responses from the plurality of second entities. The first entity (or another entity, such as an LMF) may use the responses from the second entity to determine the distance to the second entity, and may use the plurality of distances and the known positions of the second entity to determine the position of the first entity by trilateration.

[0088] In some instances, additional information may be obtained in the form of an angle of arrival (AoA) or angle of departure (AoD) that defines a straight line direction (e.g., which may be in the horizontal plane or in three dimensions) or a range of possible directions (e.g., of the UE as seen from the location of a base station). The intersection of the two directions may provide another estimate of the UE's position.

[0089] For positioning techniques (e.g., TDOA and RTT) that use PRS (positioning reference signal) signals, PRS signals transmitted by multiple TRPs are measured and the arrival times of these signals, the known transmission times, and the known locations of the TRPs are used to determine the distance from the UE to the TRPs. For example, RSTD (reference signal time difference) can be determined for PRS signals received from multiple TRPs and used in TDOA techniques to determine the location (position) of the UE. Positioning reference signals may be referred to as PRS or PRS signals. PRS signals are typically transmitted using the same power, and PRS signals with the same signal characteristics (e.g., the same frequency shift) may interfere with each other, so that PRS signals from farther TRPs may be drowned out by PRS signals from closer TRPs, so that signals from farther TRPs may not be detected. PRS muting can be used to help reduce interference by muting some PRS signals (reducing the power of the PRS signal, for example, to zero and thereby not sending the PRS signal). In this way, the UE can more easily detect (at the UE) a weaker PRS signal without a stronger PRS signal interfering with the weaker PRS signal. The term RS and its variants (eg, PRS, SRS, CSI-RS (Channel State Information - Reference Signal)) may refer to one reference signal or more than one reference signal.

[0090] Positioning Reference Signals (PRS) include downlink PRS (DL PRS, often referred to as PRS for short) and uplink PRS (UL PRS) (the uplink PRS may be referred to as SRS (sounding reference signal) for positioning). PRS may include a PN code (pseudo-random number) or be generated using a PN code (e.g., by modulating a carrier signal with a PN code) so that the source of the PRS can be used as a pseudo-satellite. The PN code may be unique to the PRS source (at least unique within a specified area so that the same PRS from different PRS sources do not overlap). PRS may include PRS resources and / or PRS resource sets of a frequency layer. A DL PRS positioning frequency layer (or simply a frequency layer) is a collection of DL PRS resource sets from one or more TRPs, where the PRS resources have common parameters configured by higher layer parameters DL-PRS-PositioningFrequencyLayer, DL-PRS-ResourceSet, and DL-PRS-Resource. Each frequency layer has a DL PRS subcarrier spacing (SCS) for a DL PRS resource set and DL PRS resource in that frequency layer. Each frequency layer has a DL PRS cyclic prefix (CP) for the DL PRS resource sets and DL PRS resources in that frequency layer. In 5G, a resource block occupies 12 consecutive subcarriers and a specified number of symbols. A common resource block is a set of resource blocks that occupy a channel bandwidth. A bandwidth part (BWP) is a set of consecutive common resource blocks and may include all common resource blocks within the channel bandwidth or a subset of the common resource blocks. In addition, the DL PRS point A parameter defines the frequency of the reference resource block (and the lowest subcarrier of the resource block), where DL PRS resources belonging to the same DL PRS resource set have the same point A, and all DL PRS resource sets belonging to the same frequency layer have the same point A. Frequency layers also have the same DL PRS bandwidth, the same starting PRB (and center frequency), and the same comb size value (i.e., the frequency of PRS resource elements per symbol, so that for comb-N, every Nth resource element is a PRS resource element). A PRS resource set is identified by a PRS resource set ID and can be associated with a specific TRP (identified by a cell ID) transmitted by the antenna panel of the base station. The PRS resource ID in a PRS resource set may be associated with an omni-directional signal and / or associated with a single beam (and / or beam ID) transmitted from a single base station (where a base station may transmit one or more beams). Each PRS resource in a PRS resource set may be transmitted on a different beam, and as such, the PRS resources (or simply resources) may also be referred to as beams. This does not imply anything about whether the base station and beam on which the PRS is transmitted are known to the UE.

[0091] The TRP may be configured, for example, by instructions received from a server and / or by software in the TRP to transmit DL PRS on a schedule. According to the schedule, the TRP may transmit DL PRS intermittently (e.g., periodically at consistent intervals from the initial transmission). The TRP may be configured to transmit one or more PRS resource sets. A resource set is a collection of PRS resources across a TRP, where the resources have the same periodicity, a common muting mode configuration (if any), and the same cross-slot repetition factor. Each PRS resource set in a PRS resource set includes a plurality of PRS resources, where each PRS resource includes a plurality of OFDM (orthogonal frequency division multiplexing) resource elements (REs), which may be in a plurality of resource blocks (RBs) within N (one or more) consecutive symbols within a slot. PRS resources (or, in general, reference signal (RS) resources) may be referred to as OFDM PRS resources (or OFDMRS resources). RBs are RE sets that span a certain number of one or more consecutive symbols in the time domain and a certain number (12 for 5G RBs) of consecutive subcarriers in the frequency domain. Each PRS resource is configured with an RE offset, a slot offset, a symbol offset within a slot, and the number of consecutive symbols that the PRS resource can occupy within a slot. The RE offset defines the starting RE offset in frequency for the first symbol within the DL PRS resource. The relative RE offsets of the remaining symbols within the DL PRS resource are defined based on the initial offset. The slot offset is the starting slot of the DL PRS resource relative to the corresponding resource set slot offset. The symbol offset determines the starting symbol of the DL PRS resource within the starting slot. The transmitted REs may be repeated across slots, where each transmission is called a repetition, so that there may be multiple repetitions in a PRS resource. The DL PRS resources in a DL PRS resource set are associated with the same TRP, and each DL PRS resource has a DL PRS resource ID. The DL PRS resource ID in a DL PRS resource set is associated with a single beam transmitted from a single TRP (although a TRP may transmit one or more beams).

[0092] PRS resources may also be defined by quasi co-location parameters and starting PRB parameters. The quasi co-location (QCL) parameter may define any quasi co-location information of the DLPRS resources with other reference signals. The DL PRS may be configured as QCL type D with a DL PRS or SS / PBCH (synchronization signal / physical broadcast channel) block from a serving cell or a non-serving cell. The DL PRS may be configured as QCL type C with an SS / PBCH block from a serving cell or a non-serving cell. The starting PRB parameter defines the starting PRB index of the DLPRS resource with respect to reference point A. The starting PRB index has a granularity of one PRB and may have a minimum value of 0 PRBs and a maximum value of 2176 PRBs.

[0093] A PRS resource set is a collection of PRS resources with the same periodicity, the same muting pattern configuration (if any), and the same repetition factor across time slots. Each time all repetitions of all PRS resources in a PRS resource set are configured to be transmitted is referred to as an "instance". Thus, an "instance" of a PRS resource set is a specified number of repetitions for each PRS resource and a specified number of PRS resources within a PRS resource set, such that once the specified number of repetitions is transmitted for each of the specified number of PRS resources, the instance is complete. An instance may also be referred to as an "opportunity". A DL PRS configuration including a DL PRS transmission schedule may be provided to a UE to facilitate (or even cause) the UE to measure a DL PRS.

[0094] Multiple frequency layers of PRS can be aggregated to provide an effective bandwidth greater than any bandwidth in the bandwidth of each layer. Multiple frequency layers belonging to component carriers (which can be continuous and / or separate) and satisfying criteria such as quasi-co-location (QCL) and having the same antenna port can be spliced ​​to provide a larger effective PRS bandwidth (for DL ​​PRS and UL PRS), thereby improving the accuracy of arrival time measurement. Splicing includes combining PRS measurements on various bandwidth segments into a unified fragment so that the spliced ​​PRS can be regarded as taken from a single measurement. In the case of QCL, different frequency layers behave similarly, so that the splicing of PRS produces a larger effective bandwidth. The larger effective bandwidth (which can be referred to as the bandwidth of the aggregated PRS or the frequency bandwidth of the aggregated PRS) provides better time domain resolution (e.g., the resolution of TDOA). The aggregated PRS includes a collection of PRS resources, and each PRS resource in the aggregated PRS can be referred to as a PRS component, and each PRS component can be sent on different component carriers, frequency bands or frequency layers, or on different parts of the same frequency band.

[0095] RTT positioning is an active positioning technique because RTT uses positioning signals transmitted by the TRP to the UE and by the UE (participating in RTT positioning) to the TRP. The TRP can transmit a DL-PRS signal received by the UE, and the UE can transmit an SRS (sounding reference signal) signal received by multiple TRPs. The sounding reference signal may be referred to as an SRS or an SRS signal. In 5G multi-RTT, coordinated positioning may be used in which the UE transmits a single UL-SRS for positioning received by multiple TRPs, rather than transmitting a separate UL-SRS for positioning for each TRP. A TRP participating in multi-RTT will typically search for UEs currently residing on the TRP (served UEs, where the TRP is the serving TRP) and also search for UEs residing on adjacent TRPs (neighbor UEs). A neighbor TRP may be a TRP of a single BTS (base transceiver station) (e.g., a gNB), or may be a TRP of one BTS and a TRP of a separate BTS. For RTT positioning (including multi-RTT positioning), the DL-PRS signal and the UL-SRS positioning signal in a PRS / SRS positioning signal pair used to determine the RTT (and thereby used to determine the distance between the UE and the TRP) may occur close to each other in time so that errors due to UE motion and / or UE clock drift and / or TRP clock drift are within acceptable limits. For example, the signals in the PRS / SRS positioning signal pair may be sent from the TRP and the UE, respectively, within approximately 10 ms of each other. In the case where the SRS for positioning is being transmitted by the UE and the PRS and the SRS for positioning are transmitted close to each other in time, it has been found that radio frequency (RF) signal congestion (which may result in excessive noise, etc.) may result (especially if many UEs are attempting to locate concurrently) and / or computational congestion may result at the TRP where many UEs are attempting to measure concurrently.

[0096] RTT positioning can be UE-based or UE-assisted. In UE-based RTT, the UE 200 determines the RTT and corresponding distance to each TRP in the TRP 300, and determines the positioning of the UE 200 based on the distance to the TRP 300 and the known position of the TRP 300. In UE-assisted RTT, the UE 200 measures the positioning signal and provides the measurement information to the TRP 300, and the TRP 300 determines the RTT and the distance. The TRP 300 provides the distance to a location server (e.g., server 400), and the server determines the position of the UE 200, for example, based on the distance to different TRPs 300. The RTT and / or distance may be determined by the TRP 300 receiving the signal from the UE 200, by the TRP 300 in combination with one or more other devices (e.g., one or more other TRPs 300 and / or server 400), or by one or more devices other than the TRP 300 that receive the signal from the UE 200.

[0097] Various positioning technologies are supported in 5G NR. The NR native positioning methods supported in 5G NR include DL-only positioning methods, UL-only positioning methods, and DL+UL positioning methods. Downlink-based positioning methods include DL-TDOA and DL-AoD. Uplink-based positioning methods include UL-TDOA and UL-AoA. Combined DL+UL-based positioning methods include RTT with one base station and RTT with multiple base stations (multi-RTT).

[0098] A positioning estimate (e.g., for a UE) may be referred to by other names, such as position estimate, position, fix, position fix, fix, etc. The positioning estimate may be geodetic and include coordinates (e.g., latitude, longitude, and possibly altitude), or may be municipal and include a street address, postal address, or some other textual description of the location. The positioning estimate may be further defined relative to some other known location or in absolute terms (e.g., using latitude, longitude, and possibly altitude). The positioning estimate may include an expected error or uncertainty (e.g., by including an area or volume within which the location is expected to be contained with some specified or default confidence level).

[0099] refer to Figure 5, shows a system diagram illustrating various entities configured to utilize a V2X communication link. Generally speaking, V2X communication involves the transfer of information between a vehicle and any other entity that may affect the vehicle or may be affected by the vehicle. A vehicle may include an OBU, which may have some or all of the components of UE 200, and UE 200 is an example of an OBU. The OBU may be configured to communicate with other entities such as infrastructure (e.g., brake lights), pedestrians, other vehicles, and other wireless nodes. In one example, V2X may cover other more specific types of communications, such as vehicle to infrastructure (V2I), vehicle to vehicle (V2V), vehicle to pedestrian (V2P), vehicle to device (V2D), and vehicle to grid (V2G).

[0100] Vehicle-to-vehicle (V2V) is a communication model designed to allow vehicles or cars to "talk" to each other, typically by having the cars form a wireless ad hoc network on the road. Vehicle-to-infrastructure (V2I) is a communication model that allows vehicles to share information with components that support the road or highway system, such as overhead radio frequency identification (RFID) readers and cameras, traffic lights, lane markings, street lights, signs, and parking meters. Similar to V2V communication, V2I communication is typically wireless and bidirectional: data from infrastructure components can be delivered to vehicles through the ad hoc network, and vice versa. Vehicle-to-pedestrian (V2P) communication involves the ability of vehicles or cars to communicate with or identify a wide range of road users, including people walking, children being pushed in strollers, people using wheelchairs or other motorized devices, passengers getting on and off buses and trains, and cyclists. Vehicle-to-device (V2D) communication consists in the exchange of information between a vehicle and any electronic device that can be connected to the vehicle itself. Vehicle-to-grid (V2G) communication can include vehicles communicating with the power grid.

[0101] These more specific types of communications are useful for implementing various functions. For example, vehicle-to-vehicle (V2V) is particularly useful for collision avoidance safety systems, while vehicle-to-pedestrian (V2P) is useful for issuing safety warnings to pedestrians and cyclists. Vehicle-to-infrastructure (V2I) is useful for optimizing traffic light control and issuing speed advisories, while vehicle-to-network (V2N) is useful for providing real-time traffic updates / route planning and cloud services.

[0102] As referred to herein, V2X communications may include any of these more specific types of communications, as well as any communication between a vehicle and another entity that does not fall within one of these existing communication standards. Thus, V2X is a fairly broad vehicle communication system.

[0103] V2X communication can be based on Institute of Electrical and Electronics Engineers (IEEE) 802.11 wireless local area network (WLAN) technology, LTE / 5G NR PC5 and / or Uu interface, where vehicles and entities (e.g., V2X transmitters) communicate through an ad hoc network formed when two V2X transmitters come into range of each other. It also exists in cellular-based solutions, such as 5G NR-based V2X, which can leverage this technology to provide secure communications, precise positioning, and efficient processing. For example, C-V2X can Figure 1 The communication system 100 described in the specification is used for a V2X communication link.

[0104] One benefit of V2X communication is safety. For example, V2X communication can enable a vehicle to communicate with its surroundings so that the vehicle can improve driver awareness and provide driving assistance to the driver. For example, the vehicle can be aware of other moving vehicles and pedestrians on the road. The vehicle can then communicate their location to the driver, who may not be aware. If an accident is avoided in this way, the safety of other vehicles and pedestrians on the road is improved. This is just one use case of V2X for improving safety. Other examples of V2X use cases related to safety include forward collision warning, lane change warning / blind spot warning, emergency electric brake light warning, intersection movement assistance, emergency vehicle approaching, road work warning, and platooning.

[0105] The V2X communication standard is also intended to develop advanced driver assistance systems (ADAS), which help drivers make critical decisions in lane changes, speed changes, overtaking speeds, etc. ADAS can assist in driving under challenging conditions, such as bad weather, low lighting, low visibility, etc. ADAS can also be used for non-line-of-sight sensing, overtaking (e.g., passing other vehicles on the road), cooperative driving, and Do Not Overtake (DNP) warnings.

[0106] The V2X communication standard can also provide assistance in different modes. The first V2X mode can be used to improve driver awareness. For example, a vehicle can use its knowledge of the location of various other vehicles on the road to provide the driver with a bird's-eye view of an intersection, or provide the driver with perspective capabilities when driving behind a truck (for example, the vehicle will visually display to the driver other vehicles on the other side of the truck that are obscured by the truck). The second V2X mode can be configured to provide cooperative driving and collision avoidance. For example, V2X can be used for platooning to tightly group vehicles on the road by enabling those vehicles to communicate and accelerate / brake simultaneously. V2X can also be used to regulate vehicle speed or overtaking negotiations, where a vehicle can signal its intention to overtake other vehicles in order to protect overtaking situations. Vehicles configured for autonomous driving can use the third V2X mode.

[0107] In one example, vehicle 500 may be able to communicate with infrastructure 502 (e.g., a traffic light) using vehicle-to-infrastructure (V2I) communications. In some embodiments, vehicle 500 may be able to communicate with other vehicles on the road (such as vehicle 504) via vehicle-to-vehicle (V2V) communications. Vehicle 500 may be able to communicate with cellular station 506 via a cellular protocol such as a Uu interface. Cell station 506 may be a base station such as gNB 110a and may include some or all of the components of TRP 300. In one example, vehicle 500 may be able to communicate with device 508 via vehicle-to-device (V2D) communications. In some such embodiments, device 508 may be any electronic device that can be connected to the vehicle itself. For example, device 508 may be a third-party or in-vehicle GPS navigation device that vehicle 500 may communicate with to obtain information available to device 508. If the GPS navigation device has information about congested routes, traffic density, the location of other vehicles on the road with similar devices, etc., then vehicle 500 may be able to obtain all of this information. In one example, device 508 may include a user interface display, audio, and / or haptic components configured to provide an alert to a user.

[0108] In one example, vehicle 500 may be able to detect UEs or other wireless devices carried by pedestrians 510 via vehicle-to-pedestrian (V2P) technology. For example, vehicle 500 may have a detection method, such as a camera or sensor that allows vehicle 500 to detect and confirm the presence of pedestrians 510 on the road. Pedestrians 510 may include a wide range of people, including people walking, children being pushed in strollers, people using wheelchairs or other motorized devices, passengers getting on and off buses and trains, cyclists, etc.

[0109] In one example, a vehicle 500 may be configured to communicate with a roadside unit (RSU) 512 or other networked device such as an AP. The RSU may be located in a busy traffic area and may be configured to perform the messaging techniques described herein. The RSU 512 may include some or all of the components of the TRP 300. Generally speaking, the capabilities of an RSU are not as good as a TRP because the coverage area of ​​the RSU is smaller than that of the TRP.

[0110] In some embodiments, Figure 5 The vehicle 500 and other entities in the vehicle can also receive the data from a network or server (such as server 400 ( Figure 5 The vehicle 500 may be able to communicate with a network and server to receive information about the location and capabilities of the infrastructure 502, vehicles 504, cellular stations 506, pedestrians 510, and RSUs 512 without having to communicate directly with those entities.

[0111] refer to Figure 6 , a diagram showing an example use case for providing basic safety messages (BSM) and sensor data sharing messages (SDSM). The diagram includes an intersection 600 having at least one traffic light 608, an RSU 602 configured to communicate with entities near the intersection 600, such as multiple vehicles, traffic lights 608, other signal devices, and sensors / detectors (e.g., vehicle detection devices, pedestrian crossing signals, etc.). The RSU 602 may be communicatively coupled to a server 606 via a network 604. The server 606 may be configured as a multi-access edge computing (MEC) server. The network 604 may include a WAN and / or the Internet. The intersection 600 may also include one or more cameras 614 configured to capture images of vehicles at the intersection 600 and provide image information to the RSU 602, the network 604, and / or the server 606. The intersection 600 may be within the coverage area of ​​one or more cellular base stations, such as a base station 616. Base station 616 may be communicatively coupled to RSU 602 and / or server 606 via network 604. Entities located at intersection 600 may be configured to utilize V2X communication technologies, such as WiFi, PC5, and Uu interfaces.

[0112] Figure 6The use cases in provide examples of BSM and SDSM reporting and corresponding scenarios between multiple vehicles and / or other stations (e.g., RSU 602) to illustrate that some BSM and SDSM information sent by some stations may be more relevant to a subset of vehicles and less relevant to another subset of vehicles. The vehicles at the intersection 600 may include V2X-enabled vehicles 610a-e and non-V2X-enabled vehicles 612a-c. The locations and capabilities of the vehicles 610a-e, 612a-c are examples of the corresponding need to facilitate interpretation of potential message traffic and filtering messages by excluding irrelevant messages and / or data components. The V2X-enabled vehicles 610a-e may be configured to periodically (e.g., 100ms, 200ms, 500ms, etc.) send BSMs and SDSMs including object detection information obtained using onboard sensors. The first vehicle 610a may be traveling south to the intersection 600 and may send a BSM based on its location and may send an SDSM including detected object information associated with the second vehicle 610b traveling east to the intersection, the third vehicle 612c traveling north to the intersection 600, and the fourth vehicle 610d traveling north from the intersection 600. Other objects may also be within the range of the onboard sensors and included in the SDSM. The second vehicle 610b may be configured to receive the BSM and SDSM sent from the first vehicle 610a, and send the BSM and SDSM based on objects detected by sensors on the second vehicle 610b (such as the third vehicle 612c, the fifth vehicle 610c crossing the intersection 600, the sixth vehicle 612b in the left turn lane, and the seventh vehicle 610e leaving the intersection 600 eastward). The first vehicle 610a may be configured to receive the BSM and SDSM from the second vehicle 610b. Each V2X-enabled vehicle may send and receive BSMs and SDSMs to each other as described, which may increase the processing load of the corresponding OBUs decoding a large number of messages. The techniques provided herein enable the OBUs to filter V2X messages to reduce processing requirements.

[0113] Filtering techniques can be based on the contextual relevance of the reporting vehicle and the position and / or state of the detected object. For example, the first vehicle 610a approaches the intersection 600 from the north, so the positions of other vehicles (such as the second vehicle 610b, the third vehicle 612c, the fifth vehicle 610c, the sixth vehicle 612b and the eighth vehicle 612a) approaching the intersection 600 are relevant because they represent the risk of collision. On the contrary, the positions of the fourth vehicle 610d leaving the intersection to the north and the seventh vehicle 610e leaving the intersection 600 are less relevant to the first vehicle 610a because the risk of collision is lower. Similarly, the seventh vehicle 610e can be configured to transmit BSM and SDSM to report the detection of the eighth vehicle 612a, but the BSM and SDSM sent by other vehicles approaching the intersection 600 are no longer relevant because the seventh vehicle 610e is leaving the intersection 600. In general, the relevance of BSM and / or SDSM object detection information is based on the risk of collision with the sending vehicle (e.g., BSM) or the corresponding object (e.g., SDSM object information). The relevance of BSM and / or SDSM may be determined using factors such as the location and trajectory of the vehicle, the geometry of the environment, road and traffic conditions, environmental conditions (e.g., day, night, rain, snow, fog, etc.), and vehicle performance factors (e.g., stopping distance).

[0114] like Figure 6 As described in , BSMs and SDSMs can be transmitted and received by vehicles and other stations in the network, such as RSU 602. In one example, roadside sensors and cameras can be configured to communicate with network 604, and server 606 and / or RSU 602 can be configured to utilize network sensor data to detect objects and generate SDSMs. RSU 602 or other stations, such as base station 616, can be configured to send SDSMs to vehicles.

[0115] refer to Figure 7, an example diagram 700 of an ITS stack reference architecture is shown. In general, an ITS access technology layer 712 may include various communication media and related protocols for the physical layer and the data link layer. In one example, the SDSM filtering technology described herein may occur at the ITS stack or at a lower layer. The access layer 712 may include access technologies in the ITS stack. The access layer 712 is not limited to a specific type of medium, but is generally based on a wireless access technology for wireless communication. Access technologies may be used for communication within an ITS station (e.g., UE, OBU, RSU, etc.) and for external communication (e.g., with other ITS stations). For external communication, some ITS access technologies represent complete, non-ITS-specific communication systems (such as GPRS, UMTS, WiMAX), which are considered to be "logical links" over which ITS data is transparently transmitted. The ITS network and transport layer 710 includes protocols for data delivery between ITS stations and from ITS stations to other network nodes, such as network nodes in a core network (e.g., the Internet). ITS network protocols may include routing data from a source to a destination through intermediate nodes and propagating data in a geographic area. ITS transport protocols can provide end-to-end delivery of data, and according to the requirements of ITS facilities and applications, additional services such as data transmission, flow control and congestion avoidance can also be provided. The specific protocol in the ITS network and transport layer is the Internet Protocol IP version 6 (IPv6). The use of IPv6 includes the transmission of IPv6 packets through the ITS network protocol, the dynamic selection of ITS access technology and the handover between them, and the interoperability issues of IPv6 and IPv4. The ITS facility layer 708 can provide a series of functions to support ITS applications. These facilities provide data structures to store, aggregate and maintain data of different types and sources, such as from vehicle sensors and from data received through other communications. ITS facilities can implement various types of addressing for applications, provide ITS-specific message processing and support the establishment and maintenance of communication sessions. These facilities can include the management of services, such as the discovery and download of services as software modules and their management in ITS stations. The ITS application layer 706 refers to ITS applications and use cases for road safety, traffic efficiency, infotainment and commerce. The ITS stack may include two vertical protocol entities, such as an ITS management layer 704 and an ITS security layer 702. The ITS management layer 704 may be responsible for the configuration of ITS stations, cross-layer information exchange between different layers, and other tasks. The ITS security layer 702 may be configured to provide security and privacy services, including secure messaging at different layers of the communication stack, management of identities and security credentials, and aspects of security platforms (firewalls, security gateways, tamper-resistant hardware). Figure 7 The ITS stack in is an example and not a limitation, as other protocols and messaging techniques may be used to communicate the BSM and SDSM as described herein.

[0116] refer to Figure 8 , a diagram showing an example use case for sending safety and object detection messages between vehicles. The use case depicts an intersection 800 with a first V2X-enabled vehicle 802, a second V2X-enabled vehicle 804, a non-V2X vehicle 806, and a pedestrian (e.g., VRU) 808. The second vehicle 804 includes onboard sensors and is configured to detect objects within a detection range 804a. The onboard sensors may include radar, lidar, cameras, and other RF signaling to detect nearby objects and stations. For example, the second vehicle 804 may utilize a rear-facing camera to detect a non-V2X vehicle 806 and utilize RF signaling (e.g., V2P) to detect a VRU 808. The second vehicle 804 may utilize an RF link 810 (e.g., V2X message, DSRC message) to communicate safety and object detection information. In one example, the safety information may be included in the BSM and the object detection information may be included in the SDSM. The first vehicle 802 may use the BSM and SDSM to determine the locations of the second vehicle 804, the non-V2X vehicle 806, and the VRU 808. The first vehicle 802 may use the corresponding object location information to perform vehicle control, such as slowing down, changing routes, turning on lights, etc.

[0117] refer to 9A to 9C , a diagram showing an example scenario for determining related BSM and SDSM messages. Fig.9AA first scenario 900 is depicted with a vehicle 902 having a first V2X configuration, a vehicle 904 having a second V2X configuration, and a non-V2X vehicle 906. The first vehicle 902 has a first object detection area 902a, and the second vehicle 904 has a second object detection area 904a. The object detection areas 902a, 904a may be based on onboard sensors, such as cameras and radar units, mounted on the respective vehicles 902, 904. In the first scenario 900, the non-V2X vehicle 906 is located outside the first detection area 902a and within the second detection area 904a. The BSM sent by the second vehicle 904 at this time is relevant to the first vehicle 902 because there is a risk of collision based on the current positions of the first vehicle 902 and the second vehicle 904. The SDSM sent by the second vehicle 904 will include information about the non-V2X vehicle 906 because it is located in the second object detection area 904a. The SDSM sent by the second vehicle 904 is relevant to the first vehicle 902 because it is reporting information about a non-V2X vehicle 906 that is outside the first object detection area 902a (i.e., it is not detected by the first vehicle 902) and based on the positions of the vehicles 902, 906, there is a risk of collision.

[0118] Fig. 9B A second scenario 920 is depicted with a vehicle 902 of a first V2X configuration, a vehicle 904 of a second V2X configuration, and a non-V2X vehicle 906. In the second scenario 920, the second vehicle 904 and the non-V2X vehicle 906 are located outside the first object detection area 902a, and the non-V2X vehicle 906 is located within the second object detection area 904a. The BSM transmitted by the second vehicle 904 at this time is not relevant to the first vehicle 902 because the second vehicle 904 has already left the intersection, and based on the current positions of the first vehicle 902 and the second vehicle 904, there is no risk of a collision. However, the SDSM transmitted by the second vehicle 904 is relevant to the first vehicle 902 because it is reporting information about the non-V2X vehicle 906 outside the first object detection area 902a (i.e., it is not detected by the first vehicle 902), and based on the positions of the vehicles 902, 906, there is a risk of a collision.

[0119] Fig. 9CA third scenario 950 is depicted with a vehicle 902 in a first V2X configuration, a non-V2X vehicle 906, and a vehicle 908 in a third V2X configuration. The third object detection area 908a is based on the capabilities of the sensors in the third vehicle 908. In the third scenario 950, the non-V2X vehicle 906 is outside the first object detection area 902a, and the third vehicle 908 is within the first object detection area 902a. The BSM transmitted by the third vehicle 908 at this time is relevant to the first vehicle 902 because the third vehicle 908 is at an intersection, and based on the current positions of the first vehicle 902 and the third vehicle 908, there is a risk of a collision. However, the SDSM transmitted by the third vehicle 908 is not relevant to the first vehicle 902 because it is reporting information about the non-V2X vehicle 906 that has passed through the intersection, and based on the positions of the vehicles 902, 906, there is no risk of a collision.

[0120] The locations and capabilities of vehicles 902, 904, 906, 908 are examples of demonstration sample use cases and capabilities for determining relevance based on the locations of the vehicles and the geometry of the environment. Other factors such as the capabilities of the vehicles, road conditions, and environmental conditions may be used to determine the risk of collision and, therefore, the relevance of the transmitted BSMs and SDSMs. Relevance determinations may be made for multiple vehicles in an area (e.g., Figure 6 ), and the relevance determination may be used to filter SDSM messages or portions of SDSM messages sent by a vehicle.

[0121] In operation, in one example, the entire SDSM can be filtered based on its association with the BSM from the same sender before decoding. For example, the receiver in the OBU can be configured to determine whether to discard the SDSM sent from the same vehicle based on the information contained in the BSM sent by the vehicle. The OBU can be configured to determine the relevance of the BSM based on the position information (e.g., position) in the sent BSM and other position information such as the geometry of the OBU's own position / future trajectory and the environment (e.g., map data). The BSM and SDSM sent from the remote vehicle can be associated with each other based on the information contained in the message. In one example, the association can be based on the TempID contained in each of the BSM and the SDSM. If the remote vehicle uses the same TempID for the sent BSM and SDSM, the SDSM can be filtered after verification. In one example, if both messages are signed with the same certificate, the association of the BSM and the SDSM can be based on the certificate value. For example, if each message contains the hash value of the signature certificate of another message. Once an SDSM is associated with a BSM and a decision is made to drop the SDSM, filtering may occur at the ITS stack or at a lower layer (eg, using L2 source address). An SDSM associated with a non-correlated BSM may be dropped.

[0122] refer to Fig.10 , a diagram 1000 of an ASN representation of an example SDSM 1002 is shown. The SDSM 1002 includes a first portion containing host data 1004 and a second portion containing detected object data 1008. In one example, the detected object data 1008 may be indexed and may include object data for up to 255 object instances. In one example, the SDSM filtering techniques described herein may utilize one or more information elements in the host data 1004 to filter the SDSM message and / or decode or discard one or more object instances.

[0123] In operation, in one example, the entire SDSM can be filtered by decoding only the host data portion of the SDSM. In one example, an objMaxPositionOffset information element (IE) 1006 indicating the maximum position offset between all detected objects can be included in the host data 1004 (i.e., the first portion) of the SDSM message. Thus, the maximum position offset can define the region of interest of the vehicle receiving the SDSM, and objects within the maximum position offset can be decoded if they are related to the receiving vehicle.

[0124] refer to Fig.11A and Fig. 11B, a diagram showing example relative positions between vehicles and regions of interest. The first diagram 1100 includes a first V2X-enabled vehicle 1102, a second V2X-enabled vehicle 1104, and a plurality of detected objects such as a third vehicle 1108 and a fourth vehicle 1110. The third vehicle 1108 and the fourth vehicle 1110 may be vehicles or other objects that do not support V2X. The second vehicle 1104 has an SDSM communication range 1104a and is sending a BSM and an SDSM to the first vehicle 1102 via a communication link 1112. The host data 1004 for SDSM sent by the second vehicle 1104 includes a maximum position offset IE 1006 to define a region of interest 1106 around the second vehicle. The first vehicle 1102 has a correlation distance 1102a to define a distance in front of the first vehicle 1102 for filtering object detection data. The correlation distance 1102a may be a user setting, or may be based on the capabilities of the first vehicle 1102, the geometry of the road, the vehicle state (e.g., speed, uphill, downhill), road conditions, or other driver and / or environmental factors (e.g., day, night, visibility, driver fatigue, etc.). The relative distance between the first vehicle 1102 and the second vehicle 1104 may be based on ground and / or satellite positioning techniques as described herein and reported in the BSM and / or SDSM sent from the second vehicle 1104. The region of interest 1106 may be determined based on the position of the second vehicle 1104 (e.g., contained in the BSM) and the objMaxPositionOffset information element (IE) 1006 contained in the host data 1004 of the SDSM sent by the second vehicle 1104. As depicted in the first diagram 1100, the correlation distance 1102a does not intersect the region of interest 1106. Therefore, the OBU on the first vehicle 1102 may discard all detected objects 1008 in the SDSM.

[0125] exist Fig. 11BIn the second graph 1150 in FIG. 1 , the relative distance between the first vehicle and the second vehicle decreases such that there is an overlap between the correlation distance 1102a and the region of interest 1106. In this example, the OBU in the first vehicle may detect the overlap based on the positions of the vehicles 1102, 1104 and the corresponding correlation distance 1102a (applied to the position of the first vehicle 1102) and the objMaxPositionOffset information element (IE) 1006 included in the host data 1004 of the SDSM sent by the second vehicle 1104. The OBU in the first vehicle may then decode the detected object data 1008 including object information of all objects detected by the second vehicle 1104 (i.e., the third vehicle 1108 and the fourth vehicle 1110).

[0126] refer to Fig.12 , a diagram 1200 of an example group-based object detection scheme is shown. Diagram 1200 includes two example V2X-enabled vehicles, such as a first vehicle 1202 and a second vehicle 1204, configured to transmit and receive messages via a communication link 1220. The second vehicle 1204 includes a vehicle configured to detect nearby objects (such as Figure 8 The host data 1004 may include an onboard sensor of a plurality of vehicles (depicted in FIG. 1004 ). The second vehicle 1204 may utilize an objMaxPositionOffset information element (IE) 1006 to configure the region of interest 1206. The host data 1004 may include additional IEs to define sub-regions of interest, which may be used to group detected objects within the region of interest 1206. For example, the region of interest 1206 may include a first sub-region 1206a, a second sub-region 1206b, and a third sub-region 1206c. The number and orientation of the sub-regions 1206a-c are examples and not limitations, as other numbers and arrangements of sub-regions may be used.

[0127] In operation, in one example, the sub-region configuration can be used to implement partial filtering of irrelevant reported objects within the SDSM, and the OBU can be configured to utilize the host data to decode object instances of relevant detected objects. Fig.13In the example host data 1300 in FIG. 1 , the objMaxPositionOffset IE 1006 may be used to define the region of interest 1206, and the additional IE 1304 may be used to define sub-regions and / or sub-groups of object instances. In one example, the objGroupEndIndex IE may be used to organize the detected objects in different groups and indicate the starting index of the detected objects in each group. The objects detected in the relevant groups will be decoded by the receiver in the OBU, and the objects in the irrelevant groups will be discarded (e.g., ignored, not decoded). The sub-regions 1206a-c may define three groups based on the heading of the second vehicle 1204, which may be included in the host data 1300 as one or more heading information elements 1302. For example, the first sub-region 1206a may define a first group of objects detected between -60 degrees and +60 degrees from the heading of the second vehicle 1204. The second sub-area 1206b may define a second group including objects detected between +60 and 180 degrees, and the third sub-area 1206c may define a third group including objects detected between 180 and -60 degrees, such as Fig.12 As depicted in . Other sub-regions and groups may also be defined. For example, two groups of regions of interest may be defined including a front region (eg, -90 degrees to +90 degrees) and a rear region (eg, +90 degrees to -90 degrees).

[0128] The SDSM can be generated such that detected object instances are sorted and indexed based on sub-region / detected object groups. In one example, referring to the objGroupEndIndex IE, an array of index values ​​(e.g., [5, 10, 30]) can be used to identify different sub-regions. The first sub-region 1206a can include detected object information in instance indexes 0-5, the second sub-region 1206b can utilize detected object information in instance indexes 5-10, and the third sub-region 1206c can utilize detected object information in instance indexes 10-30. Other indexing schemes can also be used to create more or fewer groupings. A receiver in an OBU on the first vehicle 1202 (e.g., a receiving vehicle) can be configured to decode object detection instances based on index values ​​corresponding to regions determined to be related to the first vehicle 1202 (e.g., based on the locations and / or trajectories of the first vehicle 1202 and the second vehicle 1204, the geometry of the road, and other factors that may increase or decrease the ability to safely operate the vehicles between one or more detected objects). In one example, referring to Fig.12, objects detected in the second sub-area 1206b including the seventh vehicle 1216 and the third sub-area 1206c including the fifth vehicle 1212 and the sixth vehicle 1214 may be associated with the first vehicle 1202 approaching the intersection (e.g., because the coverage areas of the second sub-area 1206b and the third sub-area 1206c are directed to the intersection that may include incoming vehicles). The receiver in the OBU on the first vehicle 1202 may utilize the index information associated with the second sub-area 1206b and the third sub-area 1206c to decode the object instances in the object data associated with the fifth vehicle 1212, the sixth vehicle 1214, and the seventh vehicle 1216. The third vehicle 1208 and the fourth vehicle 1210 are located in the first sub-area 1206a, and the associated data is contained in the detected object data 1008 in the SDSM sent by the second vehicle 1204. In one example, the first vehicle 1202 will not decode (e.g., discard) object instances associated with the third vehicle 1208 and the fourth vehicle 1210. The other vehicles in diagram 1200 may also be configured to send BSMs and SDSMs to each other, and the receiving vehicles may perform partial filtering based on the sub-regions / groups defined in the host data of the corresponding SDSM message.

[0129] In one example, additional fields may be included in the host data 1300 to provide finer-grained filtering of object instances. For example, the additional IE 1304 may include an objMaxPosOffsetInGroup IE, which may include an index array identifying detected objects within the maximum position offset of a sub-region / group. The objMinHeadingInGroup IE and the objMaxHeadingInGroup IE may include an index array identifying detected objects facing toward or away from the detection station (e.g., 0 degrees for facing and 180 degrees for away). For example, a group including the fourth vehicle 1210 and the sixth vehicle 1214 may be created because they are driving away from the second vehicle 1204 (i.e., the reporting vehicle). Other information elements may also be included in the host data 1300 to enable the receiver to partially filter the object instances in the detected object data 1008 so that the receiver will decode or discard the object instances based on the index values ​​in the host data 1300.

[0130] refer to Fig.14 , further reference Figures 1 to 13, the method 1400 for filtering SDSM based on association with BSM includes the stages shown. However, the method 1400 is an example and not a limitation. The method 1400 can be modified, for example, by adding, removing, rearranging, combining, executing concurrently, and / or splitting a single stage into multiple stages. The method 1400 can be performed by an OBU in a vehicle or other network resources such as an RSU and / or an MEC server.

[0131] At stage 1402, the method includes receiving a basic safety message and one or more sensor data sharing messages from a vehicle. An OBU (such as UE 200, including processor 210 and transceiver 215) is a component for receiving a BSM and one or more SDSMs. In one example, reference Fig.9A , the OBU on the first V2X configured vehicle 902 is configured to receive safety and sensor data messages via a communication link such as V2X or other ITS networking and transport layer 710. The BSM may include a temporary ID value associated with the sending vehicle, as well as other information elements such as the current location (e.g., latitude, longitude, altitude, location accuracy) and other status information associated with the sending vehicle (e.g., transmission and speed, heading, braking system status, etc.). The second V2X configured vehicle 904 may be configured to send BSMs on a periodic basis or in response to a query message provided by the first vehicle 902 or another station (e.g., RSU). The second vehicle 904 may also send object detection information, such as SDSM. For example, the SDSM may include a temporary ID value associated with the sending vehicle, and a detected vehicle based on a detected vehicle (such as a non-V2X vehicle 906). The OBU on the first vehicle 902 is configured to receive the BSM and SDSM sent by the second vehicle 904.

[0132] At stage 1404, the method includes determining the relevance of the basic safety message based at least in part on the location of the vehicle. The OBU (including the processor 210) is a component for determining the relevance of the BSM. The BSM will include an information element based on the current location of the second vehicle 904. The OBU can be configured to determine the relevance of the BSM based on the risk of collision with the second vehicle 904. The OBU can be configured to utilize factors such as the location and trajectory of the vehicle, the geometry of the environment (e.g., map data), road conditions, environmental conditions (e.g., day, night, rain, snow, fog, etc.), and vehicle performance factors (e.g., stopping distance) to determine the relevance of the BSM received from the vehicle.

[0133] At stage 1406, the method includes decoding or discarding one or more sensor data sharing messages based on the correlation of the basic security message. The OBU including the processor 210 is a component for decoding or discarding one or more SDSMs. In one example, the OBU on the first vehicle 902 can be configured to associate the BSM and SDSM sent from the second vehicle 904 based on the information contained in the message. For example, the association can be based on the TempID contained in the BSM and the SDSM. If the remote vehicle uses the same TempID for the sent BSM and SDSM, the SDSM can be filtered after verification. If both messages are signed with the same certificate, the association of the BSM and the SDSM can be based on the security certificate value. For example, if each message contains a hash value of the signature certificate of the other message. Once the SDSM has been associated with the BSM, it can be determined based on the correlation of the BSM to decode or discard the SDSM. Therefore, if the BSM is related based on the analysis of stage 1404, the SDSM is decoded. On the contrary, if it is determined that the BSM is not related, the SDSM is discarded (e.g., not decoded).

[0134] refer to Fig.15 , further reference Figures 1 to 13 , method 1500 for partially filtering SDSM includes the stages shown. However, method 1500 is an example and not a limitation. Method 1500 can be modified, for example, by adding, removing, rearranging, combining, executing concurrently, and / or splitting a single stage into multiple stages. Method 1500 can be performed by an OBU in a vehicle or other network resources such as an RSU and / or an MEC server.

[0135] At stage 1502, the method includes receiving a sensor data sharing message from a vehicle. An OBU (such as UE 200, including processor 210 and transceiver 215) is a component for receiving the SDSM. In one example, reference Fig.11A and Fig. 11B , the OBU on the first V2X configured vehicle 1102 is configured to receive safety and / or sensor data messages via a communication link 1112 such as a V2X or other ITS networking and transport layer 710. The second vehicle 1104 may include an onboard sensor for detecting nearby objects and may send object detection information via the communication link 1112. In one example, the object detection information may be included in the SDSM. For example, the SDSM may include the current location information of the sending vehicle, and detected vehicle data based on detected vehicles (such as a third vehicle 1108 and a fourth vehicle 1110). The OBU on the first vehicle 1102 is configured to receive the SDSM sent by the second vehicle 1104.

[0136] At stage 1504, the method includes decoding a first portion of the sensor data sharing message to determine an area of ​​interest associated with the vehicle. The OBU (including the processor 210 and the transceiver 215) is a component for decoding the first portion of the SDSM. In one example, reference Fig.10 , the SDSM may include a first portion including host data 1004 and a second portion including detected object data 1008. The OBE in the first vehicle 1102 may be configured to decode the host data 1004 and determine a value for an objMaxPosOffset information element 1006. The objMaxPosOffset value may define a radius extending from the position of the second vehicle 1104. In one example, a region of interest associated with the second vehicle 1104 may be defined as a circle having a radius of objMaxPosOffset around the second vehicle. Other parameters and geometries or functions may also be used to define the region of interest. The host data 1004 may include other information elements to define an area or volume of space (e.g., additional IE 1304) surrounding the current position of the vehicle (e.g., refPos) to be sent. For example, a reference Fig.12 and Fig.13 , the region of interest may include sub-regions and object parameters to define groups of detected objects, and the host data 1004 may include index information to enable the receiving OBU to decode object instances in the detected object data 1008 based on correlation of the sub-regions.

[0137] At stage 1506, the method includes determining the relative position of the region of interest. The OBU (including the processor 210 and the transceiver 215) is a component for determining the relative position of the region of interest. The relative position of the region of interest can be based on the relative distance between the sending vehicle and the receiving vehicle. In one example, the position of the sending and receiving vehicles can be based on the terrestrial and / or satellite positioning techniques described herein and as reported in the BSM and / or SDSM sent from the vehicle. In one example, reference Fig.11A and Fig. 11B , the receiving vehicle may have a relevant distance 1102a to define the distance in front of the receiving vehicle for filtering object detection data. The relevant distance 1102a may be a user setting, or may be based on the capabilities of the receiving vehicle, the geometry of the road, the vehicle state (e.g., speed, uphill, downhill), road conditions, or other driver and / or environmental factors (e.g., day, night, visibility, driver fatigue, etc.).

[0138] At stage 1508, the method includes decoding or discarding a second portion of the sensor data sharing message based on the relative location of the region of interest. The OBU (including the processor 210 and the transceiver 215) is a component for decoding or discarding the second portion of the SDSM. The second portion of the SDSM includes detected object data 1008, which includes object instances for detected objects (e.g., vehicles, VRUs, obstacles, etc.). In one example, the receiving OBU can be configured to decode or discard one or more object instances in the detected object data 1008 based on the relevance of the region of interest and / or one or more sub-regions of interest. In one example, reference Fig. 11B , if the relevant distance 1102a of the receiving vehicle extends into the region of interest associated with the transmitting vehicle, the receiving OBU can be configured to decode all object instances in the detected object data 1008. Fig.12 and Fig.13 , the receiving OBU may be configured to decode or discard a subset of object instances in the detected object data 1008 based on the relevance (i.e., the relative positions) of the sub-regions defined in the host data 1300. Partial filtering of object instances based on the sub-region group index provides a technical advantage of reducing the processing power and latency associated with decoding each object instance included in the SDSM.

[0139] refer to Fig.16 , further reference Figures 1 to 13 , a method 1600 for providing detected object data includes the stages shown. However, the method 1600 is an example and not a limitation. The method 1600 may be modified, for example, by adding, removing, rearranging, combining, executing concurrently, and / or splitting a single stage into multiple stages. The method 1600 may be performed by an OBU based on sensor data obtained by a vehicle, or by other network resources such as an RSU and / or an MEC server based on sensor data obtained via a network.

[0140] At stage 1602, the method includes detecting one or more objects near the vehicle. An OBU (such as UE 200, including a processor 210 and a transceiver 215) is a component for detecting one or more objects. The OBU may include one or more cameras 218, sensors 213, and wireless transceivers 240 to perform object detection. For example, the sensor processor 234 may include a processor for radar, lidar, optical sensing, and other RF signaling to detect nearby objects and stations. In one example, the vehicle may use RF signaling to determine the distance and orientation (e.g., RTT and AoA measurements) to adjacent stations. Non-vehicle stations (such as RSUs or MEC servers) may be configured to detect objects based on networked sensors (such as cameras, Hall effect sensors, radars, lidars, acoustic wave measurements, and other RF sensing and object detection technologies known in the art).

[0141] At stage 1604, the method includes organizing information associated with one or more detected objects in the vicinity of the vehicle into one or more data groups. The OBU (including the processor 210) is a component for organizing the one or more detected objects into one or more data groups. In one example, reference Fig.11A and Fig. 11B , the data group may be based on the region of interest 1106, such that the receiving station may be configured to decode object instances in the SDSM associated with objects detected within the region of interest 1106. In one example, referring to Fig.12 and Fig.13 , one or more data groups may be based on sub-regions 1206a - c and / or additional criteria such as defined by additional IE 1304 .

[0142] At stage 1606, the method includes generating a sensor data sharing message including host data and detected object data based on information associated with one or more objects near the vehicle, wherein the detected object data is organized based on one or more data groups, and the host data includes index information associated with the one or more data groups. The OBU (including the processor 210) is a component for generating an SDSM. The SDSM may include a first portion including the host data 1300 and a second portion including the detected object data 1008. The OBU may be configured to organize object instances in the detected object data 1008 by index groups, and then include an array of index groups as a parameter in the host data 1300. For example, with reference to the objGroupEndIndex IE in the host data 1300, an array of index values ​​(e.g., [5, 10, 30]) may be used to identify different data groups (e.g., sub-areas). The first data group may include detected object information in instance indexes 0-5, the second data group may utilize detected object information in instance indexes 5-10, and the third data group may utilize detected object information in instance indexes 10-30. Other indexing schemes may also be used to create more or fewer data groups. For example, the objMaxPosOffsetInGroup, objMinHeadingInGroup, and objMaxHeadingInGroup IEs may include index values ​​that enable the receiving vehicle to decode only relevant object instances.

[0143] At stage 1608, the method includes sending a sensor data sharing message. The OBU (including the processor 210 and the transceiver 215) is a component for sending the SDSM. The SDSM may include an object instance based on one or more objects detected at stage 1602 and the host data 1300 generated at stage 1606. The SDSM may be sent periodically or based on a request from a neighboring station. The SDSM may be sent via a communication link such as V2X or other ITS networking and transport layer 710.

[0144] refer to Fig.17 , further reference Figures 1 to 13 , a method 1700 for filtering a portion of detected object data based on a data group includes the stages shown. However, the method 1700 is an example and not a limitation. The method 1700 may be modified, for example, by adding, removing, rearranging, combining, executing concurrently, and / or splitting a single stage into multiple stages. The method 1700 may be performed by an OBU in a vehicle or other network resources such as an RSU and / or an MEC server.

[0145] At stage 1702, the method includes receiving a sensor data sharing message associated with a first vehicle including host data and detected object data, wherein the detected object data is organized into one or more data groups, and the host data includes index information associated with the one or more data groups. An OBU (such as UE 200, including processor 210 and transceiver 215) is a component for receiving the SDSM. The SDSM may be sent from the first vehicle (or other station such as RSU) via a communication link such as V2X or other ITS networking and transport layer 710. Reference Fig.10 and Fig.13 , the SDSM may include a first portion containing host data 1300 and a second portion containing detected object data 1008. Object instances in the detected object data 1008 may be organized by index groups, and the host data 1300 may include an array of index groups as IE parameters. For example, with reference to the objGroupEndIndex IE in the host data 1300, an array of index values ​​(e.g., [5, 10, 30]) may be used to identify different data groups (e.g., sub-areas). The first data group may include detected object information in instance indexes 0-5, the second data group may utilize detected object information in instance indexes 5-10, and the third data group may utilize detected object information in instance indexes 10-30. Other indexing schemes may also be used to create more or fewer data groups. For example, the objMaxPosOffsetInGroup, objMinHeadingInGroup, and objMaxHeadingInGroup IEs may include index values ​​that enable the receiving vehicle to decode only relevant object instances.

[0146] At stage 1704, the method includes determining an operating context for the second vehicle. The OBU (including the processor 210 and the sensor 213) is a component for determining the operating context. The operating context may be based on vehicle and environmental factors to enable the second vehicle to determine whether the detected object data is relevant to the second vehicle. For example, the operating context may be based on factors such as the position and trajectory of the first vehicle and the second vehicle, the geometry of the environment (e.g., map data), road and traffic conditions, environmental conditions (e.g., daytime, nighttime, rainy days, snowy days, foggy days, etc.), and performance factors associated with the second vehicle (e.g., stopping distance). Other parameters associated with the operation of the vehicle may be used as factors for determining the operating context for the second vehicle.

[0147] At stage 1706, the method includes filtering one or more data groups based at least in part on the operating context of the second vehicle and index information associated with the one or more data groups. The OBU (including the processor 210) is a component for filtering the plurality of data groups. Filtering the plurality of data groups may be based on the contextual relevance of the locations of the first vehicle and the second vehicle and the locations and / or states of the detected object data groups. In general, filtering enables the second vehicle to decode objects in the data groups that represent a safety risk, or to discard objects in the data groups that do not represent a safety risk. In one example, reference is made to Fig.12 , objects detected in the second sub-area 1206b including the seventh vehicle 1216 and the third sub-area 1206c including the fifth vehicle 1212 and the sixth vehicle 1214 may be associated with the first vehicle 1202 approaching the intersection. The receiver in the OBU on the first vehicle 1202 may utilize the index information associated with the second sub-area 1206b and the third sub-area 1206c to decode the object instances in the object data associated with the fifth vehicle 1212, the sixth vehicle 1214, and the seventh vehicle 1216. The third vehicle 1208 and the fourth vehicle 1210 are located in the first sub-area 1206a, and the related data is included in the detected object data 1008 in the SDSM sent by the second vehicle 1204. In one example, the first vehicle 1202 will not decode (e.g., discard) the object instances associated with the third vehicle 1208 and the fourth vehicle 1210. Other vehicles among Figure 1200 can also be configured to send BSM and SDSM to each other, and the receiving vehicle can perform partial filtering based on the sub-area / group defined in the host data of the corresponding SDSM message. Other indexing schemes can also be used to create more or less data groups. For example, objMaxPosOffsetInGroup, objMinHeadingInGroup and objMaxHeadingInGroup IE can include an index value that enables the second vehicle to only decode the related object instance. For example, because the 4th vehicle 1210 and the 6th vehicle 1214 are just leaving the intersection, their object instances can be indexed so that the OBU in the second vehicle 1204 will not decode them based on the objMinHeadingInGroup array.

[0148] Other examples and implementations are within the scope of this disclosure and the appended claims. For example, due to the nature of software and computers, the functions described above may be implemented using software executed by a processor, hardware, firmware, hard wiring, or any combination thereof. Features that implement a function may also be physically located at different locations, including being distributed so that portions of a function are implemented at different physical locations.

[0149] As used herein, the singular forms "a", "an" and "the" also include the plural forms, unless the context clearly indicates otherwise. As used herein, the terms "comprises", "includes" and "comprising" specify the presence of stated features, integers, steps, operations, elements and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or groups thereof.

[0150] Likewise, as used herein, "or" used in a listing of items (possibly followed by "at least one of" or followed by "one or more of") indicates a disjunctive listing, so that, for example, a listing of "at least one of A, B, or C," or a listing of "one or more of A, B, or C," or a listing of "A or B or C" means A or B or C, or AB (A and B), or AC (A and C), or BC (B and C), or ABC (i.e., A and B and C), or a combination of more than one feature (e.g., AA, AAB, ABBC, etc.). Thus, a statement that an item (e.g., a processor) is configured to perform a function with respect to at least one of A or B, or a statement that an item is configured to perform function A or function B means that the item may be configured to perform the function with respect to A, or may be configured to perform the function with respect to B, or may be configured to perform the functions with respect to both A and B. For example, the phrase "a processor configured to measure at least one of A or B" or "a processor configured to measure A or measure B" means that the processor may be configured to measure A (and may or may not be configured to measure B), or may be configured to measure B (and may or may not be configured to measure A), or may be configured to measure A and measure B (and may be configured to select which of A and B to measure or measure both). Similarly, a description of a component for measuring at least one of A or B includes: a component for measuring A (which may or may not be able to measure B), or a component for measuring B (and may or may not be configured to measure A), or a component for measuring A and B (which may be able to select which of A and B to measure or measure both). For another example, a description that an item (e.g., a processor) is configured to perform at least one of function X or perform function Y means that the item may be configured to perform function X, or may be configured to perform function Y, or may be configured to perform function X and perform function Y. For example, the phrase "a processor configured to measure at least one of X or Y" means that the processor may be configured to measure X (and may or may not be configured to measure Y), or may be configured to measure Y (and may or may not be configured to measure X), or may be configured to measure X and measure Y (and may be configured to select which one or both of X and Y to measure).

[0151] As used herein, unless otherwise stated, a statement that a function or operation is "based on" an item or condition means that the function or operation is based on the recited item or condition, and may be based on one or more items and / or conditions other than the recited item or condition.

[0152] Substantial variations may be made as required. For example, customized hardware may also be used, and / or specific elements may be implemented in hardware, software executed by a processor (including portable software, such as applets, etc.), or both. In addition, connections to other computing devices (such as network input / output devices) may be employed. Unless otherwise indicated, components (functional or otherwise) shown in the figures and / or discussed herein as being connected or communicating with each other are communicatively coupled. That is, these components may be connected directly or indirectly to enable communication between them.

[0153] The systems and devices discussed above are examples. Various configurations may appropriately omit, replace, or add various processes or components. For example, features described with respect to certain configurations may be combined in various other configurations. Different aspects and elements of a configuration may be combined in a similar manner. In addition, technology is constantly evolving, and therefore many of the elements are examples and do not limit the scope of the present disclosure or claims.

[0154] A wireless communication system is a system in which communications are transmitted wirelessly, i.e., by electromagnetic waves and / or sound waves propagating through atmospheric space rather than by wires or other physical connections. A wireless communication network may not cause all communications to be sent wirelessly, but may be configured to cause at least some communications to be sent wirelessly. In addition, the term "wireless communication device" or similar terms does not require that the functionality of the device be used exclusively or even primarily for communication, does not require that communications using the wireless communication device be exclusively or even primarily wireless, nor does it require that the device be a mobile device, but rather indicates that the device includes wireless communication capabilities (unidirectional or bidirectional), for example, including at least one radio component (each radio component is part of a transmitter, receiver or transceiver) for wireless communication.

[0155] Specific details are given in this specification to provide a thorough understanding of example configurations (including specific implementations). However, the configurations can be practiced without these specific details. For example, well-known circuits, processes, algorithms, structures, and techniques have been shown without unnecessary details to avoid obfuscating the configuration. This specification provides example configurations and does not limit the scope, applicability, or configuration of the claims. Instead, the previous description of the configuration provides a description for implementing the technology. Various changes can be made to the functions and arrangements of the elements.

[0156] As used herein, the terms "processor-readable medium," "machine-readable medium," and "computer-readable medium" refer to any medium that participates in providing data that causes a machine to operate in a particular manner. Using a computing platform, various processor-readable media may be involved in providing instructions / code to a processor for execution, and / or may be used to store and / or carry such instructions / code (e.g., as signals). In many specific implementations, processor-readable media are physical and / or tangible storage media. Such media may take many forms, including, but not limited to, non-volatile media and volatile media. Non-volatile media include, for example, optical disks and / or magnetic disks. Volatile media include, but are not limited to dynamic memory.

[0157] After describing several example configurations, various modifications, alternative constructions, and equivalents may be used. For example, the above elements may be components of a larger system, in which other rules may take precedence over the application of the present disclosure or otherwise modify the application of the present disclosure. In addition, multiple operations may be taken before, during, or after considering the above elements. Therefore, the above description does not limit the scope of the claims.

[0158] Unless otherwise indicated, "about" and / or "approximately" as used herein in reference to a measurable value (such as an amount, a duration of time, etc.) encompasses variations of ±20% or ±10%, ±5%, or +0.1% from the specified value, as appropriate in the context of the systems, devices, circuits, methods, and other specific implementations described herein. Unless otherwise indicated, "substantially" as used herein in reference to a measurable value (such as an amount, a duration of time, a physical property (such as frequency), etc.) also encompasses variations of ±20% or ±10%, ±5%, or +0.1% from the specified value, as appropriate in the context of the systems, devices, circuits, methods, and other specific implementations described herein.

[0159] A statement that a value exceeds (or is greater than or above) a first threshold is equivalent to a statement that the value meets or exceeds a second threshold that is slightly greater than the first threshold, e.g., the second threshold is one value higher than the first threshold at the resolution of the computing system. A statement that a value is less than (or within or below) a first threshold is equivalent to a statement that the value is less than or equal to a second threshold that is slightly less than the first threshold, e.g., the second threshold is one value lower than the first threshold at the resolution of the computing system.

[0160] Specific implementation examples are described in the following numbered clauses:

[0161] Clause 1. A method for providing detected object data, comprising: detecting one or more objects near a vehicle; organizing information associated with the one or more detected objects near the vehicle into one or more data groups; generating a sensor data sharing message including host data and detected object data based on the information associated with the one or more detected objects near the vehicle, wherein the detected object data is organized based on the one or more data groups, and the host data includes index information associated with the one or more data groups; and sending the sensor data sharing message.

[0162] Clause 2. The method of clause 1, wherein the one or more data sets define an area surrounding the vehicle.

[0163] Clause 3. The method of clause 2, wherein the area is a circle around the vehicle, and the host data includes a first information element for defining a radius of the circle.

[0164] Clause 4. The method of clause 1, wherein the one or more data sets define a plurality of areas proximate to the vehicle.

[0165] Clause 5. The method of clause 4, wherein the host data comprises a second information element comprising an array of index values ​​associated with a position offset for each of the plurality of areas in the vicinity of the vehicle.

[0166] Clause 6. The method of Clause 1, wherein the one or more data sets are associated with a heading of each of the one or more detected objects.

[0167] Clause 7. The method of clause 1, further comprising sending a basic safety message including a current location of the vehicle, wherein the sensor data sharing message is associated with the basic safety message.

[0168] Clause 8. The method of clause 7, wherein the basic safety message and the sensor data sharing message each include an identification information element including a same identification value.

[0169] Clause 9. The method of clause 1, wherein detecting the one or more objects in the vicinity of the vehicle is based on signals obtained by a radar sensor, a lidar sensor, an optical sensor, a radio frequency communication system, or a combination thereof.

[0170] Clause 10. A method for filtering detected object data, comprising: receiving a sensor data sharing message associated with a first vehicle including host data and detected object data, wherein the detected object data is organized into one or more data groups, and the host data includes index information associated with the one or more data groups; determining an operating context of a second vehicle; and filtering the one or more data groups based at least in part on the operating context of the second vehicle and the index information associated with the one or more data groups.

[0171] Clause 11. The method of clause 10, wherein the one or more data sets define an area surrounding the first vehicle.

[0172] Clause 12. The method of clause 11, wherein the area is a circle around the first vehicle, and the host data includes a first information element defining a radius of the circle.

[0173] Clause 13. The method of clause 10, wherein the one or more data sets define a plurality of areas proximate to the first vehicle.

[0174] Clause 14. The method of clause 13, wherein the host data comprises second information comprising an array of index values ​​associated with a position offset for each of the plurality of areas in the vicinity of the first vehicle.

[0175] Clause 15. The method of Clause 10, wherein the one or more data sets are associated with a heading of each of the one or more detected objects.

[0176] Clause 16. The method of clause 10, further comprising receiving a basic safety message including a current location of the first vehicle, wherein the sensor data sharing message is associated with the basic safety message.

[0177] Clause 17. The method of clause 16, wherein the basic safety message and the sensor data sharing message each include an identification information element containing a same identification value.

[0178] Clause 18. A method according to clause 10, wherein determining the operating context of the second vehicle includes determining the current positions of the first vehicle and the second vehicle, determining the trajectories of the first vehicle and the second vehicle, determining the geometry of the environment near the second vehicle, or a combination thereof.

[0179] Clause 19. The method of clause 10, wherein determining the operating context of the second vehicle comprises determining current environmental conditions, determining current road conditions, determining performance factors associated with the second vehicle, or a combination thereof.

[0180] Clause 20. The method of Clause 10, wherein filtering the one or more data groups comprises decoding the one or more data groups associated with the second vehicle, or discarding the one or more data groups not associated with the second vehicle.

[0181] Clause 21. A device comprising: a memory; at least one transceiver; at least one processor, the at least one processor being communicatively coupled to the memory and the at least one transceiver and configured to: detect one or more objects near a vehicle; organize information associated with the one or more detected objects near the vehicle into one or more data groups; generate a sensor data sharing message including host data and detected object data based on the information associated with the one or more detected objects near the vehicle, wherein the detected object data is organized based on the one or more data groups and the host data includes index information associated with the one or more data groups; and send the sensor data sharing message.

[0182] Clause 22. The apparatus of clause 21, wherein the one or more data sets define an area surrounding the vehicle.

[0183] Clause 23. The apparatus of clause 22, wherein the area is a circle around the vehicle, and the host data includes a first information element for defining a radius of the circle.

[0184] Clause 24. The apparatus of clause 21, wherein the one or more data sets define a plurality of areas proximate to the vehicle.

[0185] Clause 25. The apparatus of Clause 24, wherein the host data comprises a second information element comprising an array of index values ​​associated with a position offset for each of the plurality of areas in the vicinity of the vehicle.

[0186] Clause 26. The apparatus of Clause 21, wherein the one or more data sets are associated with a heading of each of the one or more detected objects.

[0187] Clause 27. The apparatus of clause 21, wherein the at least one processor is further configured to send a basic safety message including a current location of the vehicle, wherein the sensor data sharing message is associated with the basic safety message.

[0188] Clause 28. The apparatus of clause 27, wherein the basic safety message and the sensor data sharing message each include an identification information element including a same identification value.

[0189] Clause 29. An apparatus according to clause 21, wherein the at least one processor is further configured to detect the one or more objects near the vehicle based on signals obtained by a radar sensor, a lidar sensor, an optical sensor, a radio frequency communication system, or a combination thereof.

[0190] Clause 30. A device comprising: a memory; at least one transceiver; at least one processor, the at least one processor being communicatively coupled to the memory and the at least one transceiver and configured to: receive a sensor data sharing message associated with a first vehicle comprising host data and detected object data, wherein the detected object data is organized into one or more data groups, and the host data comprises index information associated with the one or more data groups; determine an operating context of a second vehicle; and filter the one or more data groups based at least in part on the operating context of the second vehicle and the index information associated with the one or more data groups.

[0191] Clause 31. The apparatus of clause 30, wherein the one or more data sets define an area surrounding the first vehicle.

[0192] Clause 32. The apparatus of clause 31, wherein the area is a circle surrounding the first vehicle, and the host data includes a first information element for defining a radius of the circle.

[0193] Clause 33. The apparatus of clause 30, wherein the one or more data sets define a plurality of areas proximate to the first vehicle.

[0194] Clause 34. The device of clause 33, wherein the host data comprises second information comprising an array of index values ​​associated with a position offset for each of the plurality of areas in the vicinity of the first vehicle.

[0195] Clause 35. The apparatus of Clause 30, wherein the one or more data sets are associated with a heading of each of the one or more detected objects.

[0196] Clause 36. The apparatus of clause 30, wherein the at least one processor is further configured to receive a basic safety message including a current location of the first vehicle, wherein the sensor data sharing message is associated with the basic safety message.

[0197] Clause 37. The apparatus of clause 36, wherein the basic safety message and the sensor data sharing message each include an identification information element including a same identification value.

[0198] Clause 38. An apparatus according to clause 30, wherein the at least one processor is also configured to determine the operating context of the second vehicle based at least in part on the current positions of the first vehicle and the second vehicle, the trajectories of the first vehicle and the second vehicle, the geometry of the environment near the second vehicle, or a combination thereof.

[0199] Clause 39. An apparatus according to clause 30, wherein the at least one processor is further configured to determine the operating context of the second vehicle based at least in part on current environmental conditions, current road conditions, performance factors associated with the second vehicle, or a combination thereof.

[0200] Clause 40. The apparatus of clause 30, wherein the at least one processor is further configured to decode the one or more data groups related to the second vehicle, or to discard the one or more data groups not related to the second vehicle to filter the one or more data groups.

[0201] Clause 41. A device for providing detected object data, comprising: a component for detecting one or more objects near a vehicle; a component for organizing information associated with the one or more detected objects near the vehicle into one or more data groups; a component for generating a sensor data sharing message including host data and the detected object data based on the information associated with the one or more detected objects near the vehicle, wherein the detected object data is organized based on the one or more data groups and the host data includes index information associated with the one or more data groups; and a component for sending the sensor data sharing message.

[0202] Clause 42. A device for filtering detected object data, comprising: a component for receiving a sensor data sharing message associated with a first vehicle including host data and the detected object data, wherein the detected object data is organized into one or more data groups, and the host data includes index information associated with the one or more data groups; a component for determining an operating context of a second vehicle; and a component for filtering the one or more data groups based at least in part on the operating context of the second vehicle and the index information associated with the one or more data groups.

[0203] Item 43. A non-transitory processor-readable storage medium comprising processor-readable instructions, the processor-readable instructions being configured to cause one or more processors to provide detected object data, the processor-readable instructions comprising code for: detecting one or more objects near a vehicle; organizing information associated with the one or more detected objects near the vehicle into one or more data groups; generating a sensor data sharing message comprising host data and the detected object data based on the information associated with the one or more detected objects near the vehicle, wherein the detected object data is organized based on the one or more data groups and the host data includes index information associated with the one or more data groups; and sending the sensor data sharing message.

[0204] Item 44. A non-transitory processor-readable storage medium comprising processor-readable instructions, the processor-readable instructions being configured to cause one or more processors to filter detected object data, the processor-readable instructions comprising code for: receiving a sensor data sharing message associated with a first vehicle comprising host data and the detected object data, wherein the detected object data is organized into one or more data groups and the host data comprises index information associated with the one or more data groups; determining an operating context of a second vehicle; and filtering the one or more data groups based at least in part on the operating context of the second vehicle and the index information associated with the one or more data groups.

[0205] Clause 45. A method for filtering detected object data, comprising: receiving a basic safety message and one or more sensor data sharing messages from a vehicle; determining the relevance of the basic safety message based at least in part on the location of the vehicle; and decoding or discarding the one or more sensor data sharing messages based on the relevance of the basic safety message.

[0206] Clause 46. The method of clause 45, wherein the basic safety message and the one or more sensor data sharing messages are received via a smart transport system networking and transport layer.

[0207] Clause 47. The method of clause 45, wherein the basic safety message and the one or more sensor data sharing messages each include an identification information element including a same identification value.

[0208] Clause 48. The method of clause 45, wherein the basic security message and the one or more sensor data sharing messages are each signed with the same security credential value.

[0209] Clause 49. The method of clause 45, wherein determining the relevance of the basic safety message is further based on a trajectory of the vehicle, a geometry of an environment near the vehicle, environmental conditions, or a combination thereof.

[0210] Clause 50. A method for partially filtering a sensor data sharing message, comprising: receiving the sensor data sharing message from a vehicle; decoding a first portion of the sensor data sharing message to determine an area of ​​interest associated with the vehicle; determining a relative position of the area of ​​interest; and decoding or discarding a second portion of the sensor data sharing message based on the relative position of the area of ​​interest.

[0211] Clause 51. The method of clause 50, wherein the area of ​​interest is a circle around the vehicle, and the first portion of the sensor data sharing message includes an information element for defining a radius of the circle.

[0212] Clause 52. The method of clause 51, wherein the area of ​​interest comprises a plurality of sub-areas near the vehicle.

[0213] Clause 53. A method according to clause 52, wherein the first portion of the sensor data sharing message includes one or more information elements, the one or more information elements including an array of index values ​​associated with a position offset of each sub-area of ​​the multiple sub-areas near the vehicle.

[0214] Clause 54. The method of clause 53, wherein determining the relative position of the area of ​​interest comprises determining the relative positions of the plurality of sub-areas proximate to the vehicle.

[0215] Clause 55. The method of clause 54, wherein determining the relative positions of the plurality of sub-areas in the vicinity of the vehicle is based on a heading of the vehicle.

[0216] Clause 56. A method according to clause 50, wherein the first portion of the sensor data sharing message includes one or more information elements associated with a heading of one or more objects detected by the vehicle, and decoding or discarding the second portion of the sensor data sharing message is based at least in part on the heading of one or more objects detected by the vehicle.

[0217] Clause 57. The method of clause 50, further comprising receiving a basic safety message including a current location of the vehicle, wherein the sensor data sharing message is associated with the basic safety message.

[0218] Clause 58. The method of clause 57, wherein the basic safety message and the sensor data sharing message each include an identification information element containing a same identification value.

[0219] Clause 59. The method of clause 50, wherein the sensor data sharing message is received via a smart transport system networking and transport layer.

[0220] Clause 60. A device comprising: a memory; at least one transceiver; at least one processor, the at least one processor being communicatively coupled to the memory and the at least one transceiver and configured to: receive a basic safety message and one or more sensor data sharing messages from a vehicle; determine the relevance of the basic safety message based at least in part on the location of the vehicle; and decode or discard the one or more sensor data sharing messages based on the relevance of the basic safety message.

[0221] Clause 61. The apparatus of clause 60, wherein the basic safety message and the one or more sensor data sharing messages are received via a smart transport system networking and transport layer.

[0222] Clause 62. The apparatus of clause 60, wherein the basic safety message and the one or more sensor data sharing messages each include an identification information element including a same identification value.

[0223] Clause 63. The apparatus of clause 60, wherein the basic security message and the one or more sensor data sharing messages are each signed with the same security credential value.

[0224] Clause 64. An apparatus according to clause 60, wherein the at least one processor is further configured to determine the relevance of the basic safety message based at least in part on a trajectory of the vehicle, a geometry of an environment near the vehicle, environmental conditions, or a combination thereof.

[0225] Clause 65. A device comprising: a memory; at least one transceiver; at least one processor, the at least one processor being communicatively coupled to the memory and the at least one transceiver and configured to: receive a sensor data sharing message from a vehicle; decode a first portion of the sensor data sharing message to determine an area of ​​interest associated with the vehicle; determine a relative position of the area of ​​interest; and decode or discard a second portion of the sensor data sharing message based on the relative position of the area of ​​interest.

[0226] Clause 66. The apparatus of Clause 65, wherein the area of ​​interest is a circle around the vehicle, and the first portion of the sensor data sharing message includes an information element defining a radius of the circle.

[0227] Clause 67. The apparatus of clause 66, wherein the area of ​​interest comprises a plurality of sub-areas near the vehicle.

[0228] Clause 68. An apparatus according to clause 67, wherein the first portion of the sensor data sharing message comprises one or more information elements, the one or more information elements comprising an array of index values ​​associated with a position offset of each of the multiple sub-areas near the vehicle.

[0229] Clause 69. The apparatus of clause 68, wherein the at least one processor is further configured to determine the relative position of the region of interest based at least in part on the relative positions of the plurality of sub-regions proximate to the vehicle.

[0230] Clause 70. The apparatus of clause 69, wherein the at least one processor is further configured to determine the relative positions of the plurality of sub-areas proximate to the vehicle based at least in part on a heading of the vehicle.

[0231] Clause 71. An apparatus according to clause 65, wherein the first portion of the sensor data sharing message includes one or more information elements associated with a heading of one or more objects detected by the vehicle, and the at least one processor is further configured to decode or discard the second portion of the sensor data sharing message based at least in part on the heading of one or more objects detected by the vehicle.

[0232] Clause 72. The apparatus of clause 65, wherein the at least one processor is further configured to receive a basic safety message including a current location of the vehicle, wherein the sensor data sharing message is associated with the basic safety message.

[0233] Clause 73. The apparatus of clause 72, wherein the basic safety message and the sensor data sharing message each include an identification information element including a same identification value.

[0234] Clause 74. The apparatus of clause 72, wherein the sensor data sharing message is received via a smart transport system networking and transport layer.

[0235] Clause 75. An apparatus for filtering detected object data, comprising: a component for receiving a basic safety message and one or more sensor data sharing messages from a vehicle; a component for determining the relevance of the basic safety message based at least in part on the location of the vehicle; and a component for decoding or discarding the one or more sensor data sharing messages based on the relevance of the basic safety message.

[0236] Clause 76. A device for partially filtering a sensor data sharing message, comprising: a component for receiving the sensor data sharing message from a vehicle; a component for decoding a first portion of the sensor data sharing message to determine an area of ​​interest associated with the vehicle; a component for determining a relative position of the area of ​​interest; and a component for decoding or discarding a second portion of the sensor data sharing message based on the relative position of the area of ​​interest.

[0237] Clause 77. A non-transitory processor-readable storage medium comprising processor-readable instructions, the processor-readable instructions being configured to cause one or more processors to filter detected object data, the processor-readable instructions comprising code for: receiving a basic safety message and one or more sensor data sharing messages from a vehicle; determining the relevance of the basic safety message based at least in part on a location of the vehicle; and decoding or discarding the one or more sensor data sharing messages based on the relevance of the basic safety message.

[0238] Clause 78. A non-transitory processor-readable storage medium comprising processor-readable instructions, the processor-readable instructions being configured to cause one or more processor portions to filter sensor data sharing messages, the processor-readable instructions comprising code for: receiving the sensor data sharing message from a vehicle; decoding a first portion of the sensor data sharing message to determine an area of ​​interest associated with the vehicle; determining a relative position of the area of ​​interest; and decoding or discarding a second portion of the sensor data sharing message based on the relative position of the area of ​​interest.

Claims

1. A method for providing detected object data, comprising: detecting one or more objects in the vicinity of the vehicle; organizing information associated with one or more detected objects in the vicinity of the vehicle into one or more data groups; generating a sensor data sharing message including host data and detected object data based on the information associated with the one or more detected objects in the vicinity of the vehicle, wherein the detected object data is organized based on the one or more data groups and the host data includes index information associated with the one or more data groups; as well as The sensor data sharing message is sent. 2 . The method of claim 1 , wherein the one or more data sets define an area surrounding the vehicle. 3 . The method of claim 2 , wherein the area is a circle around the vehicle and the host data includes a first information element for defining a radius of the circle. The method of claim 1 , wherein the one or more data sets define a plurality of areas in the vicinity of the vehicle. 5 . The method of claim 4 , wherein the host data comprises a second information element comprising an array of index values ​​associated with a position offset for each of the plurality of areas in the vicinity of the vehicle. The method of claim 1 , wherein the one or more data sets are associated with a heading of each of the one or more detected objects. 7 . The method of claim 1 , further comprising sending a basic safety message including a current location of the vehicle, wherein the sensor data sharing message is associated with the basic safety message. 8 . The method of claim 7 , wherein the basic safety message and the sensor data sharing message each include an identification information element including a same identification value.

9. The method of claim 1, wherein detecting the one or more objects near the vehicle is based on signals obtained by a radar sensor, a lidar sensor, an optical sensor, a radio frequency communication system, or a combination thereof.

10. A method for filtering detected object data, comprising: receiving a sensor data sharing message associated with a first vehicle including host data and detected object data, wherein the detected object data is organized into one or more data groups and the host data includes index information associated with the one or more data groups; determining an operating context of a second vehicle; as well as The one or more data groups are filtered based at least in part on the operating context of the second vehicle and the index information associated with the one or more data groups. The method of claim 10 , wherein the one or more data sets define an area surrounding the first vehicle. 12 . The method of claim 11 , wherein the area is a circle around the first vehicle and the host data includes a first information element for defining a radius of the circle.

13. The method of claim 10, wherein the one or more data sets define a plurality of areas proximate to the first vehicle.

14. The method of claim 13, wherein the host data includes second information including an array of index values ​​associated with a position offset for each of the plurality of areas in the vicinity of the first vehicle.

15. The method of claim 10, wherein the one or more data sets are associated with a heading of each of the one or more detected objects.

16. The method of claim 10, further comprising receiving a basic safety message including a current location of the first vehicle, wherein the sensor data sharing message is associated with the basic safety message.

17. The method of claim 16, wherein the basic safety message and the sensor data sharing message each include an identification information element including a same identification value.

18. The method of claim 10, wherein determining the operating context of the second vehicle comprises determining current positions of the first vehicle and the second vehicle, determining trajectories of the first vehicle and the second vehicle, determining a geometry of an environment near the second vehicle, or a combination thereof.

19. The method of claim 10, wherein determining the operating context of the second vehicle comprises determining current environmental conditions, determining current road conditions, determining performance factors associated with the second vehicle, or a combination thereof.

20. The method of claim 10, wherein filtering the one or more data groups comprises decoding the one or more data groups associated with the second vehicle, or discarding the one or more data groups not associated with the second vehicle.

21. An apparatus comprising: Memory; at least one transceiver; at least one processor, the at least one processor being communicatively coupled to the memory and the at least one transceiver and configured to: detecting one or more objects in the vicinity of the vehicle; organizing information associated with one or more detected objects in the vicinity of the vehicle into one or more data groups; generating a sensor data sharing message including host data and detected object data based on the information associated with the one or more detected objects in the vicinity of the vehicle, wherein the detected object data is organized based on the one or more data groups and the host data includes index information associated with the one or more data groups; as well as The sensor data sharing message is sent.

22. The apparatus of claim 21, wherein the at least one processor is further configured to send a basic safety message including a current location of the vehicle, wherein the sensor data sharing message is associated with the basic safety message.

23. The apparatus of claim 21, wherein the at least one processor is further configured to detect the one or more objects near the vehicle based on signals obtained by a radar sensor, a lidar sensor, an optical sensor, a radio frequency communication system, or a combination thereof.

24. An apparatus comprising: Memory; at least one transceiver; at least one processor, the at least one processor being communicatively coupled to the memory and the at least one transceiver and configured to: receiving a sensor data sharing message associated with a first vehicle including host data and detected object data, wherein the detected object data is organized into one or more data groups and the host data includes index information associated with the one or more data groups; determining an operating context of a second vehicle; as well as The one or more data groups are filtered based at least in part on the operating context of the second vehicle and the index information associated with the one or more data groups.

25. The apparatus of claim 24, wherein the one or more data sets are associated with a heading of each of the one or more detected objects.

26. The apparatus of claim 24, wherein the at least one processor is further configured to receive a basic safety message including a current location of the first vehicle, wherein the sensor data sharing message is associated with the basic safety message.

27. The apparatus of claim 26, wherein the basic safety message and the sensor data sharing message each include an identification information element including a same identification value.

28. An apparatus according to claim 24, wherein the at least one processor is further configured to determine the operating context of the second vehicle based at least in part on the current positions of the first vehicle and the second vehicle, the trajectories of the first vehicle and the second vehicle, the geometry of the environment near the second vehicle, or a combination thereof.

29. The apparatus of claim 24, wherein the at least one processor is further configured to determine the operating context of the second vehicle based at least in part on current environmental conditions, current road conditions, performance factors associated with the second vehicle, or a combination thereof.

30. The apparatus of claim 24, wherein the at least one processor is further configured to decode the one or more data groups associated with the second vehicle, or discard the one or more data groups not associated with the second vehicle to filter the one or more data groups.

Images