Region configuration indication for connected vehicle multicast communications

Abstract

Systems and techniques are described for providing enhanced regional configuration for V2X multicast communications. For example, a computing device can determine a region indication type for a multicast message of a UE. The region indication type is included in a plurality of configured region indication types. The computing device can determine a region identification (ID) for a current location of the UE. The current location of the UE is within a geographic region corresponding to a region ID, and the region ID is selected from a plurality of region IDs of a region indication type. A computing device can determine range information for a multicast message. The range information indicates a reception area within the geographic region corresponding to the region ID. A computing device can send sidelink information indicating a region ID and range information. A computing device can send a multicast message.

Description

Technical Field

[0001] This disclosure relates in general to vehicle communications. For example, aspects of this disclosure relate to enhanced regional configurations for vehicle-to-everything (V2X) multicast communications. Background Technology

[0002] Wireless communication systems are widely deployed to provide a variety of telecommunications services, such as telephone, video, data, messaging, and broadcasting. Typical wireless communication systems may employ multiple access technologies capable of supporting communication with multiple users by sharing available system resources. Examples of such multiple access technologies include Code Division Multiple Access (CDMA) systems, Time Division Multiple Access (TDMA) systems, Frequency Division Multiple Access (FDMA) systems, Orthogonal Frequency Division Multiple Access (OFDMA) systems, Single Carrier Frequency Division Multiple Access (SC-FDMA) systems, and Time Division Synchronous Code Division Multiple Access (TD-SCDMA) systems.

[0003] These multiple access technologies have been adopted in various telecommunications standards to provide a common protocol that enables different wireless devices to communicate at the city, national, regional, and even global levels. An example telecommunications standard is 5G New Radio (NR). 5G NR is part of the Continuous Evolution of Mobile Broadband (CWB) program issued by the 3rd Generation Partnership Project (3GPP) to meet new requirements associated with latency, reliability, security, scalability (e.g., with the Internet of Things (IoT)), and other requirements. 5G NR includes services associated with enhanced mobile broadband (eMBB), massive machine-type communications (mMTC), and ultra-reliable low-latency communications (URLLC). Some aspects of 5G NR can be based on the 4G Long Term Evolution (LTE) standard. Various aspects of wireless communication can include direct communication between devices, such as in vehicle-to-vehicle (V2X), vehicle-to-vehicle (V2V), and / or device-to-device (D2D) communications. There is a need for further improvements to V2X, V2V, and / or D2D technologies. Furthermore, these improvements can also be applied to other multiple access technologies and telecommunications standards that adopt them. Summary of the Invention

[0004] The following is a simplified summary of the invention relating to one or more aspects disclosed herein. Therefore, this summary should not be considered an exhaustive overview relating to all conceived aspects, nor should it be considered to identify key or decisive elements relating to all conceived aspects or to depict the scope associated with any particular aspect. Thus, the sole purpose of this summary is to present, in a simplified form, certain concepts relating to one or more aspects involving the mechanisms disclosed herein, prior to the detailed description presented below.

[0005] Vehicle-to-everything (V2X) communication is a vehicle communication system that enables the wireless transmission of information from a vehicle to other entities within the transportation system that may affect that vehicle (e.g., other vehicles, pedestrians with smartphones, vulnerable road users (VRUs) equipped with devices such as cyclists, roadside units (RSUs), and / or other transportation infrastructure). V2X technology can be used to improve road safety, fuel savings, and traffic efficiency. V2X wireless communication can include distance-based multicast messages between V2X UEs (e.g., also referred to as V2X-enabled UEs, V2X-capable UEs, and / or connected vehicles, etc.). For example, V2X distance-based multicast messages can be used to broadcast information for context-aware purposes, where nearby vehicles are relevant or intended receivers. In some examples, V2X distance-based multicast can be used to broadcast information from a sending UE (e.g., Tx UE) to a subset of nearby vehicle UEs or other entities (e.g., Rx UE), for example, to share information about traffic conditions, road hazards, and various other events that are only considered relevant to entities within the immediate vicinity of the Tx UE.

[0006] In some cases, distance-based multicast messages can be used to broadcast data from a Tx UE to a group of one or more Rx UEs within a configured distance of the Tx UE's current location. The Tx UE's current location can be mapped to a specific region identifier (ID) corresponding to a unique geographic area (e.g., region) surrounding the Tx UE's current location. The mapping between region IDs and corresponding geographic areas can be based on region configuration information provided by the network entity associated with the UE. In some examples, multiple region IDs can be implemented based on mapping a geodesic surface area (e.g., a portion of the Earth's surface) to multiple regions of approximately 5 square meters.

[0007] The distance configured for V2X distance-based multicast messages can be based on a range requirement value corresponding to the radius of a circle centered on the current location of the Tx UE (e.g., the current region ID). Rx UEs that are V2X enabled or have V2X capabilities and are located within the specified minimum radius of the circle are required to correctly decode packets of distance-based multicast messages. For example, an Rx UE may calculate the distance between the current Rx UE region ID and the current Tx UE region ID, and may be required to decode V2X distance-based multicast messages if the calculated distance is less than or equal to the configured range requirement value indicated for the V2X distance-based multicast message.

[0008] Two-dimensional (2D) region indication may not provide sufficient granularity to optimize distance-based multicast transmissions that only reach a specific subset of intended receivers (e.g., candidate Rx UEs for specific V2X distance-based multicast messages). For example, existing techniques based on 2D region indication information cannot be used to specify the intended reception area using geometry other than a circle with a radius given by a minimum range requirement value. Additionally, 2D region indication information does not indicate the directionality of interest of the intended candidate receivers (e.g., as in an example where a Tx vehicle UE is interested in data that other vehicles (Rx UEs) moving only in the same direction are also interested in). 2D region indication information also does not indicate the height information of the intended candidate receivers and cannot distinguish candidate Rx UEs on different vertical levels, such as parking garages or highways.

[0009] This document describes systems and techniques for improving and enhancing region ID configurations that can be used to extend V2X distance-based multicast. In some aspects, these systems and techniques can be used, for example, to configure the UE using a three-dimensional (3D) region indication type and a 3D region indication mode to implement 3D region indication for a Tx UE and / or one or more intended Rx UEs for V2X multicast messages. In some aspects, these systems and techniques can be used, for example, to implement directional region indication based on a UE configured using a directional region indication type and a directional region indication mode. In some examples, the intended receiver (e.g., Rx UE) for a V2X multicast message can be determined based on the enhanced region indication information of the Tx UE, wherein the Tx UE enhanced region indication information includes a 2D or 3D enhanced region corresponding to the Tx UE, and additionally includes range information of one or more of the following: a non-circular area indicating the intended Rx UE, height information of the intended Rx UE, and / or direction information of the intended Rx UE. In some respects, these systems and technologies can be additionally used to implement receive region determination and indication, wherein the region of the intended Rx UE for V2X multicast messages is the intersection of the sending region indication (e.g., Tx UE region ID) and the receiving region indication.

[0010] According to at least one exemplary example, an apparatus for a user equipment (UE) for wireless communication is provided. The apparatus includes: at least one memory; and at least one processor coupled to the at least one memory, wherein the at least one processor is configured to: determine a region indication type of a multicast message of the UE, wherein the region indication type is included among a plurality of configured region indication types; determine a region identifier (ID) of the UE's current location, wherein the current location of the UE is within a geographic region corresponding to the region ID, and wherein the region ID is selected from a plurality of region IDs of the region indication type; determine range information of the multicast message, wherein the range information indicates a reception area within the geographic region corresponding to the region ID; transmit sidelink information indicating the region ID and the range information; and transmit the multicast message.

[0011] In another exemplary example, a method for performing wireless communication at a UE is provided. The method includes: determining a region indication type for a multicast message of the UE, wherein the region indication type is included among a plurality of configured region indication types; determining a region identifier (ID) for the current location of the UE, wherein the current location of the UE is within a geographic region corresponding to the region ID, and wherein the region ID is selected from a plurality of region IDs of the region indication type; determining range information for the multicast message, wherein the range information indicates a reception area within the geographic region corresponding to the region ID; transmitting sidelink information indicating the region ID and the range information; and transmitting the multicast message.

[0012] In another exemplary example, a non-transitory computer-readable storage medium is provided, the non-transitory computer-readable storage medium including instructions stored thereon, which, when executed by at least one processor, cause the at least one processor to: determine a region indication type of a multicast message of the UE, wherein the region indication type is included among a plurality of configured region indication types; determine a region identifier (ID) of the UE's current location, wherein the current location of the UE is within a geographic region corresponding to the region ID, and wherein the region ID is selected from a plurality of region IDs of the region indication type; determine range information of the multicast message, wherein the range information indicates a receiving area within the geographic region corresponding to the region ID; send sidelink information indicating the region ID and the range information; and send the multicast message.

[0013] In another exemplary example, an apparatus for wireless communication is provided, the apparatus comprising: means for determining a region indication type of a multicast message for a UE, wherein the region indication type is included among a plurality of configured region indication types; means for determining a region identifier (ID) of the current location of the UE, wherein the current location of the UE is within a geographic region corresponding to the region ID, and wherein the region ID is selected from a plurality of region IDs of the region indication type; means for determining range information of the multicast message, wherein the range information indicates a receiving area within the geographic region corresponding to the region ID; means for transmitting sidelink information indicating the region ID and the range information; and means for transmitting the multicast message.

[0014] In another exemplary example, an apparatus for a user equipment (UE) for wireless communication is provided. The apparatus includes: at least one memory; and at least one processor coupled to the at least one memory, wherein the at least one processor is configured to: receive sidelink information indicating range information and a region identifier (ID) corresponding to the current location of a second UE, wherein the current location of the second UE is within a geographic region corresponding to the region ID, and wherein the region ID is included in a plurality of region IDs of a specific region indication type; determine a reception area including a portion of the geographic region corresponding to the region ID, wherein the reception area is determined based on direction information or angle information included in the range information; and decode a multicast message received corresponding to the sidelink information, wherein the multicast message is decoded based on the current location of the first UE within the reception area.

[0015] In another exemplary example, a method for wireless communication performed at a UE is provided. The method includes: receiving sidelink information indicating range information and a region identifier (ID) corresponding to the current location of a second UE, wherein the current location of the second UE is within a geographic region corresponding to the region ID, and wherein the region ID is included in a plurality of region IDs of a specific region indication type; determining a reception area including a portion of the geographic region corresponding to the region ID, wherein the reception area is determined based on direction information or angle information included in the range information; and decoding a multicast message received corresponding to the sidelink information, wherein the multicast message is decoded based on the current location of the first UE within the reception area.

[0016] In another exemplary example, a non-transitory computer-readable storage medium is provided, comprising instructions stored thereon that, when executed by at least one processor, cause the at least one processor to: receive sidelink information indicating range information and a region identifier (ID) corresponding to the current location of a second UE, wherein the current location of the second UE is within a geographic region corresponding to the region ID, and wherein the region ID is included in a plurality of region IDs of a particular region indication type; determine a reception area including a portion of the geographic region corresponding to the region ID, wherein the reception area is determined based on direction information or angle information included in the range information; and decode a multicast message received corresponding to the sidelink information, wherein the multicast message is decoded based on the current location of the first UE within the reception area.

[0017] In another exemplary example, an apparatus for wireless communication is provided, the apparatus comprising: means for receiving sidelink information indicating range information and a region identifier (ID) corresponding to the current location of a second UE, wherein the current location of the second UE is within a geographic region corresponding to the region ID, and wherein the region ID is included in a plurality of region IDs of a specific region indication type; determining a reception area including a portion of the geographic region corresponding to the region ID, wherein the reception area is determined based on direction information or angle information included in the range information; and means for decoding a multicast message received corresponding to the sidelink information, wherein the multicast message is decoded based on the current location of the first UE within the reception area.

[0018] In some aspects, the described apparatus or network device is a vehicle (e.g., a car, truck, etc., or a component or system of a car, truck, etc.), a roadside unit (RSU) or other network-enabled infrastructure equipment (e.g., a network-enabled traffic light, etc.), a mobile device (e.g., a mobile phone or so-called "smartphone" or other mobile device), a network-connected wearable device (e.g., a so-called "smartwatch"), an extended reality device (e.g., a virtual reality (VR) device, an augmented reality (AR) device, or a mixed reality (MR) device), a personal computer, a laptop computer, a server computer, a robotic device, or other equipment, including or part of such devices. In some aspects, the apparatus includes radio detection and ranging (radar) for capturing radio frequency (RF) signals. In some aspects, the apparatus includes one or more light detection and ranging (LIDAR) sensors, radar sensors, or other light-based sensors for capturing light-based (e.g., light frequency) signals. In some aspects, the apparatus includes one or more cameras for capturing one or more images. In some aspects, the apparatus also includes a display for displaying one or more images, notifications, and / or other displayable data. In some respects, the apparatus described above may include one or more sensors that can be used to determine the location of the apparatus, the state of the apparatus (e.g., temperature, humidity level, and / or other states), and / or for other purposes.

[0019] This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to determine the scope of the claimed subject matter alone. This subject matter should be understood in conjunction with the appropriate portions of the entire specification of this patent, any or all of the accompanying drawings, and each claim.

[0020] Based on the accompanying drawings and detailed description, other objects and advantages associated with the aspects disclosed herein will be apparent to those skilled in the art. Attached Figure Description

[0021] The exemplary aspects of this application are described in detail below with reference to the following figures: Figure 1 This is a diagram illustrating an example wireless communication system based on some examples; Figure 2A and Figure 2B Examples of wireless network architectures based on some examples are shown; Figure 2C This is a diagram illustrating an example of a decomposed base station architecture based on some examples; Figure 3This is a diagram illustrating examples of various user equipment (UEs) communicating through direct communication interfaces (e.g., cellular-based PC5 sidelink interfaces, DSRC interfaces defined by 802.11p, or other direct interfaces) and wide area network (Uu) interfaces, according to some examples. Figure 4 This is a block diagram illustrating an example of a computing system based on some examples of vehicles; Figure 5 This is a block diagram illustrating an example of a computing system based on some example user devices; Figure 6 This is a diagram illustrating an example wireless communication system for implementing UE-side link synchronization, based on some examples; Figures 7A to 7B Example configurations for implementing UE queues for sidelink synchronization are illustrated based on some examples; Figure 8 This is a diagram illustrating examples of devices involved in wireless communication (e.g., sidelink communication) based on some examples; Figures 9A to 9D This is a diagram illustrating examples of sensor sharing for collaborative and autonomous driving systems, based on some examples; Figure 10 This is a diagram illustrating examples of sensor sharing for collaborative and autonomous driving systems, based on some examples; Figure 11 This is an illustration of an example of a system for sensor sharing in wireless communication (e.g., V2X communication); Figure 12A This is a diagram illustrating an example of multicast message transmission and reception based on two-dimensional (2D) distance in some example wireless communications (e.g., V2X communications); Figure 12B This is a diagram illustrating examples of multiple regions that can be associated with distance-based multicast message transmission and reception in wireless communication (e.g., V2X communication) according to some examples; Figure 13A This is a diagram illustrating examples of distance-based multicast message sending and receiving for V2X sidelink communication, based on some examples. Figure 13B This is a diagram illustrating an example of vertically based multicast message transmission and reception for V2X sidelink communication, based on some examples. Figure 14 This is a diagram illustrating examples of sending and receiving regions for enhanced multicast used in V2X sidelink communication, based on some examples. Figure 15 This is a flowchart illustrating an example of a process for wireless communication at a first UE, based on some examples; Figure 16 This is a flowchart illustrating an example of a process for wireless communication at a second UE, based on some examples; Figure 17 It is a signaling diagram corresponding to some examples of the wireless communication process between the first UE and the second UE; and Figure 18 An example computing system based on some examples is shown. Detailed Implementation

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

[0023] The following description provides only exemplary aspects and is not intended to limit the scope, applicability, or configuration of this disclosure. Rather, the following description of the exemplary aspects will provide those skilled in the art with a description that can be used to implement the exemplary aspects. It should be understood that various changes may be made to the function and arrangement of the elements without departing from the spirit and scope of this application as set forth in the appended claims.

[0024] The terms “exemplary” and / or “example” are used herein to mean “serving as an example, instance, or illustration.” Any aspect described herein as “exemplary” and / or “example” is not necessarily to be construed as superior to or better than other aspects. Similarly, the term “aspects of this disclosure” does not require that all aspects of this disclosure include the features, advantages, or modes of operation discussed.

[0025] Wireless communication systems are deployed to provide a variety of telecommunications services, including telephone, video, data, messaging, and broadcasting. Wireless communication systems have undergone several generations of development. The fifth-generation (5G) mobile standard demands higher data transmission speeds, a greater number of connections, better coverage, and other improvements. According to the Next Generation Mobile Networks Alliance, the 5G standard (also known as "New Radio" or "NR") is designed to provide tens of megabits per second of data rate to each of tens of thousands of users.

[0026] A sidelink can refer to any communication link between client devices (e.g., UE, STA, etc.). For example, a sidelink can support device-to-device (D2D) communication, vehicle-to-everything (V2X) communication and / or vehicle-to-vehicle (V2V) communication, message relay, discovery signaling, beacon signaling, or any combination thereof, or other signals transmitted over the air from one UE to one or more other UEs. In some examples, licensed or unlicensed spectrum (e.g., 5 GHz or 6 GHz) can be used to transmit sidelink communication. As used herein, the term "sidelink" can refer to a 3GPP sidelink (e.g., using a PC5 sidelink interface), Wi-Fi direct communication (e.g., according to the Dedicated Short Range Communication (DSRC) protocol), or any other direct device-to-device communication protocol.

[0027] Vehicles are examples of systems that may include wireless communication capabilities. For example, vehicles (e.g., motorized vehicles, autonomous vehicles, aircraft, ships, etc.) can communicate with other vehicles and / or other devices with wireless communication capabilities. Wireless vehicle communication systems include vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), infrastructure-to-vehicle (I2V), vehicle-to-network (V2N), and vehicle-to-pedestrian (V2P) communications, collectively referred to as vehicle-to-everything (V2X) communications. V2X communications are vehicle communication systems that support the wireless transmission of information from a vehicle to other entities within the transportation system that may affect that vehicle (e.g., other vehicles, pedestrians with smartphones, vulnerable road users (VRUs) equipped with smartphones, such as cyclists, roadside units (RSUs), and / or other transportation infrastructure). The primary purpose of V2X technology is to improve road safety, fuel economy, and traffic efficiency.

[0028] In V2X communication systems, information is transmitted via wireless links from vehicle sensors (and other sources) to allow that information to be communicated to other vehicles, pedestrians, VRUs, and / or traffic infrastructure. This information can be transmitted using one or more vehicle-based messages, such as cellular vehicle-to-everything (C-V2X) messages, which may include Sensor Data Sharing Messages (SDSM), Basic Safety Messages (BSM), Cooperative Perception Messages (CAM), Collective Perception Messages (CPM), Distributed Environment Messages (DENM), VRU Perception Messages (VAM), and / or other types of vehicle-based messages. By sharing this information with other vehicles, V2X technology improves a vehicle's (and driver's) perception of potential hazards, thereby helping to reduce collisions with other vehicles and entities. Additionally, V2X technology improves traffic efficiency by providing vehicles with traffic warnings about impending potential road hazards and obstacles, allowing vehicles to choose alternative routes.

[0029] As previously mentioned, V2X technology includes V2V, V2I, and I2V communications, which can also be referred to as peer-to-peer communications. V2V, V2I, and I2V communications allow vehicles to communicate wirelessly directly with each other while on the road and with V2X-enabled infrastructure (e.g., V2X-enabled RSUs, V2X-enabled traffic lights, etc.). Using V2V, V2I, and I2V communications, vehicles can gain situational awareness by receiving information about impending road hazards (e.g., unforeseen oncoming traffic, accidents, and road conditions) from other vehicles and / or from V2X-enabled infrastructure.

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

[0031] The connected vehicle can refer to various vehicle UEs, including vehicle UEs configured for V2X communication (e.g., also referred to as "V2X UE"). As noted above, a vehicle UE can be used to perform one or more of the following: vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), infrastructure-to-vehicle (I2V), vehicle-to-network (V2N), and vehicle-to-pedestrian (V2P) communication, which are collectively referred to as vehicle-to-everything (V2X) communication.

