Sensor sharing configuration

Abstract

This disclosure provides systems, methods, and devices for wireless communication that support sensor sharing configuration. In a first aspect, a method of wireless communication includes receiving road congestion information associated with one or more areas. The method also includes receiving driving information associated with the one or more vehicles. The method also includes sending an indicator of a sensor sharing configuration for the one or more vehicles. The sensor sharing configuration is based on road congestion information and driving information. Other aspects and features are also claimed and described.

Description

TECHNICAL FIELD

[0001] Aspects of the present disclosure generally relate to wireless communication systems, and more particularly to sensor sharing configuration, such as sensor sharing configuration for sensor sharing congestion control determined by a network. Some features can enable and provide improved communications, including reduced communication overhead, improved network efficiency, improved resource and energy utilization, improved traffic safety messaging, reduction in traffic accidents, or combinations thereof. BACKGROUND

[0002] Wireless communication networks are widely deployed to provide various communication services such as voice, video, packet data, messaging, broadcast, etc. These wireless networks can be multiple-access networks capable of supporting multiple users by sharing the available network resources. Such networks can be multiple access networks allowing communications for multiple users by sharing the available network resources.

[0003] A wireless communication network can include a number of components. These components can include wireless communication devices such as a base station (or node B) that can support communication for a number of user equipments (UEs). A UE can communicate with a base station via the downlink and uplink. The downlink (or forward link) refers to the communication link from the base station to the UE, and the uplink (or reverse link) refers to the communication link from the UE to the base station.

[0004] A base station can send data and control information on the downlink to a UE or receive data and control information on the uplink from the UE. On the downlink, transmissions from the base station can encounter interference due to transmissions from neighbor base stations or other wireless radio frequency (RF) transmitters. On the uplink, transmissions from a UE can encounter interference from uplink transmissions of other UEs communicating with the neighbor base stations or from other wireless RF transmitters. This interference can degrade performance on both the downlink and uplink.

[0005] As the demand for mobile broadband access continues to increase, the possibilities of interference and congested networks grows with more UEs accessing the long-range wireless communication networks and more short-range wireless systems being deployed in communities. Research and development continue to advance wireless technologies not only to meet the growing demand for mobile broadband access, but to advance and enhance the user experience with mobile communications.

[0006] One increasingly focused area of wireless network research is the intersection of wireless communications and vehicular traffic. As vehicular technology advances, improvements to traffic control devices and other roadside devices are being pushed. Generally, a server (such as a cloud server) is configured to receive information from different devices of a traffic system (e.g., a traffic safety system), such as on-board units (OBUs) of vehicles, roadside units (RSUs), traffic control devices, user equipment (UEs), and the like. To illustrate, the server can receive one or more messages, such as application layer messages, including basic safety messages (BSMs), cooperative awareness messages (CAMs), collective perception messages (CPMs), sensor data sharing messages (SDSMs), other application layer messages, or combinations thereof. In some implementations, the messages received by the server can include sensor information or indications of detected objects. If the server receives multiple messages that each report the same detected object, network channel load (e.g., over-the-air (OTA) congestion) can increase, which can decrease packet reception rate (PRR) and object awareness rate (OAR). To limit the server from receiving multiple messages that each report the same detected object, the traffic system can implement one or more redundancy mitigation techniques (e.g., one or more sensor sharing mitigation techniques) to limit or reduce different devices of the traffic system sharing messages indicating the same detected object. The redundancy mitigation techniques can be configured to implement filtering or reduction of redundancies or unnecessary updates of information associated with sensed or detected objects. For example, the redundancy mitigation techniques can define one or more rules to omit a portion or subset of sensed or detected objects (e.g., sensor data) that satisfy at least one rule. OBUs and RSUs are generally limited to congestion detection in their immediate area. Although a vehicle can be aware of a planned travel route of the vehicle, the vehicle can be unable to determine or predict congestion along the planned route, or how the congestion can change. Thus, the vehicle can be unable to effectively select an appropriate redundancy mitigation technique when the vehicle travels along the planned route. As a result of not selecting or using an appropriate redundancy mitigation technique, the traffic system can continue to suffer from increased network channel load (e.g., increased OTA congestion). SUMMARY

[0007] The following summarizes some aspects of the present disclosure to provide a basic understanding of the technology discussed. This summary is not an extensive overview of all contemplated features of the present disclosure, and is not intended to identify key or critical elements of the present disclosure or to delineate the scope of any or all aspects thereof. Its sole purpose is to present some concepts of one or more aspects of the present disclosure in a general framework so as to provide a basic understanding of the aspects thereof for the

[0008] In one aspect of the disclosure, a method of communication is performed by a network entity. The method includes receiving road congestion information associated with one or more areas. The method also includes receiving travel information associated with one or more vehicles. The method also includes transmitting an indicator of a sensor sharing configuration for the one or more vehicles. The sensor sharing configuration is based on the road congestion information and the travel information.

[0009] In an additional aspect of the disclosure, a network entity includes a memory storing processor-readable code and at least one processor coupled to the memory. The at least one processor is configured to execute the processor-readable code to cause the at least one processor to receive road congestion information associated with one or more areas and receive travel information associated with one or more vehicles. The at least one processor is configured to execute the processor-readable code to cause the at least one processor to transmit or initiate transmission of an indicator of a sensor sharing configuration for the one or more vehicles. The sensor sharing configuration is based on the road congestion information and the travel information.

[0010] In an additional aspect of the disclosure, an apparatus for wireless communication includes means for receiving road congestion information associated with one or more areas. The apparatus also includes means for receiving travel information associated with one or more vehicles. The apparatus also includes means for transmitting an indicator of a sensor sharing configuration for the one or more vehicles. The sensor sharing configuration is based on the road congestion information and the travel information.

[0011] In an additional aspect of the disclosure, a non-transitory computer-readable medium stores instructions that, when executed by a processor, cause the processor to perform operations. The operations include receiving road congestion information associated with one or more areas. The operations also include receiving travel information associated with one or more vehicles. The operations also include transmitting an indicator of a sensor sharing configuration for the one or more vehicles. The sensor sharing configuration is based on the road congestion information and the travel information.

[0012] In an additional aspect of the disclosure, an apparatus includes a communication interface configured to receive road congestion information associated with one or more areas. The communication interface is further configured to receive travel information associated with one or more vehicles. The apparatus also includes at least one processor coupled to a memory storing processor-readable code. The at least one processor is configured to execute the processor-readable code to cause the at least one processor to generate an indicator of a sensor sharing configuration for the one or more vehicles. The sensor sharing configuration is based on the road congestion information and the travel information.

[0013] In an additional aspect of the disclosure, a method for wireless communication is performed by a network entity. The method includes transmitting road congestion information associated with an area. The method also includes receiving an indicator of a sensor sharing configuration for one or more vehicles. The sensor sharing configuration is based on the road congestion information and travel information associated with the one or more vehicles. The method also includes transmitting a message indicating the sensor sharing configuration to at least one vehicle.

[0014] In an additional aspect of the disclosure, a network entity includes a memory storing processor-readable code and at least one processor coupled to the memory. The at least one processor is configured to execute the processor-readable code to cause the at least one processor to transmit road congestion information associated with an area. The at least one processor is also configured to execute the processor-readable code to cause the at least one processor to receive an indicator of a sensor sharing configuration for one or more vehicles. The sensor sharing configuration is based on the road congestion information and travel information associated with the one or more vehicles. The at least one processor is further configured to execute the processor-readable code to cause the at least one processor to transmit a message indicating the sensor sharing configuration to at least one vehicle or initiate transmission of the message to at least one vehicle.

[0015] In an additional aspect of the disclosure, an apparatus for wireless communication includes means for transmitting road congestion information associated with an area. The apparatus also includes means for receiving an indicator of a sensor sharing configuration for one or more vehicles. The sensor sharing configuration is based on the road congestion information and travel information associated with the one or more vehicles. The apparatus also includes means for transmitting a message indicating the sensor sharing configuration to at least one vehicle.

[0016] In an additional aspect of the disclosure, a non-transitory computer-readable medium stores instructions that, when executed by a processor, cause the processor to perform operations. The operations include transmitting road congestion information associated with an area. The operations also include receiving an indicator of a sensor sharing configuration for one or more vehicles. The sensor sharing configuration is based on the road congestion information and travel information associated with the one or more vehicles. The operations also include transmitting a message indicating the sensor sharing configuration to at least one vehicle.

[0017] In an additional aspect of the disclosure, an apparatus includes a communication interface configured to transmit road congestion information associated with an area. The communication interface is further configured to receive an indicator of a sensor sharing configuration for one or more vehicles. The sensor sharing configuration is based on the road congestion information and travel information associated with one or more vehicles. The apparatus also includes at least one processor coupled to a memory storing processor-readable code. The at least one processor is configured to execute the processor-readable code to cause the at least one processor to generate a message indicating the sensor sharing configuration for at least one vehicle.

[0018] In an additional aspect of the disclosure, a method for communication is performed by a vehicle. The method includes transmitting travel information associated with the vehicle. The method also includes receiving a configuration message indicating a sensor sharing configuration for the vehicle. The sensor sharing configuration is based on the travel information and road congestion information associated with an area. The method further includes transmitting a message indicating a detected object based on the sensor sharing configuration.

[0019] In an additional aspect of the disclosure, a vehicle includes a memory storing processor-readable code and at least one processor coupled to the memory. The at least one processor is configured to execute the processor-readable code to cause the at least one processor to transmit travel information associated with the vehicle. The at least one processor is also configured to execute the processor-readable code to cause the at least one processor to receive a configuration message indicating a sensor sharing configuration for the vehicle. The sensor sharing configuration is based on the travel information and road congestion information associated with an area. The at least one processor is further configured to execute the processor-readable code to cause the at least one processor to transmit a message indicating a detected object based on the sensor sharing configuration.

[0020] In an additional aspect of the disclosure, an apparatus for communication includes means for transmitting travel information associated with a vehicle. The apparatus also includes means for receiving a configuration message indicating a sensor sharing configuration for the vehicle. The sensor sharing configuration is based on the travel information and road congestion information associated with an area. The apparatus further includes means for transmitting a message indicating a detected object based on the sensor sharing configuration.

[0021] In an additional aspect of the disclosure, a non-transitory computer-readable medium stores instructions that, when executed by a processor, cause the processor to perform operations. The operations include transmitting travel information associated with a vehicle. The operations also include receiving a configuration message indicating a sensor sharing configuration for the vehicle. The sensor sharing configuration is based on the travel information and road congestion information associated with a region. The operations also include transmitting a message indicating a detected object based on the sensor sharing configuration.

[0022] In an additional aspect of the disclosure, an apparatus includes a communication interface configured to transmit travel information associated with a vehicle. The communication interface is also configured to receive a configuration message indicating a sensor sharing configuration for the vehicle. The sensor sharing configuration is based on the travel information and road congestion information associated with a region. The apparatus also includes at least one processor coupled to a memory storing processor-readable code. The at least one processor is configured to execute the processor-readable code to cause the at least one processor to generate a message indicating a detected object based on the sensor sharing configuration.

[0023] The foregoing has outlined rather broadly the features and technical advantages of examples according to the disclosure in order that the detailed description that follows can be better understood. Additional features and advantages will be described hereinafter. The disclosed concepts and specific examples can be readily utilized as bases for modifying or designing other for carrying the same purposes thereof. Such equivalent constructions are not to depart from the scope of the claims. The characteristics of the concepts disclosed herein, both as organized and operated, together with the associated advantages, will be better understood from the following description when considered in connection with the accompanying drawings. Each of the figures is provided for the purpose of illustration and description, and is not intended as a definition of the limits of the claims.

[0024] While aspects and implementations are described in this application by illustration to some examples, those skilled in the art will understand that additional implementations and use cases can come about in many different arrangements and scenarios. The innovations described herein can be implemented across many differing platform types, devices, systems, form factors, and configurations. For example, various aspects and / or uses can be implemented via integrated chip implementations (e.g., chips) and other non-module-component based devices (e.g., end-user devices, vehicles, communication devices, computing devices, industrial equipment, retail / purchasing devices, medical devices, artificial intelligence (Al)-enabled devices, etc.). While some examples can or can not be specifically directed to use cases or applications, a wide assortment of applicability of the innovations described throughout will be recognized. The scope of the disclosed aspects is to be given by the appended claims and their equivalents. In some practical, real-world implementations, devices incorporating aspects and features described can necessarily include additional components and features for operation and implementation of the claimed aspects. For example, transmission and reception of wireless signals necessarily includes a number of components, hardware and software, for analog and digital purposes (e.g., antennas, radio frequency (RF) chains, power amplifiers, modulators, buffers, processors, interleavers, adders / summers, etc.). It is intended that the innovations described herein can be practiced in a wide variety of devices, chip-level components, systems, distributed arrangements, end-user devices, etc. of varying sizes, shapes, and constitution. BRIEF DESCRIPTION OF DRAWINGS

[0025] Further understanding of the nature and advantages of the disclosure can be realized by reference to the following drawings. In the drawings, like components or features can have the same reference label. Furthermore, various components of the same type can be distinguished by adding a dash and a second label that distinguishes among the goods of like-sounding components. If only the first reference label is used in the specification, the description is applicable to any one of the similar components having the same first reference label irrespective of the second reference label.

[0026] Figure 1 is a block diagram illustrating details of an example wireless communication system in accordance with one or more aspects.

[0027] Figure 2 is a block diagram illustrating an example of a base station and a user equipment (UE) in accordance with one or more aspects.

[0028] Figure 3 is a diagram illustrating an example disaggregated base station architecture in accordance with one or more aspects.

[0029] Figure 4is a block diagram illustrating an example wireless communications system that supports sensor sharing configuration in accordance with one or more aspects.

[0030] Figure 5 is a block diagram illustrating an example format of an information element that supports sensor sharing configuration in accordance with one or more aspects.

[0031] Figure 6 is a flow chart illustrating an example process that supports sensor sharing configuration in accordance with one or more aspects.

[0032] Figure 7 is a flow chart illustrating an example process that supports sensor sharing configuration in accordance with one or more aspects.

[0033] Figure 8 is a flow chart illustrating an example process that supports sensor sharing configuration in accordance with one or more aspects.

[0034] Figure 9 is a flow chart illustrating an example process that supports sensor sharing configuration in accordance with one or more aspects.

[0035] Figure 10 is a perspective view of a motor vehicle having a driver monitoring system in accordance with one or more aspects.

[0036] Figure 11 is a block diagram of an example network entity that supports sensor sharing configuration in accordance with one or more aspects.

[0037] Figure 12 is a block diagram of an example server that supports sensor sharing configuration in accordance with one or more aspects.

[0038] The same reference numbers and designations in the various drawings indicate the same elements. DETAILED DESCRIPTION

[0039] The detailed description set forth below, in connection with the appended drawings and embodiments described herinin, is intended as a description of various configurations and is not intended to limit the scope of the disclosure. Rather, the detailed description includes specific details for the purpose of providing a thorough understanding of the inventive subject matter. It will be apparent to those skilled in the art, from this disclosure, that the

[0040] The present disclosure provides systems, apparatuses, methods, and computer- readable media that support sensor sharing configuration. For example, a network of a transportation system can be configured to determine a sensor sharing configuration (e.g., a redundancy mitigation technique) to be used by a vehicle based on travel information of the vehicle. To illustrate, a server (e.g., a cloud server) of the transportation system can be configured to receive travel information associated with one or more vehicles. For example, the server can receive a basic safety message (BSM), a cooperative awareness message (CAM), a collective perception message (CPM), a sensor data sharing message (SDSM), or another message that includes or indicates travel information of one or more vehicles. Additionally, the server can determine congestion, such as traffic congestion or over-the-air (OTA) congestion, of one or more zones or areas based on congestion information received from one or more vehicles, one or more network entities, one or more user equipment (UEs), one or more road side units (RSUs), one or more base stations, or a combination thereof. In some implementations, the congestion information includes one or more channel busy ratio (CBR) measurements that are included in or indicated by one or more BSMs, one or more CAMs, one or more other messages, or a combination thereof. Additionally or alternatively, as an illustrative, non-limiting example, the server can determine congestion based on other information, such as a time of day (e.g., a peak hour), an emergency or dangerous situation, an event (e.g., a parade, a sporting event, a concert), historical travel data of the vehicle, or a combination thereof. Based on the travel information of the one or more vehicles and the determined congestion, the server can predict future locations of the one or more vehicles and determine a sensor sharing configuration, such as a mitigation technique or rule, a parameter for the mitigation technique or rule, or a combination thereof, for the one or more vehicles. The server can transmit an indicator to the one or more vehicles that indicates the sensor sharing configuration. For example, the sensor sharing configuration can be communicated to the one or more vehicles in a dedicated manner (e.g., an application layer or through Uu or PC5 signaling (PC5-S)) or in a common manner (e.g., a Uu-based system information block (SIB) broadcast or a PC5-based distance signaling).

[0041] Particular implementations of the subject matter described in this disclosure can be implemented to realize one or more of the following potential advantages or benefits. In some aspects, the disclosure provides techniques (e.g., redundancy mitigation techniques) for supporting sensor sharing configurations. For example, these techniques can enable a network (e.g., a server) to proactively determine a sensor sharing configuration for a vehicle based on travel information for the vehicle and determined congestion. By proactively determining a sensor sharing configuration for an area that the vehicle has not yet traveled to, the network can achieve more efficient spectrum utilization for one or more devices included in a transportation system as compared to relying on the vehicle to select a sensor sharing configuration. For example, the transportation system can experience improved communications, including reduced network channel load (e.g., reduced OTA congestion), improved network efficiency, improved resource and energy utilization, improved transportation safety messaging, reduction in traffic accidents, or a combination thereof.

[0042] The present disclosure generally relates to providing or participating in authorized shared access between two or more wireless devices in one or more wireless communication systems, also referred to as wireless communication networks. In various implementations, techniques and apparatuses can be used in wireless communication networks such as code division multiple access (CDMA) networks, time division multiple access (TDMA) networks, frequency division multiple access (FDMA) networks, orthogonal FDMA (OFDMA) networks, single-carrier FDMA (SC-FDMA) networks, LTE networks, GSM networks, 5thGeneration (5G) or new radio (NR) networks (sometimes referred to as “5G NR” networks, systems, or devices), as well as other communications networks. As described herein, the terms “network” and “system” can be used interchangeably.

[0043] For example, a CDMA network can implement a radio technology such as Universal Terrestrial Radio Access (UTRA), cdma2000, and the like. UTRA includes Wideband-CDMA (W-CDMA) and Low Chip Rate (LCR). CDMA2000 covers IS-2000, IS-95, and IS-856 standards.

[0044] For example, a TDMA network can implement a radio technology such as Global System for Mobile Communications (GSM). The third Generation Partnership Project (3 GPP) defines standards for the GSM EDGE (enhanced data rates for GSM evolution) radio access network (RAN) also referred to as GERAN. GERAN is the radio component of a GSM / EDGE network alongside with the network's core network and base stations (e.g., Ater and Abis interfaces) and controller (A interfaces, etc.). The radio access network represents the component of a GSM network that phones and packet data route to and from the public switched telephone network (PSTN) and Internet. A mobile phone operator's network can include one or more GERANs, which can couple with a UTRAN in the case of a UMTS / GSM network. Also, an operator network can include one or more LTE networks, or one or more other networks. The various different network types can use different radio access technologies (RATs) and RANs.