[0032] In some cases, the connected vehicle may include an On-Board Unit (OBU) or otherwise be associated with an OBU. The OBU can be used to perform and / or manage communication between the V2X UE (e.g., the connected vehicle) and the mobile network, infrastructure network, surrounding environment, etc. In some examples, the OBU of the first V2X UE can be used to communicate using sidelink communication with corresponding OBUs of various other (e.g., additional) V2X UEs, roadside units (RSUs), and / or vulnerable road users (VRUs, e.g., scooters, pedestrian smartphones, etc.). In some cases, sidelink communication can be used to enable direct communication between V2X or V2V connected vehicles, or directional communication between V2X or V2P connected vehicles and pedestrian UEs, etc.

[0033] In some examples, V2X wireless communication may include distance-based multicast messages between V2X UEs (e.g., also referred to as V2X-enabled UEs, V2X-capable UEs, and / or connected vehicles, etc.). For example, V2X distance-based multicast messages may be used to broadcast information for context-aware purposes where a nearby vehicle is a relevant or intended receiver. In some examples, V2X distance-based multicast may be used to broadcast information from a sending UE (e.g., a Tx UE) to a subset of nearby vehicle UEs or other entities (e.g., Rx UEs), for example, to share information about traffic conditions, road hazards, and various other events that are only considered relevant to entities within the immediate vicinity of the Tx UE.

[0034] In some cases, distance-based multicast messages can be used to broadcast data from a Tx UE to a group of one or more Rx UEs within a configured distance of the Tx UE's current location. The Tx UE's current location can be mapped to a specific region identifier (ID) corresponding to a unique geographic area (e.g., region) surrounding the Tx UE's current location. The mapping between region IDs and corresponding geographic areas can be based on region configuration information provided by the network entity associated with the UE. In some examples, multiple region IDs can be implemented based on mapping a geodesic surface area (e.g., a portion of the Earth's surface) to multiple regions of approximately 5 square meters.

[0035] The distance configured for V2X distance-based multicast messages can be based on a range requirement value corresponding to the radius of a circle centered on the current location of the Tx UE (e.g., the current region ID). Rx UEs that are V2X enabled or have V2X capabilities and are located within the specified minimum radius of the circle are required to correctly decode packets of distance-based multicast messages. For example, an Rx UE may calculate the distance between the current Rx UE region ID and the current Tx UE region ID, and may be required to decode V2X distance-based multicast messages if the calculated distance is less than or equal to the configured range requirement value indicated for the V2X distance-based multicast message.

[0036] Two-dimensional (2D) region indication may not provide sufficient granularity to optimize distance-based multicast transmissions that only reach a specific subset of intended receivers (e.g., candidate Rx UEs for specific V2X distance-based multicast messages). For example, existing techniques based on 2D region indication information cannot be used to specify the intended reception area using geometry other than a circle with a radius given by a minimum range requirement value. Additionally, 2D region indication information does not indicate the directionality of interest of the intended candidate receivers (e.g., as in an example where a Tx vehicle UE is interested in data that other vehicles (Rx UEs) moving only in the same direction are also interested in). 2D region indication information also does not indicate the height information of the intended candidate receivers and cannot distinguish candidate Rx UEs on different vertical levels, such as parking garages or highways.

[0037] This document describes systems, apparatus, processes (also referred to as methods), and computer-readable media (collectively, “Systems and Technologies”) for improving and enhancing region identification (ID) information that can be used to extend V2X distance-based multicast messages to indicate intended or candidate receivers using additional information beyond two-dimensional (2D) range or distance. For example, these systems and Technologies can be used to provide V2X multicast messages based on three-dimensional (3D) region configuration information indicating candidate receivers for the corresponding multicast messages.

[0038] In an exemplary example, these systems and technologies can be used to provide 3D region configuration information for V2X multicast messages, including distance-based V2X multicast messages. The 3D region configuration information can indicate a receiving region corresponding to a candidate receiver for the corresponding multicast message. The receiving region can be a two-dimensional (2D) area or a 3D area. The 3D region configuration information can additionally indicate one or more of direction information and / or height information that can be used by the candidate receiver UE to determine the receiving region for the corresponding multicast message.

[0039] In some aspects, these systems and technologies can be used to implement 3D region indication for Tx UEs and / or one or more intended Rx UEs for V2X multicast messages. For example, these systems and technologies can be used to configure UEs (e.g., at least Tx UEs and Rx UEs) based on information indicating 3D region indication type and 3D region indication mode to implement 3D region indication for V2X multicast messages. In some aspects, these systems and technologies can be used to implement directional region indication, for example, based on configuring UEs using directional region indication type and directional region indication mode. In some aspects, these systems and technologies can be used to indicate altitude-based region indication, for example, based on configuring UEs using altitude-based region indication type and altitude-based region indication mode. In some examples, these systems and technologies can be used to indicate lane-based and / or road-based region indication for V2X UEs and / or UEs with V2X capabilities, for example, based on configuring UEs using lane-based or road-based region indication type and region indication mode (respectively).

[0040] In some examples, the intended receiver (e.g., Rx UE) for V2X multicast messages can be determined based on the enhanced region indication information of the Tx UE. This enhanced region indication information includes a 2D or 3D enhanced region corresponding to the Tx UE, and additionally includes range information indicating a subset (e.g., a sub-region) of the Tx UE's enhanced region. For example, the range information may indicate a non-circular area of ​​the intended Rx UE within the Tx UE's region. In another example, the range information may indicate one or more included height value ranges and / or one or more excluded height value ranges of the intended Rx UE.

[0041] In some aspects, the range of included or excluded height values ​​for the intended Rx UE can be combined with the intended Rx UE's 2D region information to implement a 3D region indication configuration for the reception area of ​​the intended Rx UE associated with the corresponding V2X multicast message. The 2D region information can correspond to a circular region or a non-circular region (e.g., a region with a non-circular geometry). In some examples, the range information can indicate the orientation information of the intended Rx UE, wherein the orientation information is indicated relative to the Tx UE associated with the V2X multicast message.

[0042] For example, direction information can identify an Rx UE that is in front of a Tx UE, moving in the same direction as the Tx UE, etc., as an intended recipient of a V2X multicast message sent by the Tx UE. Direction information can be used to identify Rx UEs included in the intended recipients of a V2X multicast message, can be used to identify Rx UEs excluded from the intended recipients of a V2X multicast message, or a combination of both.

[0043] In some respects, these systems and technologies can be additionally used to implement receive region determination and indication, wherein the region of the intended Rx UE for V2X multicast messages is the intersection of the sending region indication (e.g., Tx UE region ID) and the receiving region indication.

[0044] Additional aspects of this disclosure are described below with reference to the figures.

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

[0046] In some cases, network entities may be implemented in aggregated or monolithic base station or server architectures, or alternatively, in decomposed base station or server architectures, and may include one or more of a central unit (CU), distributed unit (DU), radio unit (RU), near real-time (near RT) RAN intelligent controller (RIC), or non-real-time (non-RT) RIC. In some cases, network entities may include server equipment, such as multi-access edge computing (MEC) equipment. A base station or server (e.g., having an aggregated / monolithic or decomposed base station architecture) may operate according to one of several RATs based on the network in which the base station or server is deployed to communicate with the UE, roadside unit (RSU), and / or other equipment, and may alternatively be referred to as an access point (AP), network node, node B (NB), evolved node B (eNB), next-generation eNB (ng-eNB), new radio (NR) node B (also referred to as gNB or gNodeB), etc. Base stations are primarily used to support the radio access of the UE, including supporting data, voice, and / or signaling connections for the supported UE. In some systems, the base station can provide edge node signaling functions, while in others, it can provide additional control and / or network management functions. The communication links through which the UE can transmit signals to the base station are called uplink (UL) channels (e.g., reverse traffic channel, reverse control channel, access channel, etc.). The communication links through which the base station can transmit signals to the UE are called downlink (DL) or forward link channels (e.g., paging channel, control channel, broadcast channel, or forward traffic channel, etc.). As used herein, the term traffic channel (TCH) can refer to uplink, reverse or downlink, and / or forward traffic channel.

[0047] The terms "network entity" or "base station" (e.g., having a converged / monolithic base station architecture or a disaggregated base station architecture) can refer to a single physical TRP or multiple physical TRPs that may or may not be co-located. For example, when the term "network entity" or "base station" refers to a single physical TRP, the physical TRP may be a base station antenna corresponding to a cell (or several cell sectors) of the base station. When the term "network entity" or "base station" refers to multiple co-located physical TRPs, these physical TRPs may be antenna arrays of the base station (e.g., as in a multiple-input multiple-output (MIMO) system or where the base station employs beamforming). When the term "base station" refers to multiple non-co-located physical TRPs, the physical TRPs may be a distributed antenna system (DAS) (a network of spatially separated antennas connected via a transmission medium to a common source) or a remote radio headend (RRH) (a remote base station connected to a serving base station). Alternatively, a non-co-located physical TRP may be a serving base station from which a measurement report is received from a UE and a neighboring base station from which the UE is measuring its reference radio frequency (RF) signal (or simply "reference signal"). As used in this article, a TRP is the point by which a base station transmits and receives wireless signals, so any mention of transmitting from or receiving at a base station should be understood as referring to a specific TRP of the base station.

[0048] In some specific implementations supporting UE positioning, network entities or base stations may not support the UE's radio access (e.g., may not support data, voice, and / or signaling connections regarding the UE), but instead may transmit reference signals to the UE for measurement, and / or receive and measure signals transmitted by the UE. Such a base station may be referred to as a positioning beacon (e.g., in the case of transmitting signals to the UE) and / or as a location measurement unit (e.g., in the case of receiving and measuring signals from the UE).

[0049] Roadside units (RSUs) are communication links or interfaces (e.g., cellular-based side links or PC5 interfaces, 802.11-based or WiFi-based). ™ An RSU is a device that sends and receives messages to or from one or more UEs, other RSUs, and / or base stations via a Dedicated Short Range Communication (DSRC) interface and / or other interfaces. Examples of messages that can be sent and received by an RSU include Vehicle-to-Everything (V2X) messages, which are described in more detail below. An RSU may reside on various transportation infrastructure systems, including roads, bridges, parking lots, toll booths, and / or other infrastructure systems. In some examples, an RSU may facilitate communication between a UE (e.g., a vehicle, pedestrian user equipment, and / or other UE) and the transportation infrastructure system. In some implementations, an RSU may communicate with servers, base stations, and / or other systems capable of performing centralized management functions.

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

[0051] Radio frequency signals, or “RF signals,” comprise electromagnetic waves of a given frequency that transmit information across the space between a transmitter and a receiver. As used herein, a transmitter may send a single “RF signal” or multiple “RF signals” to a receiver. However, due to the propagation characteristics of RF signals through multipath channels, a receiver may receive multiple “RF signals” corresponding to each transmitted RF signal. The same transmitted RF signal on different paths between the transmitter and receiver may be referred to as a “multipath” RF signal. As used herein, where the context clearly indicates that the term “signal” refers to a wireless signal or RF signal, an RF signal may also be referred to as a “wireless signal” or simply “signal.”

[0052] According to various aspects, Figure 1An exemplary wireless communication system 100 is illustrated. The wireless communication system 100 (also referred to as a wireless wide area network (WWAN)) may include individual base stations 102 and individual UEs 104. In some aspects, base station 102 may also be referred to as a "network entity" or "network node". One or more of base stations 102 may be implemented in an aggregated or monolithic base station architecture. Additionally or alternatively, one or more of base stations 102 may be implemented in a decomposed base station architecture and may include one or more of a central unit (CU), a distributed unit (DU), a radio unit (RU), a near real-time (near RT) RAN intelligent controller (RIC), or a non-real-time (non-RT) RIC. Base station 102 may include macrocell base stations (high-power cellular base stations) and / or small cell base stations (low-power cellular base stations). In one aspect, a macro cell base station may include an eNB and / or an ng-eNB (where the wireless communication system 100 corresponds to a Long Term Evolution (LTE) network), or a gNB (where the wireless communication system 100 corresponds to an NR network), or a combination of both, and a small cell base station may include femtocells, picocells, microcells, etc.

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

[0054] Base station 102 can wirelessly communicate with UE 104. Each base station in base station 102 can provide communication coverage for a corresponding geographical coverage area 110. In one aspect, base station 102 in each coverage area 110 can support one or more cells. A “cell” is a logical communication entity used to communicate with a base station (e.g., on a frequency resource, referred to as a carrier frequency, component carrier, carrier, frequency band, etc.) and can be associated with an identifier (e.g., Physical Cell Identifier (PCI), Virtual Cell Identifier (VCI), Cell Global Identifier (CGI)) to distinguish cells operating via the same or different carrier frequencies. In some cases, different cells can be configured according to different protocol types that can provide access for different types of UEs (e.g., Machine Type Communication (MTC), Narrowband IoT (NB-IoT), Enhanced Mobile Broadband (eMBB), or other protocol types). Because a cell is supported by a specific base station, the term “cell” can refer to either or both of the logical communication entity and the base station supporting the logical communication entity, depending on the context. Furthermore, since the TRP is typically the physical transmission point of the cell, the terms “cell” and “TRP” can be used interchangeably. In some cases, the term "cell" can also refer to the geographic coverage area of ​​a base station (e.g., a sector), as long as the carrier frequency can be detected and used for communication within a portion of the geographic coverage area 110.

[0055] While the geographic coverage areas 110 of adjacent macro cell base stations 102 may partially overlap (e.g., in a handover area), some areas within geographic coverage areas 110 may substantially overlap with larger geographic coverage areas 110. For example, a small cell base station 102' may have a coverage area 110' that substantially overlaps with the coverage areas 110 of one or more macro cell base stations 102. A network that includes both small cell base stations and macro cell base stations can be referred to as a heterogeneous network. A heterogeneous network may also include a home eNB (HeNB) that can provide service to a restricted group referred to as a Closed Subscriber Group (CSG).

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

[0057] The wireless communication system 100 may further include a WLAN AP 150 communicating with a WLAN station (STA) 152 via a communication link 154 in unlicensed spectrum (e.g., 5 GHz). When communicating in unlicensed spectrum, the WLAN STA 152 and / or WLAN AP 150 may perform a Free Channel Assessment (CCA) or Listen-After-Talk (LBT) process before communication to determine if the channel is available. In some examples, the wireless communication system 100 may include devices (e.g., UEs, etc.) that communicate with one or more UEs 104, base stations 102, APs 150, etc., using ultra-wideband (UWB) spectrum. The UWB spectrum can range from 3.1 GHz to 10.5 GHz.

[0058] Small cell base station 102' can operate in licensed and / or unlicensed spectrum. When operating in unlicensed spectrum, small cell base station 102' can employ LTE or NR technology and use the same 5 GHz unlicensed spectrum as WLAN AP 150. Small cell base station 102' employing LTE and / or 5G in unlicensed spectrum can enhance coverage of the access network and / or increase the capacity of the access network. NR in unlicensed spectrum can be referred to as NR-U. LTE in unlicensed spectrum can be referred to as LTE-U, Licensed Assisted Access (LAA), or MulteFire.

[0059] The wireless communication system 100 may also include a millimeter-wave (mmW) base station 180, which can operate at mmW and / or near-mmW frequencies to communicate with the UE 182. The mmW base station 180 may be implemented in a converged or monolithic base station architecture, or alternatively, in a decomposed base station architecture (e.g., including one or more of a CU, DU, RU, near-RT RIC, or non-RT RIC). Extremely high frequency (EHF) is a portion of the electromagnetic spectrum that contains radio frequency (RF). EHF has a range of 30 GHz to 300 GHz, with wavelengths between 1 mm and 10 mm. Radio waves in this band may be referred to as millimeter waves. Near-mmW extends down to frequencies of 3 GHz with wavelengths of 100 mm. Ultra-high frequency (SHF) bands extend between 3 GHz and 30 GHz, and are also referred to as centimeter waves. Communication using mmW and / or near-mmW radio bands has high path loss and relatively short range. mmW base station 180 and UE 182 can utilize beamforming (transmit and / or receive) on mmW communication link 184 to compensate for extremely high path loss and short range. Furthermore, it should be understood that in alternative configurations, one or more base stations 102 may also use mmW or near-mmW and beamforming for transmission. Therefore, it should be understood that the foregoing illustrations are merely examples and should not be construed as limiting the various aspects disclosed herein.

[0060] Transmit beamforming is a technique used to focus RF signals in a specific direction. Traditionally, when a network node or entity (e.g., a base station) broadcasts an RF signal, it broadcasts the signal in all directions (omnidirectionally). Using transmit beamforming, a network node determines where a given target device (e.g., a UE) is located (relative to the transmitting network node) and projects a stronger downlink RF signal in that specific direction, thus providing the receiving device with a faster and stronger RF signal (in terms of data rate). To change the directivity of the RF signal during transmission, a network node can control the phase and relative amplitude of the RF signal at each of one or more transmitters broadcasting the RF signal. For example, a network node can use an array of antennas (called a "phased array" or "antenna array") that forms an RF beam that can be "manipulated" to be pointed in different directions without actually moving the antennas. Specifically, RF currents from the transmitters are fed to the individual antennas with the correct phase relationship so that radio waves from the individual antennas add together in the desired direction to increase radiation, while canceling each other out in the undesired direction to suppress radiation.

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

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

[0063] The receive beam can be spatially dependent. Spatial dependency means that parameters for the transmit beam for the second reference signal can be derived based on information about the receive beam for the first reference signal. For example, a UE can use a specific receive beam to receive one or more reference downlink reference signals (e.g., Position Reference Signal (PRS), Tracking Reference Signal (TRS), Phase Tracking Reference Signal (PTRS), Cell Specific Reference Signal (CRS), Channel State Information Reference Signal (CSI-RS), Primary Synchronization Signal (PSS), Secondary Synchronization Signal (SSS), Synchronization Signal Block (SSB), etc.) from a network node or entity (e.g., a base station). The UE can then form a transmit beam based on the parameters of the receive beam to transmit one or more uplink reference signals (e.g., Uplink Position Reference Signal (UL-PRS), Sounding Reference Signal (SRS), Demodulation Reference Signal (DMRS), PTRS, etc.) to that network node or entity (e.g., a base station).

[0064] It should be noted that, depending on the entity forming the "downlink" beam, the beam can be either a transmit beam or a receive beam. For example, if a network node or entity (e.g., a base station) is forming a downlink beam to transmit a reference signal to the UE, then the downlink beam is a transmit beam. However, if the UE is forming a downlink beam, then the downlink beam is a receive beam for receiving downlink reference signals. Similarly, depending on the entity forming the "uplink" beam, the beam can be either a transmit beam or a receive beam. For example, if a network node or entity (e.g., a base station) is forming an uplink beam, then the uplink beam is an uplink receive beam, while if the UE is forming an uplink beam, then the uplink beam is an uplink transmit beam.

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