[0045] An OFDMA network can implement a radio technology such as evolved UTRA (E- UTRA), Institute of Electrical and Electronics Engineers (IEEE) 802.11, IEEE 802.16, IEEE 802.20, and flash-OFDM. UTRA, E-UTRA, and GSM are part of universal mobile telecommunication system (UMTS). In particular, long term evolution (LTE) is a release of UMTS that uses E-UTRA. UTRA, E-UTRA, GSM, UMTS, and LTE are described in documents from the organization named "3rd Generation Partnership Project" (3GPP) and cdma2000 is described in documents from an organization named "3rd Generation Partnership Project 2" (3GPP2). These various radio technologies and standards are known or are being developed. For example, 3GPP is a collaboration between groups of telecommunications associations that aims to define a globally applicable third generation (3G) mobile phone specification. 3GPP LTE is a 3GPP project to improve the UMTS mobile phone standard. The 3 GPP can define specifications for the next generation of mobile networks, mobile systems, and mobile devices. The present disclosure can describe certain aspects with reference to LTE, 4G, or 5G NR technology; however, such description is not intended to be limited to a particular technology or application, and reference to one or more aspects described with reference to one technology can be understood to reference an aspect of another technology. Additionally, one or more aspects of the present disclosure can relate to shared access to wireless spectrum between networks using different radio access technologies or radio air interfaces.

[0046] 5G networks contemplate diverse deployments, diverse spectrum, and diverse services and devices that can be implemented using an OFDM-based unified air interface. In order to meet these goals, further enhancements to LTE and LTE-A are considered in addition to development of the new radio technology for 5G NR networks. 5G NR will be capable of scaling to provide coverage (1) to a massive Internet of Things (IoT) with an ultra-high density (e.g., ~1M nodes / km2), ultra-low complexity (e.g., ~10s of bits / sec), ultra-low energy (e.g., -10+ years of battery life), and deep coverage with the capability to go beyond 1640 dB of coverage; (2) including mission-critical control with strong security to protect sensitive personal, financial, or classified information, ultra-high reliability (e.g., -99.9999% reliability), ultra-low latency (e.g., -1 ms), and users with wide ranges of mobility or lack thereof; and (3) with enhanced mobile broadband including extreme high capacity (e.g., - 10 Tbps / km2), extreme data rates (e.g., - 10 Gbps / user), and deep awareness with advanced discovery and optimizations.

[0047] Devices, networks, and systems can be configured to communicate via one or more portions of the electromagnetic spectrum. The electromagnetic spectrum is often subdivided, based on frequency / wavelength, into various classes, bands, channels, etc. In 5G NR, two initial operating bands have been identified as frequency Range Designations FR1 (410 MHz - 7.125 GHz) and FR2 (24.25 GHz - 52.6 GHz). The frequencies between FR1 and FR2 are often referred to as mid-band frequencies. Although a portion of FR1 is greater than 6 GHz, FR1 is often (interchangeably) referred to as a “Sub-6 GHz” band in various documents and articles. A similar nomenclatural issue sometimes occurs with respect to FR2, which is often (interchangeably) referred to as a “millimeter wave” (mmWave) band in documents and articles, despite being different from the extremely high frequency (EHF) band (30 GHz - 300 GHz) which is identified by the International Telecommunications Union (ITU) as a “mmWave” band.

[0048] With the above aspects in mind, unless specifically stated otherwise, it should be understood that the term “Sub-6 GHz” or the like, if used herein, can broadly represent frequencies that can be less than 6 GHz, can be within FR1, or can include mid-band frequencies. Further, unless specifically stated otherwise, it should be understood that the term “mmWave” or the like, if used herein, can broadly represent frequencies that can include mid-band frequencies, can be within FR2, or can be within the EHF band.

[0049] 5G NR devices, networks, and systems can be implemented to take advantage of waveform characteristics that are based on optimized OFDM. These characteristics can include scalable numerology and transmission time intervals (TTIs); a common, flexible framework to efficiently multiplex services and features with dynamic, low-latency time -division duplex (TDD) or frequency-division duplex (FDD) designs; and advanced wireless technologies such as massive multiple input, multiple output (MIMO), robust millimeter wave transmissions, advanced channel coding, and device-centric mobility. Scalability of numerologies and scaling of subcarrier spacing in 5G NR can efficiently address operation of diverse services across diverse spectrum and diverse deployments. For example, in various outdoor and macro coverage deployments of sub-3 GHz FDD or TDD implementations, subcarrier spacing can occur at 15 kHz, for example, with bandwidths of 1 MHz, 5 MHz, 10 MHz, 20 MHz, and so on, that are overcome. For other various outdoor and small cell coverage deployments of TDD greater than 3 GHz, subcarrier spacing can occur at 30 kHz over 80 MHz / 100 MHz bandwidth. For other various indoor wideband implementations, subcarrier spacing can occur at 60 kHz over 160 MHz bandwidth using TDD on the unlicensed portion of the 5 GHz band. Finally, for various deployments transmitting through mmWave components at TDD of 28 GHz, subcarrier spacing can occur at 120 kHz over 500 MHz bandwidth.

[0050] The scalable numerology of 5G NR facilitates an extensible TTI for diverse latency and quality of service (QoS) requirements. For example, shorter TTIs can be used for low latency and high reliability, while longer TTIs can be used for higher spectral efficiency. Efficient multiplexing of long and short TTIs allows for transmissions to start at symbol boundaries. 5G NR also contemplates a self-contained integrated subframe design, where uplink or downlink scheduling information, data, and acknowledgements are located in the same subframe. The self-contained integrated subframe supports communications in unlicensed or contention-based shared spectrum, with adaptive uplink or downlink that can be flexibly configured on a per-cell basis to dynamically switch between uplink and downlink to meet current traffic demands.

[0051] For clarity, certain aspects of the apparatus and techniques can be described below referring to example 5G NR implementations or in a 5G-centric manner; however, the description is not intended to be limited to 5G applications.

[0052] Further, it should be appreciated that wireless communication networks adapted in accordance with the concepts herein can operate with any combination of licensed or unlicensed spectrum according to the load and availability in operation. As such, it will be apparent to one of ordinary skill in the art that the systems, apparatus and methods described herein can be applied to other communications systems and applications than the particular examples provided.

[0053] While aspects and implementations are described in this application by illustration to some examples, those skilled in the art will understand that additional implementations and use cases can come about in many different arrangements and scenarios. Innovations described herein can be implemented across many differing platform types, devices, systems, form factors, and so on. For example, implementations or use cases can be realized in conjunction with integrated chip implementations or other non-module-component based devices (e.g., end-user devices, vehicles, communication devices, computing devices, industrial equipment, retail devices or purchasing devices, medical devices, AI-enabled devices, and / or the like). While some examples can or can not be specifically directed to use cases or applications, a wide assortment of applicability of the described innovations can occur. Implementations can range from chip-level or modular components to non-modular, non-chip-level implementations, and further to aggregate, distributed, or original equipment manufacturer (OEM) devices or systems incorporating one or more of the described aspects. In some practical environments, devices incorporating described aspects and features can necessarily include additional components and features to enable and practice the claimed and described aspects. It is intended that innovations described herein can be practiced in a wide variety of implementations, including both large and small devices, chip-level components, multi-component systems (e.g., radio frequency (RF) chains, communication interfaces, processors), distributed arrangements, end-user devices, and / or the like.

[0054] Figure 1 is a block diagram illustrating details of an example wireless communication system in accordance with one or more aspects. The wireless communication system can include wireless network 100. Wireless network 100 may, for example, include a 5G wireless network. As recognized by those skilled in the art, Figure 1 Components appearing in the middle can likely have related counterpart components in other network arrangements, including for example, cellular-style network arrangements and non-cellular-style network arrangements (e.g., device-to-device or peer-to-peer or ad hoc network arrangements, etc.).

[0055] Figure 1The wireless network 100 as illustrated includes a number of base stations 105 and other network entities. A base station can be a station that communicates with the UEs and can also be referred to as an evolved node B (eNB), a next generation eNB (gNB), and an access point, among other examples. Each base station 105 can provide communication coverage for a particular geographic area. In 3 GPP, the term "cell" can refer to this particular geographic coverage area of a base station or a base station subsystem serving the coverage area, depending on the context in which the term is used. In the implementations of wireless network 100 herein, a base station 105 can be associated with a same operator or different operators (e.g., the wireless network 100 can include a plurality of operator wireless networks). Additionally, in the implementations of wireless network 100 herein, a base station 105 can provide wireless communication

[0056] A base station can provide communication coverage for a macro cell or a small cell, such as a pico cell or a femto cell, or other types of cells, or combinations thereof. A macro cell can generally cover a relatively large geographic area (e.g., 100s of feet to 10s of km in radius) and can allow unrestricted access by UEs with service subscriptions with the network provider. A small cell, such as a pico cell, can generally cover a relatively small geographic area (e.g., 100s of feet to 10s of km in radius) and can allow unrestricted access by UEs with service subscriptions with the network provider. A small cell, such as a femto cell, can also generally cover a relatively small geographic area (e.g., a home) and, in addition to unrestricted access, can also provide restricted access by UEs having Figure 1 In the illustrated example, base stations 105d and 105e are regular macro base stations of a network while base stations 105a-105c are macro base stations that utilize one of three-dimensional (3D), full-dimensional (FD), or massive MIMO. Base stations 105a-105c utilize their higher dimensionality MIMO capabilities to employ 3D beamforming in elevation and azimuth to increase coverage and capacity. Base station 105f is a small cell base station, which can be a home node or an access point. Base stations can support one or multiple (e.g., two, three, and four, etc.) cells.

[0057] Wireless network 100 can support synchronous or asynchronous operation. For synchronous operation, the base stations can have similar frame timings, and transmissions from different base stations can be approximately aligned in time. For asynchronous operation, the base stations can have different frame timings, and transmissions from different base stations can not be aligned in time. In some scenarios, networks can be enabled or configured to handle dynamic switching between synchronous or asynchronous operations.

[0058] The UEs 115 are dispersed throughout the wireless network 100, and each UE can be stationary or mobile. It should be appreciated that, although a mobile apparatus is commonly referred to as a UE in standards and specifications issued by the 3GPP, such an apparatus can alternatively or additionally be referred to by those skilled in the art as a mobile station (MS), a subscriber station, a mobile unit, a subscriber unit, a wireless unit, a remote unit, a mobile device, a wireless device, a wireless communication device, a remote device, a mobile subscriber station, an access terminal (AT), a mobile terminal, a wireless terminal, a remote terminal, a handset, a terminal, a user agent, a mobile client, a client, a gaming device, an augmented reality device, a vehicular component, a vehicular device, or a vehicular module, or some other suitable terminology. In the present document, a “mobile” apparatus or UE need not necessarily have a capability to move, and can be stationary. Some non-limiting examples of mobile apparatuses such as one or more of the UEs 115 can include specific implementations of a mobile telephone, a cellular telephone (cell phone), a smart phone, a session initiation protocol (SIP) phone, a wireless local loop (WLL) station, a laptop, a personal computer (PC), a notebook, a netbook, a smartbook, a tablet, and a personal digital assistant (PDA). A mobile apparatus can additionally be an IoT or “Internet of Everything” (IoE) device such as an automobile or other transportation vehicle, a satellite radio, a global positioning system (GPS) device, a global navigation satellite system (GNSS) device, a logistics controller, a drone, a multicopter, a quadcopter, a smart energy or security device, a solar panel or solar array, municipal lighting, water, or other infrastructure; an industrial automation and enterprise device; a consumer and wearable device such as eyewear, a wearable camera, a smartwatch, a health or fitness tracker, a mammal-implantable device, a posture-tracking device, a medical device, a digital audio player (e.g., MP3 player), a camera, a game console, etc.; and a digital home or smart home device such as a home audio, video, and multimedia device, an appliance, a sensor, a kiosk, smart lighting, a home security system, a smart meter, etc. In one aspect, a UE can be a device that includes a universal integrated circuit card (UICC). In another aspect, a UE can be a device that does not include a UICC. In some aspects, UEs that do not include UICCs can also be referred to as IoT devices. Figure 1The exemplified specific implementation UEs 115a-115d are examples of mobile smart phone type devices accessing the wireless network 100. A UE can also be a machine specifically configured for connected communications, including machine type communication (MTC), enhanced MTC (eMTC), and narrowband IoT (NB-IoT), among others. Figure 1 The exemplified UEs 115e-115k are examples of various machines configured for communication that access the wireless network 100.

[0059] A mobile device, such as a UE 115, can be able to communicate as and / or operate with any type of the base stations, whether macro base stations, pico base stations, femto base stations, and relays, among others. In Figure 1 In the example of FIG. 1, communication links (indicated as xh) between base stations 105 and UEs 115, as well as communication links (indicated as xh) between base stations 105, represent wireless transmissions between UEs 115 and base stations 105, or between base stations 105, or between base stations 105 and network equipment, which can be wired or wireless transmissions. A UE 115 can be capable of communicating with macro base stations, small cell base stations, and / or other relays. Base stations 105 utilize a

[0060] In operation, at the wireless network 100, base stations 105a-105c serve UEs 115a and 115b using 3D beamforming and coordinated spatial techniques, such as coordinated multipoint (CoMP) or multi-connectivity, among other techniques. Macro base station 105d performs backhaul communications with base stations 105a-105c, as well as small cell (base station 105f). Macro base station 105d also transmits multicast services which are subscribed to and received by UEs 115c and 115d. Such multicast services can include mobile television or stream video, or can include other services for providing community information, such as weather emergencies or alerts, such as Amber alerts or gray alerts.

[0061] The particular implemented wireless network 100 supports mission critical communications with ultra-reliable and redundant links for mission critical devices, such as the UE 115e, which is a drone. Redundant communication links with the UE 115e include links from the macro base stations 105d and 105e and the small cell base station 105f. Other machine type devices, such as the UE 115f (thermometer), the UE 115g (smart meter), and UE 115h (wearable device) can communicate through the wireless network 100 directly with base stations, such as the small cell base station 105f and the macro base station 105e, or through communication with another user device which relays its information to the network, such as UE 115f communicating temperature measurement information to the smart meter UE 115g, which then reports it to the network through the small cell base station 105f. The wireless network 100 can also provide additional network efficiency through dynamic, low-latency TDD communications or low-latency FDD communications, such as in a vehicle-to-vehicle (V2V) mesh network between UEs 115i-115k in communication with macro base station 105e. In addition, the V2V mesh network can include or correspond to a vehicle-to-everything (V2X) network between UEs 115i-115k and one or more other devices, such as UEs 115x, 115y, or UE 115z (e.g., a road side unit (RSU)).