[0066] For example, still refer to Figure 1 One of the frequencies used by macro cell base station 102 may be an anchor carrier (or "PCell"), and the other frequencies used by macro cell base station 102 and / or mmW base station 180 may be secondary carriers ("SCell"). In carrier aggregation, base station 102 and / or UE 104 may use up to [number missing] frequencies per carrier. Y A spectrum with a bandwidth of MHz (e.g., 5MHz, 10MHz, 15MHz, 20MHz, 100MHz), having up to a total of [number missing] in each direction. Yx MHz ( x(Multiple component carriers) are used for transmission. Component carriers may or may not be adjacent to each other in the spectrum. Carrier allocation may be asymmetric with respect to the downlink and uplink (e.g., more or fewer carriers may be allocated to the downlink compared to the uplink). Simultaneous transmission and / or reception on multiple carriers allows the UE 104 / 182 to significantly increase its data transmission and / or reception rates. For example, two aggregated 20MHz carriers in a multi-carrier system would theoretically result in a data rate that is twice as high (e.g., 40MHz) compared to the data rate obtained by a single 20MHz carrier.

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

[0068] The wireless communication system 100 may further include a UE 164, which can communicate with the macro cell base station 102 on the communication link 120 and / or with the mmW base station 180 on the mmW communication link 184. For example, the macro cell base station 102 may support PCells and one or more SCells for the UE 164, and the mmW base station 180 may support one or more SCells for the UE 164.

[0069] The wireless communication system 100 may also include one or more UEs, such as UE 190, which are indirectly connected to one or more communication networks via one or more device-to-device (D2D) peer-to-peer (P2P) links (referred to as "side links"). Figure 1In one example, UE 190 has a D2D P2P link 192 with one of UEs 104 connected to one of the base stations in base station 102 (e.g., UE 190 can indirectly obtain cellular connectivity through this D2D P2P link), and has a D2D P2P link 194 with a WLAN STA 152 connected to WLAN AP 150 (UE 190 can indirectly obtain WLAN-based Internet connectivity through this D2D P2P link). In one example, D2D P2P links 192 and 194 can use any known D2D RAT (such as LTE Direct (LTE-D), Wi-Fi Direct (Wi-Fi-D), Bluetooth). ® (etc.) to support.

[0070] According to various aspects, Figure 2A An example wireless network architecture 200 is illustrated. For example, a 5GC 210 (also referred to as a Next-Generation Core (NGC)) can be functionally considered as a control plane function 214 (e.g., UE registration, authentication, network access, gateway selection, etc.) and a user plane function 212 (e.g., UE gateway function, access to a data network, IP routing, etc.), which operate collaboratively to form the core network. A user plane interface (NG-U) 213 and a control plane interface (NG-C) 215 connect a gNB 222 to the 5GC 210, and specifically to the control plane function 214 and the user plane function 212. In an additional configuration, an ng-eNB 224 can also connect to the 5GC 210 via the NG-C 215 to the control plane function 214 and the NG-U 213 to the user plane function 212. Furthermore, the ng-eNB 224 can communicate directly with the gNB 222 via a backhaul connection 223. In some configurations, the new RAN 220 may have only one or more gNB 222s, while other configurations include one or more of both ng-eNB 224 and gNB 222. The gNB 222 or ng-eNB 224 can be used with UE 204 (e.g., Figure 1 (to communicate with any UE depicted in the text).

[0071] In some aspects, the wireless network architecture 200 may include a location server 230 that can communicate with the 5GC 210 to provide location assistance to the UE 204. The location server 230 may be implemented as multiple separate servers (e.g., physically separate servers, different software modules on a single server, different software modules distributed across multiple physical servers, etc.), or alternatively, each may correspond to a single server. The location server 230 may be configured to support one or more location services for the UE 204 that can be connected to the location server 230 via the core network, the 5GC 210, and / or via the Internet (not illustrated). Furthermore, the location server 230 may be integrated into a component of the core network, or alternatively, may be external to the core network. In some examples, the location server 230 may be operated by the operator or provider of the 5GC 210, a third party, an original equipment manufacturer (OEM), or other parties. In some cases, multiple location servers may be provided, such as the operator's location server, the OEM's location server for a specific device, and / or other location servers. In such cases, location assistance data may be received from the operator's location server, and additional assistance data may be received from the OEM's location server.

[0072] According to various aspects, Figure 2B Another example wireless network architecture 250 is illustrated. For example, 5GC 260 can be functionally considered as a control plane function provided by Access and Mobility Management Function (AMF) 264 and a user plane function provided by User Plane Function (UPF) 262, which operate collaboratively to form a core network (e.g., 5GC 260). User plane interface 263 and control plane interface 265 connect ng-eNB 224 to 5GC 260, and specifically to UPF 262 and AMF 264, respectively. In some examples, gNB 222 can also connect to 5GC 260 via control plane interface 265 to AMF 264 and user plane interface 263 to UPF 262. Furthermore, ng-eNB 224 can communicate directly with gNB 222 via backhaul connection 223, with or without a direct gNB connection to 5GC 260. In some configurations, the new RAN 220 may have only one or more gNB 222s, while other configurations include one or more of both ng-eNB 224 and gNB 222. The gNB 222 or ng-eNB 224 can be used with UE 204 (e.g., Figure 1 The base station of the new RAN 220 communicates with the AMF 264 via the N2 interface and with the UPF 262 via the N3 interface.

[0073] The functions of AMF 264 include registration management, connection management, reachability management, mobility management, lawful interception, transmission of session management (SM) messages between UE 204 and Session Management Function (SMF) 266, transparent proxy service for routing SM messages, access authentication and access authorization, transmission of short message service (SMS) messages between UE 204 and Short Message Service Function (SMSF) (not shown), and Security Anchor Functionality (SEAF). AMF 264 can also interact with Authentication Server Function (AUSF) (not shown) and UE 204, and receive an intermediate key established as a result of UE 204's authentication process.

[0074] In the case of UMTS (Universal Mobile Telecommunications System) Subscriber Identity Module (USIM) authentication, AMF 264 retrieves security material from the AFS. AMF 264 functionality may also include Security Context Management (SCM). The SCM receives a key from the SEAF, which it can use to derive access network-specific keys. AMF 264 functionality may also include location service management for regulatory services, transmission of location service messages between UE 204 and Location Management Function (LMF) 270 (which acts as location server 230), transmission of location service messages between new RAN 220 and LMF 270, allocation of EPS bearer identifiers for interoperability with Evolved Packet Systems (EPS), and UE 204 mobility event notification. Furthermore, AMF 264 also supports functionality for non-3GPP access networks.

[0075] In some cases, UPF 262 may perform functions including: acting as an anchor point for intra-RAT / inter-RAT mobility (where applicable), acting as an external Protocol Data Unit (PDU) session point for interconnection to a data network (not shown), providing packet routing and forwarding, packet inspection, user plane policy rule enforcement (e.g., gating, redirection, traffic steering), lawful interception (user plane collection), traffic usage reporting, quality of service (QoS) handling for user plane (e.g., uplink / downlink rate enforcement, reflective QoS marking in downlink), uplink traffic verification (Service Data Flow (SDF) to QoS flow mapping), transport-level packet marking in uplink and downlink, downlink packet buffering and downlink data notification triggering, and delivering and forwarding one or more "end markers" to the source RAN node. In some aspects, UPF 262 may also support location service messages via user plane in UE 204 with location servers such as Secure User Plane Positioning (SUPL) Location Platform (SLP) (…). Figure 2B The transfer between (not shown in the image).

[0076] In some examples, the SMF 266's functions may include session management, UE Internet Protocol (IP) address allocation and management, selection and control of user plane functions, service orientation configuration at the UPF 262 for routing services to the correct destination, partial control over policy enforcement and QoS, and downlink data notification. The interface through which the SMF 266 communicates with the AMF 264 may be referred to as the N11 interface.

[0077] In some aspects, the wireless network architecture 250 may include an LMF 270 that can communicate with the 5GC 260 to provide location assistance to the UE 204. The LMF 270 may be implemented as multiple separate servers (e.g., physically separate servers, different software modules on a single server, different software modules distributed across multiple physical servers, etc.), or alternatively, each may correspond to a single server. The LMF 270 may be configured to support one or more location services for the UE 204, which may connect to the LMF 270 via the core network 5GC 260 and / or via the Internet (not illustrated). The SLP may support similar functionality to the LMF 270, but the LMF 270 communicates with the AMF 264, the new RAN 220, and the UE 204 via the control plane (e.g., using interfaces and protocols designed to deliver signaling messages rather than voice or data), while the SLP communicates with the UE 204 and external clients via the user plane (e.g., using protocols designed to carry voice and / or data, such as Transmission Control Protocol (TCP) and / or IP). Figure 2B (Not shown in the image) communicates.

[0078] In some cases, the LMF 270 and / or SLP can be integrated with base stations such as gNB 222 and / or ng-eNB 224. When integrated with gNB 222 and / or ng-eNB 224, the LMF 270 and / or SLP may be referred to as a “Location Management Component” or “LMC”. As used herein, references to LMF 270 and SLP include both cases where the LMF 270 and SLP are components of the core network (e.g., 5GC 260) and cases where the LMF 270 and SLP are components of the base station.

[0079] As described above, the wireless communication system supports communication between multiple UEs. In various examples, the wireless communication system can be configured to support device-to-device (D2D) communication and / or vehicle-to-everything (V2X) communication. V2X may also be referred to as cellular V2X (C-V2X). V2X communication can be performed using any radio access technology such as LTE, 5G, WLAN, or other communication protocols. In some examples, UEs can send V2X messages to and receive V2X messages from other UEs, roadside units (RSUs), and / or other devices via direct communication links or interfaces (e.g., PC5 or sidelink interfaces, 802.11p DSRC interfaces, and / or other communication interfaces) and / or via a network (e.g., eNBs, WiFi APs, and / or other network entities). These communications can be performed using resources allocated by the network (e.g., eNBs or other network devices), resources pre-configured for V2X use, and / or resources determined by the UE (e.g., using free channel assessment (CCA) regarding resources of the 802.11 network).

[0080] V2X communication can include communication between vehicles (e.g., vehicle-to-vehicle (V2V)), communication between vehicles and infrastructure (e.g., vehicle-to-infrastructure (V2I)), communication between vehicles and pedestrians (e.g., vehicle-to-pedestrian (V2P)), and / or communication between vehicles and network servers (vehicle-to-network (V2N)). For V2V, V2P, and V2I communication, data packets can be transmitted directly between vehicles (e.g., using a PC5 interface, using an 802.11 DSRC interface, etc.) without passing through a network, eNB, or gNB. V2X-enabled vehicles can, for example, use short-range direct communication modes that provide 360° non-line-of-sight (NLOS) perception, supplemental onboard line-of-sight (LOS) sensors such as cameras, radio detection and ranging (RADAR), light detection and ranging (LIDAR), and other sensors. The combination of wireless technology and onboard sensors enables V2X vehicles to visually observe, hear, and / or anticipate potential driving hazards (e.g., at blind intersections, in adverse weather conditions, and / or in other scenarios). V2X vehicles can also understand alerts or notifications from other V2X-enabled vehicles (based on V2V communication), from infrastructure systems (based on V2I communication), and from user equipment (based on V2P communication). Infrastructure systems may include roads, stop lights, road signs, bridges, toll booths, and / or other infrastructure systems that can communicate with vehicles using V2I messaging.

[0081] Depending on the specific implementation desired, sidelink communication can be performed according to 3GPP communication protocols (e.g., using the PC5 sidelink interface for LTE, 5G, etc.), Wi-Fi direct communication protocols (e.g., DSRC protocol), or any other device-to-device communication protocol. In some examples, sidelink communication can be performed using one or more unlicensed National Information Infrastructure (U-NII) frequency bands. For example, sidelink communication can be performed in the frequency bands corresponding to U-NII-4 (5.850 GHz to 5.925 GHz), U-NII-5 (5.925 GHz to 6.425 GHz), U-NII-6 (6.425 GHz to 6.525 GHz), U-NII-7 (6.525 GHz to 6.875 GHz), U-NII-8 (6.875 GHz to 7.125 GHz), or any other frequency band suitable for performing sidelink communication.

[0082] Figure 2C This is an illustration of an example of a decomposed base station architecture that can be adopted by the disclosed system for enhanced VRU prediction via server-based processing (e.g., cloud-based processing using one or more servers), based on some examples. The deployment of communication systems (such as 5G NR systems) can involve various components or constituent parts arranged in multiple ways. In a 5G NR system or network, network nodes, network entities, network mobility elements, radio access network (RAN) nodes, core network nodes, network elements or network equipment (such as base stations (BS)), or one or more units (or components) performing base station functionality can be implemented in aggregated or decomposed architectures. For example, a BS (such as a NodeB (NB), evolved NB (eNB), NR BS, 5G NB, AP, transmit / receive point (TRP), or cell, etc.) can be implemented as an aggregated base station (also known as a standalone BS or monolithic BS) or a decomposed base station.

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

[0084] Base station type operation or network design can take into account the aggregation characteristics of base station functionality. For example, decomposed base stations can be utilized in Integrated Access Backhaul (IAB) networks, Open Radio Access Networks (O-RAN (such as network configurations advocated by the O-RAN Alliance)), or Virtualized Radio Access Networks (vRAN, also known as Cloud Radio Access Networks (C-RAN)). Decomposition can include distributing functionality across two or more units in various physical locations, as well as virtually distributing the functionality of at least one unit, which allows for flexibility in network design. The various units in a decomposed base station or decomposed RAN architecture can be configured for wired or wireless communication with at least one other unit.

[0085] As mentioned earlier, Figure 2C A diagram illustrating an example decomposed base station 200c architecture is shown. The decomposed base station 200c architecture may include one or more central units (CUs) 211c, which may communicate directly with the core network 223c via a backhaul link, or indirectly with the core network 223c via one or more decomposed base station units, such as a near real-time (near-RT) RAN Intelligent Controller (RIC) 227c via an E2 link, or a non-real-time (non-RT) RIC 217 associated with a Service Management and Orchestration (SMO) framework 207c, or both. CUs 211c may communicate with one or more distributed units (DUs) 231c via appropriate midhaul links (such as F1 interfaces). DUs 231c may communicate with one or more radio units (RUs) 241c via appropriate fronthaul links. RUs 241c may communicate with corresponding UEs 221c via one or more RF access links. In some implementations, a UE 221c may be served simultaneously by multiple RUs 241cs.

[0086] Each unit in a cell (e.g., CU 211c, DU 231c, RU 241c, and near-RT RIC 227c, non-RT RIC 217c, and SMO frame 207c) may include or be coupled to one or more interfaces configured to receive or transmit signals, data, or information (collectively, signals) via a wired or wireless transmission medium. Each of the cells, or an associated processor or controller providing instructions to the communication interfaces of these cells, may be configured to communicate with one or more other cells via the transmission medium. For example, these cells may include a wired interface configured to receive signals or transmit signals to one or more other cells via a wired transmission medium. Additionally, the cells may include a wireless interface that may include a receiver, transmitter, or transceiver (such as an RF transceiver) configured to receive or transmit signals, or both, to one or more other cells over a wireless transmission medium.

[0087] In some aspects, the CU 211c can host one or more higher-level control functions. Such control functions may include Radio Resource Control (RRC), Packet Data Convergence Protocol (PDCP), Serving Data Adaptation Protocol (SDAP), etc. Each control function can be implemented using an interface configured to signal to other control functions hosted by the CU 211c. The CU 211c can be configured to handle user plane functions (e.g., Central Unit-User Plane (CU-UP)), control plane functions (e.g., Central Unit-Control Plane (CU-CP)), or combinations thereof. In some implementations, the CU 211c 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 bidirectionally with the CU-CP units via an interface such as an E1 interface. The CU 211c can be implemented to communicate with the DU131c for network control and signaling, as needed.

[0088] DU 231c may correspond to a logical unit that includes one or more base station functions for controlling the operation of one or more RU 241cs. In some aspects, DU 231c may host one or more of the Radio Link Control (RLC) layer, 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.) at least in part according to functional splits (such as those defined by the 3rd Generation Partnership Project (3GPP). In some aspects, DU 231c may also host one or more low PHY layers. Each layer (or module) may be implemented using an interface configured to communicate signals with other layers (and modules) hosted by DU 231c or with control functions hosted by CU 211c.

[0089] Lower-layer functionality can be implemented by one or more RU 241cs. In some deployments, the RU 241c controlled by the DU 231c may correspond to a logical node that hosts RF processing functions or low-PHY layer functions (such as performing Fast Fourier Transform (FFT), Inverse FFT (iFFT), digital beamforming, Physical Random Access Channel (PRACH) extraction and filtering, or both) based at least in part on functional decomposition (such as lower-layer functional decomposition). In this architecture, the RU 241c may be implemented to handle over-the-air (OTA) communications with one or more UE 221cs. In some specific implementations, the real-time and non-real-time aspects of control plane and user plane communications with the RU 241c may be controlled by the corresponding DU 231c. In some scenarios, this configuration enables the implementation of the DU 231c and CU 211c in server-based (e.g., cloud-based) RAN architectures (such as vRAN architectures).

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

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

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

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

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

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

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

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

[0098] The vehicle computing system 450 also includes a power management system 451. In some implementations, the power management system 451 may include a power management integrated circuit (PMIC), a backup battery, and / or other components. In some cases, other systems of the vehicle computing system 450 may include one or more PMICs, batteries, and / or other components. The power management system 451 may perform power management functions of the vehicle 404, such as managing the power supply to the computing system 450 and / or other parts of the vehicle. For example, the power management system 451 may provide a stable power supply in response to power fluctuations, such as those based on starting the vehicle's engine. In another example, the power management system 451 may perform thermal monitoring operations, such as by checking the ambient and / or transistor junction temperatures. In another example, the power management system 451 may perform certain functions based on the detection of a certain temperature level, such as cooling certain components of the vehicle computing system 450 (e.g., control system 452, such as one or more ECUs) by a cooling system (e.g., one or more fans, air conditioning system, etc.), shutting down certain functions of the vehicle computing system 450 (e.g., limiting the infotainment system 454, such as by turning off one or more displays, disconnecting from wireless networks, etc.), and other functions.

[0099] The vehicle computing system 450 also includes a communication system 458. The communication system 458 may include communication methods for communicating with a network (e.g., a gNB or other network entity via a Uu interface) and / or with other UEs (e.g., via a PC5 interface, a WiFi interface (e.g., DSRC), Bluetooth). ™ The interface and / or other wireless and / or wired interfaces transmit signals to another vehicle or UE and from the network (e.g., via a gNB or other network entity through the Uu interface) and / or from other UEs (e.g., via the PC5 interface, WiFi interface (e.g., DSRC), Bluetooth). ™ Both software and hardware components that receive signals from an interface and / or other wireless and / or wired interfaces to another vehicle or UE. For example, communication system 458 is configured to receive signals via any suitable wireless network (e.g., 3G network, 4G network, 5G network, WiFi network, Bluetooth). ™The communication system 458 wirelessly transmits and receives information via a network and / or other networks. The communication system 458 includes various components or devices for performing wireless communication functionality, including an Original Equipment Manufacturer (OEM) subscriber identity module (referred to as a SIM or SIM card) 460, a subscriber SIM 462, and a modem 464. Although the vehicle computing system 450 is shown as having two SIMs and one modem, in some specific implementations, the computing system 450 may have any number of SIMs (e.g., one SIM or more than two SIMs) and any number of modems (e.g., one modem, two modems, or more than two modems).

[0100] A SIM is a device (e.g., an integrated circuit) that securely stores a specific subscriber's or user's International Mobile Subscriber Identity (IMSI) number and associated keys (e.g., encryption-decryption keys). The IMSI and keys can be used to identify and authenticate subscribers on a specific UE. The OEM SIM 460 can be used by the communication system 458 to establish a wireless connection for vehicle-based operations, such as for emergency call (eCall) functionality, communication with the vehicle manufacturer's communication system (e.g., for software updates), and other operations. The OEM SIM 460 can be crucial for supporting key services such as eCalls for making emergency calls in the event of a car accident or other emergency. For example, eCalls could include automatically dialing emergency numbers (e.g., "9-1-1" in the US, "1-1-2" in Europe, etc.) in the event of a vehicle accident and relaying the vehicle's location to emergency services (such as police stations, fire departments, etc.).

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

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

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

[0104] In some examples, the communication system 458 may be or may include a Telematics Control Unit (TCU). In some implementations, the TCU may include a Network Access Device (NAD) (also referred to in some cases as a Network Control Unit or NCU). The NAD may include a modem 464, Figure 4 This includes any other modems, OEM SIM 460, user SIM 462, and / or other components for wireless communication not shown. In some examples, the communication system 458 may include a Global Navigation Satellite System (GNSS). In some cases, the GNSS may be part of one or more sensor systems 456, as described below. The GNSS may provide the vehicle computing system 450 with the ability to perform one or more location services, navigation services, and / or other services that can utilize GNSS functionality.

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

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

[0107] In some examples, computing system 450 may include Intelligent Transport System (ITS) 455. In some examples, ITS 455 may be used to implement V2X communication. For example, the ITS stack of ITS 455 may generate V2X messages based on information from the application layer of the ITS. In some cases, the application layer may determine whether certain conditions have been met to generate messages for use by ITS 455 and / or generate messages to be transmitted to other vehicles (for V2V communication), pedestrian UEs (for V2P communication), and / or infrastructure systems (for V2I communication). In some cases, communication system 458 and / or ITS 455 may obtain Vehicle Access Network (CAN) information (e.g., from other components of the vehicle via the CAN bus). In some examples, communication system 458 (e.g., TCU NAD) may obtain CAN information via the CAN bus and may transmit CAN information to the PHY / MAC layer of ITS 455. ITS 455 may provide CAN information to the ITS stack of ITS 455. CAN information may include vehicle-related information, such as the vehicle's direction of travel, speed, braking information, and other information. CAN information may be provided to the ITS 455 continuously or periodically (e.g., every 1 millisecond (ms), every 10 ms, etc.).

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

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

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

[0111] In some examples, ITS 455 may determine certain actions to be performed (e.g., V2X-based actions) based on messages received from other UEs. These actions may include safety-related and / or other operations, such as those for road safety, traffic efficiency, infotainment, business, and / or other applications. In some examples, these actions may include causing a vehicle (e.g., control system 452) to perform automatic functions, such as automatic braking, automatic steering (e.g., maintaining direction of travel in a specific lane), automatic lane change negotiation with other vehicles, and other automatic functions. In one exemplary example, communication system 458 may receive a message from another vehicle (e.g., via a PC5 interface, DSRC interface, or other device-to-device direct interface) indicating that the other vehicle is about to stop suddenly. In response to receiving the message, the ITS stack may generate a message or instruction and may transmit the message or instruction to control system 452, which may cause control system 452 to automatically brake vehicle 404 to stop it before colliding with another vehicle. In other exemplary examples, these actions may include triggering a message to warn the driver that another vehicle is in the lane adjacent to the vehicle, a message to warn the driver to stop the vehicle, a message to warn the driver that a pedestrian is at an upcoming intersection, a message to warn the driver that a toll station is within a certain distance of the vehicle (e.g., within 1 mile), and so on.

[0112] In some examples, the ITS 455 may receive a large number of messages from other UEs (e.g., vehicles, RSUs, etc.). In such cases, the ITS 455 will authenticate (e.g., decode and decrypt) each message and / or determine which operations to perform. Such a large number of messages can result in a high computational load on the vehicle computing system 450. In some cases, this high computational load can lead to an increase in the temperature of the computing system 450. An increase in the temperature of the components of the computing system 450 can adversely affect its ability to process a large number of incoming messages. One or more functionalities may be transferred from vehicle 404 to another device (e.g., user equipment, RSUs, etc.) based on the temperature of the vehicle computing system 450 (or its components) exceeding or approaching one or more thermal levels. Transferring one or more functionalities can reduce the computational load on vehicle 404 and help lower the temperature of the components. A thermal load balancer may be provided, which, depending on the temperature of the computing system 450 and the processing power of the vehicle computing system 450, enables the vehicle computing system 450 to perform thermal-based load balancing to control the processing load.

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

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

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

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

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

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

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

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

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

[0122] Figure 6This is an illustration of an example wireless communication system 600 for configuring the transmission of sidelink synchronization signals by a wireless device. In some aspects, system 600 may include one or more user equipment (UE) devices, such as UE 602 and UE 604. As noted above, UE devices (e.g., UE 602 and / or UE 604) may include any wireless communication device used by a user to communicate over a wireless communication network (e.g., mobile phone, router, tablet computer, laptop computer, tracking device, wearable device (e.g., smartwatch, glasses, extended reality (XR) devices such as virtual reality (VR) headsets, augmented reality (AR) headsets or glasses, or mixed reality (MR) headsets, etc.), vehicles (e.g., cars, motorcycles, bicycles, etc.), Internet of Things (IoT) devices, etc.).

[0123] In some examples, system 600 may include one or more base stations. For example, system 600 may include base station 610, base station 612, and base station 614. In some cases, base station 610, base station 612, and / or base station 614 may be associated with UE 602 (e.g., UE 602 may communicate with base station 610 using a network (Uu) interface). In some aspects, one or more of the base stations (e.g., base station 610, base station 612, and / or base station 614) may communicate with location server 616 (e.g., configured to implement LMF 270).

[0124] In some cases, UE 602 and UE 604 may be configured to communicate using sidelink communication (e.g., PC5, DSRC, and / or Uu-based sidelink communication, etc.). In some aspects, the UE receiving sidelink communication (e.g., UE 602 and / or UE 604) may use a sidelink synchronization signal (SLSS) to synchronize with the transmitting UE to properly demodulate and / or decode the received data. In some cases, the SLSS may include a primary sidelink synchronization signal (P-SSS) and / or a secondary sidelink synchronization signal (S-SSS). In some aspects, the SLSS (e.g., P-SSS and / or S-SSSS) may be included in a sidelink synchronization signal block (S-SSB). In some examples, the S-SSB may be transmitted as part of a physical sidelink broadcast channel (PSBCH).

[0125] In some cases, the source of the SLSS used by the UE device can be a Global Navigation Satellite System (GNSS) signal, a base station signal, a signal from another UE, and / or an internal clock signal (e.g., a clock generated by the UE device). In some examples, UE 602 may preferentially use the GNSS signal received from satellite 608 as the source of the SLSS. In some aspects, if the GNSS signal is unavailable, UE 602 may utilize downlink signals from base stations (e.g., base stations 610, 612, and / or 614) as the source of the SLSS. In some examples, if UE 602 cannot receive GNSS signals or base station signals, UE 602 may utilize signals from another UE as the source of the SLSS. In some cases, if no external source of SLSS (e.g., GNSS satellites, base stations, or other UEs) is available, UE 602 may utilize an internal clock as the source of the SLSS.

[0126] In some cases, the UE device may be located in a geographical area where the UE device cannot receive GNSS signals and / or base station signals to serve as a sidelink synchronization source. As shown in the figure, UE 604 is located within a shielded geographical area 606. In some cases, the shielded geographical area 606 may correspond to a geographical area where the GNSS signal quality and / or base station signal quality is insufficient (e.g., inaccessible or below-threshold signal quality). Exemplary examples of the shielded geographical area 606 may include tunnels, urban canyons, forests, parking garages, and / or any other geographical area where the GNSS signal quality and / or base station signal quality is insufficient.

[0127] In some examples, base stations (e.g., base station 610, base station 612, and / or base station 614) may instruct UE 602 to send SLSS 618 based on the location of UE 602 relative to a shielded geographic area 606. For example, location server 616 (e.g., LMF270) may calculate the location of UE 602 (e.g., based on positioning reference signals, UL / DL measurements, etc.). In some cases, location server 616 can determine the location of UE 602 with an accuracy of 50 meters (m). In some aspects, location server 616 can determine the location of UE 602 with an accuracy of 10 meters.

[0128] In some aspects, location server 616 may transmit location data associated with UE 602 to one or more base stations near the shielded geographic area 606. In some cases, the base stations may use the location data to determine that UE 602 is adjacent to the shielded geographic area 606. For example, location server 616 may transmit the location of UE 602 to base station 614, and base station 614 may use the location data to determine the proximity of UE 602 to the shielded geographic area 606. In some cases, when UE 602 is near the shielded geographic area 606, base station 614 may instruct UE 602 to send SLSS 618. In some examples, when UE 602 is within a threshold distance of the shielded geographic area 606, base station 614 may instruct UE 602 to send SLSS 618. For example, when UE 602 is within 1000m of the shielded geographic area 606, base station 614 may instruct UE 602 to send SLSS 618.

[0129] In some examples, location server 616 can use the location of UE 602 to determine the location of UE 602 on a map. For example, location server 616 can access map data and determine the proximity of UE 602 to a shielded geographical area 606. In some cases, location server 616 can send a message to a base station (e.g., base station 614) to instruct UE 602 to send SLSS 618. In some aspects, multi-access edge computing (MEC) can be used to implement (e.g., performed by LMF 270) UE device positioning functionality. In some configurations, MEC can be used to reduce latency when signaling the UE device to send sidelink synchronization signals.

[0130] In some aspects, base stations (e.g., base station 610, base station 612, and / or base station 614) may instruct UE 602 to send SLSS 618 based on a geofence configuration corresponding to a geographic area (e.g., shielded geographic area 606) associated with the sum and difference of signal quality. For example, base station 614 may instruct UE 602 to send SLSS 618 based on proximity to shielded geographic area 606 (e.g., based on the location of base station 614). In some examples, the base station may instruct all associated UE devices to send sidelink synchronization signals. In some cases, the base station may instruct all associated UE devices within a region or area to send sidelink synchronization signals. In some instances, the base station may use UE location data (e.g., received from location server 616) to select the UE device to send the sidelink synchronization signal. In some cases, the geofence configuration of shielded geographic area 606 may be based on cell identifiers. For example, the coverage area or geofence corresponding to shielded geographic area 606 may correspond to one or more base station identifiers corresponding to base station 610, base station 612, and / or base station 614. In some aspects, the identifiers associated with a geofence may include a Physical Cell Identifier (PCI), a Virtual Cell Identifier (VCI), and / or a Cell Global Identifier (CGI). In some cases, the base station identifier for the geofence used to implement the shielded geographic area 606 may be configured based on cell handover and / or cell reselection. In some aspects, (e.g., the base station geofence used to identify the shielded geographic area 606) may be configured by network operator (e.g., by Public Land Mobile Network (PLMN)).

[0131] In some examples, UE 602 and UE 604 may use sidelink communication to associate and form a UE queue (e.g., a cluster of associated UE devices). In some cases, the UE queue may include a queue leader configured to send sidelink synchronization signals to the UE devices in the queue. In some examples, the UE devices in the UE queue may specify the queue leader based on the UE device's location within the queue. In some cases, the queue leader (e.g., the queue's sidelink synchronization source) may be selected as the UE device that last lost GNSS and / or base station connectivity in the queue (e.g., a UE device at the rear of the queue). In an exemplary example, based on UE 602's location at the rear of the queue (e.g., UE 602 will enter shielded geographic area 606 after UE 604), UE 602 may be designated as the queue leader configured to send SLSS 618.

[0132] In some aspects, UE 602 and / or UE 604 may initiate UE queue formation when expected to enter a shielded geographic area 606. In some examples, two or more UE devices may form a UE queue based on parameters that may include UE location (e.g., distance between UE devices), direction of travel, lane location (e.g., UE devices in the same or adjacent lanes), travel speed, UE capabilities (e.g., UE sidelink configuration, UE capability to propagate SLSS, UE capability configured as an independent SLSS source, etc.), and / or any other UE parameters, attributes, or metrics.

[0133] Figure 7A A system 700 is illustrated that can be used to implement a UE queue for synchronizing sidelink communication. In some examples, system 700 may include UEs 702, UE 704, and UE 706, each capable of receiving GNSS signals from satellite 708. In some aspects, the GNSS signals from satellite 708 may be used as a sidelink synchronization signal (SLSS). In some examples, UEs 702, UE 704, and UE 706 may communicate using sidelink communication and use the GNSS signals from satellite 708 as SLSS to demodulate received data. In some cases, each UE device in system 700 (e.g., UE 702, UE 704, and UE 706) may be associated with base station 712.

[0134] In some aspects, system 700 may include a tunnel 710 associated with insufficient GNSS signal and / or insufficient base station signal. In some examples, tunnel 710 may correspond to any shielded geographical area (e.g., parking garage, urban canyon, forest, etc.) where UE devices may not receive suitable GNSS signal and / or suitable base station signal. In some cases, UE 702 may initiate UE queue formation before entering tunnel 710. In some examples, UE 702 may transmit sidelink communication to UE 704 and / or UE 706 to initiate UE queue formation. In some aspects, UE 702, UE 704, and UE 706 may form a UE queue based on parameters that may include UE location (e.g., distance between UE devices), direction of travel, lane positioning, travel speed, and / or UE capabilities. For example, UE 702, UE 704, and UE 706 may form a UE queue in response to determining that each of the respective UE devices is traveling in the same traffic lane. In another example, UE 702, UE 704, and UE 706 may form a UE queue in response to determining that each of the respective UE devices is traveling within 5 miles per hour (mph) of each other. In another example, UE 702, UE 704, and UE 706 may form a UE queue in response to determining that each of the respective UE devices is within 50 meters of each other. In yet another example, UE 702, UE 704, and UE 706 may form a UE queue in response to determining that each of the respective UE devices has the capability to be configured as a sidelink synchronization signal source.

[0135] In some respects, UEs 702, UE 704, and UE 706 may transmit sidelink communications to determine the appropriate position of each UE device within the UE queue. For example, UE 702 may be identified as the "head" of the UE queue, and UE 706 may be identified as the "tail" of the UE queue. In some cases, the position of a UE device within the UE queue can be used to determine the queue leader. In some instances, the queue leader may correspond to the UE device that will send a sidelink synchronization signal (e.g., a UE device that will be configured as a sidelink synchronization source).

[0136] In some cases, the queue leader (e.g., the sidelink synchronization source of the queue) may be selected as the UE device that last lost GNSS and / or base station connectivity in the queue (e.g., a UE device at the rear of the queue). In one exemplary example, based on the location of UE 706 at the rear of the queue (e.g., UE 706 will be the last to enter tunnel 710), UE 706 may be designated as the queue leader configured to send sidelink synchronization signals to UE 702 and UE 704. In another example, the queue leader may be selected as the UE device located at the center of the UE queue. For example, UE 704 may be selected as the queue leader to minimize the transmission distance of the sidelink synchronization signal (e.g., from UE 704 to UE 706 and from UE 704 to UE 702).

[0137] In some cases, the designation of the queue leader can be dynamically changed based on changes in the relative positioning of the UE devices. For example, if UE 704 is positioned as the last device in the UE queue (e.g., UE 704 is overtaken by UE 706 before entering tunnel 710), then UE 704 can be designated as the queue leader. In another example, if UE 702 is overtaken by both UE 704 and UE 706 before entering tunnel 710, then UE 702 can be designated as the queue leader. In some examples, UE devices may join or leave the UE queue at different times. In some cases, changes in the composition of the UE queue can lead to changes in the queue leader.

[0138] In some aspects, the formation of a UE queue (e.g., the arrangement and / or positioning of UE devices within the queue) can be configured based on factors such as the number of UE devices in the queue, the number of traffic lanes, and the length of the tunnel. For example, a UE queue comprising six UE devices may have a 6×1 formation (e.g., six vehicles in one lane) or a 3×2 formation (e.g., three vehicles in each of two parallel lanes). In some examples, the formation of the UE queue can be configured to provide efficient aggregation of UE devices within the queue. In some cases, efficient aggregation of UE devices may correspond to a queue formation in which UE devices are closer together than one another. In some examples, efficient aggregation of UE devices may correspond to a queue formation that minimizes the transmission distance between the queue leader (e.g., for transmitting sidelink synchronization signals) and the UE device furthest from the queue leader.

[0139] In some aspects, the formation of the UE queue can be configured based on the tunnel length. For example, the length of the columns in the UE queue (e.g., UE devices lined up in the direction of travel) can be relative to the tunnel length (e.g., a shorter tunnel may correspond to a shorter column length). In some examples, the formation of the UE queue can be updated dynamically. For example, the formation of the UE queue can be changed based on changes in the number of UE devices in the UE queue, changes in the number of available traffic lanes, traffic conditions, signal transmission quality, etc.

[0140] Figure 7B Examples of those that can be followed Figure 7A The configuration of system 700 shown is illustrated. In some aspects, UE 702 may be located inside tunnel 710, while UE 704 and UE 706 may be located outside tunnel 710. In some examples, UE 704 and UE 706 may receive GNSS signals from satellite 708. In some cases, UE 704 and UE 706 may be associated with base station 712. In some examples, UE 702 may not be able to receive GNSS signals from satellite 708 when it is inside tunnel 710 (illustrated by 'X' 716). In some cases, UE 702 may not be able to receive base station signals from base station 712 when it is inside tunnel 710 (illustrated by 'X' 718).

[0141] In some respects, UE 706 can be configured as a queue leader for a UE queue that includes UE 702, UE 704, and UE 706. In some cases, UE 706 can transmit a sidelink synchronization signal (SLSS) 714 based on GNSS signals from satellite 708. In some examples, UE 702 can receive SLSS 714 from UE 706 and use SLSS 714 to demodulate sidelink communications from UE 704 and / or UE 706. In some cases, UE 704 can continue to use GNSS signals from satellite 708 as its SLSS.

[0142] Figure 8Example 800 illustrates wireless communication between devices based on sidelink communication (such as V2X or other D2D communication). This communication may be based on a time-slot structure. For example, transmitting UE 802 may transmit 814, which can be received by receiving UEs 804, 806, and 808, and this transmission may include, for example, a control channel and / or a corresponding data channel. At least one UE may include an autonomous vehicle or an unmanned aerial vehicle. The control channel may include information for decoding the data channel and may also be used by the receiving devices to avoid interference by avoiding transmission on occupied resources during data transmission. The number of TTIs and RBs occupied by the data transmission may be indicated in a control message from the transmitting device. Besides operating as receiving devices, UEs 802, 804, 806, and 808 may each be capable of operating as transmitting devices. Therefore, UEs 806 and 808 are illustrated as transmitting 816 and 820, respectively. Transmissions 814, 816, 820 (and 818 by RSU 807) may be broadcast or multicast to nearby devices. For example, UE 808 may transmit communications intended to be received by other UEs within range 801 of UE 814. Additionally / alternatively, RSU 807 may receive communication 818 from UEs 802, 804, 806, 808 and / or transmit the communication to those UEs. UEs 802, 804, 806, 808, or RSU 807 may include detection components. UEs 802, 804, 806, 808, or RSU 807 may also include BSM or mitigation components.

[0143] In wireless communications (such as V2X communications), V2X entities can perform sensor sharing with other V2X entities to achieve collaboration and autonomous driving. For example, see reference... Figure 9A As shown in Figure 900, the main vehicle (HV) 902 can detect multiple objects within its environment. For example, at box 932, HV 902 can detect the presence of a non-V2X entity (NV) 906. If RV1 904 and / or RSU 908 cannot detect NV 906 on their own, HV 902 can notify other entities (such as the first remote vehicle (RV1) 904 or roadside unit (RSU) 908) of the presence of NV 906. HV 902 notifying RV1 904 and / or RSU 908 of NV 906 is a sharing of sensor information. (Reference) Figure 9B As shown in Figure 910, HV 902 can detect physical obstacles 912 (such as potholes, debris, or objects that may be obstacles in the path of HV 902 and / or RV1 904 that have not yet been detected by RV1 904 and / or RSU 908). HV 902 can notify RV1 and / or RSU 908 of the obstacle 912, allowing the obstacle 912 to be avoided. (See reference...) Figure 9CAs shown in Figure 920, HV 902 can detect the presence of vulnerable road user (VRU) 922, and can share detection of VRU 922 with RV1 904 and RSU 908 in instances where RSU 908 and / or RV1 904 may not be able to detect VRU 922. (See reference...) Figure 9D As shown in Figure 930, when the HV detects a nearby entity (e.g., NV, VRU, obstacle), it can send a Sensor Data Sharing Message (SDSM) 934 to the RV and / or RSU to share the detection of that entity. SDSM 934 can be a broadcast message, making it available to any receiving device near the HV. In some instances, the shared information can be relayed to other entities, such as the RV. For example, see Reference Figure 10 As shown in Figure 1000, HV 1002 can detect the presence of NV 1006 and / or VRU 1022. HV 1002 can broadcast SDSM 1010 to RSU 1008 to report the detection of NV 1006 and / or VRU 1022. RSU 1008 can relay the SDSM 1010 received from HV 1002 to the remote vehicle, so that the remote vehicle is aware of the presence of NV 1006 and / or VRU 1022. For example, RSU 1008 can send SDSM 1012 to RV1 1004, where SDSM 1012 includes information related to the detection of NV 1006 and / or VRU 1022.

[0144] Figure 11 This is a diagram illustrating an example of a system 1100 for sensor sharing in wireless communication (e.g., V2X communication). Figure 11 In this diagram, system 1100 is shown to include multiple equipped (e.g., V2X-enabled) network devices. These equipped network devices include vehicles (e.g., cars) 1110a, 1110b, 1110c, 1110d, and RSU 1105. Multiple unequipped network devices are also shown, including an unequipped vehicle 1120, a VRU (e.g., a cyclist) 1130, and a pedestrian 1140. System 1100 may include, for example... Figure 11 This indicates more or fewer equipped network devices and / or more or fewer unequipped network devices. Additionally, system 1100 may include, for example... Figure 11The examples show more or fewer different types of equipped network devices (e.g., which may include equipped UEs) and / or more or fewer different types of unequipped network devices (e.g., which may include unequipped UEs). Additionally, in one or more examples, the equipped network devices may be equipped with a wide variety of capabilities, including but not limited to C-V2X / DSRC capabilities, 4G / 5G cellular connectivity, GPS capabilities, camera capabilities, radar capabilities, and / or LIDAR capabilities.

[0145] Multiple equipped network devices may be capable of performing V2X communication. Additionally, at least some of the equipped network devices are configured to transmit and receive sensing signals for radar (e.g., RF sensing signals) and / or LIDAR (e.g., optical sensing signals) to detect nearby vehicles and / or objects. Additionally or alternatively, in some cases, at least some of the equipped network devices are configured to use one or more cameras to detect nearby vehicles and / or objects (e.g., by processing images captured by the one or more cameras to detect these vehicles / objects). In one or more examples, vehicles 1110a, 1110b, 1110c, 1110d, and RSU 1105 may be configured to transmit and receive some kind of sensing signal (e.g., radar and / or LIDAR sensing signals).

[0146] In some examples, some of the network devices equipped in the system 1100 may have sensors with higher capabilities than other network devices equipped in the system 1100 (e.g., GPS receivers, cameras, RF antennas, and / or optical lasers and / or optical sensors). For example, vehicle 1110b may be a luxury vehicle and therefore have more expensive and more capable sensors than other vehicles that are economy vehicles. In one exemplary example, vehicle 1110b may have one or more LIDAR sensors (e.g., high-capacity optical lasers and optical sensors) with higher capabilities than other network devices equipped in the system 1100. In one exemplary example, the LIDAR of vehicle 1110b may be able to detect VRUs (e.g., cyclists) 1130 and / or pedestrians 1140 with high confidence (e.g., 70 percent confidence). In another example, vehicle 1110b may have radar with higher capabilities than other network devices equipped in the system 1100 (e.g., high-capacity RF antennas). For example, the radar of vehicle 1110b may be able to detect VRU (e.g., a cyclist) 1130 and / or pedestrian 1140 with a certain degree of confidence (e.g., 85 percent confidence). In another example, vehicle 1110b may have a camera with higher capabilities than other network devices equipped in system 1100 (e.g., higher resolution capability, higher frame rate capability, better lens, etc.).

[0147] During operation of system 1100, the equipped network devices (e.g., at least one of vehicles 1110a, 1110b, 1110c, 1110d and / or RSU 1105) can transmit and / or receive sensing signals (e.g., RF and / or optical signals) to sense and detect vehicles (e.g., vehicles 1110a, 1110b, 1110c, 1110d and 1120) and / or objects (e.g., VRU 1130 and pedestrian 1140) located within and around the road. The equipped network devices (e.g., at least one of vehicles 1110a, 1110b, 1110c, 1110d and / or RSU 1105) can then use the sensing signals to determine the characteristics of the detected vehicles and / or objects (e.g., motion, size, type, direction of travel, and speed). The network device equipped (e.g., at least one of vehicles 1110a, 1110b, 1110c, 1110d and / or RSU 1105) can generate at least one vehicle-based message 1115 (e.g., V2X message, such as Sensor Data Sharing Message (SDSM), Basic Safety Message (BSM), Cooperative Sensing Message (CAM), Collective Sensing Message (CPM) and / or other types of messages), which includes information related to determined characteristics of the detected vehicle and / or object.

[0148] Vehicle-based messages 1115 may include information related to the detected vehicle or object (e.g., the location of the vehicle or object, the accuracy of the location, the speed of the vehicle or object, the direction the vehicle or object is traveling, and / or other information related to the vehicle or object), traffic conditions (e.g., low-speed and / or dense traffic, high-speed traffic, accident-related information, etc.), weather conditions (e.g., rain, snow, etc.), message type (e.g., emergency message, non-emergency or "regular" message, etc.), road topology (line-of-sight (LOS) or non-LOS (NLOS), etc.), any combination thereof, and / or other information. In some examples, vehicle-based messages 1115 may also include information about the preferences of the equipped network device for receiving vehicle-based messages from certain other equipped network devices. In some cases, the vehicle-based message 1115 may include the current capabilities of the equipped network equipment (e.g., vehicles 1110a, 1110b, 1110c, 1110d), such as the sensing capabilities of the equipped network equipment (which may affect the accuracy with which the equipped network equipment senses vehicles and / or objects), processing capabilities, thermal status of the equipped network equipment (which may affect the vehicle's ability to process data), and health status of the equipped network equipment.

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

[0150] In some implementations, vehicle-based message 1115 may include specific use case or safety warnings related to the current status of the equipped network devices (e.g., vehicles 1110a, 1110b, 1110c, 1110d), such as a No-Passing Warning (DNPW) or a Forward Collision Warning (FCW). In some examples, vehicle-based message 1115 may take the form of a standard Basic Safety Message (BSM), a Collaborative Sensing Message (CAM), a Collective Sensing Message (CPM), a Sensor Data Sharing Message (SDSM) (e.g., SAE J3224 SDSM), and / or other formats.

[0151] As previously noted, this document describes systems and techniques for sending and / or receiving multicast messages using three-dimensional (3D) region configuration information indicating a candidate receiver for a corresponding multicast message. In an exemplary example, these systems and techniques can be used to provide 3D region configuration information for V2X multicast messages, such as distance-based V2X multicast messages. The 3D region configuration information can indicate a receiving region corresponding to a candidate receiver for the corresponding multicast message. The receiving region can be a two-dimensional (2D) area or a 3D area. The 3D region configuration information can additionally indicate one or more of direction information and / or height information that can be used by the candidate receiver UE to determine the receiving region for the corresponding multicast message.

[0152] Figure 12AFigure 1200 illustrates an example of two-dimensional (2D) distance-based multicast in wireless communications (e.g., V2X communications) according to some examples. A first vehicle UE 1202a may be configured as a transmitting UE (e.g., a Tx UE) for one or more distance-based multicast messages (e.g., one or more V2X multicast messages). For example, the desired communication range of the distance-based multicast messages transmitted by the first vehicle UE 1202a may correspond to region 1210, which includes a circular area with a radius of 1215 centered on the current location of the vehicle UE 1202a.

[0153] The first vehicle UE 1202a may send (e.g., broadcast) sidelink information associated with and scheduling a distance-based multicast message. The sidelink information may indicate the current location of the first vehicle UE 1202a and the desired communication range. For example, if the first vehicle UE 1202a, the second vehicle UE 1202b, and / or the third vehicle UE 1202c are configured to use a default 2D circular area (e.g., such as area 1210) to implement the distance-based multicast message, the UE receiving the sidelink information from the first vehicle UE 1202a may use the desired communication range and the location information of the first vehicle UE 1202a to determine whether these vehicles are the intended recipients of the upcoming multicast message scheduled by the sidelink information. For example, the second vehicle UE 1202b and / or the third vehicle UE 1202c may determine the receiving area for the multicast message as a circular area centered on the location of the first vehicle UE 1202a and having a radius equal to the desired communication range 1215. If the second vehicle UE 1202b or the third vehicle UE 1202c determines that its current location is within the determined reception area 1210, then the UE is the intended receiver of the multicast message and may be required to correctly decode the packets associated with the multicast message.

[0154] In some aspects, the desired communication range can be determined based on the V2X application associated with the multicast message. For example, different types of V2X applications (e.g., and corresponding different types of V2X messages or communications) may utilize different range requirements for V2X distance-based multicast message delivery. In some examples, the range requirement for Cooperative Aware Message (CAM) V2X packet delivery (e.g., CAM V2X multicast messages) could be 300 meters. In another example, the range requirement for highway traffic congestion warning V2X packet delivery (e.g., highway traffic congestion warning V2X multicast messages) could be 1000 meters; and so on. In some examples, in distance-based packet delivery for V2X multicast messages, only Rx UEs within the desired (e.g., minimum and / or required) communication range from the Tx UE are required to correctly decode the V2X multicast message packets. For example, in the example of Figure 12, neither the second vehicle UE 1202b nor the third vehicle UE 1202c is within the range requirement given by the distance 1215 from the first vehicle UE 1202a (e.g., neither vehicle UE 1202b nor vehicle UE 1202c is within the circular region 1210 with a radius equal to the distance 1215), and neither is required to correctly decode V2X multicast messages from the first vehicle UE 1202a.

[0155] In some specific implementations of NR V2X, the location of a Tx UE can be indicated by a region identifier (ID) of the Tx UE's current location. A region ID can be included in multiple region IDs, each corresponding to a different geographic region (e.g., each region ID can be an index for a specific region / geographic region). The current location of the Tx UE can be within a specific geographic region corresponding to the region ID signaled by the Tx UE to potential or candidate Rx UEs.

[0156] Figure 12BThis is an illustration of an example of multiple regions 1240 that can be associated with the transmission and reception of multicast messages based on V2X distance. In some examples, network entities (e.g., base stations, gNBs, etc.) may use the SL-ZoneConfig information element to send region configuration information to the UE in the cell. The SL-ZoneConfig information element may include various parameters corresponding to the multiple regions 1240. For example, the SL-ZoneConfig information element may include an SL-ZoneWidth value indicating the width (W) of the region, an SL-ZoneLength value indicating the length (L) of the region, an SL-ZoneIdLongiMod indicating the number of regions configured based on longitude, and an SL-ZoneIdLatiMode indicating the number of regions configured based on latitude. In some examples, each of the SL-ZoneWidth and SL-ZoneLength parameters can be configured to 5m, 10m, 20m, 50m, 100m, 200m, or 500m; each of the SL-ZoneIdLongiMod and SL-ZoneIdLatiMode parameters can be configured to an integer value between 1 and 4. For example, for a region with a horizontal dimension of A km and a vertical dimension of B km (e.g., such as...), Figure 12B As shown), the horizontal and vertical dimensions of each of the 1240 regions, as well as the (A×B) km dimensions, can be configured using parameters in the SL-ZoneConfig information element. 2 The number of regions included in the region.

[0157] In some examples, the UE may calculate the region ID information (e.g., Zone_id) corresponding to the UE's current location based on the following: x1=Floor(x / L)Mod64 y1=Floor(y / L)Mod64 Zone_id=y1*64+x1 Here, L is the value of SL-ZoneLength included in the SL-ZoneConfig information element. The value of x represents the longitude geodesic distance between the UE's current location and the geographic coordinates (0, 0) (e.g., corresponding to the Greenwich Observatory), expressed in meters based on the WGS84 model. The value of y represents the latitude geodesic distance between the UE's current location and the geographic coordinates (0, 0), expressed in meters based on the WGS84 model.

[0158] In some example implementations of NR V2X, distance-based Hybrid Automatic Repeat Request (HARQ) feedback can be used to enforce communication range requirements. This can be based on region or... Figure 12AThe region identifier (e.g., Zone_id above) corresponding to region 1210 is used to indicate the Tx UE location. The region identifier of the Tx UE location may be included in the location of the Tx UE (e.g., Figure 12A The sidelink control information (SCI) sent by the vehicle UE (1202a) may additionally include or indicate the minimum communication range for V2X multicast messages. In some examples, any Rx UE within the minimum communication range indicated by the SCI may be required to send HARQ feedback to the Tx UE to ensure distance-based packet delivery.

[0159] In some cases, SCI format 2-B can be used to implement V2X distance-based multicast for decoding Physical Side Link Shared Channel (PSSCH) transmissions (e.g., data transmission of V2X multicast messages). SCI format 2-B information can be transmitted as a PSSCH transmission and can be used to schedule corresponding PSSCH transmissions for V2X multicast messages. In some cases, distance-based V2X multicast using SCI format 2-B is implemented with a NACK-only HARQ feedback implementation. In the NACK-only HARQ feedback implementation, the Rx UE does not send an ACK in response to successful reception or decoding of the SCI (e.g., no transmission in the success case) and sends a NACK in response to unsuccessful reception or decoding of the SCI (e.g., transmission only in the failure case).

[0160] In some examples, SCI Format 2-B information may include one or more of the following: HARQ process number (e.g., on four bits); new data indicator (e.g., on one bit); redundant version (e.g., on two bits); one or more source Layer 2 (L2) IDs (e.g., on eight bits); one or more destination L2 IDs (e.g., on 16 bits); HARQ feedback enable / disable indicator (e.g., on one bit); region ID (e.g., on 12 bits); and communication range requirements (e.g., on four bits, as determined by the higher-layer parameter SL-ZoneConfig MCR-Index). In some cases, each UE may have one or more L2 IDs for V2X communication via PC5 (e.g., one or more source L2 IDs and one or more destination L2 IDs from SCI Format 2-B information).

[0161] In some specific implementations of V2X distance-based multicast, the communication range requirement can be based on the x and y coordinates of the Tx UE and corresponds to a 2D receiving area that does not support the direction indication, height indication, and / or non-circular receiving area indication for one or more expected Rx UEs for receiving V2X multicast messages.

[0162] For various V2X applications, scenarios, and / or message types, a 2D circular communication range indication for the current specific implementation of V2X distance-based multicast may be suboptimal. For example, in a two-way highway example, some vehicle UE data may only be of interest to (e.g., related to) UEs moving in the same direction of travel, and a V2X multicast message that can indicate the expected or candidate Rx UE based on directionality is needed. In a multi-level highway example, some vehicle UE data may only be of interest to (e.g., related to) UEs currently located on the same level (e.g., at the same height), and a V2X multicast message that can indicate the expected or candidate Rx UE based on height is needed. In examples of multiple highway intersections and / or in intersecting areas, some vehicle UE data may only be of interest to (e.g., related to) UEs within the same lane of travel, and a V2X multicast message that can indicate the expected or candidate Rx UE based on lane location is needed. In examples of multi-level parking lots and / or multi-level highways, some vehicle UE data may be of interest only to UEs within a specific level (e.g., relevant to that UE), and V2X multicast messages need to be able to indicate the expected or candidate Rx UEs based on the level within the multi-level parking lot or highway. The systems and techniques described herein can be used to provide enhanced region indication information, which can be used to optimize distance-based multicast transmission and reception. For example, a Tx UE can use enhanced region indication information to direct V2X multicast messages to a narrower and more specific subset of nearby UEs, thereby reducing unnecessary retransmissions in response to the Tx UE receiving a HARQ NACK indicating a failed decoding of the multicast message at the Rx UE. Reducing unnecessary retransmissions of multicast messages to unexpected Rx UEs can reduce network load and interference for V2X communications.

[0163] For example, Figure 13A This is a diagram illustrating an example of direction- and distance-based multicast 1300 for V2X sidelink communication, and Figure 13B This is a diagram illustrating an example of height- and distance-based multicast 1350 for V2X sidelink communication, based on some examples. As used herein, direction- and distance-based multicast (e.g., Figure 13A ) and height- and distance-based multicast (e.g., Figure 13B These can be collectively referred to as “enhanced multicast” and / or “three-dimensional multicast” (e.g., “3D multicast”).

[0164] For example, Figure 13A Example multicast 1300 can utilize three-dimensional region ID configuration and / or indication based on the use of two planar dimensions (x and y) and a third directional dimension (e.g., θ; {N, E, S, W} basic directions; etc.). Figure 13B Example multicast 1350 can utilize three-dimensional region ID configuration and / or indication based on the use of two planar dimensions (x and y) and a third height dimension (e.g., z). Three-dimensional region ID configuration and / or indication can be additionally implemented by combining the two planar dimensions (x and y) with various other third dimensions, such as indexes for specific lanes of a multi-lane road, indexes for specific layers of a multi-level parking garage or multi-level road, etc.

[0165] As previously noted above, the three-dimensional region configuration and / or indication utilized by the systems and techniques described herein can reduce network congestion and improve resource efficiency within the network. For example, by using three-dimensional region configuration and indication instead of the existing 2D circular region configuration and indication, the number of intended receivers (e.g., Rx UEs) for V2X multicast messages, sensor sharing, and / or collision warnings can be significantly reduced. Reducing the number of Rx UEs for V2X multicast messages allows for a higher modulation and decoding scheme (MCS) for V2X multicast messages (e.g., where the MCS defines the number of useful bits that can be transmitted per resource element (RE)) and / or reduces the number of retransmissions performed by Tx UEs in response to receiving HARQ NACKs from Rx UEs.

[0166] exist Figure 13A In the example, the first vehicle UE 1302a may be a Tx UE for V2X multicast messages. Based on the current location of the first vehicle UE 1302a (e.g., the region ID corresponding to the current location of the first vehicle UE 1302a), the reception area 1310 may be defined in two dimensions (and in some cases referred to as a two-dimensional (2D) region) for the intended receiver of the V2X multicast message. For example, the reception area 1310 may be a circular area with a radius given by the range requirement 1315 associated with the V2X multicast message. In existing specific implementations using two-dimensional region configuration and indication, based on the minimum range given by the reception area 1310 for both vehicle UE 1302b and vehicle UE 1302c, both the second vehicle UE 1302b and the third vehicle UE 1302c will be required to correctly decode the V2X multicast message from the first vehicle UE 1302a. Based on the fact that the pedestrian UE is located within the minimum range of the receiving area 1310, in existing specific implementations using two-dimensional area configuration and indication, the pedestrian UE (e.g., a UE carried by a pedestrian or otherwise associated with a pedestrian) may additionally be required to correctly decode V2X multicast messages from the first vehicle UE 1302a.

[0167] In one exemplary example, these systems and techniques enable enhanced V2X multicast message transmission and reception based on indicating the intended reception area for multicast messages, including a subset of the reception area 1310, using directional range information transmitted by the first vehicle UE 1302a. For example, the first vehicle UE 1302a may transmit a V2X multicast message indicating sensor-shared information with a vulnerable road user (VRU) 1307 in an intersecting area preceding the first vehicle UE 1302a. Sensor-shared information or messages with VRU 1307 may be associated with other vehicle UEs near the intersecting area and moving towards the intersecting area. In some respects, the first vehicle UE 1302a may send sidelink information (e.g., PSCCH transmission for scheduling PSSCH transmission of V2X multicast messages) indicating that the candidate receiver UE for sharing V2X multicast messages with VRU sensors is only a vehicle UE that is near the first vehicle UE 1302a and is moving in the same direction as the first vehicle UE 1302a.

[0168] For example, based on the fact that the second vehicle UE 1302b is traveling in the opposite direction to the first vehicle UE 1302a, the second vehicle UE 1302b is within the area of ​​the receiving region 1310 (e.g., within the minimum distance 1315 of the first vehicle UE 1302a), but is not a candidate receiver UE. The third vehicle UE 1302c is within the area of ​​the receiving region 1310 (e.g., within the minimum distance 1315 of the first vehicle UE 1302a) and is traveling in the same direction as the first vehicle UE 1302a, and is a candidate receiver UE for VRU sensor sharing V2X multicast messages. The third vehicle UE 1302c may be required to correctly decode the VRU sensor sharing V2X multicast messages (e.g., required to transmit HARQ NACK feedback if the multicast message is not successfully decoded). The second vehicle UE 1302b can ignore VRU sensor-shared V2X multicast messages (e.g., skip decoding of the VRU sensor-shared V2X multicast message) based on its status as a non-candidate receiver UE for V2X multicast messages.

[0169] In another example, the first vehicle UE 1302a may send a V2X multicast message including a collision warning. The collision warning V2X multicast message may be relevant only to other vehicle UEs located after the first vehicle UE 1302a. The first vehicle UE 1302a may send sidelink information including directional range information for limiting candidate Rx UEs (e.g., interested receivers) for the collision warning V2X multicast message to a sub-area-only region within the receiving area 1310. The third vehicle UE 1302c may be a candidate Rx UE required to correctly decode the collision warning V2X multicast message from the first vehicle UE 1302a. The second vehicle UE 1302b may be a non-candidate Rx UE not required to correctly decode the collision warning V2X multicast message from the first vehicle UE 1302a. For example, the second vehicle UE 1302b may ignore collision warning V2X multicast messages (e.g., skip decoding the collision warning V2X multicast message) based on being a non-candidate receiver UE for V2X multicast messages.

[0170] In another exemplary example, enhanced V2X multicast message transmission and reception can be implemented based on using altitude information sent by the Tx vehicle UE to indicate the expected reception area for V2X multicast messages. For example, as previously noted, in a multi-level parking garage or multi-level highway, some vehicle UE data may only be of interest to other vehicle UEs on a specific level. Figure 13BAn example is provided: a first vehicle UE 1352a located on a first layer 1371 of a parking lot or highway; a second vehicle UE 1352b and a third vehicle UE 1352c located on a second layer 1372 of a parking lot or highway; and a fourth vehicle UE 1352d located on a third layer 1373 of a parking lot or highway. V2X multicast messages from the first vehicle UE 1352a may be associated only with other vehicle UEs also located on the first layer 1371. The second vehicle UE 1352b, the third vehicle UE 1352c, and the fourth vehicle UE 1352d (respectively) may receive sidelink information for V2X multicast messages from the first vehicle UE 1352a, wherein the intended receiver is indicated as any UE also located on the first layer 1371. The second, third, and fourth vehicle UEs 1352b-1352d can ignore V2X multicast messages from the first vehicle UE 1352 based on their location on different layers. In another example, a V2X multicast message from the second vehicle UE 1352b can indicate that the intended receiver is any UE also located on layer 2 1372. The third vehicle UE 1352c can be the required receiver that must successfully decode the V2X multicast message from the second vehicle UE 1352b or send a HARQ NACK feedback. The first vehicle UE 1352a and the fourth vehicle UE 1352d are not intended receivers of V2X multicast messages from the second vehicle UE 1352b and can ignore the V2X multicast messages without decoding.

[0171] In an exemplary example, these systems and technologies can utilize application layer configurations with different region indication types for enhanced V2X multicast message transmission and reception. For instance, the application layer of a V2X UE can be configured with multiple region indication types, each corresponding to one or more different V2X applications, services, message types, etc. Different region indication types can utilize corresponding region range information to indicate the receiving area within the geographic region corresponding to the region ID of the Tx UE. For example, a first-direction region indication type can be used to indicate a region that includes only a specific direction based on the sender region (e.g., a specific direction including the region corresponding to the Tx UE region ID). A second-direction region indication type can be used to indicate a region that excludes a specific direction based on the sender region (e.g., excluding the specific direction corresponding to the Tx UE region ID).

[0172] In another example, the lane-based area indication type can be used to indicate an area comprising a specific lane segment of a road. In some examples, the lane-based area indication type can be used to indicate an area comprising a specific lane or multiple lanes of a multi-lane highway. In another example, the height-level area indication type can be used to indicate an area comprising one or more levels of a multi-story parking garage or a multi-story highway. The height-level area indication type can be used to indicate a corresponding portion of an area comprising one or more levels of a multi-story parking garage or a multi-story highway.

[0173] In some respects, numerous region indication modes (e.g., multiple region indication modes) can be configured in the application layer of the V2X UE and can be used to configure the Rx UE to determine a specific region indication type for V2X multicast messages, wherein the specific region indication type is included among multiple region indication types. For example, the determined region indication type for V2X multicast messages can be determined based on one or more of the following: V2X application type, V2X service type, V2X broadcast mode, etc.

[0174] In some examples, the default region indication can be configured as a transmitter-centric (e.g., centered on the current location of the Tx UE) circular communication range, such as the circular communication range exemplified by region 1210 centered on the first vehicle UE 1302a and given by radius 1215 in FIG. 12, and / or centered on the first vehicle UE 1202a and given by… Figure 13AThe radius 1315 gives the circular communication range of the receiving area 1310, etc. In some cases, the default area indication can be the transmitter-centered circular communication range specified by 3GPP R16 C-V2X. In one exemplary example, the direction area indication mode can be used to indicate the direction area indication type using basic direction (e.g., N, E, S, W) direction indications. In some aspects, the angle area indication mode can be used to indicate the angle area indication type using quantized angle information and / or one or more angle value ranges to indicate a limited selection of nearby UEs as receiver candidates for V2X multicast messages. In another exemplary example, height indication, floor indication, and / or layer indication can be used in conjunction with 2D area indication (e.g., in conjunction with transmitter-centered circular communication range area indication). In some aspects, these systems and technologies may include and / or be used to implement packet-specific area indication modes. For example, sensor sharing message packets sent via V2X multicast may include and / or correspond to objects in a specific direction, and the direction area indication type may be most efficient for the receiver UE to detect and provide feedback HARQ NACK information (e.g., based on the receiver UE being in the reception area identified corresponding to the direction area indication information and based on the receiver UE failing to decode the corresponding V2X multicast message).

[0175] In one exemplary example, Tx vehicle UEs and / or Rx vehicle UEs may use their respective current location information in conjunction with application-layer region type configuration to determine a specific region ID for the current location of the vehicle UE. In some aspects, the current location of each vehicle UE may be a GPS-based location or another positioning system-based location. In some examples, the GPS-based or positioning system-based location of the vehicle UE may be fused with additional sensor data obtained by the vehicle UE (e.g., radar sensor data, lidar sensor data, camera sensor data, etc.) to determine a specific region ID from multiple region IDs of a specific region indication type corresponding to the current location of the vehicle UE.

[0176] For example, a vehicle UE can fuse accelerometer and / or other inertial sensor data with its GPS-based current location information to determine its direction of travel or movement. In some cases, the vehicle UE can use accelerometer and / or other inertial data to determine the section of a highway it is located on. In another example, the vehicle UE can utilize camera data (e.g., images, videos, video frames, etc.) to perform lane detection, street sign detection, etc., to determine the specific highway on which it is traveling (e.g., where it is located), or the specific lane it is using (e.g., where it is located). In some aspects, the vehicle UE can utilize camera-based sign detection to determine the specific parking level in a multi-story parking garage.

[0177] In some cases, V2X multicast messages can be associated with a source L2 ID and a destination L2 ID. For example, as previously noted above, one or more source L2 IDs and destination L2 IDs may be included in SCI format 2-B information (e.g., sidelink information) associated with the PSSCH transmission of the V2X multicast message and used to schedule the PSSCH transmission of the V2X multicast message. In existing implementations of distance-based V2C multicast message reception, the source L2 ID can be determined based on information associated only with the Tx UE (e.g., in existing implementations, the source L2 ID may be a unique identifier for the Tx UE, and / or in existing implementations, the destination L2 ID may be a unique identifier for one or more Rx UEs). In an exemplary example, a Tx vehicle UE may determine and configure source L2 ID information and / or destination L2 ID information for V2X multicast transmission based on the specific transmission region where the Tx vehicle UE is located (e.g., based on a region ID determined for the UE’s current location, wherein the determined region ID is included in a plurality of region IDs corresponding to a specific region indication type used and / or configured for V2X multicast transmission).

[0178] For example, a Tx UE may determine the source L2 ID of a V2X multicast message based on the region indication type to be used for V2X multicast transmission and based on corresponding region mapping information from the application layer (e.g., mapping the Tx UE's current location to a specific region ID among multiple region IDs of the region indication type to be used for V2X multicast transmission). In another exemplary example, the Tx UE may additionally determine the range of receiving regions (e.g., receiving areas) for V2X multicast transmission and may use one or more destination L2 IDs mapped to the determined receiving region to indicate the receiving region. In some aspects, one or more destination L2 IDs may be used to indicate an interested receiver (e.g., a candidate Rx vehicle UE) for the V2X multicast message based on direction and / or altitude information corresponding to the receiving region, based on the V2X application type, etc.

[0179] In some respects, a Tx UE may transmit sidelink information indicating its sending region (of a specific region indication type) and / or one or more receiving regions of an expected Rx UE for V2X multicast messages. For example, a Tx UE may directly indicate its sending region and / or one or more receiving regions using one or more reserved bits within the SCI format 2-B sidelink information associated with and used for scheduling V2X messages. In another example, a Tx UE may implicitly indicate its sending region and / or one or more receiving regions by encoding region indication information into one or more source L2 IDs and / or destination L2 IDs.

[0180] Figure 14 This is an illustration of an example of enhanced V2X multicast message reception 1400 based on a sending region indication (corresponding to sending region 1410) corresponding to a Tx UE and a receiving region indication (e.g., receiving area) (corresponding to receiving region 1425) corresponding to an expected receiver (e.g., a candidate Rx UE) of the V2X multicast message. In an illustrative example, the Tx UE may indicate its Tx UE region ID information in SCI format 2-B sidelink information associated with and used for scheduling the V2X multicast message. A nearby UE may receive the sidelink information and use at least the Tx UE region ID information to determine whether it is an expected candidate receiver for the V2X multicast message associated with the sidelink information. For example, a nearby UE may decode the sidelink information and determine whether to receive V2X multicast message data packets based on the range information of the multicast message, where the range information indicates a receiving area within the geographic region corresponding to the Tx UE region ID.

[0181] In some aspects, such as in examples where the V2X application type utilizes directional area indication type, altitude-based or layer-based area indication type, and / or 3D area indication type, the Tx vehicle UE may send sidelink information to further indicate the corresponding receiving area range. Based on the receiving area range, the UE receiving the sidelink information may decide whether to decode the scheduled V2X multicast message data packets, and if decoding fails, send a physical sidelink feedback channel (PSFCH) indicating HARQ NACK.

[0182] In some examples, the receiving region may be indicated based on a mapping between the corresponding receiving region and one or more destination L2 IDs (e.g., configured by the V2X application layer). In another example, the receiving region may be indicated as a receiving region ID carried by one or more reserved bits in the SCI Format 2-B sidelink information. For example, the receiving region ID may be indicated by a lower layer (e.g., the Media Access Control (MAC) layer). In an exemplary example, the receiving region ID may be carried by a first set of one or more reserved bits in the SCI Format 2-B sidelink information, and the sending region ID may be carried by a second set of one or more reserved bits in the SCI Format 2-B sidelink information. In some examples, the Tx UE may indicate a three-dimensional region indication based on the sidelink information including the sending region ID but excluding the receiving region ID. In some examples, the Tx UE may indicate a three-dimensional region indication based on the sidelink information including the receiving region ID but excluding the sending region ID. In some examples, the Tx UE may indicate a three-dimensional region indication based on the sidelink information including both the sending region ID and the receiving region ID. In another exemplary example, the TxUE may indicate a three-dimensional region indication based on selecting a specific sending region and a specific receiving region for a V2X multicast message, wherein both the specific Tx region and the specific Rx region are selected from the same plurality of regions (e.g., from the same plurality of region IDs).

[0183] exist Figure 14 In the example, the first vehicle UE 1402a can be a Tx UE for V2X multicast messages. The first vehicle UE 1402a can send sidelink information indicating the sending region and / or receiving region for identifying candidate receivers of V2X multicast messages.

[0184] For example, in an example where the sidelink information only indicates the sending region, the sending region can be configured to be the same as the receiving region used for V2X multicast messages. In an exemplary example, the Tx-only region sidelink information sent by the first vehicle UE 1402a may include a Tx region ID corresponding to the receiving region 1425. For example, the vehicle UE 1402d may decode V2X multicast messages from the first vehicle UE 1402a based on being located within the receiving region 1425.

[0185] In another exemplary example, where the sidelink information only indicates the receiving region, the receiving region can be configured to be the same as the receiving region used for V2X multicast messages. For example, the Rx region-only sidelink information sent by the first vehicle UE 1402a may include an Rx region ID corresponding to the receiving region 1425. For example, the vehicle UE 1402d may decode V2X multicast messages from the first vehicle UE 1402a based on being located within the receiving region 1425.

[0186] In another illustrative example, the sidelink information may indicate a Tx region ID corresponding to the sending region 1410 of the first vehicle UE 1402a and an Rx region ID corresponding to the receiving region 1425 of the candidate receiver for the V2X multicast message. Nearby UEs (e.g., UEs within range of receiving and decoding the sidelink information sent by the first vehicle UE 1402a) may determine the receiving region for the V2X multicast message from the first vehicle UE 1402a as the intersection region between the sending region 1410 and the receiving region 1425. For example, vehicle UEs 1402b, 1402c, and 1402d are each located within the sending region 1410. Only vehicle UE 1402d is also located within the receiving region 1425. Based on the receiving area located within the intersecting area between the sending area 1410 and the receiving area 1425, the vehicle UE 1402d can determine that it is the required receiver of the V2X multicast message from the first vehicle UE 1402a, and must either successfully decode the V2X multicast message from the first vehicle UE 1402a or otherwise send a HARQ NACK feedback indicating unsuccessful decoding.

[0187] In an exemplary example, the Rx UE (e.g., a vehicle UE, a V2X-enabled UE, etc.) can be any UE within the range of the Tx UE, where the Rx UE receives and decodes sidelink information corresponding to the V2X multicast message of the Tx UE. In some aspects, the UE application layer of each Rx UE can be used to determine whether the Rx UE is a receiver candidate (e.g., expected or desired receiver) for the V2X multicast message corresponding to the sidelink information. For example, based on the receive region indication included in the sidelink information from the Tx UE and the corresponding region determination for the Rx UE itself, the Rx UE can determine whether it is a receiver candidate for the V2X multicast message. For example, the corresponding region determination for the Rx UE can be a receive region ID intersected with the sending region ID to determine the receive region (e.g., the receive area for the V2X multicast message), or it can be a region ID that directly indicates the receive region (e.g., the receive area) for the V2X multicast message. In some examples, determining the corresponding region for an Rx UE may include comparing the Rx UE's current location with a receiving region identified from sidelink information. In some examples, determining the corresponding region for an Rx UE may include using the Rx UE's current location to identify the Rx UE region; and comparing that Rx UE region with a receiving region identified from sidelink information.

[0188] In some examples, where the sidelink information includes range information indicating the receiving area that is not a transmitter-centric circular 2D area (e.g., range information including direction, height, floor, level, lane, etc.), the receiving range for V2X multicast messages from a Tx UE depends not only on the minimum communication range (MCR) value (e.g., where MCR is the radius of the transmitter-centric circular 2D area used in existing specific implementations). Figure 12A radius 1215, Figure 13A(The radius 1315, etc., can be an MCR value). In some aspects, if the sidelink information indicates that the Rx UE is not a receiver candidate for V2X multicast messages (e.g., based on range indications or range information from the Tx UE's sidelink information, such as a range corresponding to the destination L2 ID value), the Rx UE does not decode the PSSCH transmission of the V2X multicast message and transmits neither HARQACK nor HARQ NACK feedback. If the sidelink information indicates that the Rx UE is a receiver candidate for V2X multicast messages, the Rx UE may be required to successfully decode the PSSCH transmission of the V2X multicast message, thus transmitting only HARQ NACK feedback if decoding fails. In some aspects, in response to receiving a HARQ NACK for the initial PSSCH transmission of the V2X multicast message, the PSFCH V2X transmission may be reduced and may be associated with a corresponding reduction in the Tx UE's PSSCH retransmission of the V2X multicast message.

[0189] Figure 15 This is a flowchart illustrating an example of a process 1500 for wireless communication. Process 1500 may be performed by a user equipment (UE) or by components, systems, or devices of the UE (e.g., the UE's chipset or other components or systems of the UE). For example, the UE may include one or more of the following: Figure 1 The UEs listed are, for example, UE 104, UE 152, UE 164, UE 182, UE 190, etc. Figure 2A or Figure 2B UE 204; Figure 2C UE 221c; Figure 3 UE 304, 305, 307; Figure 4 Transportation vehicle 404; Figure 5 UE 507; Figure 6 UE 602, 604; Figure 7A or Figure 7B UE 702, 704, 706; Figure 8 UEs 802, 804, 806, and 808; Figures 9A to 9D UE 902, 904; Figure 10 UE 1004, 1006; Figure 11 UEs 1110a, 1110b, 1110c, 1110d, and 1120 in Figure 12; UEs 1202a, 1202b, and 1202c in Figure 12; Figure 13A UE 1302a, 1302b, 1302c and / or with Figure 13A User 1307 is associated with user UE; Figure 13B UE 1352a, 1352b, 1352c; Figure 14 UE 1402a, 1402b, 1402c, 1402d; etc.

[0190] In an exemplary example, process 1500 may be performed by a source UE (such as a source V2X UE configured to send one or more V2X multicast messages). For example, process 1500 may be performed by a UE that is related to the one described herein. Figures 3 to 14 One or more of the connected vehicles (e.g., vehicle UE, V2X UE, etc.) described herein are the same or similar and may be referred to herein as “source UE” (e.g., the source or initiator of one or more V2X ULs sending (such as V2X multicast messages).

[0191] At box 1502, the UE (or its components, system, or device) can determine the region indication type of the UE's multicast messages. The region indication type is included among a variety of configured region indication types.

[0192] At box 1504, the UE (or its components, system, or device) can determine the region identifier (ID) of the UE's current location. The UE's current location is within a geographic region corresponding to the region ID. The region ID is selected from a plurality of region IDs of region indication type. In some aspects, the geographic region includes the sending region for multicast messages used by the UE, and the region ID includes a sending region ID corresponding to the sending region.

[0193] At box 1506, the UE (or its components, system, or device) may determine the range information for the multicast message. This range information indicates the receiving area within the geographic region corresponding to the region ID. In some aspects, to determine the range information for the multicast message, the UE (or its components, system, or device) may determine a receiving region ID corresponding to the receiving region used for the multicast message. In some cases, the receiving area includes the intersection area between the receiving region and the sending region used for the multicast message. In some examples, the UE (or its components, system, or device) may determine the receiving region from a plurality of configured receiving regions and may determine the sending region from a plurality of configured sending regions. In some cases, the plurality of configured receiving regions and the plurality of configured sending regions are the same. In some aspects, the sidelink information includes one or more Layer 2 (L2) IDs indicating the receiving region ID. In some examples, the sidelink information includes one or more reserved Sidelink Control Information (SCI) bits indicating the receiving region ID. In some cases, the sidelink information also includes one or more reserved SCI bits indicating the sending region ID.

[0194] At box 1508, the UE (or its components, system, or apparatus) may transmit sidelink information indicating region ID and range information. In some cases, the sidelink information is configured to enable one or more candidate UEs located in the receiving area to decode multicast messages.

[0195] At box 1510, the UE (or its components, system, or device) may send multicast messages.

[0196] In some respects, a UE (or its components, systems, or devices) may receive a Hybrid Automatic Repeat Request (HARQ) Negative Acknowledgment (NACK) corresponding to a multicast message. A HARQ NACK indicates that a candidate UE in the receiving area has failed to decode the multicast message.

[0197] In some cases, sidelink information includes a source L2 ID indicating one or more of the following: a region ID or a region indication type associated with a multicast message. In such cases, the sidelink information may also include a destination L2 ID indicating range information. In some aspects, the source L2 ID further indicates one or more of the following: direction information or altitude information for a geographic region. In some examples, the sidelink information includes a first destination L2 ID indicating direction or angle information corresponding to a first receiving area within a geographic region. In such examples, the sidelink information also includes a second destination L2 ID indicating direction or angle information corresponding to a second receiving area within a geographic region, wherein the first receiving area is different from the second receiving area. In some cases, the sidelink information includes a first destination L2 ID indicating a first range of altitude values ​​corresponding to the first receiving area within a geographic region. In such cases, the sidelink information may also include a second destination L2 ID indicating a second range of altitude values ​​corresponding to the second receiving area within a geographic region, wherein the first receiving area is different from the second receiving area.

[0198] In some cases, sidelink information includes sidelink control information (SCI) included in the Physical Sidelink Control Channel (PSCCH) transmission. In other cases, multicast messages include vehicular-to-everything (V2X) messages included in the Physical Sidelink Shared Channel (PSSCH) transmission.

[0199] In some cases, the UE is a vehicle-to-everything (V2X) UE (e.g., a vehicle or other V2X UE), and the multicast message is a V2X multicast message between the V2X UE and one or more receiving candidate UEs located within the receiving area. In such cases, range information may indicate a basic directional and / or angular range relative to the V2X UE's current direction of movement. In some examples, the receiving area is located before or after the V2X UE's current direction of movement.

[0200] In some cases, a geographic region is included in multiple geographic regions associated with a region indication type. In such cases, based on the region indication type, the shape or geometry of each corresponding geographic region among the multiple geographic regions may be identical. In such cases, each corresponding geographic region may correspond to a lane of a road, a portion of a road lane, and / or the direction of travel within a road lane. In some aspects, each corresponding geographic region may correspond to different levels of a multi-story parking garage or different levels of a multi-story road.

[0201] Figure 16 This is a flowchart illustrating another example of a process 1600 for wireless communication. Process 1600 may be performed by a user equipment (UE) or by components, systems, or devices of the UE (e.g., the UE's chipset or other components or systems of the UE). For example, the UE may include one or more of the following: Figure 1 The UEs listed are, for example, UE 104, UE 152, UE 164, UE 182, UE 190, etc. Figure 2A or Figure 2B UE 204; Figure 2C UE 221c; Figure 3 UE 304, 305, 307; Figure 4 UE404; Figure 5 UE 507; Figure 6 UE 602, 604; Figure 7A or Figure 7B UE 702, 704, 706; Figure 8 UEs 802, 804, 806, and 808; Figures 9A to 9D UE 902, 904; Figure 10 UE 1004, 1006; Figure 11 UEs 1110a, 1110b, 1110c, 1110d, and 1120 in Figure 12; UEs 1202a, 1202b, and 1202c in Figure 12; Figure 13A UE 1302a, 1302b, 1302c and / or with Figure 13A User 1307 is associated with user UE; Figure 13B UE 1352a, 1352b, 1352c; Figure 14 UE 1402a, 1402b, 1402c, 1402d; etc.

[0202] In some cases, process 1600 may be performed by a different UE than the UE used to perform process 1500. For example, process 1600 may be performed by a V2X destination UE (e.g., a V2X-capable UE) associated with the V2X source UE performing process 1500. "Destination UE" may refer to a V2X-enabled or V2X-capable UE associated with the source UE. For example, the destination UE may subscribe to the source UE to receive one or more V2X multicast messages initiated by the source UE (e.g., from the network). In some examples, the destination UE may send a request to the network indicating a request to subscribe to some (or all) of the V2X multicast messages initiated by the source UE. In other examples, the network may identify one or more destination UEs for receiving V2X multicast messages initiated by the source UE. In some examples, the source UE may provide the network with information indicating one or more destination UEs for receiving V2X multicast messages initiated by the source UE in the DL.

[0203] At box 1602, the UE (or its components, system, or apparatus) may receive sidelink information indicating range information and a region identifier (ID) corresponding to the current location of the second UE. The current location of the second UE is within a geographic region corresponding to the region ID. The region ID is included among multiple region IDs of a specific region indication type, determining a reception area that includes a portion of the geographic region corresponding to the region ID. The reception area is determined based on direction or angle information included in the range information. In some cases, the sidelink information is configured to enable one or more candidate UEs located within the reception area to decode multicast messages, wherein the first UE is included among the one or more candidate UEs.

[0204] In some aspects, the geographic region includes the sending region for multicast messages used by the UE, and the region ID includes the sending region ID corresponding to the sending region. In some cases, the range information is based on the receiving region ID corresponding to the receiving region used for multicast messages. In some examples, the receiving region includes the intersection area between the receiving region and the sending region for multicast messages. In some cases, the receiving region is included in multiple configured receiving regions, and the sending region is included in multiple configured sending regions. In some examples, the multiple configured receiving regions and the multiple configured sending regions are the same.

[0205] In some aspects, sidelink information includes one or more Layer 2 (L2) IDs indicating the receive region ID. In some cases, sidelink information includes one or more reserved sidelink control information (SCI) bits indicating the receive region ID. In some examples, sidelink information also includes one or more reserved SCI bits indicating the send region ID.

[0206] At box 1604, the UE (or its components, system, or device) can decode multicast messages received corresponding to sidelink information. The multicast messages are decoded based on the current location of the first UE within the receiving area.

[0207] In some respects, a UE (or its components, systems, or devices) may send a Hybrid Automatic Repeat Request (HARQ) Negative Acknowledgment (NACK) corresponding to a multicast message. A HARQ NACK indicates that the first UE has failed to decode the multicast message.

[0208] In some cases, sidelink information includes a source L2 ID indicating one or more of the following: a region ID or a region indication type associated with a multicast message. In such cases, the sidelink information may also include a destination L2 ID indicating range information. In some instances, the source L2 ID further indicates one or more of direction information or altitude information for a geographic region. In some examples, the sidelink information includes a first destination L2 ID indicating direction or angle information corresponding to a first receiving area within a geographic region. In such examples, the sidelink information may also include a second destination L2 ID indicating direction or angle information corresponding to a second receiving area within a geographic region, wherein the first receiving area is different from the second receiving area. In some aspects, the sidelink information includes a first destination L2 ID indicating a first range of altitude values ​​corresponding to a first receiving area within a geographic region. In such aspects, the sidelink information may also include a second destination L2 ID indicating a second range of altitude values ​​corresponding to a second receiving area within a geographic region, wherein the first receiving area is different from the second receiving area.

[0209] In some respects, sidelink information includes sidelink control information (SCI) included in the Physical Sidelink Control Channel (PSCCH) transmission. In such respects, multicast messages may include vehicular-to-everything (V2X) messages included in the Physical Sidelink Shared Channel (PSSCH) transmission.

[0210] In some cases, the first UE is a V2X-enabled UE (e.g., a V2X-enabled vehicle or other V2X-enabled UE), and the second UE is a V2X UE. In such cases, the multicast message can be a V2X multicast message between the V2X UE and the V2X-enabled UE. In some examples, range information indicates a basic directional and / or angular range relative to the current direction of movement of the V2X UE. In some cases, the receiving area is located before or after the current direction of movement of the V2X UE.

[0211] In some respects, geographic regions are included in multiple geographic regions associated with a region indication type. In such respects, the shape or geometry of each corresponding geographic region among the multiple geographic regions may be identical, based on the region indication type. In some instances, each corresponding geographic region corresponds to a lane of a road, a portion of a road lane, and / or the direction of travel within a road lane. In some cases, each corresponding geographic region corresponds to a different level of a multi-story parking garage or a different level of a multi-story road.

[0212] Wireless communication devices (e.g., UEs) may include various components such as one or more input devices, one or more output devices, one or more processors, one or more microprocessors, one or more microcomputers, one or more cameras, one or more sensors, one or more receivers, transmitters and / or transceivers, and / or other components configured to perform the steps of the processes described herein. In some examples, computing devices may include a display, a network interface configured to communicate and / or receive data, any combination thereof, and / or other components. The network interface may be configured to communicate and / or receive Internet Protocol (IP) based data or other types of data.

[0213] Configured to execute Figure 15 Process 1500 Figure 16 Components of the apparatus for process 1600 and / or other processes described herein may be implemented in a circuit. For example, components may include electronic circuits or other electronic hardware, and / or may be implemented using electronic circuits or other electronic hardware, which may include one or more programmable electronic circuits (e.g., a microprocessor, graphics processing unit (GPU), digital signal processor (DSP), central processing unit (CPU), and / or other suitable electronic circuits), and / or may include computer software, firmware, or any combination thereof for performing the various operations described herein, and / or may be implemented using computer software, firmware, or any combination thereof for performing the various operations described herein.

[0214] Figure 15 Process 1500 Figure 16Process 1600 and / or other processes described herein may be exemplified as logic flowcharts, whose operations represent sequences of operations that can be implemented in hardware, computer instructions, or combinations thereof. In the context of computer instructions, each operation represents a computer-executable instruction stored on one or more computer-readable storage media that, when executed by one or more processors, performs the described operation. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc., that perform a particular function or implement a particular data type. The order in which operations are described is not intended to be construed as limiting, and any number of described operations may be combined in any order and / or in parallel to implement the process.

[0215] Additionally, Figure 15 Process 1500 Figure 16 Process 1600 and / or other processes described herein may be executed under the control of one or more computer systems configured with executable instructions, and may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that executes jointly on one or more processors, by hardware, or a combination thereof. As noted above, the code may be stored on a computer-readable or machine-readable storage medium, for example, in the form of a computer program comprising multiple instructions executable by one or more processors. The computer-readable or machine-readable storage medium may be non-transitory.

[0216] Figure 17 This is a signaling diagram corresponding to the wireless communication procedure 1700 that can be performed between the first UE 1702 and the second UE 1706. In some cases, the first UE 1702 may be associated with performing... Figure 15 The process 1500 is the same as or similar to that of the UE. For example, the first UE 1702 may be a V2X UE. In some cases, the second UE 1706 may be associated with the execution Figure 16 The process of UE 1600 is the same as or similar to that of UE 1706. For example, the second UE 1706 can be a V2X UE, a UE with V2X capability, a pedestrian UE, etc.

[0217] In some examples, at box 1712, the first UE 1702 may determine the region indication type of the multicast message. For example, the multicast message may be a V2X multicast message sent using sidelink communication between the first UE 1702 and one or more additional entities (e.g., such as a second UE 1706). In some cases, the V2X multicast message may be a distance-based V2X multicast message. In some aspects, the V2X multicast message may be sent via the physical sidelink shared channel (PSSCH) of the first UE 1702. The V2X multicast message may be associated with corresponding sidelink information indicating the expected or candidate receiver of the V2X multicast message. The corresponding sidelink information may additionally schedule the V2X multicast message (e.g., may schedule the PSSCH transmission corresponding to the V2X multicast message). For example, the corresponding sidelink information may include sidelink control information (SCI) sent as the physical sidelink control channel (PSCCH) of the first UE 1702.

[0218] Figure 18 This is a block diagram illustrating an example of a computing system 1800 employed by the disclosed systems and technologies, which may be represented by enhanced locale configuration indications for V2X multicast messages. Specifically, Figure 18 An example of computing system 1800 is illustrated. This computing system can be any computing device, such as constituting an internal computing system, a remote computing system, a camera, or any component thereof, wherein the components of the system communicate with each other using connection 1805. Connection 1805 can be a physical connection using a bus, or a direct connection to processor 1810, as in a chipset architecture. Connection 1805 can also be a virtual connection, a networking connection, or a logical connection.

[0219] In some aspects, computing system 1800 is a distributed system in which the functions described herein can be distributed across a data center, multiple data centers, a peer-to-peer network, etc. In some aspects, one or more of the described system components represent a plurality of such components, each of which performs some or all of the functions described for that component. In some aspects, the components can be physical or virtual devices.

[0220] Example system 1800 includes at least one processing unit (CPU or processor) 1810 and a connection 1805 that communicatively couples various system components, including system memories 1815 such as read-only memory (ROM) 1820 and random access memory (RAM) 1825, to processor 1810. Computing system 1800 may include a cache 1812 of high-speed memory that is directly connected to, closely proximate to, or integrated into processor 1810.

[0221] Processor 1810 may include any general-purpose processor and hardware or software services (such as services 1832, 1834, and 1836 stored in storage device 1830 and configured to control processor 1810), as well as dedicated processors in which software instructions are incorporated into the actual processor design. Processor 1810 may be a substantially completely independent computing system containing multiple cores or processors, buses, memory controllers, caches, etc. Multi-core processors may be symmetric or asymmetric.

[0222] To enable user interaction, the computing system 1800 includes an input device 1845 that can represent any number of input mechanisms, such as a microphone for voice, a touch-sensitive screen for gesture or graphical input, a keyboard, a mouse, motion input, voice input, etc. The computing system 1800 may also include an output device 1835 that can be one or more of multiple output mechanisms. In some instances, a multi-mode system allows the user to provide multiple types of input / output to communicate with the computing system 1800.

[0223] The computing system 1800 may include a communication interface 1840, which typically controls and manages user input and system output. The communication interface may perform or facilitate the receiving and / or transmitting of wired or wireless communications using wired and / or wireless transceivers, including utilizing audio jacks / plugs, microphone jacks / plugs, Universal Serial Bus (USB) ports / plugs, Apple... ™ Lightning ™ Ports / plugs, Ethernet ports / plugs, fiber optic ports / plugs, dedicated wired ports / plugs, 3G, 4G, 5G and / or other cellular data network wireless signal transmission, Bluetooth ™ Wireless signal transmission, Bluetooth ™ Low-power (BLE) wireless signal transmission, IBEACON ™ Wireless signal transmission, radio frequency identification (RFID) wireless signal transmission, near field communication (NFC) wireless signal transmission, dedicated short range communication (DSRC) wireless signal transmission, 802.11 Wi-Fi wireless signal transmission, wireless local area network (WLAN) signal transmission, visible light communication (VLC), microwave access global interoperability (WiMAX), infrared (IR) wireless signal transmission, public switched telephone network (PSTN) signal transmission, integrated services digital network (ISDN) signal transmission, self-organizing network signal transmission, radio wave signal transmission, microwave signal transmission, infrared signal transmission, visible light signal transmission, ultraviolet light signal transmission, wireless signal transmission along the electromagnetic spectrum, or those communications in some combination thereof.

[0224] The communication interface 1840 may also include one or more ranging sensors (e.g., LIDAR sensors, laser rangefinders, RF radars, ultrasonic sensors, and infrared (IR) sensors) configured to collect data and provide measurements to the processor 1810, thereby configuring the processor 1810 to perform determinations and calculations required to obtain various measurements from the one or more ranging sensors. In some examples, measurements may include time of flight, wavelength, azimuth, elevation, range, linear velocity, and / or angular velocity, or any combination thereof. The communication interface 1840 may also include one or more Global Navigation Satellite System (GNSS) receivers or transceivers used to determine the position of the computing system 1800 based on one or more signals received from one or more satellites associated with one or more GNSS systems. GNSS systems include, but are not limited to, the US GPS, the Russian GLONASS, the Chinese BeiDou Navigation Satellite System (BDS), and the European Galileo GNSS. There are no limitations on operation on any particular hardware arrangement, and therefore the basic features here can be easily replaced to obtain improved hardware or firmware arrangements as they are developed.

[0225] Storage device 1830 may be a non-volatile and / or non-transitory and / or computer-readable storage device, and may be a hard disk or other type of computer-readable medium capable of storing data accessible by a computer, such as magnetic tape, flash memory cards, solid-state storage devices, digital multifunction disks, cartridges, floppy disks, hard disks, magnetic tapes, magnetic stripes, any other magnetic storage media, flash memory, memristor memory, any other solid-state storage, CD-ROM, rewritable CD, DVD, Blu-ray Disc, holographic disc, another optical medium, Secure Digital (SD) card, microSD card, Memory Stick. ®Cards, smart card chips, EMV chips, Subscriber Identity Module (SIM) cards, mini / micro / nano / micro SIM cards, another integrated circuit (IC) chip / card, random access memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash EPROM, cache memory (e.g., layer 1 (L1) cache, layer 2 (L2) cache, layer 3 (L3) cache, layer 4 (L4) cache, layer 5 (L5) cache, or other (L#) cache), resistive random access memory (RRAM / ReRAM), phase change memory (PCM), spin-transfer torque RAM (STT-RAM), another memory chip or card and / or combinations thereof.

[0226] Storage device 1830 may include software services, servers, services, etc., which enable the system to perform functions when the code defining such software is executed by processor 1810. In some aspects, hardware services performing specific functions may include software components for performing functions stored in a computer-readable medium connected to necessary hardware components such as processor 1810, connection 1805, output device 1835, etc. The term "computer-readable medium" includes, but is not limited to, portable or non-portable storage devices, optical storage devices, and various other media capable of storing, containing, or carrying instructions and / or data. Computer-readable media may include non-transitory media in which data can be stored and which does not include carrier waves and / or transient electronic signals propagating wirelessly or over a wired connection. Examples of non-transitory media may include, but are not limited to, magnetic disks or magnetic tapes, optical storage media such as compact discs (CDs) or digital versatile discs (DVDs), flash memory, memory, or memory devices. Computer-readable media may store code and / or machine-executable instructions thereon, which may represent procedures, functions, subroutines, programs, routines, subroutines, modules, software packages, classes, or any combination of instructions, data structures, or program statements. Code segments may be coupled to other code segments or hardware circuitry by passing and / or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc., may be passed, forwarded, or transmitted via any suitable means, including memory sharing, message passing, token passing, network transmission, etc.

[0227] Specific details have been provided in the foregoing description to offer a thorough understanding of the aspects and examples presented herein, but those skilled in the art will recognize that this application is not limited thereto. Therefore, although illustrative aspects of this application have been described in detail herein, it is to be understood that the inventive concepts can be implemented and employed in a variety of other ways, and the appended claims are not intended to be construed as including these variations unless limited by prior art. The various features and aspects of the applications described above can be used individually or in combination. Furthermore, without departing from the broader scope of this specification, aspects can be used in any number of environments and applications beyond those described herein. Therefore, the specification and drawings should be considered illustrative rather than restrictive. For illustrative purposes, the methods are described in a particular order. It should be understood that, in alternative aspects, the methods may be performed in a different order than described.

[0228] For clarity, in some instances, this technology may be presented as comprising individual functional blocks, which include devices, device components, steps, or routines embodied in a method, either in software or a combination of hardware and software. Additional components may be used in addition to those shown in the figures and / or described herein. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form to avoid obscuring these aspects in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail to avoid obscuring the aspects.

[0229] Furthermore, those skilled in the art will understand that the various exemplary logic blocks, modules, circuits, and algorithm steps described in connection with the aspects disclosed herein can be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability 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 may 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.

[0230] Various aspects described above can be presented as processes or methods, depicted as flowcharts, diagrams, data flow graphs, structure diagrams, or block diagrams. While flowcharts may describe operations as sequential processes, many operations within an operation can be executed in parallel or concurrently. Furthermore, the order of operations can be rearranged. A process terminates when its operations are completed, but it may have additional steps not included in the diagrams. A process can correspond to a method, function, procedure, subroutine, subroutine, etc. When a process corresponds to a function, its termination may correspond to the function returning to its calling function or the main function.

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

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

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

[0234] The various exemplary logic blocks, modules, and circuits described in conjunction with the aspects disclosed herein can be implemented or performed using hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof, and can take any form factor of various form factors. When implemented in software, firmware, middleware, or microcode, program code or code segments (e.g., computer program products) for performing necessary tasks can be stored in a computer-readable or machine-readable medium. A processor can perform the necessary tasks. Examples of form factors include: laptop computers, smartphones, mobile phones, tablet devices, or other small form factor personal computers, personal digital assistants, rack-mounted devices, self-contained devices, etc. The functionality described herein can also be embodied in peripheral devices or interlocking cards. By further example, such functionality can also be implemented on circuit boards of different chips or different processes executed on a single device.

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

[0236] The techniques described herein can also be implemented in electronic hardware, computer software, firmware, or any combination thereof. Such techniques can be implemented in any of a variety of devices, such as general-purpose computers, wireless communication devices (mobile phones), or integrated circuit devices with multiple uses, including applications in wireless communication devices (mobile phones) and other devices. Any feature described as a module or component can be implemented together in an integrated logic device or separately as discrete but interoperable logic devices. If implemented in software, the techniques can be implemented at least in part by a computer-readable data storage medium comprising program code including instructions that, when executed, perform one or more of the methods, algorithms, and / or operations described above. The computer-readable data storage medium can form part of a computer program product, which may include packaging material. The computer-readable medium may include memory or data storage media, such as random access memory (RAM) (such as synchronous dynamic random access memory (SDRAM)), read-only memory (ROM), non-volatile random access memory (NVRAM), electrically erasable programmable read-only memory (EEPROM), flash memory, magnetic or optical data storage media, etc. Additionally or alternatively, the technology may be implemented at least in part by a computer-readable communication medium that carries or conveys program code in the form of instructions or data structures that can be accessed, read and / or executed by a computer, such as propagated signals or waves.

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

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

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

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

[0241] Claim language or other languages ​​that state "at least one of" and / or "one or more of" in a set indicate that one member of the set or multiple members of the set (in any combination) satisfy the claim. For example, claim language stating "at least one of A and B" or "at least one of A or B" means A, B, or A and B. In another example, claim language stating "at least one of A, B, and C" or "at least one of A, B, or C" means A, B, C, or A and B, or A and C, or B and C, A and B and C, or any repetition is information or data (e.g., A and A, B and B, C and C, A and A and B, etc.), or any other ordering, repetition, or combination of A, B, and C. The language "at least one of" and / or "one or more of" in a set does not limit the set to the items listed in the set. For example, the language of a claim stating "at least one of A and B" or "at least one of A or B" may refer to A, B, or A and B, and may additionally include items not listed in the set of A and B. The phrases "at least one" and "one or more" are used interchangeably herein.

[0242] Claims using phrases such as "at least one processor, the at least one processor being configured to," "at least one processor being configured to," "one or more processors, the one or more processors being configured to," or "one or more processors being configured to," or other languages, indicate that one or more processors (in any combination) are capable of performing associated operations. For example, a claim using the phrase "at least one processor, the at least one processor being configured to: X, Y, and Z" means that a single processor can be used to perform operations X, Y, and Z; or that multiple processors are each assigned a specific subset of tasks to perform operations X, Y, and Z, such that the multiple processors together perform X, Y, and Z; or that a group of multiple processors work together to perform operations X, Y, and Z. In another example, a claim using the phrase "at least one processor, the at least one processor being configured to: X, Y, and Z" could mean that any single processor can perform only at least one subset of operations X, Y, and Z.

[0243] When referring to one or more elements that perform functions (e.g., steps of a method), one element may perform all functions, or more than one element may jointly perform these functions. When more than one element jointly performs these functions, each function does not need to be performed by every single element (e.g., different functions may be performed by different elements), and / or each function does not need to be performed by only one element as a whole (e.g., different elements may perform different sub-functions of a function). Similarly, when referring to one or more elements configured to cause another element (e.g., a device) to perform functions, one element may be configured to cause another element to perform all functions, or more than one element may be jointly configured to cause another element to perform these functions.

[0244] When referring to an entity that performs or is configured to perform functions (e.g., steps of a method) (e.g., any entity or device described herein), the entity may be configured to cause one or more elements (individually or collectively) to perform those functions. One or more components of the entity may include at least one memory, at least one processor, at least one communication interface, another component configured to perform one or more of those functions, and / or any combination thereof. When referring to an entity that performs functions, the entity may be configured to cause one component to perform all functions, or to cause more than one component to perform those functions collectively. When the entity is configured to cause more than one component to perform those functions collectively, each function does not need to be performed by every single component (e.g., different functions may be performed by different components), and / or each function does not need to be performed by only one component as a whole (e.g., different components may perform different sub-functions of a function).

[0245] The exemplary aspects of this disclosure include: Aspect 1. An apparatus for a user equipment (UE) for wireless communication, the apparatus comprising: at least one memory; and at least one processor coupled to the at least one memory, wherein the at least one processor is configured to: determine a region indication type of a multicast message of the UE, wherein the region indication type is included among a plurality of configured region indication types; determine a region identifier (ID) of the current location of the UE, wherein the current location of the UE is within a geographic region corresponding to the region ID, and wherein the region ID is selected from a plurality of region IDs of the region indication type; determine range information of the multicast message, wherein the range information indicates a reception area within the geographic region corresponding to the region ID; transmit sidelink information indicating the region ID and the range information; and transmit the multicast message.

[0246] Aspect 2. The apparatus according to aspect 1, wherein the sidelink information is configured to cause one or more candidate UEs located in the receiving area to decode the multicast message.

[0247] Aspect 3. The apparatus according to any one of Aspect 1 or 2, wherein the at least one processor is further configured to: receive a Hybrid Automatic Repeat Request (HARQ) Negative Acknowledgment (NACK) corresponding to the multicast message, wherein the HARQ NACK indicates that a candidate UE located in the receiving area has failed to decode the multicast message.

[0248] Aspect 4. The apparatus according to any one of Aspects 1 to 3, wherein the sidelink information includes: a source layer 2 (L2) ID indicating one or more of the following: the region ID or the region indication type associated with the multicast message; and a destination L2 ID indicating the range information.

[0249] Aspect 5. The apparatus according to aspect 4, wherein the side link information includes: a first destination L2 ID indicating direction or angle information corresponding to a first receiving area within the geographic region; and a second destination L2 ID indicating direction or angle information corresponding to a second receiving area within the geographic region, the first receiving area being different from the second receiving area.

[0250] Aspect 6. The apparatus according to aspect 4, wherein the sidelink information includes: a first destination L2 ID indicating a first range of altitude values ​​corresponding to a first receiving area within the geographic region; and a second destination L2 ID indicating a second range of altitude values ​​corresponding to a second receiving area within the geographic region, the first receiving area being different from the second receiving area.

[0251] Aspect 7. The apparatus according to any one of Aspects 4 to 6, wherein the source L2 ID further indicates one or more of the direction information or the altitude information of the geographic region.

[0252] Aspect 8. The apparatus according to any one of Aspects 1 to 7, wherein the geographical region includes a sending region for the multicast message for the UE, and wherein the region ID includes a sending region ID corresponding to the sending region.

[0253] Aspect 9. The apparatus according to aspect 8, wherein, in order to determine the range information of the multicast message, the at least one processor is configured to: determine a receiving region ID corresponding to a receiving region for the multicast message.

[0254] Aspect 10. The apparatus according to aspect 9, wherein the receiving region includes an intersection region between the receiving region and the sending region for the multicast message.

[0255] Aspect 11. The apparatus according to any one of Aspects 9 or 10, wherein the at least one processor is configured to: determine the receiving region from a plurality of configured receiving regions; and determine the transmitting region from a plurality of configured transmitting regions.

[0256] Aspect 12. The apparatus according to aspect 11, wherein the receiving region of the plurality of configurations and the transmitting region of the plurality of configurations are the same.

[0257] Aspect 13. The apparatus according to any one of Aspects 9 to 12, wherein the side link information includes one or more Layer 2 (L2) IDs indicating the receiving region ID.

[0258] Aspect 14. The apparatus according to any one of Aspects 9 to 12, wherein the sidelink information includes one or more sidelink control information (SCI) reserved bits indicating the receiving region ID.

[0259] Aspect 15. The apparatus according to aspect 14, wherein the side link information further includes one or more SCI reserved bits indicating the sending region ID.

[0260] Aspect 16. The apparatus according to any one of Aspects 1 to 15, wherein: the sidelink information includes sidelink control information (SCI) information included in the transmission of the physical sidelink control channel (PSCCH); and the multicast message includes vehicle-to-everything (V2X) messages included in the transmission of the physical sidelink shared channel (PSSCH).

[0261] Aspect 17. The apparatus according to any one of Aspects 1 to 16, wherein the UE is a vehicle-to-everything (V2X) UE, and wherein the multicast message is a V2X multicast message between the V2X UE and one or more receiving candidate UEs located within the receiving area.

[0262] Aspect 18. The apparatus according to aspect 17, wherein the range information indicates a basic direction or angular range relative to the current direction of movement of the V2X UE.

[0263] Aspect 19. The apparatus according to any one of Aspects 17 or 18, wherein the receiving area is located before or after the current direction of movement of the V2X UE.

[0264] Aspect 20. The apparatus according to any one of aspects 1 to 19, wherein: the geographic region is included in a plurality of geographic regions associated with the region indication type; and based on the region indication type, one or more of the shapes or geometric dimensions of each of the plurality of geographic regions are identical.

[0265] Aspect 21. The apparatus according to aspect 20, wherein each corresponding geographical region corresponds to one or more of a road lane, a portion of a road lane, or a direction of travel within a road lane.

[0266] Aspect 22. The apparatus according to aspect 20, wherein each corresponding geographical region corresponds to a different level of a multi-story parking lot or a different level of a multi-story road.

[0267] Aspect 23. An apparatus for a first user equipment (UE) for wireless communication, the apparatus comprising: at least one memory; and at least one processor coupled to the at least one memory, wherein the at least one processor is configured to: receive sidelink information indicating range information and a region identifier (ID) corresponding to a current location of a second UE, wherein the current location of the second UE is within a geographic region corresponding to the region ID, and wherein the region ID is included in a plurality of region IDs of a specific region indication type; determine a reception area including a portion of the geographic region corresponding to the region ID, wherein the reception area is determined based on direction information or angle information included in the range information; and decode a multicast message received corresponding to the sidelink information, wherein the multicast message is decoded based on the current location of the first UE within the reception area.

[0268] Aspect 24. The apparatus according to aspect 23, wherein the sidelink information is configured to cause one or more candidate UEs located in the receiving area to decode the multicast message, the first UE being included in the one or more candidate UEs.

[0269] Aspect 25. The apparatus according to any one of Aspects 23 or 24, wherein the at least one processor is further configured to: send a Hybrid Automatic Repeat Request (HARQ) Negative Acknowledgment (NACK) corresponding to the multicast message, wherein the HARQ NACK indicates that the first UE has failed to decode the multicast message.

[0270] Aspect 26. The apparatus according to any one of Aspects 23 to 25, wherein the sidelink information includes: a source layer 2 (L2) ID indicating one or more of the following: the region ID or the region indication type associated with the multicast message; and a destination L2 ID indicating the range information.

[0271] Aspect 27. The apparatus according to aspect 26, wherein the side link information includes: a first destination L2 ID indicating direction or angle information corresponding to a first receiving area within the geographic region; and a second destination L2 ID indicating direction or angle information corresponding to a second receiving area within the geographic region, the first receiving area being different from the second receiving area.

[0272] Aspect 28. The apparatus according to aspect 26, wherein the sidelink information includes: a first destination L2 ID indicating a first range of altitude values ​​corresponding to a first receiving area within the geographic region; and a second destination L2 ID indicating a second range of altitude values ​​corresponding to a second receiving area within the geographic region, the first receiving area being different from the second receiving area.

[0273] Aspect 29. The apparatus according to any one of Aspects 26 to 28, wherein the source L2 ID further indicates one or more of the direction information or the altitude information of the geographic region.

[0274] Aspect 30. The apparatus according to any one of Aspects 23 to 29, wherein the geographical region includes a sending region for the multicast message for the UE, and wherein the region ID includes a sending region ID corresponding to the sending region.

[0275] Aspect 31. The apparatus according to aspect 30, wherein the range information is based on a receiving region ID corresponding to the receiving region for the multicast message.

[0276] Aspect 32. The apparatus according to aspect 31, wherein the receiving region includes an intersection region between the receiving region and the sending region for the multicast message.

[0277] Aspect 33. The apparatus according to any one of Aspects 31 or 32, wherein: the receiving region is included in a plurality of configured receiving regions; and the transmitting region is included in a plurality of configured transmitting regions.

[0278] Aspect 34. The apparatus according to aspect 33, wherein the receiving region of the plurality of configurations and the transmitting region of the plurality of configurations are the same.

[0279] Aspect 35. The apparatus according to any one of Aspects 31 to 34, wherein the side link information includes one or more Layer 2 (L2) IDs indicating the receiving region ID.

[0280] Aspect 36. The apparatus according to any one of Aspects 31 to 35, wherein the sidelink information includes one or more sidelink control information (SCI) reserved bits indicating the receiving region ID.

[0281] Aspect 37. The apparatus according to aspect 36, wherein the side link information further includes one or more SCI reserved bits indicating the sending region ID.

[0282] Aspect 38. The apparatus according to any one of Aspects 23 to 37, wherein: the sidelink information includes sidelink control information (SCI) information included in the transmission of the physical sidelink control channel (PSCCH); and the multicast message includes vehicle-to-everything (V2X) messages included in the transmission of the physical sidelink shared channel (PSSCH).

[0283] Aspect 39. The apparatus according to any one of Aspects 23 to 38, wherein the first UE is a UE with vehicle-to-everything (V2X) capability, and the second UE is a V2X UE, and wherein the multicast message is a V2X multicast message between the V2X UE and the V2X-capable UE.

[0284] Aspect 40. The apparatus according to aspect 39, wherein the range information indicates a basic direction or angle range relative to the current direction of movement of the V2X UE.

[0285] Aspect 41. The apparatus according to any one of Aspects 39 or 40, wherein the receiving area is located before or after the current direction of movement of the V2X UE.

[0286] Aspect 42. The apparatus according to any one of Aspects 23 to 41, wherein: the geographic region is included in a plurality of geographic regions associated with the region indication type; and based on the region indication type, one or more of the shapes or geometric dimensions of each of the plurality of geographic regions are identical.

[0287] Aspect 43. The apparatus according to aspect 42, wherein each corresponding geographical region corresponds to one or more of a road lane, a portion of a road lane, or a direction of travel within a road lane.

[0288] Aspect 44. The apparatus according to aspect 42, wherein each corresponding geographical region corresponds to a different level of a multi-story parking lot or a different level of a multi-story road.

[0289] Aspect 45. A method for wireless communication performed at a UE, the method comprising the operation according to any one of aspects 1 to 22.

[0290] Aspect 46. A non-transitory computer-readable storage medium comprising instructions stored thereon, the instructions causing the at least one processor, when executed by at least one processor, to perform any one of aspects 1 to 22.

[0291] Aspect 47. An apparatus for wireless communication, the apparatus comprising one or more components for performing operations according to any one of aspects 1 to 22.

[0292] Aspect 48. A method of wireless communication performed at a UE, the method comprising operations according to any one of aspects 23 to 44.

[0293] Aspect 49. A non-transitory computer-readable storage medium comprising instructions stored thereon, the instructions causing the at least one processor, when executed by at least one processor, to perform any one of aspects 23 to 44.

[0294] Aspect 50. An apparatus for wireless communication, the apparatus comprising one or more components for performing operations according to any one of aspects 23 to 44.

Claims

1. An apparatus for a user equipment (UE) for wireless communication, the apparatus comprising: At least one memory; and At least one processor, said at least one processor being coupled to said at least one memory, said at least one processor being configured to: Determine the region indication type of the multicast message of the UE, wherein the region indication type is included in a variety of configured region indication types; Determine the region identifier (ID) of the current location of the UE, wherein the current location of the UE is within a geographic region corresponding to the region ID, and wherein the region ID is selected from a plurality of region IDs of the region indication type; Determine the range information of the multicast message, wherein the range information indicates the receiving area within the geographical region corresponding to the region ID; Send sidelink information indicating the region ID and the range information; and Send the multicast message.

2. The apparatus of claim 1, wherein the sidelink information is configured to enable one or more candidate UEs located in the receiving area to decode the multicast message.

3. The apparatus of claim 1, wherein the at least one processor is further configured to: Receive a Hybrid Automatic Repeat Request (HARQ) Negative Acknowledgment (NACK) corresponding to the multicast message, wherein the HARQ NACK indicates that the candidate UE located in the receiving area failed to decode the multicast message.

4. The apparatus of claim 1, wherein the side link information includes: Indicates one or more of the following source layer 2 (L2) IDs: the region ID or the region indication type associated with the multicast message; as well as The destination L2 ID that indicates the range information.

5. The apparatus of claim 4, wherein the side link information includes: A first destination L2ID indicating direction or angle information corresponding to a first receiving area within the geographical region; as well as A second destination L2ID indicating direction or angle information corresponding to a second receiving area within the geographic region, wherein the first receiving area is different from the second receiving area.

6. The apparatus of claim 4, wherein the side link information includes: A first destination L2ID indicating a first range of altitude values ​​corresponding to a first receiving area within the geographic region; as well as A second destination L2ID indicating a second range of altitude values ​​corresponding to a second receiving area within the geographic region, wherein the first receiving area is different from the second receiving area.

7. The apparatus of claim 4, wherein the source L2 ID further indicates one or more of the direction information or the altitude information of the geographic region.

8. The apparatus of claim 1, wherein the geographical region includes the sending region of the multicast message for the UE, and wherein the region ID includes a sending region ID corresponding to the sending region.

9. The apparatus of claim 8, wherein, in order to determine the range information of the multicast message, the at least one processor is configured to: Determine the receiving region ID corresponding to the receiving region used for the multicast message.

10. The apparatus of claim 9, wherein the receiving region includes the intersection region between the receiving region and the sending region for the multicast message.

11. The apparatus of claim 9, wherein the at least one processor is configured to: Determine the receiving region from multiple configured receiving regions; and The sending region is determined from a plurality of configured sending regions.

12. The apparatus of claim 11, wherein the receiving region of the plurality of configurations and the transmitting region of the plurality of configurations are the same.

13. The apparatus of claim 9, wherein the sidelink information includes one or more Layer 2 (L2) IDs indicating the receiving region ID.

14. The apparatus of claim 9, wherein the sidelink information includes one or more sidelink control information (SCI) reserved bits indicating the receiving region ID.

15. The apparatus of claim 14, wherein the sidelink information further includes one or more SCI reserved bits indicating the sending region ID.

16. The apparatus according to claim 1, wherein: The sidelink information includes the sidelink control information (SCI) included in the Physical Sidelink Control Channel (PSCCH) transmission; and The multicast messages include vehicle-to-everything (V2X) messages included in the Physical Side Link Shared Channel (PSSCH) transmission.

17. The apparatus of claim 1, wherein the UE is a vehicle-to-everything (V2X) UE, and wherein the multicast message is a V2X multicast message between the V2X UE and one or more receiving candidate UEs located within the receiving area.

18. The apparatus of claim 17, wherein the range information indicates: The basic direction or angle range relative to the current movement direction of the V2X UE.

19. The apparatus of claim 17, wherein the receiving area is located before or after the current direction of movement of the V2X UE.

20. The apparatus according to claim 1, wherein: The geographic region is included in a plurality of geographic regions associated with the region indication type; and Based on the region indication type, one or more of the shapes or geometric dimensions of each of the plurality of geographic regions are the same.

21. The apparatus of claim 20, wherein each corresponding geographical region corresponds to one or more of a road lane, a portion of a road lane, or a direction of travel within a road lane.

22. The apparatus of claim 20, wherein each corresponding geographical region corresponds to a different level of a multi-story parking lot or a different level of a multi-story road.

23. An apparatus for a first user equipment (UE) for wireless communication, the apparatus comprising: At least one memory; and At least one processor, said at least one processor being coupled to said at least one memory, said at least one processor being configured to: Receive sidelink information indicating range information and region identifier (ID) corresponding to the current location of the second UE, wherein the current location of the second UE is within a geographic region corresponding to the region ID, and wherein the region ID is included in a plurality of region IDs of a specific region indication type; Determine a receiving area that includes a portion of the geographic region corresponding to the region ID, wherein the receiving area is determined based on the direction or angle information included in the range information; as well as The multicast message received corresponding to the side link information is decoded, wherein the multicast message is decoded based on the current location of the first UE within the receiving area.

24. The apparatus of claim 23, wherein the sidelink information is configured to enable one or more candidate UEs located in the receiving area to decode the multicast message, the first UE being included among the one or more candidate UEs.

25. The apparatus of claim 23, wherein the at least one processor is further configured to: Send a Hybrid Automatic Repeat Request (HARQ) Negative Acknowledgment (NACK) corresponding to the multicast message, wherein the HARQ NACK indicates that the first UE failed to decode the multicast message.

26. The apparatus of claim 23, wherein the side link information includes: Indicates one or more of the following source layer 2 (L2) IDs: the region ID or the region indication type associated with the multicast message; as well as The destination L2 ID that indicates the range information.

27. The apparatus of claim 26, wherein the side link information includes: A first destination L2ID indicating direction or angle information corresponding to a first receiving area within the geographical region; as well as A second destination L2ID indicating direction or angle information corresponding to a second receiving area within the geographic region, wherein the first receiving area is different from the second receiving area.

28. The apparatus of claim 26, wherein the side link information includes: A first destination L2ID indicating a first range of altitude values ​​corresponding to a first receiving area within the geographic region; as well as A second destination L2ID indicating a second range of altitude values ​​corresponding to a second receiving area within the geographic region, wherein the first receiving area is different from the second receiving area.

29. The apparatus of claim 26, wherein the source L2 ID further indicates one or more of the direction information or the altitude information of the geographic region.

30. The apparatus of claim 23, wherein the geographical region includes the sending region of the multicast message for the UE, and wherein the region ID includes a sending region ID corresponding to the sending region.

Images