[0062] The base stations 105 can communicate with the core network 130 and with one another. For example, the base stations 105 can interface with the core network 130 through backhaul links 132 (e.g., via an SI, N2, N3, or other interface). The base stations 105 can communicate with one another over backhaul links 134 (e.g., via an X2, Xn, or other interface) either directly (e.g., direct

[0063] The core network 130 can provide user authentication, access authorization, tracking, Internet Protocol (IP) connectivity, and other access, routing, or mobility functions. The core network 130 can be an evolved packet core (EPC), which can include at least one mobility management entity (MME), at least one serving gateway (S-GW), and at least one Packet Data Network (PDN) gateway (P-GW). The MME can manage non-access stratum (e.g., control plane) functions such as mobility, authentication, and bearer management for UEs 115 served by base stations 105 associated with the EPC. User IP packets can be transferred through the S-GW, which itself can be connected to the P-GW. The P-GW can provide IP address allocation as well as other functions. The P-GW can be connected to the network operators IP services. The operators IP services can include the Internet, an intranet, an IP multimedia subsystem (IMS), or a packet-switched (PS) streaming service.

[0064] In some implementations, the core network 130 includes or is coupled to management functions such as Location Management Function (LMF) 131, Sensing Management Function (SnMF), or Access and Mobility Management Function (AMF) that are entities in the 5G core network (5GC) that support various functionalities, such as managing support for different location services for one or more UEs. The SnMF can be configured to manage support for sensing operations of one or more sensing operations or sensing services for one or more devices, such as one or more UEs 115, one or more base stations 105, one or more TRPs, or combinations thereof. For example, the SnMF may include one or more servers, such as multiple distributed servers. Base station 105 may forward sensing messages to the SnMF and may communicate with the SnMF via NR Location Protocol A (NRPPa). The SnMF is configured to control sensing parameters of UE 115, and the SnMF may provide information to base station 105 and UE 115 enabling actions to be taken at UE 115, base station 105, or another device. LMF 131 may include one or more servers, such as multiple distributed servers. Base station 105 can forward location messages to LMF 131 and can communicate with LMF 131 via NR Positioning Protocol A (NRPPa). LMF 131 is configured to control the positioning parameters of UE 115, and LMF 131 can provide information to base station 105 and UE 115, enabling actions to be taken at UE 115. In some implementations, UE 115 and base station 105 are configured to communicate with LMF 131 via AMF.

[0065] Figure 2 This is a block diagram illustrating an example of a base station 105 and a UE 115 according to one or more aspects. The base station 105 and the UE 115 can be... Figure 1 This refers to any one of the base stations and one of the UEs in the system. For restricted association scenarios (as mentioned above), base station 105 can be... Figure 1 The base station 105 is a small cell base station, and UE 115 can be UE 115c or 115d operating within the service area of ​​base station 105f. UE 115 will be included in the list of accessible UEs of small cell base station 105f in order to access it. Base station 105 can also be some other type of base station. Figure 2 As shown, base station 105 may be equipped with antennas 234a to 234t, and UE 115 may be equipped with antennas 252a to 252r for facilitating wireless communication.

[0066] At base station 105, a transmit processor 220 can receive data from a data source 212 and control information from a controller 240, such as a processor. The control information can be for the physical broadcast channel (PBCH), physical control format indicator channel (PCFICH), physical hybrid ARQ (automatic repeat request) indicator channel (PHICH), physical downlink control channel (PDCCH), enhanced physical downlink control channel (EPDCCH), MTC physical downlink control channel (MPDCCH), etc. The data can be for the physical downlink shared channel (PDSCH), etc. In addition, transmit processor 220 can process (e.g., encode and symbol map) the data and control information to obtain data symbols and control symbols, respectively. Transmit processor 220 can also generate reference symbols, e.g., for the primary synchronization signal (PSS) and secondary synchronization signal (SSS), and cell-specific reference signals. A transmit (TX) MIMO processor 230 can perform spatial processing (e.g., precoding) on the data symbols, control symbols, or reference symbols, if applicable, and can provide output symbol streams to modulators (MODs) 232a through 232t. For example, spatial processing performed on the data symbols, control symbols, or reference symbols can include precoding. Each modulator 232 can process a respective output symbol stream (e.g., for OFDM, etc.) to obtain an output sample stream. In addition, or alternatively, each modulator 232 can process the output sample stream (e.g., convert it to analog, amplify it, filter it, and up-convert it) to obtain a downlink signal. Downlink signals from modulators 232a through 232t can be transmitted via antennas 234a through 234t, respectively.

[0067] At UE 115, antennas 252a through 252r can receive the downlink signals from base station 105 and can provide received signals to demodulators (DEMOD) 254a through 254r, respectively. Each demodulator 254 can condition (e.g., filter, amplify, downconvert, and digitize) a respective received signal to obtain input samples. Each demodulator 254 can further process the input samples (e.g., for OFDM, etc.) to obtain received symbols. A MIMO detector 256 can obtain received symbols from demodulators 254a through 254r, perform MIMO detection on the received symbols if applicable, and provide detected symbols. A receive processor 258 can process (e.g., demodulate, deinterleave, and decode) the detected symbols, provide decoded data for UE 115 to a data sink 260, and provide decoded control information to a controller 280, such as a processor.

[0068] On the uplink, at the UE 115, a transmit processor 264 can receive and process data (e.g., for the physical uplink shared channel (PUSCH)) from a data source 262 and control information (e.g., for the physical uplink control channel (PUCCH)) from the controller 280. Additionally, the transmit processor 264 can also generate reference symbols for a reference signal. The symbols from the transmit processor 264 can be precoded by a TX MIMO processor 266 if applicable, further processed by modulators 254a through 254r (e.g., for SC-FDM, etc.), and transmitted to the base station 105. At the base station 105, the uplink signals from the UE 115 can be received by the antennas 234, processed by the demodulators 232, detected by a MIMO detector 236 if applicable, and further processed by a receive processor 238 to obtain decoded data and control information sent by the UE 115. The receive processor 238 can provide the decoded data to a data sink 239 and to the controller 240.

[0069] The controllers 240 and 280 can direct the operation at the base station 105 and the UE 115, respectively. The controller 240 or other processor and module at the base station 105 or the controller 280 or other processor and module at the UE 115 can perform or direct the execution of various processes for the techniques described herein, such as to perform or direct the execution of processes described with reference to the above figures, or other processes for the techniques described herein. Memories 242 and 282 can store data and program codes for the base station 105 and the UE 115, respectively. A scheduler 244 can schedule UEs for data transmission on the downlink or uplink. Figure 6 to Figure 9

[0070] ​In some cases, the UEs 115 and base stations 105 can operate in a shared radio frequency spectrum band, which can include licensed or unlicensed frequency spectrum. In an unlicensed frequency portion of the shared radio frequency spectrum band, UEs 115 or base stations 105 can traditionally perform a medium-sensing procedure to contend for access to the spectrum. For example, the UEs 115 or base stations 105 can perform a listen before talk or listen before transmit (LBT) procedure, such as a clear channel assessment (CCA), before communicating in order to determine whether the shared channel is available. In some implementations, a CCA can include an energy detection procedure to determine whether there are any other active transmitters. For example, a device can infer that a change in the received signal strength indicator (RSSI) of a power meter indicates that the channel is occupied. In particular, a signal power that is concentrated in some bandwidth and exceeds a predetermined noise floor can indicate another wireless transmitter. A CCA can also include detection of specific sequences indicating use of the channel. For example, another device can transmit a specific preamble

[0071] Figure 3 An illustration diagram illustrating an example disaggregated base station 300 architecture is shown. The disaggregated base station 300 architecture can include one or more central units (CU) 310 that can communicate directly with a core network 320 via a backhaul link, or indirectly through one or more disaggregated base station units, such as a near real-time (near-RT) RAN intelligent controller (RIC) 325 via an E2 link, or a non-RT RIC 315 associated with a service management and orchestration (SMO) framework 305, or both. The core network 320 can include or correspond to the core network 130. The CU 310 can communicate with one or more distributed units (DU) 330 via respective fronthaul links, such as an Fl interface. The DU 330 can communicate with one or more radio units (RU) 340 via respective front-haul links. The RU 340 can communicate with respective UEs 115 via one or more radio frequency (RF) access links. In some implementations, a UE 115 can be simultaneously served by multiple RUs 340.

[0072] Each of the units (i.e., CU 310, DU 330, RU 340, and near-RT RIC 325, non-RT RIC 315, and SMO framework 305) can include or be coupled to one or more interfaces configured to receive or transmit signals, data, or information (collectively, signals) via wired or wireless transmission media. Each of the units, or an associated processor or controller providing instructions to the communication interfaces of these units, can be configured to communicate with one or more of the other units via the transmission media. For example, the units can include wired interfaces configured to receive or transmit signals to one or more of the other units over a wired transmission medium. In addition, the units can include wireless interfaces, which can include receivers, transmitters, or transceivers (such as radio frequency (RF) transceivers) configured to receive or transmit signals to one or more of the other units over a wireless transmission medium, or both.

[0073] In some aspects, the CU 310 can host one or more higher layer control functions. Such control functions can include radio resource control (RRC), packet data convergence protocol (PDCP), service data adaptation protocol (SDAP), etc. Each control function can utilize an interface configured to communicate signals with other control functions hosted by the CU 310. The CU 310 can be configured to handle user plane functionality (i.e., central unit-user plane (CU-UP)), control plane functionality (i.e., central unit-control plane (CU-CP)), or a combination thereof. In some implementations, the CU 310 can be logically split into one or more CU-UP units and one or more CU-CP units. When implemented in an O-RAN configuration, the CU-UP units can communicate bi-directionally with the CU-CP units via an interface, such as an El interface. As needed, the CU 310 can be implemented to communicate with the DU 330 for network control and signaling.

[0074] The DUs 330 can correspond to logical units that include one or more base station functions for controlling operation of one or more RUs 340. In some aspects, the DUs 330 can host one or more of a radio link control (RLC) layer, a medium access control (MAC) layer, and one or more high physical (PHY) layers (such as modules for forward error correction (FEC) encoding and decoding, scrambling, modulation and demodulation, etc.), depending at least in part on a functional split, such as a functional split defined by the Third Generation Partnership Project (3GPP). In some aspects, the DUs 330 can also host one or more low PHY layers. Each layer (or module) can be implemented with an interface configured to communicate signals with other layers (and modules) hosted by the DUs 330 or with control functions hosted by the CUs 310.

[0075] Lower layer functionality can be implemented by one or more RUs 340. In some deployments, the RUs 340 controlled by the DUs 330 can correspond to logical nodes that host RF processing functions or low PHY layer functions (such as performing fast Fourier transform (FFT), inverse FFT (iFFT), digital beamforming, physical random access channel (PRACH) extraction and filtering, etc.), or both, based at least in part on a functional split, such as a lower layer functional split. In such architectures, the RUs 340 can be implemented to handle over-the-air (OTA) communications with one or more UEs 115. In some implementations, real-time and non-real-time aspects of control plane and user plane communications with the RUs 340 can be controlled by the corresponding DUs 330. In some scenarios, this configuration can enable the DUs 330 and CUs 310 to be implemented in a cloud-based RAN architecture, such as a vRAN architecture.

[0076] The SMO framework 305 can be configured to support RAN deployment and orchestration of non-virtualized network elements and virtualized network elements. For non- virtualized network elements, the SMO framework 305 can be configured to support deployment of dedicated physical resources for RAN coverage requirements, which can be managed via an operations and maintenance interface, such as an Ol interface. For virtualized network elements, the SMO framework 305 can be configured to interact with a cloud computing platform, such as Open Cloud (O-Cloud) 390, to perform network element lifecycle management, such as to instantiate virtualized network elements, via a cloud computing platform interface, such as an 02 interface. Such virtualized network elements can include, but are not limited to, CUs 310, DUs 330, RUs 340, and near-RT RICs 325. In some implementations, the SMO framework 305 can communicate with hardware aspects of a 4G RAN, such as Open eNB (O-eNB) 311, via an Ol interface. Additionally, in some implementations, the SMO framework 305 can communicate directly with one or more RUs 340 via an Ol interface. The SMO framework 305 can also include a non-RT RIC 315 configured to support functionality of the SMO framework 305.

[0077] The non-RT RIC 315 can be configured to include logical functions that enable near real-time control and optimization of RAN elements and resources, artificial intelligence / machine learning (AI / ML) workflows including model training and updates, or policy-based direction of applications / features in the near-RT RIC 325. The non-RT RIC 315 can be coupled to, or in communication with, the near-RT RIC 325, such as via an Al interface. The near-RT RIC 325 can be configured to include logical functions that enable near real-time control and optimization of RAN elements and resources via data collection and actions through an interface, such as via an E2 interface, that connects one or more CUs 310, one or more DUs 330, or both, and an O-eNB with the near-RT RIC 325.

[0078] In some implementations, to generate AI / ML models to be deployed in near-RT RIC 325, non-RT RIC 315 can receive parameters or external enrichment information from an external server. Such information can be utilized by near-RT RIC 325 and can be received at SMO framework 305 or non-RT RIC 315 from non-network data sources or from network functions. In some examples, non-RT RIC 315 or near-RT RIC 325 can be configured to tune RAN behavior or performance. For example, non-RT RIC 315 can monitor long-term trends and patterns of performance and employ AI / ML models to perform corrective actions through SMO framework 305, such as via reconfiguration of Ol, or via creation of RAN management policies, such as Al policies.

[0079] As described herein, a node (which can be referred to as a node, network node, network entity, or wireless node) can include, be, or be included in (e.g., as a component of) a base station (e.g., any of the base stations described herein), a transmission reception point (TRP), a UE (e.g., any of the UEs described herein), a network controller, an apparatus, a device, a computing system, an integrated access and backhaul (IAB) node, a distributed unit (DU), a central unit (CU), a remote unit (RU), a core network, an LFM, a server, and / or another processing entity configured to perform any of the techniques described herein. For example, a network node can be a UE. For another example, a network node can be a base station or network entity. For yet another example, a first network node can be configured to communicate with a second network node or a third network node. In one aspect of this example, the first network node can be a UE, the second network node can be a base station, and the third network node can be a UE. In another aspect of this example, the first network node can be a UE, the second network node can be a base station, and the third network node can be a base station. In yet other aspects of this example, the first network node, the second network node, and the third network node can be different with respect to these examples. Similarly, a reference to a UE, a base station, an apparatus, a device, a computing system, etc. can include the disclosure of the UE, the base station, the apparatus, the device, the computing system, etc. as a network node. For example, the disclosure of a UE configured to receive information from a base station also discloses a first network node configured to receive information from a second network node. Once a particular example is extended in accordance with the present disclosure (e.g., the disclosure of a UE configured to receive information from a base station also discloses a first network node configured to receive information from a second network node), the broader example of the narrower example can be interpreted in reverse, but in a broad, open-ended fashion. In the above example where the disclosure of a UE configured to receive information from a base station also discloses a first network node configured to receive information from a second network node, the first network node can refer to a first UE, a first base station, a first apparatus, a first device, a first computing system, a first one or more components, a first processing entity, etc. configured to receive the information; and the second network node can refer to a second UE, a second base station, a second apparatus, a second device, a second computing system, a second one or more components, a second processing entity, etc.

[0080] As described herein, different terminology can be used in various aspects to describe the communication of information (e.g., any information, signals, and / or the like). The disclosure of one communication term includes the disclosure of other communication terms. For example, a first network node can be described as being configured to transmit information to a second network node. In this example and consistent with the disclosure, the disclosure of the first network node being configured to transmit information to the second network node includes the disclosure of the first network node being configured to provide, communicate, output, convey, or send information to the second network node. Similarly, in this example and consistent with the disclosure, the disclosure of the first network node being configured to transmit information to the second network node includes the disclosure of the second network node being configured to receive, obtain, or decode the information provided, communicated, output, conveyed, or sent by the first network node.

[0081] Figure 4 is a block diagram of an example wireless communication system 400 that supports sensor sharing configuration in accordance with one or more aspects. In some examples, wireless communication system 400 can implement aspects of wireless network 100. Wireless communication system 400 includes UE 115, vehicle 401, vehicle 422, network entity 430, server 450, and map service server 490. In some implementations, vehicle 401 or 422 can include or correspond to UE 115e, 115i, 115j, 115k of Figure 1 In some implementations, vehicle 401, vehicle 422, and UE 115, or a combination thereof, can be referred to individually or collectively as a vehicle system. In some implementations, UE 115 can include or correspond to a device of a pedestrian (e.g., a VRU). For example, as an illustrative, non-limiting example, a device of a pedestrian can include or correspond to UE 115a, 115b, 115c, 115d, 114h, 115x, or 115y. Network entity 430 can include one or more base stations (e.g., 105), road side units (RSUs), traffic control devices, or a combination thereof.

[0082] Although Figure 4 Although one UE 115, two vehicles 401 and 422, and one network entity 430 are illustrated, in some other implementations, wireless communication system 400 can generally include multiple UEs 115, one or more vehicles 401, 422, multiple network entities 430, or a combination thereof. Note that vehicle 401 and vehicle 422 can also be referred to as mobile entities - e.g., vehicle 401 is a first mobile entity and vehicle 422 is a second mobile entity. Vehicle 401 or vehicle 422 can include or correspond to a device as described herein at least with reference to Figure 10Further described vehicles. In some implementations, the network entity 430 and the server 450 can be referred to individually or collectively as a network, a network device, or a network system (e.g., a safety system or a transportation system).

[0083] In some implementations, the wireless communication system 400 includes a vehicle-to-everything (V2X) wireless communication system. V2X is a communication system in which information is communicated between vehicles and other entities within a wireless communication network that provides V2X services. V2X services can include services for vehicle-to-vehicle (V2V), vehicle-to-pedestrian (V2P), vehicle-to-infrastructure (V2I), and vehicle-to-network (V2N). One or more V2X standards aim to develop or support advanced driver assistance systems (ADAS) that assist drivers in making critical decisions, such as lane changes, speed changes, overtake speeds, etc. Low latency communications can be used in V2X and thus are applicable for precise positioning. For example, positioning techniques such as time of arrival (TOA), time difference of arrival (TDOA), or observed time difference of arrival (OTDOA), or any other positioning techniques can be enhanced using assistance from V2X.

[0084] In some implementations, there can be at least two modes of operation for V2X services, as defined in Third Generation Partnership Project (3GPP) TS 23.285. One mode of operation uses direct wireless communication between V2X entities when they are within range of each other. Another mode of operation uses network-based wireless communication between entities. The two modes of operation can be combined, or other modes of operation can be used if needed.

[0085] In some implementations, wireless communication of the V2X wireless communication system can be over a Proximity-based Services (ProSe) Direct Communication (PC5) reference point as defined in 3GPP TS 23.303, and can use wireless communication according to Institute of Electrical and Electronics Engineers (IEEE) 1609, Wireless Access

[0086] In some implementations, the wireless communication system 400 is associated with one or more zones 419 (hereinafter collectively referred to as “zone 419”). As an illustrative, non-limiting example, a zone 419 can include or also be referred to as a geographic region, a division, or a communication service area. A zone 419 can include one or more roads, one or more intersections, or a combination thereof.

[0087] In some implementations, the UE 115, the vehicle 401, the vehicle 422, the network entity 430, or a combination thereof can be positioned within the zone 419. Although each of the UE 115, the vehicle 422, and the network entity 430 are described and illustrated as being positioned within the zone 419, in other implementations, one or more of the UE 115, the vehicle 422, or the network entity 430 can be positioned outside of the zone 419. Additionally or alternatively, the UE 115, the vehicle 401, or the vehicle 422 can be traveling towards or positioned within the zone 419. In some implementations, the UE 115, the vehicle 401, the vehicle 422, or a combination thereof is a mobile device. The network entity 430 can include a base station (such as the base station 105), an access point, a road side unit, another UE or vehicle, or a portion of a core network (such as the core network 130). The network entity 430 can be stationary or mobile. In some implementations, the network entity 430 includes or is integrated with a traffic control device, such as a traffic light, an on-ramp metering control device, a digital road sign, or another type of traffic control device. In some other implementations, the network entity 430 is communicatively coupled to and communicates with a traffic control device to control the traffic control device (e.g., via providing instructions), provide network access to the traffic control device, or a combination thereof. The server 450 can include a server, the base station 105, the core network 130, or other device or system. For example, the server 450 can include a car-to-cloud (C2C) server. In some implementations, the server 450 is or includes the LMF 131.

[0088] In some implementations, the UE 115, vehicle 401, vehicle 422, or network entity 430 is configured to communicate with another of the UE 115, vehicle 401, vehicle 422, or network entity 430 using a sidelink (SL) link / interface (e.g., using sidelink communications). Additionally or alternatively, the UE 115, vehicle 401, or vehicle 422, or a combination thereof, is configured to communicate with the network entity 430 using the SL link / interface (e.g., using sidelink communications) or a Uu link / interface (e.g., using Uu communications). The server 450 can communicate (e.g., be communicatively coupled to) with the UE 115, vehicle 401, or 422, or network entity 430 via a cellular network. As an illustrative, non-limiting example, the server 450 can be configured to know a situational awareness (e.g., a position, a heading, a speed, etc.) of the UE 115 or vehicle 401 or 422 based on information included in a safety message, such as a basic safety message (BSM) message (for a vehicle 401 or 422), a personal safety message (PSM) message (for a UE 115), a collective perception message (CPM), or a combination thereof. Additionally or alternatively, as an illustrative, non-limiting example, the server 450 can know a map of the area 419 or a map associated with the area, such as a map indicating roads, intersections, stop signs, properties of traffic lights, or other information in a geographic region. For example, the map or map data associated with the area 419 can include or correspond to the map or tracking data 492, as further described herein.

[0089] In some implementations, the BSM can include or indicate information (e.g., BSM information), such as positioning, motion, control, size, event, or a combination thereof. The positioning can include or indicate latitude, longitude, altitude, positioning accuracy. The motion can include or indicate transmission setting, speed, heading, steering wheel angle, acceleration (e.g., longitudinal acceleration, lateral acceleration, vertical acceleration, yaw rate, or a combination thereof), or a combination thereof. As an illustrative, non-limiting example, the control can include or indicate a brake system status, such as braking or not braking. As an illustrative, non-limiting example, the size can include or indicate a vehicle size, such as weight, length, width, height, maximum number of passengers, or a combination thereof. As an illustrative, non-limiting example, the event can include, indicate, or be associated with a hazard light, stop line violation, anti-lock brake system (ABS), traction control, stability control, hazardous material, emergency response, emergency braking, light change, wiper change, tire blowout, malfunctioning vehicle, airbag deployment, or a combination thereof. In some implementations, the CPM can include or indicate information about a detected object, on-board sensor, or a combination thereof. The CPM can include, correspond to, or be defined by the ETSI ITS Intelligent Transport Systems (ITS) standard. As an illustrative, non-limiting example, the CPM can include or indicate an object identifier (ID), object description, local sensor perception, neighboring vehicle perception, RSU perception, or a combination thereof.

[0090] The UE 115 can include a device such as a mobile device or a stationary device. In some implementations, the UE 115 is a device configured to communicate with the vehicle 401 or 422, the network entity 430, or both. In some implementations, the UE 115 is configured to control or partially control operation of the vehicle 401 or 422. Alternatively, the UE 115 can be associated with a pedestrian or another type of device other than a vehicle. The UE 115 can include various components (such as structures, hardware components) for performing one or more functions described herein. For example, the components can include one or more processors, one or more memory devices, one or more transmitters, one or more receivers, and optionally an antenna array, as described above with reference to the vehicle 401. In some implementations, the UE 115 can include an interface (e.g., a communication interface) that includes the transmitter, the receiver, or a combination thereof. The one or more processors can be configured to execute instructions stored in the one or more memory devices to perform operations described herein. In some implementations, the one or more processors include or correspond to one or more of the receive processor 258, the transmit processor 264, and the controller 280 of Figure 2 Figure 2 the memory 282 of the memory 282.​

[0091] UE 115 may include, as referenced herein, Figure 1 to Figure 3 UE 115 refers to one or more components as described. In some specific implementations, UE 115 is a UE with 5G capability, a UE with 6G capability, or a combination thereof.

[0092] Vehicle 401 may include equipment such as mobile devices or vehicles. For example, vehicle 401 may include or correspond to Figure 1 UEs 115e, 115i, 115j, and 115k. As an illustrative example, vehicle 401 may include autonomous or driver-assisted vehicles, UAVs, or unmanned aerial vehicles (such as…). Figure 1 The vehicle 401 may be an unmanned aerial vehicle (UAV 115e), or any other type of autonomous or semi-autonomous land vehicle, water vehicle, aircraft, or combination thereof. Although one or more examples may be described herein in the context of autonomous or semi-autonomous vehicles, such examples are illustrative and are not intended to limit vehicle 401 to any particular type of vehicle. Alternatively or additionally, although referred to herein as a vehicle, components of vehicle 401 may be included in or integrated within an onboard unit (OBU) of the vehicle. Vehicle 401 may include a variety of components (such as structural components, hardware components) for performing one or more functions described herein. For example, these components may include one or more processors 402 (collectively referred to below as “processor 402”), one or more memory devices 404 (collectively referred to below as “memory 404”), one or more transmitters 410 (collectively referred to below as “transmitter 410”), and one or more receivers 412 (collectively referred to below as “receiver 412”). In some embodiments, vehicle 401 may include an interface (e.g., a communication interface) comprising a transmitter 410, a receiver 412, or a combination thereof. Processor 402 may be configured to execute instructions 405 stored in memory 404 to perform the operations described herein. In some embodiments, processor 402 includes or corresponds to... Figure 2 The receiving processor 258, the transmitting processor 264, and the controller 280 are one or more of these, and the memory 404 includes or corresponds to the receiving processor 258, the transmitting processor 264, and the controller 280. Figure 2 The memory 282.

[0093] Memory 404 includes or is configured to store instructions 405, travel information 406, and one or more sensor sharing configurations 407 (hereinafter collectively referred to as “sensor sharing configurations 407”). Travel information 406 can include or indicate travel of vehicle 401 or for the vehicle. For example, travel information 406 can include or indicate a position of vehicle 401, a speed of vehicle 401, a heading of vehicle 401, a direction of travel of vehicle 401, a route of travel of vehicle 401, a start location of vehicle 401, an end location of vehicle 401, an estimated time of arrival of vehicle 401, or a combination thereof. Additionally or alternatively, travel information 406 can include or indicate historical travel information of vehicle 401.

[0094] Sensor sharing configurations 407 can include or indicate one or more sensor sharing mitigation techniques (e.g., one or more redundancy mitigation techniques) to be performed at one or more vehicles. As described further herein, vehicle 401 can apply such sensor sharing mitigation techniques to reduce a number of sensor-related messaging communicated by vehicle 401. The one or more sensor sharing mitigation techniques can include or indicate a frequency-based mitigation technique, a distance-based mitigation technique, a dynamics-based mitigation technique, a confidence-based mitigation technique, an entropy-based mitigation technique, an object self-announcing mitigation technique, or a combination thereof. Additionally or alternatively, sensor sharing configurations 407 can include or indicate one or more parameters for at least one of the one or more sensor sharing mitigation techniques. The one or more parameters can include or indicate a time window, a detection instance, a threshold distance, a threshold speed, another threshold or parameter, or a combination thereof. The sensor sharing mitigation techniques can be configured to enable filtering or reducing redundancy or unnecessary frequent updates of information included in a collective perception message, such as information associated with a sensed or detected object. For example, the sensor sharing mitigation techniques can be configured to enable filtering or reducing redundancy or unnecessary frequent updates of sensed or detected objects by defining one or more rules to omit a portion or subset of perceived or detected objects (e.g., sensor data) that satisfy at least one rule.

[0095] In some implementations, the sensor sharing configuration 407 or one or more sensor sharing mitigation techniques can be defined, at least in part, by a standard such as ETSI TR 103 562 V2.1.1 (2019-12). For example, a frequency-based mitigation technique can include or be defined by a frequency-based rule (e.g., Section 4.5.2 of ETSI TR 103 562 V2.1.1 (2019-12)), a distance-based mitigation technique can include or be defined by a distance-based rule (e.g., Section 4.5.7 of ETSI TR 103 562 V2.1.1 (2019-12)), a dynamic-based mitigation technique can include or be defined by a dynamic-based rule (e.g., Section 4.5.3 of ETSI TR 103 562 V2.1.1 (2019-12)), a confidence-based mitigation technique can include or be defined by a confidence-based rule (e.g., Section 4.5.4 of ETSI TR 103 562 V2.1.1 (2019-12)), an entropy-based mitigation technique can include or be defined by an entropy-based rule (e.g., Section 4.5.5 of ETSI TR 103 562 V2.1.1 (2019-12)), or an object self-announcement mitigation technique can include or be defined by an object self-announcement rule (e.g., Section 4.5.6 of ETSI TR 103 562 V2.1.1 (2019-12)).

[0096] In some implementations, at least one of the one or more sensor sharing mitigation techniques can include or be associated with a parameter. For example, a frequency-based mitigation technique (e.g., a frequency-based rule) can include or be associated with a time window (W Redundancy ), a detection instance (N Redundancy ), or a combination thereof. As another example, a distance-based mitigation technique (e.g., a distance-based rule) can include or be associated with a time window (W Redundancy ), a threshold distance (R Redundancy ), or a combination thereof. As another example, a dynamic-based mitigation technique (e.g., a dynamic-based rule) can include or be associated with a threshold distance (P Redundancy ), a threshold speed (S Redundancy ), or a combination thereof. As another example, a confidence-based mitigation technique (e.g., a confidence-based rule) can include or be associated with a time window (W Redundancy ). As an additional example, an entropy-based mitigation technique (e.g., an entropy-based rule) can include or be associated with a threshold (E Redundancy ).

[0097] In some implementations, a frequency-based mitigation technique (e.g., a frequency-based rule) can be configured to omit reporting of a detected object if the detected object appears in more than N Redundancy times (e.g., in more than N Redundancy received SDSMs or CPMs) within a time window W Redundancy . For a larger N Redundancy threshold, information about the same object is sent more frequently and can cause increased congestion. For a larger W Redundancy time window threshold, information about the same object is sent less frequently and can cause decreased congestion.

[0098] In some implementations, a distance-based mitigation technique (e.g., a distance-based rule) can be configured to omit reporting of a detected object if another detected object (e.g., detected by another vehicle) is included in a received SDSM or CPM within a time window W Redundancy and the vehicle 401 is less than a threshold distance (R Redundancy ) from another vehicle that transmitted the SDSM or CPM. For a larger R Redundancy distance threshold, information about the same object is sent less frequently and can cause decreased congestion. For a larger W Redundancy time window threshold, information about the same object is sent less frequently and can cause decreased congestion.

[0099] In some implementations, a dynamics-based mitigation technique (e.g., a dynamics-based rule) can be configured to omit reporting of a detected object if the detected object’s position changes from a position reported in a SDSM or a CPM by less than a threshold distance (e.g., P Redundancy = 4 m) and the detected object’s speed changes from a speed reported in a SDSM or a CPM by less than a threshold speed (e.g., S Redundancy = 0.5 m / s). The dynamics-based redundancy mitigation technique can be configured such that a detected object that changes speed will be reported more frequently than a detected object that moves at a constant speed. If the detected object’s speed is constant, it can be reported periodically. Similarly, a detected object that moves a larger distance will be reported more frequently than a detected object that moves a smaller distance.

[0100] In some implementations, a confidence-based mitigation technique (e.g., a confidence-based rule) can be configured to omit reporting of an object if a historical SDSM or CPM includes information about the same object and if the maximum confidence of the object information in these historical SDSMs or CPMs is higher than the confidence of the local perception of the object by the sending station (e.g., vehicle 401). The confidence-based mitigation technique can enable prioritization of object information with higher confidence even under heavy network channel load.

[0101] In some implementations, an entropy-based mitigation technique (e.g., an entropy-based rule) can be configured to omit reporting of an object if the object is expected to be perceived by a neighboring intelligent transportation system station (ITS-S) and if the relative entropy of the local perception of the object is lower than a threshold E Redundancy for multiple or all neighboring ITS-Ss. The entropy-based rule can mitigate the impact of potential loss of CPMs or SDSMs by considering the distance between ITS-Ss when estimating the set of historical CPMs or SDSMs that each neighboring ITS-S is expected to have received. Additionally or alternatively, the entropy-based rule can consider the quality and freshness of the object information when computing the expected knowledge of the neighboring ITS-Ss. In some implementations, the entropy-based rule can mitigate the risk of erroneously omitting object information from CPMs or SDSMs.

[0102] In some implementations, an object self-announcement-based mitigation technique (e.g., an object self-announcement rule) can be configured to omit reporting of a perceived object if the object itself is V2X-capable (e.g., an ITS station) that sends its own V2X messages (e.g., BSM, SDSM). The object self-announcement rule can provide a direct mechanism to identify and eliminate V2X-capable entities (RSUs, OBUs) that are reported in SDSMs, which can cause the resulting message size to decrease as market penetration increases, since other V2X-capable vehicles or other road users are no longer included in the SDSM.

[0103] The transmitter 410 is configured to transmit reference signals, control information, and data to one or more other devices, and the receiver 412 is configured to receive reference signals, synchronization signals, control information, and data from one or more other devices. For example, the transmitter 410 can transmit signaling, control information, and data to the network entity 430, a UE 115, or another vehicle 401, and the receiver 412 can receive signaling, control information, and data from the network entity, the UE, or the other vehicle. In some implementations, the transmitter 410 and the receiver 412 can be integrated in one or more transceivers. Additionally or alternatively, the transmitter 410 or the receiver 412 can include or correspond to a transmitter or a receiver, respectively, of the one or more communication devices 406. Figure 2One or more components of the described UE 115.

[0104] In some implementations, the vehicle 401 can include one or more antenna arrays. The one or more antenna arrays can be coupled to the transmitter 410, the receiver 412, or the communication interface. The antenna array can include a plurality of antenna elements configured to perform wireless communication with other devices, such as with the network entity 430 or the UE 115. In some implementations, the antenna array can be configured to perform wireless communication using different beams (also referred to as antenna beams). The beams can include TX beams and RX beams. To illustrate, the antenna array can include a plurality of independent sets (or subsets) of antenna elements (or a plurality of individual antenna arrays), and each set of antenna elements of the antenna array can be configured to communicate using a different respective beam, which can have a different respective direction than the other beams. For example, a first set of antenna elements of the antenna array can be configured to communicate via a first beam having a first direction, and a second set of antenna elements of the antenna array can be configured to communicate via a second beam having a second direction. In other implementations, the antenna array can be configured to communicate via more than two beams. Alternatively, one or more sets of antenna elements of the antenna array can be configured to concurrently generate multiple beams, e.g., using multiple RF chains of the vehicle 401. Each individual set (or subset) of antenna elements can include a plurality of antenna elements, such as two antenna elements, four antenna elements, ten antenna elements, twenty antenna elements, or any other number of antenna elements greater than two. Although described as an antenna array, in other implementations, the antenna array can include or correspond to a plurality of antenna panels, and each antenna panel can be configured to communicate using a different respective beam.

[0105] The vehicle 422 can include or correspond to the vehicle 401. For example, the vehicle 422 can include one or more components as described with reference to the vehicle 401. Additionally or alternatively, the vehicle 422 can be configured to perform one or more operations as described with reference to the vehicle 401. It is also noted that the vehicle 401 can be configured to also perform one or more operations as described with reference to the vehicle 422.

[0106] The vehicle 401 or 422 can include one or more components as described herein with reference to a vehicle of Figure 10 or a network entity of Figure 11 In some implementations, the vehicle 401 or 422 is a 5G-capable vehicle, a 6G-capable vehicle, or a combination thereof.

[0107] The network entity 430 can include a device such as a base station, road side unit, node, or another UE. The network entity 430 can be a mobile device or a stationary device. The network entity 430 can include various components (such as structural components, hardware components) for performing one or more functions described herein. For example, these components can include one or more processors 432 (hereinafter collectively referred to as “the processor 432”) and one or more memory devices 434 (hereinafter collectively referred to as “the memory 434”). In some implementations, the network entity 430 can include an interface (e.g., a communication interface) that includes a transmitter 436, a receiver 438, or a combination thereof. The processor 432 can be configured to execute instructions 435 stored in the memory 434 to perform the operations described herein. In some implementations, the processor 432 includes or corresponds to one or more of the reception processor 258, transmission processor 264, and controller 280 of FIG. 2, and the memory 434 includes or corresponds to the memory 282 of FIG. 2. Figure 2 Figure 2

[0108] The memory 434 includes or is configured to store instructions 435 and information 437. The information 437 can include or correspond to the travel information 406, the sensor sharing configuration 407, or a combination thereof. Additionally or alternatively, the information 437 can include congestion information. The congestion information can be associated with one or more areas, such as the areas 419. The congestion information can include or indicate road congestion, traffic congestion, communication congestion (e.g., over-the-air (OTA) congestion), or a combination thereof. For example, the congestion information, such as the road congestion information 470, can include one or more CBR measurements reported by a vehicle, an RSU, or a combination thereof, one or more CBR measurements reported by one or more base stations, traffic camera data, lane metric data, time congestion data, or a combination thereof.

[0109] ​​Network entity 430 includes one or more transmitters 436 (hereinafter collectively referred to as "transmitters 436") and one or more receivers 438 (hereinafter collectively referred to as "receivers 438"). Transmitters 436 are configured to transmit reference signals, control information, and data to one or more other devices, and receivers 438 are configured to receive reference signals, synchronization signals, control information, and data from one or more other devices. For example, transmitters 436 may transmit signaling, control information, and data to base station 105, UE 115, vehicle 401 or 422, another network entity 430, or server 450, and receivers 438 may receive signaling, control information, and data from the base station, the UE, the vehicle, the other network entity, or the server. In some implementations, transmitters 436 and receivers 438 may be integrated into one or more transceivers. Additionally or alternatively, transmitters 436 or receivers 438 may include or correspond to reference signals. Figure 2 The described base station 105 or reference Figure 2 One or more components of the described UE 115.

[0110] In some embodiments, network entity 430 may include one or more antenna arrays. One or more antenna arrays may be coupled to transmitter 436, receiver 438, or a communication interface. The antenna arrays may include multiple antenna elements configured to perform wireless communication with other devices, such as UE 115, vehicle 401, vehicle 422, server 450, or base station 105. In some embodiments, the antenna arrays may be configured to perform wireless communication using different beams (also referred to as antenna beams). Beams may include TX beams and RX beams. For illustration, the antenna array may include multiple independent sets (or subsets) of antenna elements (or multiple separate antenna arrays), and each set of antenna elements in the antenna array may be configured to communicate using a different corresponding beam, which may have a corresponding direction different from the other beams. For example, a first set of antenna elements of the antenna array may be configured to communicate via a first beam having a first direction, and a second set of antenna elements of the antenna array may be configured to communicate via a second beam having a second direction. In other embodiments, the antenna array may be configured to communicate via more than two beams. Alternatively, one or more sets of antenna elements of the antenna array may be configured to concurrently generate multiple beams, for example, using multiple RF chains of network entity 430. Each individual set (or subset) of antenna elements may include multiple antenna elements, such as two antenna elements, four antenna elements, ten antenna elements, twenty antenna elements, or any other number of antenna elements greater than two. Although described as an antenna array, in other specific embodiments, the antenna array may include or correspond to multiple antenna panels, and each antenna panel may be configured to communicate using a different corresponding beam.

[0111] The network entity 430 can include one or more components as described herein with reference to the UE 115 or the base station 105. In some implementations, the network entity 430 is a 5G-capable network entity, a 6G-capable network entity, or a combination thereof.

[0112] The server 450 can include various components for performing one or more functions described herein, such as structural components, hardware components. For example, the components can include one or more processors 452 (hereinafter collectively referred to as “the processor 452”) and one or more memory devices 454 (hereinafter collectively referred to as “the memory 454”). In some implementations, the server 450 can include an interface (e.g., a communication interface) including a transmitter 456, a receiver 458, or a combination thereof. The processor 452 can be configured to execute instructions 460 stored in the memory 454 to perform the operations described herein. In some implementations, the processor 452 includes or corresponds to one or more of the reception processor 238, the transmission processor 220, and the controller 240, and the memory 454 includes or corresponds to the memory 242.

[0113] The memory 454 includes or is configured to store the instructions 460, a destination region 462, a road congestion metric 464, one or more threshold values 466 (hereinafter collectively referred to as “the threshold values 466”), road topology information 468, historical travel data 469, or a combination thereof. The destination region 462 can include or indicate a region in which a destination (e.g., an end location) of a vehicle (such as the vehicle 401) is located. Additionally or alternatively, the destination region 462 can include or indicate one or more transit or intermediate regions between a current region (e.g., a region in which the vehicle is currently located) and the destination region. The regions can be identified based on map information (e.g., based on geographic locations or features or known names, such as county, city, town, state, country, province, territory, etc.), based on predefined names, based on coverage areas (e.g., cells of the wireless communication system 400), using other techniques, or a combination thereof. In some particular implementations, the destination region 462 and optionally the transit or intermediate regions can be identified from information provided by the respective vehicles, through map data from a third-party map application (e.g., supported by a map service server 490), or a combination thereof. The destination region 462 can indicate a particular region of one or more identified regions in which one or more vehicles (e.g., the vehicle 401) is expected to be located at a future time (e.g., an expected time of arrival for the final destination region or another time for a transit or intermediate region).

[0114] The road congestion metric 464 is a metric indicative of detected, measured, or estimated road congestion within the destination region 462. For example, the road congestion metric 464 can be indicative of road congestion, traffic congestion, communication congestion (e.g., OTA congestion), or a combination thereof within the destination region 462 that is beyond a detection range of one or more vehicles expected to be located within the destination region 462 at a future time. The road congestion metric 464 can be determined based on congestion information received from vehicles, UEs, RSUs, base stations, traffic cameras, lane meters, other traffic sensors, or a combination thereof associated with the destination region 462. As an illustrative, non-limiting example, the road congestion metric 464 can include a number of vehicles located within the destination region 462, a trend in the number of vehicles located within the destination region 462, a count of safety messages communicated within the destination region 462, a channel metric associated with the destination region 462, other metrics, or a combination thereof. The threshold 466 can include or be indicative of one or more values, one or more ranges, or a combination thereof. The threshold 466 can be associated with a time, a duration, a heading, a distance, or a combination thereof. Additionally or alternatively, the threshold 466 can be associated with a number of vehicles within a region, a rate of change in the number of vehicles within a region, a number of safety messages, a signal strength, or other channel metric, or a combination thereof.

[0115] Road topology information 468 includes or indicates topology or other geographic features and information associated with one or more roads drivable by vehicles monitored by server 450. For example, road topology information 468 can indicate locations, arrangements, etc. of one or more roads, as well as other related information, such as intersections between roads, road distances, locations of other elements (e.g., stop signs, traffic lights, toll facilities, etc.), or combinations thereof. In some implementations, road topology information 468 can be used to determine a location of a vehicle on a road, one or more destination areas for a vehicle, an expected path of a vehicle, or combinations thereof (e.g., based on geographic coordinates or other positioning information). Historical travel data 469 can indicate historical travel patterns of one or more vehicles. Historical travel data 469 can include or indicate historical location or positioning data associated with one or more vehicles, historical speed data associated with one or more vehicles, historical directions associated with one or more vehicles, historical headings associated with one or more vehicles, historical travel paths associated with one or more vehicles, historical travel times associated with one or more vehicles, other information, or combinations thereof. Historical travel data 469 can indicate or be analyzed to determine trends or patterns in historical travel associated with one or more vehicles, and such patterns can be periodic, have varying frequencies, or depend on time conditions (e.g., time of day, day of week, month of year, etc.). For example, historical travel data 469 can indicate that a vehicle typically travels from a first location (e.g., a home) to a second location (e.g., a workplace) in the morning, remains stationary for multiple hours, and then travels from the second location to the first location in the evening on multiple days of the week. During other days (e.g., weekends), historical travel data 469 can indicate other patterns (e.g., frequent travel from the first location to other locations such as shopping centers or entertainment locations), or can not indicate discernible patterns.

[0116] The server 450 includes one or more transmitters 456 (hereinafter collectively referred to as “the transmitter 456”) and one or more receivers 458 (hereinafter collectively referred to as “the receiver 458”). The transmitter 456 is configured to transmit reference signals, control information, and data to one or more other devices, and the receiver 458 is configured to receive reference signals, synchronization signals, control information, and data from one or more other devices. For example, the transmitter 456 can transmit signaling, control information, and data to a base station 105, a UE 115, a vehicle 401 or 422, a network entity 430, or a server 450, and the receiver 458 can receive signaling, control information, and data from the base station, the UE, the vehicle, the network entity, or the server. In some implementations, the transmitter 456 and the receiver 458 can be integrated in one or more transceivers. Additionally, or alternatively, the transmitter 456 or the receiver 458 can include or correspond to the transmitters 454 and the receivers 456 of the base station 105 or the UE 115 described with reference to FIG. 4. Figure 2 The described base station 105 or the described UE 115. Figure 2 The described one or more components of the UE 115.

[0117] The map service server 490 can include or correspond to the server 450. For example, the map service server 490 can include one or more components as described with reference to the server 450. Additionally, or alternatively, the map service server 490 can be configured to perform one or more operations as described with reference to the server 450. It is also noted that the server 450 can be configured to perform one or more operations as described with reference to the map service server 490 as well.

[0118] The map service server 490 can include map data or tracking data associated with one or more vehicles, such as map or tracking data 492 associated with the vehicle 401. The map data or tracking data can be generated, determined, or maintained as part of a map or navigation service provided by the map service server 490. For example, a vehicle participating in a service provided by the map service server 490 can provide respective location information and destination information, and the map service server 490 can transmit map data, navigation or directional data, or a combination thereof to the vehicle for the vehicle to display or provide a map, driving or navigation directions, or both, between the respective locations and destination. As an illustrative example, the map or tracking data 492 can include or indicate a map between a current (or starting) location of the vehicle 401 and a destination of the vehicle 401, navigation information (e.g., directions, travel time, etc.) associated with travel of the vehicle 401 along roads within the map, tracking data that enables the vehicle 401 to update its positioning on the map as it travels, other information indicating roads, intersections, traffic control devices, geographic features, hazards, etc., or a combination thereof. In some implementations, the map service server 490 can provide the map or tracking data 492 associated with the vehicle 401 to the server 450 to enable the server 450 to perform one or more operations described herein to support the sensor sharing configuration.

[0119] In some implementations, the wireless communication system 400 implements a 5G NR network. For example, the wireless communication system 400 can include a plurality of 5G capable UEs 115, a plurality of 5G capable vehicles 401, or a plurality of 5G capable network entities 430, such as UEs, vehicles, and network entities configured to operate according to 5G NR network protocols, such as defined by 3GPP. In some other implementations, the wireless communication system 400 implements a 6G network.

[0120] In some implementations, the sensor sharing configuration 407 can be determined or selected by a network, such as the server 450. For example, the server 450 can be configured to determine a redundancy mitigation technique, a technique parameter, or a combination thereof. The server 450 can be configured to generate an indicator (e.g., 471, 474, or 476) indicating the sensor sharing configuration 407 (e.g., the determined mitigation technique, the determined technique parameter, or a combination thereof) that the vehicle 401 or 422 or the UE 115 should use. In some implementations, the indicator can include or indicate a region (e.g., 419) in which the sensor sharing configuration 407 should be used. In some implementations, a information element (IE), such as a sensor sharing configuration IE, can be used to convey the sensor sharing configuration 407 or the indicator indicating the sensor sharing configuration 407.

[0121] The sensor sharing configuration 407, the indicator of the sensor sharing configuration 407, or the sensor sharing configuration IE can be transmitted using sidelink communications (e.g., using a PC5 interface) or downlink communications (e.g., using a Uu interface). In some implementations, the sensor sharing configuration 407, the indicator of the sensor sharing configuration 407, or the sensor sharing configuration IE can be transmitted using PC5-dedicated signaling (unicast) in a message, such as a PC5-RRC message (e.g., a RRCReconfigurationSidelink) or another PC5-RRC message, over PC5-RRC. Additionally or alternatively, the sensor sharing configuration 407, the indicator of the sensor sharing configuration 407, or the sensor sharing configuration IE can be transmitted using PC5-dedicated signaling (unicast) in a PC5-S message or another message over PC5-S. Additionally or alternatively, the sensor sharing configuration 407, the indicator of the sensor sharing configuration 407, or the sensor sharing configuration IE can be transmitted using Uu-dedicated signaling in a message, such as a radio resource control (RRC) message (e.g., a RRCReconfiguration) or other message.

[0122] In some implementations, the sensor sharing configuration IE can include:

[0123]

[0124] The sensor sharing configuration IE can include one or more fields (e.g., indicators 474) indicating whether one or more redundancy mitigation techniques / rules are enabled, and optionally one or more parameters (e.g., parameters 476) associated with the one or more redundancy mitigation techniques / rules. In the fields of an example sensor sharing configuration IE, ue-FrequencyBasedRuleEnable can indicate whether a frequency-based redundancy mitigation rule is enabled (e.g., true), ue-DistanceBasedRuleEnable can indicate whether a distance-based redundancy mitigation rule is enabled (true), ue-DynamicsBasedRuleEnable can indicate whether a dynamic-based redundancy mitigation rule is enabled (true), ue-ConfidenceBasedRuleEnable can indicate whether a confidence-based redundancy mitigation rule is enabled (true), ue-EntropyBasedRuleEnable can indicate whether an entropy-based redundancy mitigation rule is enabled (true), and ue-ObjectSelfAnnouncementRuleEnable can indicate whether an object self-announcement redundancy mitigation rule is enabled (true). Additionally, in the fields of an example sensor sharing configuration IE, W-RedundancyFB-r16 can indicate a time window for a frequency-based redundancy mitigation rule, N-RedundancyFB-r16 can indicate a threshold detection instance for a frequency-based redundancy mitigation rule, W-RedundancyDB-r16 can indicate a time window for a distance-based redundancy mitigation rule, R-RedundancyDB-r16 can indicate a threshold distance for a distance-based redundancy mitigation rule, P-RedundancyDYB-r16 can indicate a threshold distance for a dynamic-based redundancy mitigation rule, and S-RedundancyDYB-r16 can indicate a threshold speed for a dynamic-based redundancy mitigation rule. In some implementations, the value of the time window for a frequency-based redundancy mitigation rule can be in units of milliseconds (ms), the value of the threshold detection instance for a frequency-based redundancy mitigation rule can indicate a number of detections, the value of the time window for a distance-based redundancy mitigation rule can be in units of ms, the value of the threshold distance for a distance-based redundancy mitigation rule can be in units of meters, the value of the threshold distance for a dynamic-based redundancy mitigation rule can be in units of meters, and the value of the threshold speed for a dynamic-based redundancy mitigation rule can be in units of meters per second (m / s).

[0125] Reference Figure 5 , Figure 5This is a block diagram illustrating an example format of information elements supporting sensor-shared configuration according to one or more aspects. For example, an information element (IE) may include or correspond to a sensor-shared configuration IE 500. A sensor-shared configuration IE 500 may include or correspond to a sensor-shared configuration 407, a sensor-shared configuration indicator 471, a sensor-shared configuration message 472 (including an indicator 474 and optionally including a parameter 476), or a combination thereof.

[0126] The sensor shared configuration IE 500 includes one or more fields. For example, one or more fields may include a mitigation technology indicator field 502, a parameter field 504, or a combination thereof. Figure 5 As shown, the sensor shared configuration IE 500 includes a mitigation technique indicator field 502 and a parameter field 504. The mitigation technique indicator field 502 may include one or more subfields. The one or more subfields of the mitigation technique indicator field 502 may include a frequency-based mitigation technique field 506, a distance-based mitigation technique field 508, a dynamics-based mitigation technique field 510, a confidence-based mitigation technique field 512, an entropy-based mitigation technique field 514, an object-declared mitigation technique field 516, or a combination thereof. The frequency-based mitigation technique field 506 may be configured to indicate whether frequency-based mitigation techniques, such as frequency-based rules (e.g., Section 4.5.2 of ETSI TR 103 562 V2.1.1 (2019-12)). The distance-based mitigation technique field 508 can be configured to indicate whether distance-based mitigation techniques, such as distance-based rules (e.g., Section 4.5.7 of ETSI TR 103 562 V2.1.1 (2019-12)). The dynamic mitigation technique field 510 can be configured to indicate whether dynamic mitigation techniques, such as dynamic rules (e.g., Section 4.5.3 of ETSI TR 103 562 V2.1.1 (2019-12)). The confidence-based mitigation technique field 512 can be configured to indicate whether confidence-based mitigation techniques, such as confidence-based rules (e.g., Section 4.5.4 of ETSI TR 103 562 V2.1.1 (2019-12)). Entropy-based mitigation technique field 514 can be configured to indicate whether entropy-based mitigation techniques, such as entropy-based rules (e.g., Section 4.5.5 of ETSI TR 103 562 V2.1.1 (2019-12)). Object self-declaration-based mitigation technique field 516 can be configured to indicate whether object self-declaration-based mitigation techniques, such as object self-declaration rules, are enabled.

[0127] The parameter field 504 can include one or more subfields. The one or more subfields of the parameter field 504 can include a frequency-based parameter field 520, a distance-based parameter field 522, a dynamics-based parameter field 524, a confidence-based parameter field 526, an entropy-based field (not shown), or a combination thereof. The frequency-based parameter field 520 can be associated with, correspond to, or indicate one or more parameters of the frequency-based mitigation technique field 506. The frequency-based parameter field 520 can include one or more subfields, such as a time window field 530, a detection instance field 532, or a combination thereof. The time window field 530 can include or indicate a time window (W Redundancy ). The detection instance field 532 can include or indicate a detection instance (N Redundancy ).

[0128] The distance-based parameter field 522 can be associated with, correspond to, or indicate one or more parameters of the distance-based mitigation technique field 508. The distance-based parameter field 522 can include one or more subfields, such as a time window field 534, a threshold distance field 536, or a combination thereof. The time window field 534 can include or indicate a time window (W Redundancy ). The threshold distance field 536 can include or indicate a threshold distance (R Redundancy ). The dynamics-based parameter field 524 can be associated with, correspond to, or indicate one or more parameters of the dynamics-based mitigation technique field 510. The dynamics-based parameter field 524 can include one or more subfields, such as a threshold distance field 538, a threshold speed field 540, or a combination thereof. The threshold distance field 538 can include or indicate a threshold distance (P Redundancy ). The threshold speed field 540 can include or indicate a threshold speed (S Redundancy ).

[0129] The confidence-based parameter field 526 can be associated with, correspond to, or indicate one or more parameters of the confidence-based mitigation technique field 512. The confidence-based parameter field 526 can include one or more subfields, such as a time window field 542. The time window field 542 can include or indicate a time window (W Redundancy ). The entropy-based field (not shown) can be associated with, correspond to, or indicate one or more parameters of the entropy-based mitigation technique field 514. The entropy-based field (not shown) can include one or more subfields, such as an entropy threshold field. The entropy threshold field can include or indicate an entropy threshold (E Redundancy ).

[0130] Referring back to Figure 4A message including the sensor sharing configuration IE or the indicator of the sensor sharing configuration 407 can be communicated to a single UE (e.g., a vehicle) or to a group of UEs. For example, the sensor sharing configuration IE or the indicator of the sensor sharing configuration 407 can be transmitted by the network entity 430 or the server 450.

[0131] In some implementations, such as when the sensor sharing configuration IE or the indicator of the sensor sharing configuration 407 is transmitted to a single UE, the sensor sharing configuration IE or the indicator of the sensor sharing configuration 407 can be transmitted using a dedicated transmission distribution, such as PC5-dedicated signaling (unicast) or Uu-dedicated signaling. For example, using PC5-dedicated signaling, the sensor sharing configuration IE or the indicator of the sensor sharing configuration 407 can be encapsulated in PC5-RRC in a message, such as a PC5-RRC message (e.g., RRCReconfigurationSidelink). For another example, using PC5-dedicated signaling, the sensor sharing configuration IE or the indicator of the sensor sharing configuration 407 can be encapsulated in PC5-signaling (PC5-S) in a message, such as a PC5-S message. Additionally or alternatively, using Uu-dedicated signaling, the sensor sharing configuration IE or the indicator of the sensor sharing configuration 407 can be encapsulated in RRC in a message, such as a RRC message (e.g., RRCReconfiguration).

[0132] In some implementations, such as when the sensor sharing configuration IE or the indicator of the sensor sharing configuration 407 is transmitted to a group of UEs, the sensor sharing configuration IE or the indicator of the sensor sharing configuration 407 can be transmitted using a common transmission distribution, such as PC5-common signaling or Uu-common signaling. For example, using PC5-common signaling, the sensor sharing configuration IE or the indicator of the sensor sharing configuration 407 can be encapsulated in an application layer broadcast message. For another example, using PC5-common signaling, the sensor sharing configuration IE or the indicator of the sensor sharing configuration 407 can be encapsulated in an application layer connectionless (distance-based) groupcast message. The application layer connectionless (distance-based) groupcast message can be associated with a range of interest specified by the transmitter / application, targeting a specific area (e.g., an RSU provides information specific to a radius around the RSU). Additionally or alternatively, using Uu-common signaling, the sensor sharing configuration IE or the indicator of the sensor sharing configuration 407 can be encapsulated in a Uu SIB transmission, such as a SIB.

[0133] During operation of the wireless communication system 400, the server 450 can receive road congestion information associated with one or more areas. As an illustrative example, the server 450 can receive road congestion information 470 associated with the area 419, and the road congestion information 470 can indicate or be used to determine a road congestion, a traffic jam, an OTA congestion, or a combination thereof, associated with the area 419. Although illustrated as a single message in Figure 4 the road congestion information 470 can include a single message from one device or multiple messages from multiple devices, such as the UEs 115, the vehicles 422, the network entities 430, other devices located within the area 419 or having information related to the area 419, or a combination thereof. In some implementations, the road congestion information 470 includes one or more safety messages or perception messages communicated by vehicles or other UEs according to V2X standards. For example, the road congestion information 470 can include one or more BSMs, one or more CAMs, or a combination thereof, from one or more RSUs (e.g., the network entities 430) located within the area 419. Additionally or alternatively, the road congestion information 470 can include one or more channel busy ratio (CBR) measurements reported by vehicles (e.g., the vehicles 422), RSUs (e.g., the network entities 430), or a combination thereof located within the area 419. Additionally or alternatively, the road congestion information 470 can include one or more CBR measurements reported by one or more base stations (e.g., the network entities 430) serving the area 419. Additionally or alternatively, the road congestion information 470 can include traffic camera data associated with the area 419, lane metric data associated with the area 419, time congestion data associated with the area 419, other information, or a combination thereof. In a similar manner to the road congestion information 470 for the area 419, the server 450 can receive road congestion information for other areas.

[0134] The server 450 can also receive travel information associated with one or more vehicles. For example, the vehicle 401 can transmit travel information 406 to the server 450, such as when the vehicle 401 begins a trip, periodically during operation, upon request from the server 450, upon request from an operator of the vehicle 401, or a combination thereof. The travel information 406 can include or indicate information associated with movement or travel of the vehicle 401, such as from an origin location to a destination. For example, the travel information 406 can indicate a position of the vehicle 401, a speed of the vehicle 401, a heading of the vehicle 401, a direction of travel of the vehicle 401, or a combination thereof. In some implementations, the travel information 406 includes or corresponds to one or more basic safety messages (BSMs), one or more cooperative awareness messages (CAMs), one or more collective perception messages (CPMs), one or more sensor data sharing messages (SDSMs), other types of vehicle or V2X messaging, or a combination thereof.

[0135] After receiving the road congestion information 470 and the travel information 406, the server 450 can determine a road congestion metric 464 associated with the destination region 462 (e.g., the region 419) based on the road congestion information 470. In some implementations, the server 450 can identify the destination region 462 based on the travel information 406 that the one or more vehicles (e.g., the vehicle 401) are expected to be located at a future time. As described above, the destination region 462 can be a region in which a final destination location (e.g., a final destination) of the vehicle 401 is located, and optionally one or more intermediate or transit regions between the region and a region in which the vehicle 401 is currently located. The destination region 462 can be provided directly by the vehicle 401 (e.g., in the travel information 406) or by the map service server 490 (e.g., in the map or tracking data 492), or the server 450 can identify the destination region 462 based on the travel information 406. For example, the server 450 can identify the destination region 462 by extrapolating an expected location or region of the vehicle 401 based on a location of the vehicle 401, a heading of the vehicle 401, a speed of the vehicle 401, or a combination thereof. In some implementations, the server 450 can identify the destination region 462 based on a route of the vehicle 401, such as a route provided by the vehicle 401 (e.g., in the travel information 406) or a route provided by the map service server 490 (e.g., in the map or tracking data 492). Figure 4 In the depicted example, the destination region 462 can include or correspond to the region 419.

[0136] The server 450 can also use information from other sources to identify the destination region 462 or refine the identification of the destination region. In some implementations, the server 450 can receive map or tracking data 492 from a map service server 490, such as from periodic transmissions or on request of the map or tracking data 492. The map or tracking data 492 can include or indicate map data associated with the vehicle 401 (e.g., a map of a travel path from a first destination to a second destination), tracking data associated with the vehicle 401 (e.g., a current or estimated position of the vehicle 401 along the travel path or a relative position with respect to one or more waypoints or other tracking features), or a combination thereof. The server 450 can identify the destination region 462 based on the map or tracking data 492, such as by extracting a final destination corresponding to the destination region 462 or one or more regions between the vehicle 401 and the target destination that correspond to the destination region 462. Additionally or alternatively, the server 450 can identify or refine the destination region 462 further based on the road topology information 468. For example, an initial estimate of the destination region 462 can cover a large area, and the server 450 can omit portions of the area that are not connected to the current location of the vehicle 401 by one or more roads, as indicated by the road topology information 468. As another example, the server 450 can determine that the vehicle 401 is currently located on a highway with no exits within five miles, as indicated by the road topology information 468, and the server 450 can refine the initial determination of the destination region 462 to exclude or omit a portion that is within five miles of the current position of the vehicle 401 and cannot be reached by an exit. Additionally or alternatively, the server 450 can identify the destination region 462 based on historical travel data 469. For example, if the historical travel data 469 indicates that the vehicle 401 typically travels from a first location (e.g., home) to a second location (e.g., a workplace) between 9:00 and 10:00 AM on weekdays, and it is currently Tuesday at 9:15, the server 450 can identify the destination region 462 as a region that includes the second location.

[0137] The server 450 can determine a road congestion metric 464 based on road congestion information 470 corresponding to the determined destination region 462. For example, the server 450 can determine a number of messages transmitted within the region 419 (e.g., the destination region 462) that are included in the road congestion information 470 or vehicles identified by the road congestion information 470. Other road congestion metrics are also possible. As described above, the road congestion metric 464 can include a number of vehicles located within the destination region 462, a trend in the number of vehicles located within the destination region 462, a count of safety messages communicated within the destination region 462, a channel metric associated with the destination region 462, other metrics, or a combination thereof.

[0138] After determining the road congestion metric 464, the server 450 can generate an indicator of the sensor sharing configuration 407 based on the road congestion metric 464. For example, the server 450 can perform a comparison of the road congestion metric 464 to the threshold 466 to generate the indicator, and based on the results of the comparison, the server 450 can select which or how many sensor sharing mitigation techniques to include in the sensor sharing configuration 407 and optionally select associated parameters. For example, as a non-limiting example, the server 450 can compare the determined number of vehicles within the destination region 462 to a threshold number of vehicles, compare the reported CBR to a threshold CBR, or compare the current maximum sensor sharing packet size that can be transmitted without error as reported by the UE to a threshold packet size to determine which sensor sharing mitigation techniques to select or whether to increase or decrease overall sensor sharing mitigation. In some implementations, different sensor sharing mitigation techniques can correspond to different ones of the thresholds 466, different vehicle types, different regions, or other considerations, and the server 450 can select which sensor sharing mitigation techniques to include in the sensor sharing configuration 407 based on the comparison of the road congestion metric 464 to the thresholds 466, the type of vehicle 401, the destination region 462, other considerations, or a combination thereof. As an illustrative example, the server 450 can determine the sensor sharing configuration 407 to increase sensor sharing mitigation (e.g., decrease redundancy) based on the road congestion metric 464 satisfying one or more of the thresholds 466 (e.g., indicating that there is a relatively large amount of road congestion in the destination region 462) (e.g., by selecting sensor sharing mitigation techniques and optionally selecting parameters). As another example, the server 450 can determine the sensor sharing configuration 407 to decrease sensor sharing mitigation (e.g., increase redundancy) based on the road congestion metric 464 failing to satisfy one or more of the thresholds 466 (e.g., indicating that there is a relatively small amount of road congestion in the destination region 462).

[0139] After determining the sensor sharing configuration 407 based on the road congestion metric 464 and the travel information 406, the server 450 sends a sensor sharing configuration indicator 471 to enable the vehicle 401 to perform the indicated sensor sharing mitigation techniques. In some implementations, the server 450 sends the sensor sharing configuration indicator 471 to the network entity 430 (e.g., RSU, base station, etc.), and the network entity 430 sends a sensor sharing configuration message 472 to the vehicle 401, such as when the vehicle 401 is within the area 419. In some such implementations, the network entity 430 can perform some of the sensor sharing mitigation selections. For example, the sensor sharing configuration indicator 471 can indicate whether sensor sharing mitigation is to be performed, and the network entity 430 can select which sensor sharing mitigation techniques to include in the sensor sharing configuration message 472, such as based on information associated with the area 419, information associated with the network entity 430, information associated with the vehicle 401, other information, or a combination thereof. Alternatively, the sensor sharing configuration indicator 471 can include this information, and the network entity 430 can simply forward or pass through the sensor sharing configuration indicator 471 as the sensor sharing configuration message 472. In yet other implementations, the server 450 can send the sensor sharing configuration message 472 directly to the vehicle 401.

[0140] In some implementations, the sensor sharing configuration indicator 471, the sensor sharing configuration message 472, or both include an indicator 474 of one or more sensor sharing mitigation techniques to be performed at the vehicle 401. For example, the one or more sensor sharing mitigation techniques corresponding to the indicator 474 can include a frequency-based mitigation technique, a distance-based mitigation technique, a dynamic-based mitigation technique, a confidence-based mitigation technique, an entropy-based mitigation technique, an object self-announcement-based mitigation technique, or a combination thereof. In some such implementations, the sensor sharing configuration indicator 471, the sensor sharing configuration message 472, or both further indicate parameters 476 associated with the indicator 474 (e.g., the one or more sensor sharing mitigation techniques). For example, the parameters 476 can include a time window (e.g., WRedundancy), a detection instance (e.g., NRedundancy), a threshold distance (e.g., RRedundancy, PRedundancy), a threshold speed (e.g., SRedundancy), an entropy threshold (e.g., ERedundancy), or a combination thereof.

[0141] In some implementations, the network entity 430 can transmit the sensor sharing configuration message 472 to the vehicle 401 via one or more downlink communications, such as one or more Uu communications. For example, the network entity 430 can transmit the sensor sharing configuration message 472 to a single vehicle (e.g., the vehicle 401), and the sensor sharing configuration message 472 can be included in or correspond to an RRC message. Alternatively, the network entity 430 can transmit the sensor sharing configuration message 472 to multiple vehicles, including the vehicle 401, and the sensor sharing configuration message 472 can be included in or correspond to a system information block (SIB) message. In some other implementations, the network entity 430 can transmit the sensor sharing configuration message 472 via one or more sidelink communications, such as one or more PC5 communications. For example, the network entity 430 can transmit the sensor sharing configuration message 472 to a single vehicle (e.g., the vehicle 401), and the sensor sharing configuration message 472 can be included in or correspond to a sidelink radio resource control (RRC) message or a sidelink signaling message (e.g., a PC5-S message). Alternatively, the network entity 430 can transmit the sensor sharing configuration message 472 to multiple vehicles, including the vehicle 401, that are located within a particular range from the network entity 430 (e.g., using distance-based sidelink groupcast transmission). In some other implementations, the network entity 430 can broadcast the sensor sharing configuration message 472 to all vehicles within a maximum communication range of the network entity 430.

[0142] The vehicle 401 can receive the sensor sharing configuration message 472 and implement the sensor sharing mitigation technique upon receiving the sensor sharing configuration message 472, either immediately or at an indicated future time, when located within the destination region 462 (e.g., the region 419). In this way, the vehicle 401 can perform sensor sharing mitigation (e.g., redundancy mitigation) according to the technique selected by the server 450. For example, at the future time, the vehicle 401 can generate information to communicate to another device. The information can include sensor information 478, such as sensor information to be included in a CPM. The vehicle 401 can generate a message 477 for transmission to another device applying one or more sensor sharing mitigation techniques indicated by the sensor sharing configuration message 472. For example, the message 477 can include sensor information 478 that satisfies or is generated according to one or more sensor sharing mitigation rules selected by 450, and can omit at least some sensor information that does not satisfy or is not generated according to the sensor sharing mitigation rules.

[0143] As referenced above, the vehicle 401 can implement the sensor sharing mitigation technique upon receiving the sensor sharing configuration message 472, either immediately or at an indicated future time, when located within the destination region 462 (e.g., the region 419). In this way, the vehicle 401 can perform sensor sharing mitigation (e.g., redundancy mitigation) according to the technique selected by the server 450. For example, at the future time, the vehicle 401 can generate information to communicate to another device. The information can include sensor information 478, such as sensor information to be included in a CPM. The vehicle 401 can generate a message 477 for transmission to another device applying one or more sensor sharing mitigation techniques indicated by the sensor sharing configuration message 472. For example, the message 477 can include sensor information 478 that satisfies or is generated according to one or more sensor sharing mitigation rules selected by 450, and can omit at least some sensor information that does not satisfy or is not generated according to the sensor sharing mitigation rules. Figure 4As described, the present disclosure provides techniques for supporting sensor sharing configurations (e.g., redundancy mitigation techniques), such as sensor sharing configuration 407, over sidelink (e.g., PC5) or network-based (e.g., Uu) communications based on input from OBUs, RSUs, base stations, and assistance services (e.g., map service server 490). For example, server 450 can be configured to proactively determine a sensor sharing configuration 407 for vehicle 401 based on travel information 406 and road congestion metrics 464. Additionally or alternatively, server 450 can perform sensor sharing mitigation parameter adjustments based on travel information and road congestion metrics 464. By proactively determining a sensor sharing configuration 407 for a destination region 462 to which vehicle 402 has not yet traveled, the network can achieve more efficient spectrum utilization for one or more devices located within the destination region 462 (e.g., region 419) as compared to relying on vehicle 401 to select a sensor sharing configuration that does not have information related to region 419, which can be too far for vehicle 401 to measure. For example, wireless communications system 400 can experience improved communications, including reduced network channel load (e.g., reduced OTA congestion), improved network efficiency, improved resource and energy utilization, improved traffic safety messaging, reduction in traffic accidents, or combinations thereof due to channel sharing mitigation techniques selected based on more relevant information. The framework for the messages and techniques described herein can be standardized within one or more 3GPP V2X standards (e.g., (38.331, 24.587, or other standards or sections) or one or more application layer standards (e.g., SAE, ETSI-ITS, C-SAE), some of which have already identified redundancy mitigation techniques for OBUs and RSUs to reduce redundant reporting of detected objects by multiple OBUs or RSUs.

[0144] Figure 6 FIG. 6 is a flow diagram illustrating an example process 600 that supports sensor sharing configurations in accordance with one or more aspects. The operations of process 600 can be performed by a server, such as server 450 described above with reference to Figure 4 FIG. 5, or server described above with reference to Figure 12 FIG. 4. For example, example operations of process 600 (also referred to as “blocks”) can enable a server, such as a cloud entity, to support sensor sharing configurations.

[0145] In block 602, the server collects road congestion information. The road congestion information can include or correspond to road congestion information 470. The road congestion information can be associated with one or more areas, such as areas 419. In some implementations, the road congestion information can include or correspond to area OTA congestion information. For example, the road congestion information collected by the server can represent or be associated with OTA congestion, or the OTA congestion information collected by the server can represent or be associated with road congestion.

[0146] To collect the road congestion information, the server can receive information from one or more network entities (e.g., 430), such as a UE (e.g., 115), a vehicle (e.g., 401 or 422) or OBU, a base station (e.g., 105), an RSU, a traffic control device, or a combination thereof. For example, in block 604, the server collects BSMs, CAMs, or other sidelink messages transmitted by vehicles that are collected by RSUs. The sidelink messages can include one or more PC5 messages. As another example, in block 606, the server collects CBR measurements reported by vehicles or reported by RSUs. In some implementations, the CBR measurements reported by vehicles can include CBR measurements reported by OBUs. As another example, in block 608, the server collects CBR measurements reported by base stations. As another example, in block 610, the server collects vehicle and congestion data. As an illustrative, non-limiting example, the vehicle and congestion data can include data or information received from one or more traffic control devices, such as traffic cameras or lane metering devices. Although collecting road congestion information in block 602 is described as including each of blocks 604, 606, 608, and 610, in other implementations, collecting road congestion information in block 602 can not include one or more of blocks 604, 606, 608, or 610.

[0147] In block 612, the server overlays road congestion on a map. The road congestion can be determined based on the road congestion information collected by the server. For example, the road congestion can include or indicate one or more congestion levels for a road, zone, or area. In some implementations, the road congestion can include or correspond to OTA congestion. The map can include or correspond to map data, such as road topology information 468, map or tracking data 492, or a combination thereof.

[0148] In block 614, the server determines a location of the vehicle (or OBU of the vehicle), a motion state of the vehicle (or OBU of the vehicle), or a combination thereof. As an illustrative, non-limiting example, the motion state can include a speed of the vehicle, a heading of the vehicle, or a combination thereof. In some implementations, the location and motion state can include or be associated with a current location and a current motion state of the vehicle. The vehicle can include or correspond to the vehicle 401 or 422.

[0149] To determine the location or motion state of the vehicle (or OBU), the server can receive information from one or more network entities (e.g., 430), such as a vehicle (e.g., 401 or 422) or OBU, a third-party application or server, or a combination thereof. For example, in block 616, the server receives a sidelink message transmitted by the vehicle. The sidelink message transmitted by the vehicle can include a BSM, a CAM, a CPM, a SDSM, maneuver coordination information, or a combination thereof. The sidelink message transmitted by the vehicle can include or correspond to the travel information 406, the message 477, or the sensor information 478. In some implementations, the sidelink message transmitted by the vehicle includes or corresponds to a PC5 message. As another example, in block 618, the server receives map data, tracking data, or a combination thereof. The map data, tracking data, or a combination thereof can include or correspond to the map or tracking data 492. The map data, tracking data, or a combination thereof can be received from a third-party service or application, such as a third-party server (e.g., 490). To illustrate, as an illustrative, non-limiting example, the third-party service or application can include or correspond to Google Maps, Apple Maps, Life360, or OnStar Guardian. Although determining the location or motion state of the vehicle (or OBU) in block 614 is described as including each of block 616 and block 618, in other implementations, determining the location or motion state of the vehicle (or OBU) in block 614 can not include one or more of block 616 or 618.

[0150] In block 620, the server estimates a future location of the vehicle. For example, the future location of the vehicle can be a destination region of the vehicle, such as a final destination region or an intermediate destination region. The destination region can include or correspond to the region 419 or the destination region 462. Estimating the future location of the vehicle can include the server inferring or predicting the future location of the vehicle. The server can estimate (e.g., infer or predict) the future location of the vehicle based on the location of the vehicle (or OBU), the state of motion of the vehicle (or OBU), or a combination thereof, such as by extrapolating a travel path to a future time based on that information. Additionally or alternatively, the server can estimate (e.g., infer or predict) the future location of the vehicle based on road topology information, destination information, historical travel information, or a combination thereof. The road topology information can include or correspond to the road topology information 468. The historical travel information can include or correspond to information from a map application, such as a third-party map application (e.g., the map service server 490). The historical travel information can include or correspond to the historical travel data 469.

[0151] In block 622, the server determines a sensor sharing mitigation technique based on the future location of the vehicle or associated with the future location of the vehicle. The sensor sharing mitigation technique can be associated with the sensor sharing configuration 407, the sensor sharing configuration indicator 471, the sensor sharing configuration message 472, the indicator 474, the parameter 476, the sensor sharing configuration IE 500, or a combination thereof. In some implementations, the sensor sharing mitigation technique is determined based on road congestion information at the destination region (e.g., the future location of the vehicle), road congestion information associated with the current location of the vehicle, a route traveled by the vehicle, or a combination thereof. In some implementations, the server can determine a sensor sharing configuration that includes or indicates the sensor sharing mitigation technique. The sensor sharing configuration can be associated with the sensor sharing configuration 407, the sensor sharing configuration indicator 471, the sensor sharing configuration message 472, the indicator 474, the parameter 476, the sensor sharing configuration IE 500, or a combination thereof. In some implementations, the sensor sharing mitigation technique, a parameter of the sensor sharing mitigation technique, the sensor sharing configuration, or a combination thereof can be determined for the vehicle, the destination region, a region other than the destination region, or a combination thereof.

[0152] In block 624, the server sends a sensor sharing mitigation configuration message to one or more vehicles. The sensor sharing mitigation configuration message can include or indicate the determined sensor sharing mitigation technique. The sensor sharing mitigation configuration message can include or correspond to the sensor sharing configuration 407, the sensor sharing configuration indicator 471, the sensor sharing configuration message 472, the indicator 474, the parameter 476, the sensor sharing configuration IE 500, or a combination thereof.

[0153] To transmit the sensor sharing mitigation configuration message, in block 626, the server transmits the sensor sharing mitigation configuration message to the individual vehicle via dedicated sidelink or downlink signaling. For example, the server can transmit the sensor sharing mitigation configuration message over a PC5 link or a Uu link. Additionally or alternatively, to transmit the sensor sharing mitigation configuration message, in block 628, the server transmits the sensor sharing mitigation configuration message to multiple vehicles via common sidelink signaling or via downlink signaling. For example, as a non-limiting example, the server can transmit the sensor sharing mitigation configuration message to multiple devices over a PC5 link or a Uu link, such as via a broadcast or a distance-based groupcast. Although transmitting the sensor sharing mitigation configuration message in block 624 is described as including each of block 626 and block 628, in other implementations, transmitting the sensor sharing mitigation configuration message in block 624 can not include one or more of block 626 or 628.

[0154] Figure 7 FIG. 7 is a flow diagram illustrating an example process 700 that supports sensor sharing configuration in accordance with one or more aspects. The operations of process 700 can be performed by a server, such as the server 450 described above with reference to FIG. 4 or the server described with reference to FIG. 5, a core network 130, or a management function. For example, the example operations of process 700 (also referred to as “blocks”) can enable a server to support sensor sharing configuration. Figure 4 Figure 12 The operations of process 700 can be performed by a server, such as the server 450 described above with reference to FIG. 4 or the server described with reference to FIG. 5, a core network 130, or a management function. For example, the example operations of process 700 (also referred to as “blocks”) can enable a server to support sensor sharing configuration.

[0155] In block 702, the server receives road congestion information associated with one or more areas. The road congestion information can include or correspond to the road congestion information 470 or the information 437. The one or more areas can include or correspond to the areas 419. The road congestion information can be received from a network entity, such as a base station 105, an RSU, the network entity 430, or a combination thereof. To illustrate, the road congestion information can be received from one or more RSUs, such as one or more RSUs located within or near the one or more areas.

[0156] ​In some implementations, the road congestion information includes, is included in, or is indicated by one or more BSMs, one or more CAMs, or a combination thereof. Additionally or alternatively, the road congestion information can include or indicate one or more CBR measurements. The one or more CBR measurements can be generated by a vehicle, an RSU, a network entity, a base station, or a combination thereof. To illustrate, the road congestion information (which includes or indicates the one or more CBR measurements) can be received from a base station that is located within at least a portion of the one or more regions, is located near at least a portion of the one or more regions, or serves at least a portion of the one or more regions. In some implementations, the road congestion information includes traffic camera data associated with the one or more regions, lane metric data associated with the one or more regions, time congestion data associated with the one or more regions, or a combination thereof.

[0157] In block 704, the server receives travel information associated with one or more vehicles. The travel information can include or correspond to the travel information 406. The one or more vehicles can include or correspond to the vehicle 401 or the vehicle 422. The travel information can indicate, for a first vehicle of the one or more vehicles, a position of the first vehicle, a speed of the first vehicle, a heading of the first vehicle, a travel direction of the first vehicle, or a combination thereof. The travel information includes, is included in, or is indicated by one or more BSMs, one or more CAMs, one or more CPMs, one or more SDSMs, or a combination thereof.

[0158] In block 706, the server sends an indicator of a sensor sharing configuration for the one or more vehicles. The indicator can include or correspond to the sensor sharing configuration 407, the sensor sharing configuration indicator 471, the sensor sharing configuration message 472, the indicator 474, the parameter 476, the sensor sharing configuration IE 500, or a combination thereof. The sensor sharing configuration can include or correspond to the sensor sharing configuration 407. The sensor sharing configuration can be based on the road congestion information, the travel information, or a combination thereof. In some implementations, the sensor sharing configuration is based on the road congestion information and the travel information. In some implementations, the sensor sharing configuration is associated with a region of the one or more regions.

[0159] In some implementations, the indicator of the sensor sharing configuration includes or indicates one or more sensor sharing mitigation techniques to be performed at the one or more vehicles. For example, the one or more sensor sharing mitigation techniques include a frequency-based mitigation technique, a distance-based mitigation technique, a dynamic-based mitigation technique, a confidence-based mitigation technique, an entropy-based mitigation technique, an object self-announcement-based mitigation technique, or a combination thereof. Additionally or alternatively, the indicator of the sensor sharing configuration includes or indicates one or more parameters associated with the one or more sensor sharing mitigation techniques. The one or more parameters include a time window, a detection instance, a threshold distance, a threshold velocity, a threshold entropy, or a combination thereof.

[0160] In some implementations, the server identifies a destination region of the one or more regions in which the one or more vehicles are expected to be located at a future time based on the travel information. For example, the server can identify a destination region that the vehicles are traveling towards. The destination region can include or correspond to the region 419 or the destination region 462. Additionally or alternatively, the server can determine a road congestion metric associated with the destination region based on the road congestion information. For example, the road congestion metric can be associated with the destination region or another region, such as a region that the vehicles are expected to travel through. The road congestion metric can include or correspond to the road congestion metric 464. In some implementations, the server performs a comparison based on the road congestion metric and a threshold. The threshold can include or correspond to the threshold 466. Additionally or alternatively, the server can generate the indicator of the sensor sharing configuration based on the comparison, such as the comparison of the road congestion metric to the threshold. In some implementations, to generate the indicator of the sensor sharing configuration, the server determines the sensor sharing configuration to increase sensor sharing mitigation at the one or more vehicles based on the road congestion metric satisfying the threshold. Alternatively, to generate the indicator of the sensor sharing configuration, the server determines the sensor sharing configuration to decrease sensor sharing mitigation at the one or more vehicles based on the road congestion metric satisfying the threshold.

[0161] In some implementations, the server receives map data associated with the one or more vehicles, tracking data associated with the one or more vehicles, or a combination thereof. The map data, the tracking data, or the combination thereof can include or correspond to the map or tracking data 492. In some such implementations, the destination region is identified further based on the map data, the tracking data, or the combination thereof. Additionally or alternatively, the destination region can be determined further based on road topology information associated with a road on which the one or more vehicles are traveling, historical travel data associated with the one or more vehicles, or a combination thereof. The road topology information can include or correspond to the road topology information 468. The historical travel data can include or correspond to the historical travel data 469.

[0162] In some implementations, to transmit the indicator of the sensor sharing configuration, the server initiates transmission of the indicator or the sensor sharing configuration via one or more downlink communications. In some implementations, the one or more vehicles include a single vehicle, and the indicator of the sensor sharing configuration is included in an RRC message. Alternatively, the one or more vehicles include multiple vehicles, and the indicator of the sensor sharing configuration is included in a SIB message.

[0163] In some implementations, the one or more vehicles include a single vehicle, and the indicator is transmitted to another network entity to cause the another network entity to transmit the sensor sharing configuration to the single vehicle via a sidelink communication. The indicator of the sensor sharing configuration can be included in a sidelink RRC message or a sidelink signaling message. In some implementations, to provide the indicator or the sensor sharing configuration to the one or more vehicles, the server can transmit the indicator to a network entity, such as a base station or an RSU, and the network entity can transmit the indicator or the sensor sharing configuration to the one or more vehicles. In some such implementations, the indicator is transmitted to one or more network entities to cause one or more other network entities to broadcast the sensor sharing configuration via one or more sidelink communications. Additionally or alternatively, to transmit the indicator of the sensor sharing configuration, the sensor can cause one or more other network entities to transmit the sensor sharing configuration to one or more vehicles located within a particular range from the one or more other network entities via one or more sidelink communications.

[0164] In some implementations, the server receives second travel information associated with one or more other vehicles. The second travel information can include or correspond to the travel information 406. The server can transmit a second indicator of a second sensor sharing configuration for the one or more other vehicles. The second indicator can include or correspond to the sensor sharing configuration 407, the sensor sharing configuration indicator 471, the sensor sharing configuration message 472, the indicator 474, the parameter 476, the sensor sharing configuration IE 500, or a combination thereof. The second sensor sharing configuration can include or correspond to the sensor sharing configuration 407. The second sensor sharing configuration can be based on the road congestion information and the second travel information. The sensor sharing configuration can be associated with a first destination region of the one or more regions, which is different from a second sensor sharing configuration associated with a second destination region of the one or more regions. The second destination region can be different from the first destination region.

[0165] Figure 8 FIG. 8 is a flowchart illustrating an example process 800 that supports sensor sharing configuration in accordance with one or more aspects. The operations of process 800 can be implemented by a network entity (such as a base station 105, a RSU 205, a sensor 215, a server 230, a vehicle 250, or a combination thereof), or their equivalents. For example, the network entity can execute instructions stored in a non-transitory computer-readable medium to perform the operations of process 800. Figure 1UE 115z, Figure 1 to Figure 3 base station 105, Figure 4 network entity 430 or a network entity as described with reference to Figure 11 may enable the network entity to support sensor sharing configuration.

[0166] At block 802, the network entity transmits road congestion information associated with an area. For example, the road congestion information can include or correspond to road congestion information 470. In some implementations, the network entity can transmit a BSM or a CAM including the road congestion information.

[0167] At block 804, the network entity receives an indicator of a sensor sharing configuration for one or more vehicles. The indicator can include or correspond to sensor sharing configuration indicator 471. The sensor sharing configuration can include or correspond to sensor sharing configuration 407, sensor sharing configuration indicator 471, sensor sharing configuration message 472, indicator 474, parameter 476, sensor sharing configuration IE 500, or a combination thereof. The one or more vehicles can include or correspond to vehicles 401 or 422. The sensor sharing configuration can be based on the road congestion information, travel information associated with the vehicles, or a combination thereof. The travel information associated with the vehicles can include or correspond to travel information 406. In some implementations, the sensor sharing configuration can be based on the road congestion information and the travel information associated with the vehicles.

[0168] At block 806, the network entity transmits a message to at least one vehicle indicating the sensor sharing configuration. The message can include or correspond to sensor sharing configuration message 472, indicator 474, parameter 476, sensor sharing configuration IE 500, or a combination thereof. In some implementations, the network entity can generate the message based on the received indicator. Additionally or alternatively, the network entity can transmit the message using dedicated sidelink, public sidelink, or downlink signaling.

[0169] In some implementations, the network entity receives the indicator and an area indicator, a vehicle indicator, or a combination thereof. The network entity can generate and transmit the message based on the area indicator, the vehicle indicator, or a combination thereof. For example, the network entity can transmit the message to one or more vehicles located in an area corresponding to or indicated by the area indicator (e.g., 419). As another example, the network entity can transmit the message to one or more vehicles based on the vehicle indicator, such as a vehicle indicator indicating an individual vehicle or indicating a group or platoon of vehicles.

[0170] Figure 9is a flowchart illustrating an example process 900 that supports sensor sharing configuration in accordance with one or more aspects. The operations of process 900 can be performed by a vehicle such as the vehicles 401 or 422 described above with reference to Figure 4 FIG. 15, or by a UE 115i, 115j, 115k described above with reference to Figure 7 FIG. 16. For example, example operations of process 900 (also referred to as “blocks”) can enable a vehicle to support sensor sharing configuration. Figure 1 to Figure 2 In block 902, the vehicle transmits travel information associated with the vehicle. The travel information can include or correspond to the travel information 406. In some implementations, the travel information includes or indicates a route of the vehicle, a destination of the vehicle, an area in which the vehicle is located, a motion state (e.g., a speed or a heading) of the vehicle, or a combination thereof. Additionally or alternatively, the travel information can be included in or indicated by a BSM, a CAM, a CPM, a SDSM, maneuver coordination information, or a combination thereof generated or transmitted by the vehicle.

[0171] In block 904, the vehicle receives a configuration message indicating a sensor sharing configuration for the vehicle. The configuration message can include or correspond to the sensor sharing configuration indicator 471, the sensor sharing configuration message 472, the indicator 474, the parameters 476, the sensor sharing configuration IE 500, or a combination thereof. The sensor sharing configuration can include or correspond to the indicator 474, the parameters 476, the sensor sharing configuration 407, or a combination thereof. The sensor sharing configuration can be based on the travel information (e.g., 406). Additionally, the sensor sharing configuration can be based on road congestion information associated with an area. For example, the road congestion information can include or correspond to the road congestion information 470. The area can include or correspond to the area 419.

[0172] In some implementations, the configuration message, the sensor sharing configuration, or a combination thereof can include or indicate an area indicator, a vehicle indicator, or a combination thereof. For example, the area indicator can indicate one or more areas (e.g., 419) to which the sensor sharing configuration is to be applied. As another example, the vehicle indicator can indicate one or more vehicles (e.g., individual vehicles, or a group or platoon of multiple vehicles) to which the sensor sharing configuration is to be applied.

[0173]

[0174] ​In box 906, the vehicle sends a message indicating a detected object based on a sensor-sharing configuration. For example, the vehicle may detect an object based on sensor data generated by one or more sensors of the vehicle. One or more sensors of the vehicle may be configured based on the received sensor-sharing configuration. The message may include or correspond to message 477, sensor information 478, or a combination thereof.

[0175] In some implementations, the vehicle may configure one or more components, such as the OBU, based on a sensor-shared configuration. Alternatively, the vehicle may generate sensor data / information. The vehicle may generate messages (indicating detected objects) based on or according to the sensor-shared configuration.

[0176] Figure 10 This is a perspective view of a motor vehicle with a driver monitoring system, based on one or more aspects. The vehicle 1000 may include a UE within a wireless network 100 or communicate with that UE, such as... Figure 1 As shown. In some specific implementations, vehicle 1000 may include or correspond to UE 115i, 115j, or 115k, vehicle 411, or vehicle 422. One or more components described with reference to vehicle 1000 may include or correspond to one or more components as described with reference to at least vehicle 401. For example, one or more components described with reference to vehicle 1000 may include one or more sensors of vehicle 401. One or more sensors may be configured to or used to generate sensor information, such as sensor information 478.

[0177] Vehicle 1000 may include a forward-facing camera 1012 mounted inside the passenger compartment for viewing through the windshield 1002. Vehicle 1000 may also include a passenger compartment-facing camera 1014 mounted inside the passenger compartment for viewing the occupants of vehicle 1000, and particularly the driver of vehicle 1000. Although a set of mounting locations for cameras 1012 and 1014 has been shown for vehicle 1000, other mounting locations may also be used for cameras 1012 or 1014. For example, one or more cameras may be mounted on one of the driver's or passenger pillars 1026 or 1028, such as near the top of pillar 1026 or 1028. Alternatively, one or more cameras may be mounted at the front of vehicle 1000, such as behind the radiator grille 1030 or integrated with the bumper 1032. As a further example, one or more cameras may be mounted as part of a driver or passenger side mirror assembly 1034.

[0178] The camera 1012 can be oriented such that its field of view captures a scene forward of the vehicle 1000 in a direction in which the vehicle 1000 is moving when in a drive mode or a forward direction. In some embodiments, an additional camera can be located at a rear of the vehicle 1000 and oriented such that its field of view captures a scene behind the vehicle 1000 in a direction in which the vehicle 1000 is moving when in a reverse direction. Although aspects of the disclosure can be described with reference to a “forward-facing” camera (with reference to the camera 1012), aspects of the disclosure can be similarly applied to a “rear-facing” camera facing a reverse direction of the vehicle 1000. Thus, benefits obtained when an operator is operating the vehicle 1000 in a forward direction can similarly be obtained when the operator is operating the vehicle 1000 in a reverse direction.

[0179] Furthermore, although embodiments of the disclosure can be described with reference to a “forward-facing” camera (with reference to the camera 1012), aspects of the disclosure can be similarly applied to input received from an array of cameras mounted around the vehicle 1000 to provide a large field of view that can wrap around up to 360 degrees parallel to the ground and / or up to 360 degrees in a vertical direction perpendicular to the ground. For example, additional cameras can be mounted around an exterior of the vehicle 1000, such as on or integrated into doors, on or integrated into wheels, on or integrated into bumpers, on or integrated into a hood, and / or on or integrated into a roof.

[0180] The camera 1014 can be oriented such that its field of view is configured to capture a scene in a passenger compartment of the vehicle 1000 and includes a user operator of the vehicle 1000. In some implementations, the camera 1014 is configured to capture a face of the user operator of the vehicle 1000 with sufficient detail to discern a gaze direction of the user operator.

[0181] Each of the camera 1012 and the camera 1014 can include one, two, or more image sensors, such as including a first image sensor. When there are multiple image sensors, the first image sensor can have a larger field of view (FOV) than a second image sensor, or the first image sensor can have a different sensitivity or a different dynamic range than the second image sensor. In one example, the first image sensor can be a wide-angle image sensor, and the second image sensor can be a telephoto image sensor. In another example, the first sensor is configured to obtain images through a first lens having a first optical axis, and the second sensor is configured to obtain images through a second lens having a second optical axis different from the first optical axis. Additionally or alternatively, the first lens can have a first magnification, and the second lens can have a second magnification different from the first magnification. Such a configuration can occur in a camera module with a lens group, where multiple image sensors and associated lenses are located in offset positions within the camera module. Additional image sensors with larger, smaller, or the same field of view can be included.

[0182] Each image sensor can include components for capturing data representative of a scene, such as image sensors including charge-coupled devices (CCDs), Bayer filter sensors, infrared (IR) detectors, ultraviolet (UV) detectors, complementary metal-oxide-semiconductor (CMOS) sensors, and / or time-of-flight detectors. The apparatus can also include one or more components for gathering and / or focusing light rays into one or more image sensors, including simple lenses, compound lenses, spherical lenses, and aspherical lenses. These components can be controlled to capture first, second, and / or more image frames. The image frames can be processed to form a single output image frame (such as through a fusion operation), and the output image frame is further processed in accordance with aspects described herein.

[0183] As used herein, an image sensor can refer to the image sensor itself and any particular other components coupled to the image sensor for generating image frames for processing by an image signal processor or other logic circuit or stored in memory, whether a short-term buffer or a long-term non-volatile memory. For example, an image sensor can include other components of a camera, including shutters, buffers, or other readout circuitry for accessing individual pixels of the image sensor. An image sensor can also refer to an analog front end or other circuitry for converting analog signals to a digital representation of an image frame that is provided to digital circuitry coupled to the image sensor.

[0184] The vehicle 1000 can include or otherwise be coupled to an image signal processor for processing image frames from one or more image sensors, such as the first image sensor, the second image sensor, and the depth sensor. The vehicle 1000 can also include or be coupled to a power source, such as a battery or an alternator. The vehicle 1000 can also include or be coupled to Figure 2 one or more features, Figure 2 one or more additional features or components not shown, or a combination thereof.

[0185] The vehicle 1000 can include a sensor hub for interfacing with sensors to receive data about movement of the vehicle 1000, data about the environment surrounding the vehicle 1000, or other non-camera sensor data. The sensor hub can include or be coupled to one or more sensors. One example non-camera sensor is a gyroscope, i.e., a device configured to measure rotation, orientation, or angular velocity to generate motion data. Another example non-camera sensor is an accelerometer, i.e., a device configured to measure acceleration, which can also be used to determine velocity and distance traveled by integrating the measured acceleration as appropriate, and one or more of the acceleration, velocity, and / or distance can be included in the generated motion data. In further examples, the non-camera sensor can be a global positioning system (GPS) receiver, a light detection and ranging (LiDAR) system, a radio detection and ranging (RADAR) system, or other ranging system. For example, the sensor hub can interface to a vehicle bus for communicating configuration commands and / or receiving information from vehicle sensors, such as a distance (e.g., ranging) sensor or a vehicle-to-vehicle (V2V) sensor (e.g., a sensor for receiving information from nearby vehicles).

[0186] Figure 11 is a block diagram of an example network entity 1100 that supports sensor sharing configuration according to one or more aspects. The network entity 1100 can be configured to perform operations including those with reference to Figure 1 to Figure 4 , Figure 6 or Figure 8The blocks of the described process. In some implementations, the network entity 1100 includes the structure, hardware, and components illustrated and described with reference to the UE 115, the base station 105, the vehicle 401, the vehicle 422, the RSU, or the network entity 430. For example, the network entity 1100 includes a controller 280 that operates to execute logic or computer instructions stored in memory 282, as well as to control the components of the network entity 1100 that provide the features and functionality of the network entity 1100. The network entity 1100, under the control of the controller 280, transmits and receives signals via wireless radios 1101a-1101r and antennas 252a-252r. The wireless radios 1101a-1101r include various components and hardware, such as Figure 2 illustrated in FIG. 13 for the UE 115, including modulators and demodulators 254a-254r, MIMO detector 256, receive processor 258, transmit processor 264, and TX MIMO processor 266. Also, for example, the network entity 1100 can include or correspond to a base station, such as Figure 2 the base station 105 of FIG. 1. In such implementations, the wireless radios 1101a-1101t include various components and hardware, such as Figure 2 illustrated in FIG. 13 for the base station 105, including modulators and demodulators 232a-232t, transmit processor 220, TX MIMO processor 230, MIMO detector 236, and receive processor 238.

[0187] As shown, the memory 282 can include information 1102, sensor sharing configuration 1105, and communication logic 1106. The information 1102 can include road congestion information 1103, travel information 1104, or a combination thereof. The road congestion information 1103 can include or correspond to the road congestion information 470. The travel information 1104 can include or correspond to the travel information 406. The sensor sharing configuration 1105 can include or correspond to the sensor sharing configuration indicator 471, the sensor sharing configuration message 472, the indicator 474, the parameters 476, the sensor sharing configuration 407, or a combination thereof. The communication logic 1106 can be configured to enable communication between one or more UEs (e.g., the UE 115), one or more base stations (e.g., the base station 105), one or more network entities (e.g., the network entity 430), one or more network vehicles (e.g., the vehicle 401, the vehicle 422, the vehicle 1000), another server (e.g., the map service server 490 or a server as illustrated in FIG. 14), or the core network 130 or management functions. Figure 12

[0188] Figure 12 ​is a block diagram of an example server 1200 that supports sensor sharing configuration in accordance with one or more aspects. The server 1200 can be configured to perform operations including the blocks of the processes described with reference to Figure 1 、 Figure 4 or Figure 5 to Figure 7 In some implementations, the server 1200 includes the structure, hardware, and components shown and described with reference to the base station 105, the core network 130, or the server 450. For example, the server 1200 can include a controller 240 to execute logic or computer instructions stored in memory 242, as well as control the components of the server 1200 that provide the features and functionality of the server 1200. The server 1200, under the control of the controller 240, transmits and receives signals via wireless radios 1201a-1201t and antennas 234a-234t. The wireless radios 1201a-1201t include various components and hardware, as exemplified in Figure 2 with respect to the base station 105, including modulators and demodulators 232a-232t, transmit processor 220, TX MIMO processor 230, MIMO detector 236, and receive processor 238. Although the server 1200 is described as including the wireless radios 1201a-1201t and antennas 234a-234t, in other implementations, the server 1200 can additionally or alternatively include interfaces, such as interfaces configured for wired communication.

[0189] As shown, the memory 242 can include information 1202, sensor sharing control logic 1205, sensor sharing configuration 1206, and communication logic 1207. The information 1202 can include road congestion information 1203, travel information 1204, or a combination thereof. The road congestion information 1203 can include or correspond to the road congestion information 470. The travel information 1204 can include or correspond to the travel information 406. The sensor sharing control logic 1205 can be configured to generate or determine the sensor sharing configuration 1206. The sensor sharing configuration 1206 can include or correspond to the sensor sharing configuration indicator 471, the sensor sharing configuration message 472, the indicator 474, the parameters 476, the sensor sharing configuration 407, or a combination thereof. The communication logic 1207 can be configured to enable communication between the server 1200 and one or more other devices. The server 1200 can receive or transmit signals from or to one or more UEs (e.g., the UE 115), one or more base stations (e.g., the base station 105), one or more network entities (e.g., the network entity 430 or the network entity 1100), one or more network vehicles (e.g., the vehicle 401, the vehicle 422, the vehicle 1000), another server (e.g., the map server 490), or the core network 130 or management function.

[0190] Note that one or more blocks (or operations) described with reference to a figure can Figure 6 to Figure 9 be combined with one or more blocks (or operations) described with reference to another figure. For example, Figure 6 one or more blocks (or operations) described with reference to Figure 7 may be combined with one or more blocks (or operations) described with reference to Figure 6 or Figure 7 . As another example, one or more blocks associated with Figure 8 may be combined with one or more blocks (or operations) associated with Figure 9 or Figure 6 , Figure 7 or Figure 8 . Additionally or alternatively, one or more operations described above with reference to Figure 1 to Figure 5 may be combined with one or more operations described with reference to Figure 6 to Figure 9 .

[0191] In one or more aspects, techniques for supporting sensor sharing configuration can include additional aspects, such as any single aspect or any combination of aspects described in the following or in connection with one or more other processes or devices described elsewhere herein. In a first aspect, techniques for sensor sharing configuration can include receiving road congestion information associated with one or more areas. The techniques can also include receiving travel information associated with one or more vehicles. The techniques can also include transmitting an indicator of a sensor sharing configuration for the one or more vehicles. The sensor sharing configuration is based on the road congestion information and the travel information. In some examples, the techniques in the first aspect can be implemented in a method or process, such as a communication method performed by a network entity. In some other examples, the techniques of the first aspect can be implemented in a wireless communication device, such as a vehicle or a UE, which can include a vehicle, a component of a vehicle, a UE, or a component of a UE. In some examples, the wireless communication device can include at least one processing unit or system, which can include an application processor, a modem, or other components, and at least one memory device coupled to the processing unit. The processing unit or system can be configured to perform the operations described herein with respect to the wireless communication device. In some examples, the memory device includes a non-transitory computer-readable medium storing instructions or having program code stored thereon that, when executed by the processing unit or system, is configured to cause the wireless communication device to perform the operations described herein. Additionally or alternatively, the wireless communication device can include an interface (e.g., a wireless communication interface) including a transmitter, a receiver, or a combination thereof. Additionally or alternatively, the wireless communication device can include one or more means configured to perform the operations described herein.

[0192] In a second aspect, in combination with the first aspect, the travel information indicates, for a first vehicle of the one or more vehicles, a location of the first vehicle, a speed of the first vehicle, a heading of the first vehicle, a travel direction of the first vehicle, or a combination thereof.

[0193] In a third aspect, in combination with one or more of the first aspect or the second aspect, the travel information comprises one or more BSMs, one or more CAMs, one or more CPMs, one or more SDSMs, or a combination thereof.

[0194] In a fourth aspect, in combination with one or more of the first through third aspects, the indicator of the sensor sharing configuration indicates one or more sensor sharing mitigation techniques to be performed at the one or more vehicles.

[0195] In a fifth aspect, in combination with the fourth aspect, the one or more sensor sharing mitigation techniques comprise a frequency-based mitigation technique, a distance-based mitigation technique, a dynamics-based mitigation technique, a confidence-based mitigation technique, an entropy-based mitigation technique, an object self-announcement-based mitigation technique, or a combination thereof.

[0196] In a sixth aspect, in combination with the fourth aspect, the indicator of the sensor sharing configuration further indicates one or more parameters associated with the one or more sensor sharing mitigation techniques.

[0197] In a seventh aspect, in combination with the sixth aspect, the one or more parameters comprise a time window, a detection instance, a threshold distance, a threshold speed, or a combination thereof.

[0198] In an eighth aspect, in combination with one or more of the first through seventh aspects, the techniques further include identifying, based on the travel information, a destination region of one or more regions in which the one or more vehicles are expected to be located at a future time.

[0199] In a ninth aspect, in combination with the eighth aspect, the techniques further include determining, based on road congestion information, a road congestion metric associated with the destination region.

[0200] In a tenth aspect, in combination with the ninth aspect, the techniques further include generating the indicator of the sensor sharing configuration based on a comparison of the road congestion metric to a threshold value.

[0201] In an eleventh aspect, in combination with the tenth aspect, to generate the indicator of the sensor sharing configuration, the techniques further include determining, based on the road congestion metric satisfying the threshold value, the sensor sharing configuration to increase sensor sharing mitigation at the one or more vehicles.

[0202] In a twelfth aspect, in combination with the tenth aspect, to generate the indicator of the sensor sharing configuration, the techniques further include determining the sensor sharing configuration to reduce sensor sharing mitigation at the one or more vehicles based on the road congestion metric satisfying a threshold.

[0203] In a thirteenth aspect, in combination with the tenth aspect, the techniques further include receiving map data associated with the one or more vehicles.

[0204] In a fourteenth aspect, in combination with the thirteenth aspect, the destination region is identified further based on the map data.

[0205] In a fifteenth aspect, in combination with the tenth aspect, the techniques further include receiving tracking data associated with the one or more vehicles.

[0206] In a sixteenth aspect, in combination with the fifteenth aspect, the destination region is identified further based on the tracking data.

[0207] In a seventeenth aspect, in combination with the tenth aspect, the destination region is determined further based on road topology information associated with a road on which the one or more vehicles are traveling.

[0208] In an eighteenth aspect, in combination with the tenth aspect, the destination region is determined further based on historical travel data associated with the one or more vehicles.

[0209] In a nineteenth aspect, in combination with one or more of the first through eighteenth aspects, to transmit the indicator of the sensor sharing configuration, the techniques further include initiating transmission of the indicator via one or more downlink communications.

[0210] In a twentieth aspect, in combination with the nineteenth aspect, the one or more vehicles include a single vehicle.

[0211] In a twenty-first aspect, in combination with the twentieth aspect, the indicator of the sensor sharing configuration is included in a RRC message.

[0212] In a twenty-second aspect, in combination with the nineteenth aspect, the one or more vehicles include a plurality of vehicles.

[0213] In a twenty-third aspect, in combination with the twenty-second aspect, the indicator of the sensor sharing configuration is included in a SIB message.

[0214] In a twenty-third aspect, in combination with one or more of the first through twenty-second aspects, the one or more vehicles include a single vehicle.

[0215] In a twenty-fifth aspect, in combination with the twenty-fourth aspect, the indicator is transmitted to another network entity to cause the another network entity to transmit the sensor sharing configuration to the single vehicle via a sidelink communication.

[0216] In a twenty-sixth aspect, in combination with the twenty-fifth aspect, the indicator of the sensor sharing configuration is included in a sidelink RRC message or a sidelink signaling message.

[0217] In a twenty-seventh aspect, in combination with one or more of the first aspect through the twenty-sixth aspect, the indicator is transmitted to one or more network entities to cause one or more other network entities to broadcast the sensor sharing configuration via one or more sidelink communications.

[0218] In a twenty-eighth aspect, in combination with one or more of the first aspect through the twenty-seventh aspect, to transmit the indicator of the sensor sharing configuration, the at least one processor is configured to cause the one or more other network entities to transmit the sensor sharing configuration to vehicles located within a particular range from the one or more other network entities via one or more sidelink communications.

[0219] In a twenty-ninth aspect, in combination with one or more of the first aspect through the twenty-eighth aspect, the road congestion information includes one or more BSMs, one or more CAMs, or a combination thereof from one or more RSUs located within the one or more regions.

[0220] In a thirtieth aspect, in combination with one or more of the first aspect through the twenty-ninth aspect, the road congestion information includes one or more CBR measurements reported by vehicles, RSUs, or a combination thereof located within the one or more regions.

[0221] In a thirty-first aspect, in combination with one or more of the first aspect through the thirtieth aspect, the road congestion information includes one or more CBR measurements reported by one or more base stations serving the one or more regions.

[0222] In a thirty-second aspect, in combination with one or more of the first aspect through the thirty-first aspect, the road congestion information includes traffic camera data associated with the one or more regions, lane metric data associated with the one or more regions, time congestion data associated with the one or more regions, or a combination thereof.

[0223] In a thirty-third aspect, in combination with one or more of the first aspect through the thirty-second aspect, the techniques further include receiving second travel information associated with one or more other vehicles.

[0224] In the thirty-fourth aspect, in combination with the thirty-fourth aspect, these technologies also include transmitting a second indicator for a second sensor-sharing configuration for one or more other vehicles, the second sensor-sharing configuration being based on road congestion information and second driving information.

[0225] In aspect thirty-fif, in conjunction with aspect thirty-three, a sensor-sharing configuration is associated with a first destination region in one or more regions, which differs from a second sensor-sharing configuration associated with a second destination region in one or more regions. In some such aspects, the second destination region differs from the first destination region.

[0226] Those skilled in the art will understand that information and signals can be represented using any of a variety of different techniques and skills. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be mentioned throughout the above description can be represented by voltage, current, electromagnetic waves, magnetic fields or magnetic particles, light fields or optical particles, or any combination thereof.

[0227] This article is about Figure 1 to Figure 12 The components, functional blocks, and modules described include processors, electronic devices, hardware devices, electronic components, logic circuits, memory, software code, firmware code, and any combination thereof. Software should be interpreted broadly as instructions, instruction sets, code, code segments, program code, programs, subroutines, software modules, applications, software applications, software packages, routines, subroutines, objects, executable files, threads of execution, procedures, and / or functions, regardless of whether it is referred to as software, firmware, middleware, microcode, hardware description languages, or other terms. Furthermore, the features discussed herein can be implemented via dedicated processor circuitry, via executable instructions, or a combination thereof.

[0228] Those skilled in the art will further understand that the various exemplary logic blocks, modules, circuits, and algorithm steps described in conjunction with the disclosure herein can be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability between hardware and software, various exemplary components, blocks, modules, circuits, and steps have been described above in general terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. Those skilled in the art can implement the described functionality in different ways for each specific application, but such specific implementation decisions should not be construed as departing from the scope of this disclosure. Those skilled in the art will also readily recognize that the order or combination of components, methods, or interactions described herein are merely examples, and that components, methods, or interactions of various aspects of this disclosure can be combined or performed in ways other than those illustrated and described herein.

[0229] The various illustrative logics, logical blocks, modules, circuits and algorithm processes described in connection with the implementations disclosed herein can be implemented as electronic hardware, computer software, or combinations of both. The interchangeability of hardware and software has been described generally, in terms of functionality, and illustrated in the various illustrative components, blocks, modules, circuits and processes described above. Whether such functionality is implemented in hardware or software depends on the particular application and design constraints imposed on the overall system.

[0230] The hardware and data processing apparatus used to implement the various illustrative logics, logical blocks, modules and circuits described in connection with the aspects disclosed herein can be implemented or performed with a general purpose single- or multi-chip processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor can be a microprocessor, but, in the alternative, can be any conventional processor, controller, microcontroller, or state machine. A processor can also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. In some implementations, a processor configured to perform operations can include a single processor configured to perform the operations, or a plurality of computing devices configured to perform the operations individually or in combination as an aggregate. In some implementations, certain processes and methods can be performed by circuitry specifically configured to perform the processes and methods.

[0231] In one or more aspects, the functions described can be implemented in hardware, digital electronic circuitry, computer software, firmware, including the structures disclosed in this specification and their structural equivalents, or in any combination thereof. Implementations of the subject matter described in this specification also can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a computer storage medium for execution by, or to control the operation of, data processing apparatus.

[0232] If implemented in software, the functions can be stored or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media include both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage medium can be any available medium that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media. Additionally, the operations of methods or algorithms can reside in one or any combination of the machine-readable media and computer-readable media, which can be incorporated in software to implement the methods or algorithms.

[0233] Various modifications to the specific implementations described herein will be readily apparent to those skilled in the art, and the generic principles defined herein can be applied to some other implementations without departing from the spirit or scope of the disclosure. Thus, the claims are not intended to be limited to the specific implementations disclosed herein, but rather are to be accorded the full scope consistent with the language of the claims, the principles disclosed herein, and the patentable concept preserved by the disclosure.

[0234] Additionally, one of ordinary skill in the art will readily recognize that the terms "on", "under" and "over" are sometimes used in easy description of the figures and indicate relative positions on a properly oriented page relative to the orientation of the figure and can not reflect the proper orientation of any device as implemented.

[0235] Some features described in the specification in the context of separate implementations can also be implemented in combinations with each other. Conversely, various features described in the context of a single implementation can also be implemented on their own or in any suitable subcombination. Moreover, although features can be described above as acting in certain combinations and initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination and the claimed combination can be directed to a subcombination or variation of a subcombination.

[0236] Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring such an order, unless otherwise claimed in the claims. One of ordinary skill in the art would recognize that other operations can be performed, or the described operations can be performed at different times, or in a different order. Additionally, portions of the example processes can be performed at the same time, or in different orders, depending on the implementation. Furthermore, various system components can be divided into different system components depending on the implementation. Additionally, the division of functionality between different system components is for purposes of example only and is not required. For example, one or more additional operations can be performed before, after, simultaneously, or between any of the illustrated operations. In some circumstances, multitasking and parallel processing can be advantageous. Additionally, the separation of various system components in the implementations described above should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems can generally be integrated in a single software product or packaged into multiple software products. Additionally, some other implementations are within the scope of the following claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve desirable results.

[0237] As used herein, including the claims, the term “or” as used in the include at least one of the items listed. For example, a composition including components A, B, or C can include separate A; separate B; separate C; A and B together; A and C together; B and C together; or A, B, and C together. Also, as used herein, including the claims, “comprises,” “comprising,” “includes,” “including,” “has,” “having,” “contains,” “containing,” or variations thereof do not indicate a quantity or limit; e.g., an element to which these terms refer can be present one or more times. For example, a composition, a mixture, or a process can comprise a component, a mixture, or a step, respectively, one or more instances, and the like. Terms such as “first” and “second” are used to identify elements with similar or common characteristics, and are not used to identify a temporal sequence or a relative importance of the elements. The term “substantially” is defined as largely but not necessarily wholly what is specified (and includes what is specified; e.g., substantially 90 degrees includes 90 degrees and substantially parallel includes parallel), as understood by one of ordinary skill in the art. In any disclosed implementation, the term “substantially” can be replaced with “[percentage]” of what is specified, where the percentage includes 0.1%, 1%, 5%, or 10%. Unless the disclosure explicitly requires otherwise, the term “one” is defined as one or more of whatever is specified.

[0238] The foregoing description of the present disclosure has been provided in order to enable any person skilled in the art to make or use the present disclosure. Various modifications to the present disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein can be applied to other variations without departing from the spirit or scope of the present disclosure. Thus, the present disclosure is not intended to be limited to the examples described herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for communication performed by a network entity, the method comprising: Receive road congestion information associated with one or more regions; Receive driving information associated with one or more vehicles; as well as Send an indicator for a sensor-sharing configuration for the one or more vehicles, the sensor-sharing configuration being based on the road congestion information and the driving information.

2. The method of claim 1, wherein the driving information indicates, for a first vehicle among the one or more vehicles, the location of the first vehicle, the speed of the first vehicle, the heading of the first vehicle, the direction of travel of the first vehicle, or a combination thereof.

3. The method of claim 1, wherein the driving information includes one or more Basic Safety Messages (BSM), one or more Cooperative Sensing Messages (CAM), one or more Collective Sensing Messages (CPM), one or more Sensor Data Sharing Messages (SDSM), or combinations thereof.

4. The method of claim 1, wherein the indicator of the sensor sharing configuration indicates one or more sensor sharing mitigation techniques to be performed at the one or more vehicles.

5. The method according to claim 4, wherein the one or more sensor sharing mitigation techniques include frequency-based mitigation techniques, distance-based mitigation techniques, dynamic-based mitigation techniques, confidence-based mitigation techniques, entropy-based mitigation techniques, object self-declaration-based mitigation techniques, or combinations thereof.

6. The method of claim 4, wherein the indicator of the sensor sharing configuration further indicates one or more parameters associated with the one or more sensor sharing mitigation techniques.

7. The method of claim 6, wherein the one or more parameters include a time window, a detection instance, a threshold distance, a threshold velocity, or a combination thereof.

8. The method according to claim 1, further comprising: Based on the driving information, a destination area is identified in one or more of the areas, and the one or more vehicles are expected to be located in the destination area at a future time; Based on the road congestion information, a road congestion metric associated with the destination area is determined; as well as The indicator for the sensor-shared configuration is generated based on a comparison between the road congestion metric and a threshold.

9. The method of claim 8, wherein generating the indicator for the sensor-shared configuration comprises: The sensor sharing configuration is determined based on whether the road congestion metric meets the threshold to increase sensor sharing mitigation at the one or more vehicles.

10. The method of claim 8, wherein generating the indicator for the sensor-shared configuration comprises: The sensor sharing configuration is determined based on whether the road congestion metric meets the threshold to reduce sensor sharing mitigation at the one or more vehicles.

11. The method according to claim 8, further comprising: Receive map data associated with the one or more vehicles, and The destination area is further identified based on the map data.

12. The method according to claim 8, further comprising: Receive tracking data associated with the one or more vehicles, and The destination area is further identified based on the tracking data.

13. The method of claim 8, wherein the destination area is further determined based on road topology information associated with the roads on which the one or more vehicles are traveling.

14. The method of claim 8, wherein the destination area is further determined based on historical driving data associated with the one or more vehicles.

15. A network entity configured for communication, the network entity comprising: Memory, the memory storing processor-readable code; and At least one processor, coupled to the memory, is configured to execute processor-readable code to enable the at least one processor to: Receive road congestion information associated with one or more regions; Receive driving information associated with one or more vehicles; as well as Send an indicator for a sensor-sharing configuration for the one or more vehicles, the sensor-sharing configuration being based on the road congestion information and the driving information.

16. The network entity of claim 15, wherein, in order to send the indicator of the sensor sharing configuration, the at least one processor is configured to: The transmission of the indicator is initiated via one or more downlink communications.

17. The network entity of claim 16, wherein the one or more vehicles comprise a single vehicle, and wherein the indicator of the sensor-shared configuration is included in a Radio Resource Control (RRC) message.

18. The network entity of claim 16, wherein the one or more vehicles comprise a plurality of vehicles, and wherein the indicator of the sensor-shared configuration is included in a System Information Block (SIB) message.

19. The network entity of claim 15, wherein the one or more vehicles comprise a single vehicle, and wherein the indicator is sent to another network entity to cause the other network entity to send the sensor sharing configuration to the single vehicle via sidelink communication.

20. The network entity of claim 19, wherein the indicator of the sensor sharing configuration is included in a sidelink radio resource control (RRC) message or a sidelink signaling message.

21. The network entity of claim 15, wherein the indicator is sent to one or more other network entities to cause the one or more other network entities to broadcast the sensor sharing configuration via one or more sidelink communications.

22. The network entity of claim 15, wherein, in order to send the indicator of the sensor sharing configuration, the at least one processor is configured to: This enables one or more other network entities to send the sensor-sharing configuration to vehicles located within a specific range of the one or more other network entities via one or more sidelink communications.

23. An apparatus for communication, the apparatus comprising: Components used to receive road congestion information associated with one or more areas; A component used to receive driving information associated with one or more vehicles; and A component for sending an indicator for a sensor-sharing configuration for the one or more vehicles, the sensor-sharing configuration being based on the road congestion information and the driving information.

24. The apparatus of claim 23, wherein the road congestion information comprises one or more Basic Safety Messages (BSMs), one or more Cooperative Sensing Messages (CAMs), or combinations thereof, from one or more roadside units (RSUs) located in the one or more areas.

25. The apparatus of claim 23, wherein the road congestion information comprises one or more channel busy rate (CBR) measurements reported by vehicles, roadside units (RSUs), or a combination thereof located within the one or more areas.

26. The apparatus of claim 23, wherein the road congestion information includes one or more channel busy rate (CBR) measurements reported by one or more base stations serving the one or more areas.

27. The apparatus of claim 23, wherein the road congestion information includes traffic camera data associated with the one or more areas, lane metering data associated with the one or more areas, time-based congestion data associated with the one or more areas, or a combination thereof.

28. A non-transitory computer-readable medium storing instructions, which, when executed by a processor, cause the processor to perform operations including: Receive road congestion information associated with one or more regions; Receive driving information associated with one or more vehicles; and Send an indicator for a sensor-sharing configuration for the one or more vehicles, the sensor-sharing configuration being based on the road congestion information and the driving information.

29. The non-transitory computer-readable medium of claim 28, wherein the operation further comprises: Receive second driving information associated with one or more other vehicles; as well as Send a second indicator for a second sensor-sharing configuration for the one or more other vehicles, the second sensor-sharing configuration being based on the road congestion information and the second driving information.

30. The non-transitory computer-readable medium of claim 29, wherein the sensor sharing configuration is associated with a first destination region in the one or more regions, the sensor sharing configuration being different from a second sensor sharing configuration associated with a second destination region in the one or more regions, the second destination region being different from the first destination region.

Images