Virtual traffic lamp via c-v2x

Abstract

Techniques are provided for traffic intersection control information to a vehicle via a V2X communication link. An example method for providing traffic intersection control messages includes receiving vehicle information associated with a plurality of neighboring vehicles, generating one or more groups of vehicles based on the vehicle information, generating a traffic control plan based at least in part on the one or more groups of vehicles, and transmitting one or more traffic intersection control messages to one or more of the plurality of neighboring vehicles based at least in part on the traffic control plan.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. patent application No. 17 / 948,472, filed on September 20, 2022, entitled “Virtual Traffic Lights via C-V2X,” which is assigned to the assignee of this application and is incorporated herein by reference in its entirety for all purposes. Background Art

[0002] The following relates generally to wireless communications, and more particularly to providing traffic intersection control instructions to vehicles via a vehicle-to-everything (V2X) communication link.

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

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

[0005] An example method for providing traffic intersection control messages according to the present disclosure includes: receiving vehicle information associated with multiple adjacent vehicles, generating one or more vehicle groups based on the vehicle information, generating a traffic control plan based at least in part on the one or more vehicle groups, and sending one or more traffic intersection control messages to one or more of the multiple adjacent vehicles based at least in part on the traffic control plan.

[0006] Implementations of this method may include one or more of the following features. Vehicle information may include basic safety messages sent by one or more of a plurality of neighboring vehicles. One or more vehicle groups may be based on the location of the vehicle, the number of vehicles in the neighborhood, the density of traffic flowing in one direction, the configuration of the intersection, the size associated with the vehicle, the priority value associated with one or more vehicles, or any combination thereof. Receiving vehicle information may include receiving vehicle group information from a network resource. The traffic control plan may be based at least in part on the time of day, the date, the current density of traffic, the configuration of the turning lane, or any combination thereof. Sending one or more traffic intersection control messages may include unicasting a control message including forward information to one or more of a plurality of neighboring vehicles. Sending one or more traffic intersection control messages may include multicasting a vehicle control message including a list of vehicle identification values. One or more traffic intersection control messages may be sent via a PC5 interface, a Uu interface, and / or a device-to-device protocol.

[0007] An example method for receiving traffic intersection control messages according to the present disclosure includes sending one or more basic safety messages, receiving one or more traffic intersection control messages including forward information, and providing instructions to proceed or stop proceeding through a traffic intersection based at least in part on the one or more traffic intersection control messages.

[0008] Implementations of this method may include one or more of the following features. Vehicle priority information may be sent to one or more neighboring stations. Receiving one or more traffic intersection control messages may include receiving a unicast message including forward information. Receiving one or more traffic intersection control messages may include receiving a multicast message including a list of vehicle identification values. Providing an instruction to proceed or stop proceeding through an intersection may include providing instructions to a controller in an autonomous or semi-autonomous vehicle. Providing an instruction to proceed or stop proceeding through an intersection may include activating a driver alert device. One or more traffic intersection control messages may be received via a PC5 interface, a Uu interface, and / or a device-to-device protocol.

[0009] The items and / or technologies described herein may provide one or more of the following capabilities, as well as other capabilities not mentioned. A vehicle approaching or located in a congested traffic area (such as an intersection) may provide a basic safety message (BSM) to one or more adjacent roadside units (RSUs). The RSU may be configured to determine a vehicle group based at least in part on the BSM. The vehicle group may be evaluated in view of a traffic control plan, and the group may be prioritized for advancement through a traffic intersection. Traffic intersection control messages may be unicast or multicast to the vehicles, and the vehicles may advance or stop at the intersection as a group. The likelihood of vehicle congestion and collisions at the intersection may be reduced. Other capabilities may be provided, and not all, let alone all, of the capabilities discussed must be provided in accordance with every embodiment of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0011] Figure 2 yes Figure 1 A block diagram of components of an example user device is shown.

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

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

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

[0015] Figure 6A-6B A diagram of a first example use case for providing traffic intersection control information to multiple vehicles is included.

[0016] Figure 7 is a diagram of a second example use case for providing traffic intersection control information to multiple vehicles.

[0017] Figure 8 is an example message flow that provides traffic intersection control information.

[0018] Fig.9A and 9B is an Abstract System Notation (ASN) representation of an example Traffic Intersection Control (TIC) message.

[0019] Fig.10 is a process flow message of an example method for generating vehicle groups for a traffic intersection control (TIC) message.

[0020] Fig.11 is a process flow message of an example method for providing traffic intersection control messages.

[0021] Fig.12 is a process flow of an example method for receiving a traffic intersection control message. DETAILED DESCRIPTION

[0022] This article discusses techniques for providing traffic intersection control information to vehicles via V2X communication links. V2X, including cellular V2X (C-V2X) technology, enables radio frequency (RF) communications between vehicles and other wireless nodes, such as other vehicles, roadside units (RSUs), vulnerable road users (VRUs), and cellular networks. In addition to supporting safety applications, C-V2X technology and particularly NR C-V2X can be used for advanced use cases such as cooperative driving and platooning. C-V2X communications can also be used in smart road management applications to alleviate road congestion by enabling efficient road use. For example, C-V2X communications can be used to improve traffic flow at unmanaged traffic intersections / merges, and / or when traffic lights become inoperable (e.g., when a traffic light is damaged at a major intersection due to maintenance or power / traffic light failure). Such scenarios can lead to unnecessary traffic accumulation, especially during rush hour, where the general guidance is for each vehicle to stop at the intersection and then proceed. This "stop and go" procedure is generally not an efficient way to manage traffic flow, as one direction of traffic may be increased more than the other direction due to the slow movement of vehicles (since each vehicle must stop and go). This inefficiency may lead to unnecessary traffic backlogs and corresponding frustration of vehicle operators.

[0023] The technology discussed herein provides that vehicles near a traffic intersection may be configured to periodically broadcast a Basic Safety Message (BSM). The RSU may be configured to decode the BSM and intelligently estimate different parameters such as the direction of travel, the time taken to reach the traffic intersection, and the number of vehicles passing through the traffic intersection based on the information included in different BSMs. The RSU may be configured to estimate a dynamic traffic map and then unicast a Traffic Intersection Control (TIC) message instructing the vehicle to proceed or not proceed (i.e., stop) at the traffic intersection. The RSU may be configured to broadcast / multicast a TIC message with a list of temporary IDs included in the received BSM to indicate which vehicles may proceed through the traffic intersection or stop at the traffic intersection.

[0024] In an example, an RSU located near an intersection may receive V2X messages such as basic safety messages (BSM) and / or dedicated short range communication (DSRC) messages from vehicles at the intersection. The message may include information elements such as the current location (e.g., latitude, longitude, altitude, location accuracy) and other status information associated with the vehicle (e.g., transmission and speed, heading, braking system status, etc.). The RSU may be configured to utilize multicast technology to identify a group of vehicles that are advancing through the intersection in one cycle, and then identify other groups of vehicles that are advancing through the intersection in another cycle (e.g., instead of just one vehicle advancing in a standard "stop and go" method). The RSU may also utilize a V2N link such as Uu and an edge server to provide group and priority information to vehicles that do not have PC5 capabilities. The RSU may also be configured to increase the priority of special vehicles such as emergency vehicles, school buses, funeral drills, etc. to achieve accelerated travel through the intersection. Other messaging techniques and configurations may also be used.

[0025] Obtaining the location of a mobile device accessing a wireless network can be used for many applications, including, for example, emergency calling, personal navigation, consumer asset tracking, locating friends or family members, etc. Existing positioning methods include methods based on measuring radio signals transmitted from various devices or entities, including satellite vehicles (SVs) and terrestrial radio sources in wireless networks such as base stations and access points. It is expected that the standardization of 5G wireless networks will include support for various positioning methods that can utilize reference signals transmitted by base stations in a manner similar to how LTE wireless networks currently utilize positioning reference signals (PRS) and / or cell-specific reference signals (CRS) for position determination.

[0026] The description may refer to a sequence of actions performed, for example, by elements of a computing device. The various actions described herein may be performed by specific circuits (e.g., application specific integrated circuits (ASICs)), by program instructions being executed by one or more processors, or by a combination of both. The sequence of actions described herein may be embodied in a non-transitory computer-readable medium having a corresponding set of computer instructions stored thereon that, when executed, will cause an associated processor to perform the functions described herein. Thus, the various aspects described herein may be embodied in a variety of different forms, all of which are within the scope of the present disclosure, including the claimed subject matter.

[0027] As used herein, unless otherwise specified, the terms "user equipment" (UE) and "base station" are not specific to or otherwise limited to any particular radio access technology (RAT). In general, such UEs may be any wireless communication device (e.g., mobile phones, routers, tablet computers, laptop computers, consumer asset tracking devices, Internet of Things (IoT) devices, onboard units (OBUs), etc.) used by users to communicate on a wireless communication network. UEs may be mobile or may be stationary (e.g., at certain times) and may communicate with a radio access network (RAN). As used herein, the term "UE" may be interchangeably referred to as an "access terminal" or "AT," "client device," "wireless device," "subscriber equipment," "subscriber terminal," "subscriber station," "user terminal" or UT, "mobile terminal," "mobile station," "mobile device," or variations thereof. A UE disposed in a vehicle may be referred to as an onboard unit (OBU). Typically, a UE may communicate with a core network via a RAN, and through the core network, the UE may be connected 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 a wired access network, a WiFi network (eg, based on IEEE (Institute of Electrical and Electronics Engineers) 802.11, etc.), and the like.

[0028] A base station may operate according to one of several RATs for communicating with a UE, depending on the network in which it is deployed. Examples of base stations include access points (APs), network nodes, Node Bs, evolved Node Bs (eNBs), or generalized Node Bs (gNodeBs, gNBs). Additionally, in some systems, a base station may provide pure edge node signaling functionality, while in other systems it may provide additional control and / or network management functionality.

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

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

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

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

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

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

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

[0036] The UE 105 or other device may be configured to communicate in various networks and / or for various purposes and / or using various technologies (e.g., 5G, Wi-Fi communications, Wi-Fi communications at multiple frequencies, satellite positioning, one or more types of communications (e.g., GSM (Global System for Mobile Communications), CDMA (Code Division Multiple Access), LTE (Long Term Evolution), V2X (Vehicle to Everything, e.g., V2P (Vehicle to Pedestrian), V2I (Vehicle to Infrastructure), V2V (Vehicle to Vehicle), etc.), IEEE 802.11p, etc.). V2X communications may be cellular (Cellular-V2X (C-V2X)) and / or WiFi (e.g., DSRC (Dedicated Short Range Connection)). A multi-carrier transmitter may transmit modulated signals simultaneously on multiple carriers. Each modulated signal may be transmitted on a different carrier and may carry a pilot, overhead information, data, etc. The UEs 105, 106 may communicate with each other via UE-to-UE sidelink (SL) communications by transmitting on one or more sidelink channels, such as a physical sidelink synchronization channel (PSSCH), a physical sidelink broadcast channel (PSBCH), or a physical sidelink control channel (PSCCH).

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

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

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

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

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

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

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

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

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

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

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

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

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

[0050] Using the UE-based positioning method, UE 105 can obtain position measurements (e.g., which can be the same or similar to position measurements used for UE-assisted positioning methods) and the position of UE 105 can be calculated (e.g., with the aid of assistance data received from a location server such as LMF 120 or broadcast by gNB 110a, 110b, ng-eNB 114 or other base stations or APs).

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

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

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

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

[0055] As noted, in some embodiments, the positioning functionality may at least in part utilize a UE (e.g., Figure 1 This may be accomplished by using directional SS or PRS beams transmitted by base stations (such as gNBs 110a, 110b, and / or ng-eNB 114) within range of the UE 105. In some cases, the UE may calculate the position of the UE using directional SS or PRS beams from multiple base stations (e.g., gNBs 110a, 110b, ng-eNB 114, etc.).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0072] Also refer to Figure 4 , the server 400 (LMF 120 is an example thereof) includes a computing platform including a processor 410, a memory 411 including software (SW) 412, and a transceiver 415. The processor 410, the memory 411, and the transceiver 415 may be communicatively coupled to each other via a bus 420 (which may be configured for, for example, optical and / or electrical communication). One or more of the illustrated devices (e.g., a wireless transceiver) may be omitted from the server 400. The processor 410 may include one or more intelligent hardware devices, such as a central processing unit (CPU), a microcontroller, an application specific integrated circuit (ASIC), etc. The processor 410 may include a plurality of processors (e.g., including, for example, Figure 2 The memory 411 stores software 412, which may be processor-readable, processor-executable software code containing instructions configured to cause the processor 410 to perform various functions described herein when executed. Alternatively, the software 412 may not be directly executed by the processor 410, but may be configured to cause the processor 410 (e.g., when compiled and executed) to perform functions. The description may refer to the processor 410 performing functions, but this includes other implementations, such as the case where the processor 410 executes software and / or firmware. The description may refer to the processor 410 performing functions as a shorthand for including one or more processors in the processor 410 performing the functions. The description may refer to the server 400 performing functions as a shorthand for one or more appropriate components of the server 400 performing the functions. In addition to and / or in place of the memory 411, the processor 410 may include a memory with stored instructions. The functionality of the processor 410 is discussed more fully below.

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

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

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

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

[0077] UEs can use a satellite positioning system (SPS) (Global Navigation Satellite System (GNSS)) for high-precision positioning using Precise Point Positioning (PPP) or Real-Time Kinematic (RTK) techniques. These techniques use assistance data such as measurements from ground stations. LTE Release 15 allows the data to be encrypted so that UEs that specifically subscribe to the service can read the information. This assistance data changes over time. Therefore, a UE subscribed to the service may not easily "break encryption for other UEs" by passing the data to other UEs that have not paid for the subscription. Every time the assistance data changes, it will need to be repeated.

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

[0079] In conventional UE-based positioning, the UE calculates its own position, avoiding sending measurements to the network (e.g., a location server), which in turn improves latency and scalability. The UE uses the relevant BSA record information from the network (e.g., the location of the gNB (more broadly, the base station)). The BSA information can be encrypted. But because the BSA information changes much less than, for example, the PPP or RTK assistance data described previously, it may be easier to make the BSA information available (compared to PPP or RTK information) to UEs that do not subscribe and pay for decryption keys. The transmission of reference signals by the gNB makes the BSA information potentially available for crowdsourcing or access point mapping (WarDriving), essentially enabling the generation of BSA information based on on-site and / or overhead observations.

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

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

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

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

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

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

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

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

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

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

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

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

[0092] Multiple frequency layers of PRS can be aggregated to provide an effective bandwidth greater than any bandwidth of the individual layers. Multiple frequency layers of component carriers (which can be contiguous and / or separate) can be spliced ​​and meet criteria such as quasi-co-location (QCLed) and having the same antenna port to provide a larger effective PRS bandwidth (for DL ​​PRS and UL PRS), thereby increasing arrival time measurement accuracy. Splicing includes combining PRS measurements on various bandwidth fragments into a unified fragment so that the spliced ​​PRS can be regarded as being obtained from a single measurement. When QCL is used, different frequency layers behave similarly, enabling the splicing of PRS to produce a larger effective bandwidth. The larger effective bandwidth (which can be referred to as the bandwidth of the aggregated PRS or the frequency bandwidth of the aggregated PRS) provides better time domain resolution (e.g., the time domain resolution of TDOA). The aggregated PRS contains a set of PRS resources, and each PRS resource of the aggregated PRS can be referred to as a PRS component, and each PRS component can be sent on different component carriers, frequency bands or frequency layers or on different parts of the same frequency band.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0109] refer to Figure 6A-6B, diagrams showing a first example use case for providing traffic intersection control information. The diagrams include an intersection 600 having at least one traffic light 608, which may be experiencing a system failure and may be inoperable. The intersection 600 includes an RSU 602, which is configured to communicate with entities near the intersection 600, such as multiple vehicles, traffic lights 608, other signal devices, and sensors / detectors (e.g., vehicle detection devices, pedestrian crossing signals, etc.). The RSU 602 may be communicatively coupled to a server 606 via a network 604. The server 606 may be configured for multi-access edge computing (MEC). The network 604 may include a WAN and / or the Internet. The intersection 600 may also include one or more cameras 614, which are configured to capture images of vehicles at the intersection 600 and provide image information to the RSU 602, the network 604, and / or the server 606. The intersection 600 may be within the coverage area of ​​one or more cellular base stations (such as base station 616). Base station 616 may be communicatively coupled to RSU 602 and / or server 606 via network 604. Entities located at intersection 600 may be configured to utilize V2X communication technologies, such as WiFi, PC5, and Uu interfaces. Figure 6A-6B The first use case in describes a scenario where multiple vehicles are approaching or stopped at an inoperable traffic light.

[0110] In a first use case, a traffic intersection 600 includes an inoperative traffic light 608. Rush hour traffic is westbound and there is also traffic accumulation from the south to north direction. Rather than utilizing the standard stop-and-go process common at an inoperative traffic light, the C-V2X equipped vehicles and RSUs 602 at the intersection 600 are configured to negotiate and form one or more groups of vehicles so that one group can travel at a time, simulating a virtual traffic light. The groups can be based on clearance factors such as the number of vehicles in a neighborhood (e.g., 10m, 20m, 50m, 100m, etc.), the density of traffic flowing in one direction, the speed of the vehicle, the classification of the vehicle, the configuration of the intersection 600 (e.g., turn lanes, merge lanes), platoon information, and vehicle or group priority information (e.g., emergency vehicles, funeral first, motorcade, etc.).

[0111] In operation, refer to Figure 6B, vehicles approaching the intersection 600 may send BSMs to neighboring vehicles and / or RSU 602. RSU 602 or server 606 may be configured to utilize BSM information to group vehicles approaching the intersection 600 based on clearance factors. For example, a first group 652 may be based on westbound vehicles having reported locations (i.e., included in their respective BSMs) within a predetermined range of each other and / or a distance to the intersection 600 (e.g., 10m, 50m, 100m, etc.). A second group 654 may be based on eastbound vehicles having reported locations within a predetermined range of each other and / or the intersection. A third group 656 may be based on northbound vehicles, and a fourth group 658 may be based on southbound vehicles. A fifth group 660 may be based on westbound vehicles in a left turn lane (e.g., preparing to turn left at the intersection 600). Groups 652, 654, 656, 658, 660 are examples and not limitations, as other clearance factors may be used to organize groups. For example, traffic density of vehicles traveling in the same direction may be used to form groups and / or determine group size. Groups may be based on vehicle classifications, such that passenger cars may belong to one group and commercial vehicles may belong to another group.

[0112] Groups 652, 654, 656, 658, 660 may be based on information provided by other network resources. For example, other RSUs or network resources connected to network 604 may be configured to identify / generate vehicle groups and provide group information to RSU 602 or server 606. The cellular network including base station 616 may be configured to utilize mobility and other positioning services to determine that vehicles are traveling within a predetermined range of each other. Optical sensors (such as camera 614) may be configured to identify vehicle groups. Other RSUs (e.g., from previous intersections, toll booths, etc.) may be configured to provide vehicle group information to RSU 602. Vehicle group information may include an array of vehicle identification and other fields provided in a BSM or other message sent by the vehicle.

[0113] The RSU 602 may be configured to assign a priority to each group so that each vehicle in the group will be instructed to cross the intersection within the same time period. For example, all vehicles in the first group 652 may be directed to continue through the intersection 600, just as the traffic light 608 would indicate a green light. Similar instructions are provided to other groups to facilitate organized and grouped movement through the intersection. The RSU 602 may be configured to broadcast or unicast instruction messages to the corresponding vehicles in the group. For example, an application layer specification (e.g., SAE / ESTI / C-SAE) may include a traffic intersection control information message that indicates whether the receiving vehicle should proceed (e.g., green light) or not proceed (e.g., red light) through the intersection 600. For vehicles with C-V2X functionality, traffic intersection control information may be provided from the RSU 602 via a PC5 interface. Other protocols and radio access technologies may be used. In one example, a V2N-enabled vehicle may receive traffic intersection control information from a base station 616 via a Uu interface.

[0114] refer to Figure 7 , a diagram of a second example use case for providing traffic intersection control information to multiple vehicles is shown. The intersection 700 may not have additional infrastructure, such as traffic lights or RSUs. Vehicles may form a local network based on proximity, and vehicle groups may be based on the local network. For example, V2X platooning operations may be the basis for group formation. Different groups may be configured to communicate with each other to exchange traffic intersection control information. A first group 702 may be traveling southbound toward the intersection 700, and a second group 704 may be traveling westbound toward the intersection 700. One or more vehicles in the first group 702 (e.g., a leading vehicle) may be configured to exchange traffic intersection control information with one or more vehicles in the second group 704 via a first wireless link 708. A third group 706 may be traveling northbound toward the intersection 700, and may be configured to communicate with the second group 704 via a second wireless link 710. The wireless links 708, 710 may be based on a PC5 interface or other D2D protocols such as an NR side link. Other radio access technologies may also be used. The groups and communication links are examples and not limitations, as other groups and links may also be used to exchange traffic intersection control information. In operation, vehicles in a group may be configured to provide traffic intersection control information to other vehicles via unicast or multicast messages. Vehicles may be configured to negotiate right of way based on previously established clearance factors or other rule engines. For example, a first-in, first-out scheme may be used to give groups priority at intersections. In high traffic density use cases, subgroups may be created such that a portion of a group is given priority (e.g., green light) while other subgroups are provided with pause instructions (e.g., red light). Other grouping options may also be used.

[0115] refer to Figure 8, shows an example message flow 800 for providing traffic intersection information. The message flow 800 includes a plurality of vehicles having OBUs and RSUs 808. The OBUs include a first OBU 802, a second OBU 804, and a third OBU 806. In the example, reference Figure 6A-6B , OBU 802, 804, 806 are examples of OBUs included in three vehicles approaching intersection 600. RSU 808 can be RSU 602 and is communicatively coupled to network 604. Typically, vehicles near a traffic intersection periodically broadcast BSMs. The RSU can be configured to decode the BSM and intelligently estimate different parameters such as the direction of travel, the time required to reach the traffic intersection, and the number of vehicles passing through the traffic intersection based on the BSMs received from different vehicles. The RSU can be configured to estimate a dynamic traffic map based on a clearance factor and then unicast traffic intersection control information to instruct individual vehicles to proceed or not proceed at the intersection. The RSU can be configured to broadcast traffic intersection information with a list of temporary IDs included in the BSM to indicate which vehicles can proceed through the traffic intersection.

[0116] In operation, in the example, OBUs 802, 804, 806 (and Figure 8 Each of the other OBUs (not shown in FIG. 1 ) is configured to send a BSM 810 to the RSU 808. The BSM 810 may include corresponding vehicle status information, such as location information (e.g., latitude / latitude / accuracy), vehicle heading and speed, brake system status, and vehicle size information. At stage 812, the RSU 808 is configured to determine group information and a traffic control plan based at least in part on the BSM 810. For example, the location information of each vehicle may be used to identify the group, and the density of the vehicles may be used to determine the traffic control plan. Other inputs such as image information from cameras and other networked resources (e.g., other RSU information) may be received by the RSU 808 and used to determine the group information and the traffic control plan. The RSU 808 may be configured to send one or more messages including a traffic intersection control message to one or more OBUs. For example, the RSU 808 may unicast or multicast a traffic intersection control (TIC) message 814 to the OBUs 802, 804, 806 based on the group information and traffic control plan determined at stage 812. In the example, refer to Fig.9A , one or more of the TIC messages 814 may be unicast messages that include a proceed flag field (ie, proceedFlag) indicating whether the receiving vehicle will proceed through the intersection 600. In an example, reference Fig. 9B, one or more of the TIC messages 814 may include a list of identification values ​​(ie, temporaryIDList) associated with vehicles (eg, temporary IDs provided in the BSM) that indicate the vehicles that will proceed through the intersection 600 . Fig. 9B The message in can be multicast to vehicles in the coverage area, and the receiving vehicles can be configured to act on the message based on detecting their respective identities in temporaryIDList. Other signaling techniques can be used to provide traffic intersection control information to the OBU. For example, traffic intersection control information can be received from other vehicles and / or cellular networks (e.g., via the Uu interface).

[0117] The group information and traffic control plan determined at stage 812 may be based on factors such as traffic density at a given time (e.g., rush hour), group length, and group count. The RSU 808 may be configured to dynamically reorganize the group, such as by adding vehicles to the group based on group length and / or group count requirements. In an example, the RSU 808 may coordinate with multiple RSUs so that a vehicle or vehicle group may have a priority traffic flow along a route. For example, an emergency vehicle may be assigned priority so that virtual traffic signals on its intended route are synchronized. In an example, in order to avoid delays caused by the fluctuating start of vehicles in a queue, a predetermined safety distance between vehicles in a group may be assigned, and when an instruction to proceed is provided to the group, all vehicles may begin to move simultaneously (e.g., while maintaining the assigned distance). Multiple groups may be given instructions to proceed simultaneously through a traffic intersection. For example, eastbound and westbound groups with no chance of collision may proceed simultaneously through a traffic intersection. The relative timing of the groups may be used to issue simultaneous advance instructions so that the estimated time at which a group arrives at an intersection may be compared with the time at which the previous group will complete the crossing.

[0118] The RSUs described herein may be stationary or mobile devices. In an example, a traffic management center (TMC) may determine that a traffic signal is malfunctioning and then provide a mobile / portable RSU to the affected intersection. In an example, the RSU may be an unmanned aircraft dispatched to an intersection. The UAV RSU may be configured with a signal indicator (e.g., red, green, turn signal, etc.) and may be used as a replacement traffic light in addition to generating and transmitting TIC messages as described herein.

[0119] refer to Fig.10 , further reference Figures 1 to 9B, a method 1000 for generating a vehicle group for a traffic intersection control (TIC) message includes the stages shown. However, the method 1000 is an example and not a limitation. The method 1000 may be changed, for example, by adding, removing, rearranging, combining, performing stages simultaneously, and / or dividing a single stage into multiple stages. The method 1000 may be performed by an RSU, an MEC server, and / or another vehicle.

[0120] At stage 1002, the method includes connecting with the OBU and forming a coordinated network. In an example, the RSU 808 can be configured to communicate with multiple OBUs (e.g., OBUs 802, 804, 806) in neighboring vehicles. In the coordinated network, the RSU 808 can be configured as a network controller to add or remove wireless nodes (e.g., OBUs, VRUs, etc.) to the local wireless network. The RSU 808 is configured to exchange messages with the OBUs in the network.

[0121] At stage 1004, the method includes receiving vehicle information from a neighboring station. The RSU 808 may be communicatively coupled to the network 604 and other network resources, such as a server 606 and another RSU 602. For example, the RSUs may be located at different intersections or other traffic areas (e.g., toll booths, parking lots, weigh stations, etc.), and the RSUs may be configured to communicate with each other. Cellular network entities (such as base stations and location servers) may also provide vehicle information to the RSUs. The RSU 808 may be configured to receive information associated with a vehicle that is approaching but not yet within the coverage area of ​​the RSU 808.

[0122] At stage 1006, the method includes processing the BSM and associated network information. The RSU 808 may process the BSM 810 and information received from neighboring stations. The RSU 808 may determine vehicle status information (e.g., location, speed, direction, etc.) based on the received BSM 810 and / or information reported by neighboring stations. For example, a neighboring RSU may process the received BSM and forward corresponding status information to the RSU 808. The cellular network may obtain location and movement information associated with the vehicle and provide the status information to the RSU 808.

[0123] At stage 1008, the method includes determining whether the vehicle is approaching an intersection. Figure 6B, the RSU 808 includes map information for the intersection 600 and may utilize the state information obtained at stage 1006 to determine the movement of the vehicle relative to the intersection 600. For a vehicle approaching the intersection 600, at stage 1010, the RSU 808 may be configured to determine whether the vehicle is already associated with a group. The group assignment may be based on BSM information received by the RSU (e.g., assigned by the RSU) or group information assigned by a neighboring RSU or other network entity. For example, another RSU along the route may have already made a group assignment for the vehicle and provided the group information to the RSU 808. In an example, the RSU 808 may have a previously established group based on a vehicle approaching the intersection 600.

[0124] At stage 1012, the method includes determining whether the vehicle can be added to the group. For vehicles that have not yet been assigned to a group, an evaluation can be performed based on the vehicle state and the established clearance factor to determine whether the vehicle can be added to an existing group or a new group can be created. For example, a vehicle in a left turn lane (or a left turn signal is activated) can be assigned to an existing left turn group (e.g., the fifth group 660). Other allocations based on vehicle state can also be made. At stage 1014, the vehicle can be added to an existing group, or at stage 1016, a new group can be created for the vehicle. In an example, when a new group is created at stage 1016, a group priority can also be assigned. Priority can be based on factors such as being an emergency vehicle, a school bus, or being part of a first trip (e.g., a government official, a funeral, etc.). In an example, priority can be based on a subscription service so that a vehicle operator can pay a fee to receive an increased priority for some traffic use cases (e.g., fast pass). The server 606 can include subscription service information.

[0125] At stage 1018, the method includes evaluating the state of the intersection. The RSU 808 may evaluate the position of vehicles in and near the intersection before sending a traffic intersection message. For example, the position information of each vehicle may be used to identify the density of vehicles to evaluate the state of the intersection in view of the traffic control plan. Other inputs such as image information from cameras and other networked resources (e.g., roadside sensors) may be received by the RSU 808 and used to evaluate the state of the intersection and implement the traffic control plan. Typically, the state of the intersection represents the current traffic conditions, and the RSU is configured to generate a traffic intersection message in an effort to improve the current state of the intersection based on the established traffic control plan. For example, a traffic control plan may include prioritizing traffic flow in one direction based on the time of day (e.g., prioritizing rush hour lanes), and the density of traffic flow through the intersection may be evaluated. Other traffic control plans may be based on detecting traffic that is reversing due to a large number of left-turn flows (e.g., vehicles waiting to turn left blocking the through lane), and then providing priority to vehicles in the left-turn group.

[0126] At stage 1020, the method includes sending a traffic intersection control message. In an example, the RSU 808 may be configured to send one or more messages including a traffic intersection control (TIC) message to one or more OBUs in the vehicle. The RSU 808 may be configured to unicast or multicast the TIC message 814 based on the group information and intersection status determined at stage 1018. In an example, reference Fig.9A , one or more of the TIC messages 814 may be unicast messages that include a proceed flag field (ie, proceedFlag) indicating whether the receiving vehicle will proceed through the intersection. In an example, reference Fig. 9B , one or more of the TIC messages 814 may include a list of identification values ​​(ie, temporaryIDList) associated with vehicles (eg, temporary IDs provided in the BSM) indicating vehicles that will proceed through the intersection. Other signaling techniques may be used to provide traffic intersection control information to vehicles.

[0127] refer to Fig.11 , further reference Figures 1 to 10 , a method 1100 for providing a traffic intersection control (TIC) message includes the stages shown. However, the method 1100 is an example and not a limitation. The method 1100 can be changed, for example, by adding, removing, rearranging, combining, performing stages simultaneously, and / or dividing a single stage into multiple stages. The method 1100 can be performed by an RSU, an MEC server, and / or another vehicle.

[0128] At stage 1102, the method includes receiving vehicle information associated with a plurality of neighboring vehicles. RSU 808 (including processor 310 and transceiver 315) is a portion for receiving vehicle information. An OBU (such as a Fig. 6A and 6B ) is configured to send BSM 810, which can be received by RSU 808 (and / or other wireless nodes). BSM 810 may include corresponding vehicle status information, such as location information (e.g., latitude / latitude / accuracy), vehicle heading and speed, brake system status, and vehicle size information. In an example, other network resources such as other RSUs and cellular network resources (e.g., location servers) can be configured to provide vehicle information to RSU 808 via network 604. The vehicle information may include group and priority information.

[0129] At stage 1104, the method includes generating one or more vehicle groups based on the vehicle information. The RSU 808 including the processor 310 is a component for generating one or more vehicle groups. The RSU 808 may be configured to decode the BSM and intelligently estimate different parameters such as the direction of travel, the time required to reach the traffic intersection, and the number of vehicles passing through the traffic intersection based on the BSM received from different vehicles and other vehicle information obtained at stage 1102. In an example, the RSU 808 may be configured to generate one or more vehicle groups based on the method 1000. The position information of each vehicle may be used to identify the group, and the density of the vehicle may be used to determine the traffic control plan. Other inputs such as image information from cameras and other networked resources (e.g., other RSU information) may be received by the RSU 808 and used to determine the group information. One or more vehicle groups may be based on clearance factors such as the number of vehicles in the neighborhood, the density of traffic flowing in one direction, the speed of the vehicle, the classification of the vehicle, the configuration of the intersection (e.g., turning lanes, merging lanes), the size of the vehicle, the formation information, and the vehicle or group priority information (e.g., emergency vehicles, funerals first, convoys, etc.). Other clearance factors associated with likely traffic patterns may also be used to generate vehicle groups.

[0130] At stage 1106, the method includes generating a traffic control plan based at least in part on one or more vehicle groups. The RSU 808, including the processor 310, is a component for generating a traffic control plan. The traffic control plan can be used to establish priorities for groups moving through an intersection. For example, the traffic control plan can include prioritizing traffic flow in one direction based on the time and / or date of the day (e.g., prioritizing rush hour lanes), and can evaluate the current density of traffic flow through the intersection. Other traffic control plans can be based on detecting traffic that is backing up due to a turn lane configuration (e.g., vehicles waiting to turn left are blocking a through lane), and then providing priority to vehicles in a left turn group. The traffic control plan can utilize group priority information to establish a priority for the group. The traffic control plan can be based on other local environmental and traffic characteristics associated with the intersection and implemented to improve traffic flow through the intersection.

[0131] At stage 1108, the method includes sending one or more traffic intersection control messages to one or more neighboring vehicles of the plurality of neighboring vehicles based at least in part on the traffic control plan. The RSU 808, including the processor 310 and the transceiver 315, is a component for sending the one or more TIC messages. In an example, the RSU 808 may be configured to send the one or more TIC messages 814 to the OBU in each of the one or more vehicles via the PC 5 interface. The RSU 808 may be configured to unicast or multicast the TIC message 814 based on the traffic control plan generated at stage 1106. In an example, the reference Fig.9A , one or more of the TIC messages 814 may be unicast messages that include a proceed flag field (ie, proceedFlag) indicating whether the receiving vehicle will proceed through the intersection. In an example, reference Fig. 9B , one or more of the TIC messages 814 may include a list of identification values ​​(i.e., temporaryIDList) associated with vehicles (e.g., temporary IDs provided in the BSM) indicating vehicles that will proceed through the intersection. Other signaling techniques may be used to provide traffic intersection control information to vehicles. For example, the RSU may be configured to utilize other D2D and sidelink technologies to send TIC messages. In an example, the base station 616 may be configured to provide TIC messages via a Uu interface.

[0132] refer to Fig.12 , further reference Figures 1 to 10 , a method 1200 for receiving a traffic intersection control (TIC) message includes the stages shown. However, the method 1200 is an example and not a limitation. The method 1200 may be changed, for example, by adding, removing, rearranging, combining, performing stages simultaneously, and / or dividing a single stage into multiple stages. The method 1200 may be performed by an RSU, an MEC server, and / or another vehicle.

[0133] At stage 1202, the method includes sending one or more basic safety messages. An OBU including a processor 210 and a transceiver 215 is a component for sending one or more BSMs. In an example, an OBU in a vehicle approaching an intersection may be configured to send a BSM, which may be received by an RSU 808 (and / or other wireless nodes). The BSM may include corresponding vehicle status information, such as location information (e.g., latitude / latitude / accuracy), vehicle heading and speed, brake system status, and vehicle size information.

[0134] At stage 1204, the method includes receiving one or more traffic intersection control messages including forwarding information. The OBU including the processor 210 and the transceiver 215 is a component for receiving one or more TIC messages. In an example, the RSU can be configured to send one or more TIC messages via the PC 5 interface. The RSU can be configured to unicast or multicast TIC messages. For example, referring to Fig.9A , one or more of the TIC messages may be unicast messages that include travel information such as a proceed flag field (ie, proceedFlag) indicating whether the receiving vehicle will proceed through the intersection. In an example, reference Fig. 9B , one or more of the TIC messages may include forward information, such as a list of identification values ​​(i.e., temporaryIDList) associated with vehicles (e.g., temporary IDs provided in the BSM) that indicate the vehicles that will continue through the intersection. In the example, reference Figure 7 , other vehicles can be configured to send TIC messages. Other radio access technologies such as D2D, sidelink and cellular protocols (e.g., Uu interface) can be used to receive TIC messages.

[0135] At stage 1206, the method comprises providing the indication of advancing or stopping advancing through the intersection at least based on one or more traffic intersection control messages. The OBU comprising processor 210 is a component for advancing or stopping advancing through the intersection. The OBU can be communicatively coupled to the controller in an autonomous or semi-autonomous vehicle, and can be configured to provide the controller with indication as advancing or stopping instruction based on the advancing information in the TIC. In an operator-assisted vehicle, the OBU can be configured to provide indication by activating the driver warning device based on the advancing information. For example, a head-up display, monitor, audio and / or tactile device can be used for warning the operator to advance the vehicle or stop.

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

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

[0138] In addition, as used herein, "or" used in a list of items (which may begin with "at least one of..." or "one or more of...") indicates a disjunctive list, so that, for example, a list of "at least one of A, B, or C" or a list of "one or more of A, B, or C" or a list of "A or B or C" means A, or B, or C, or AB (A and B), or AC (A and C), or BC (B and C), or ABC (i.e., A and B and C), or a combination of more than one feature (e.g., AA, AAB, ABBC, etc.). Therefore, a statement that an item (e.g., a processor) is configured to perform a function with respect to at least one of A or B, or a statement that an item is configured to perform function A or function B, means that the item can be configured to perform the function with respect to A, or can be configured to perform the function with respect to B, or can be configured to perform the functions with respect to both A and B. For example, the phrase "a processor configured to measure at least one of A or B" or "a processor configured to measure A or measure B" means that the processor may be configured to measure A (and may or may not be configured to measure B), or may be configured to measure B (and may or may not be configured to measure A), or may be configured to measure a and measure B (and may be configured to select which one or both of A and B to measure). Similarly, the recitation of a component for measuring at least one of a or B includes a component for measuring a (which may or may not be able to measure B), or a component for measuring B (and may or may not be configured to measure A), or a component for measuring A and B (which may be able to select which one or both of A and B to measure). As another example, the recitation of an item (e.g., a processor) being configured to perform at least one of function X or to perform function Y means that the item may be configured to perform function X, or may be configured to perform function Y, or may be configured to perform function X and perform function Y. For example, the phrase "a processor configured to measure at least one of X or Y" means that the processor may be configured to measure X (and may or may not be configured to measure Y), or may be configured to measure Y (and may or may not be configured to measure X), or may be configured to measure X and measure Y (and may be configured to select which or both of X and Y to measure).

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

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

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

[0142] A wireless communication system is one in which communications are transmitted wirelessly, i.e., by electromagnetic waves and / or sound waves propagating through atmospheric space rather than through wires or other physical connections. A wireless communication network may not have all communications transmitted wirelessly, but may be configured to have at least some communications transmitted wirelessly. Furthermore, the term "wireless communication device" or similar terms does not require that the functionality of the device is exclusively or even primarily for communications, or that communications using the wireless communication device are exclusively or even primarily wireless, or that the device is a mobile device, but rather indicates that the device includes wireless communication capabilities (one-way or two-way), such as including at least one radio for wireless communication (each radio being part of a transmitter, receiver, or transceiver).

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

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

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

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

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

[0148] Examples of implementations are described in the following numbered clauses:

[0149] Clause 1. A method for providing traffic intersection control messages, comprising: receiving vehicle information associated with a plurality of adjacent vehicles; generating one or more vehicle groups based on the vehicle information; generating a traffic control plan based at least in part on the one or more vehicle groups; and sending one or more traffic intersection control messages to one or more of the plurality of adjacent vehicles based at least in part on the traffic control plan.

[0150] Clause 2. The method of clause 1, wherein the vehicle information comprises a basic safety message sent by one or more of the plurality of neighboring vehicles.

[0151] Clause 3. According to the method of clause 1, the one or more vehicle groups are based on the location of the vehicle, the number of vehicles in the vicinity, the density of traffic flowing in one direction, the configuration of the intersection, the size associated with the vehicle, the priority value associated with one or more vehicles, or any combination thereof.

[0152] Clause 4. The method of clause 1, wherein receiving the vehicle information comprises receiving vehicle group information from a network resource.

[0153] Clause 5. The method of clause 1, wherein the traffic control plan is based at least in part on a time of day, a date, a current density of traffic, a turn lane configuration, or any combination thereof.

[0154] Clause 6. The method of clause 1, wherein sending one or more traffic intersection control messages comprises: unicasting a vehicle control message to one or more vehicles of the plurality of neighboring vehicles, the vehicle control message comprising heading information.

[0155] Clause 7. The method of clause 1, wherein sending one or more traffic intersection control messages comprises multicasting a vehicle control message including a list of vehicle identification values.

[0156] Clause 8. The method of clause 1, wherein the one or more traffic intersection control messages are sent via a PC5 interface.

[0157] Clause 9. The method of clause 1, wherein the one or more traffic intersection control messages are sent via a Uu interface.

[0158] Clause 10. The method of clause 1, wherein the one or more traffic intersection control messages are sent via a device-to-device protocol.

[0159] Clause 11. A method of receiving traffic intersection control messages, comprising: sending one or more basic safety messages; receiving one or more traffic intersection control messages including proceeding information; and providing an instruction to proceed or to stop proceeding through an intersection based at least in part on the one or more traffic intersection control messages.

[0160] Clause 12. The method according to clause 11 further includes sending vehicle priority information.

[0161] Clause 13. The method of clause 11, wherein receiving one or more traffic intersection control messages comprises receiving a unicast message comprising forwarding information.

[0162] Clause 14. The method of clause 11, wherein receiving one or more traffic intersection control messages comprises: receiving a multicast message including a list of vehicle identification values.

[0163] Clause 15. The method of clause 11, wherein providing the instruction to proceed or to stop proceeding through the intersection comprises providing instructions to a controller in the autonomous or semi-autonomous vehicle.

[0164] Clause 16. The method of clause 11, wherein providing the instruction to proceed or to stop proceeding through the intersection includes activating a driver alert device.

[0165] Clause 17. The method of clause 11, wherein the one or more traffic intersection control messages are received via a PC5 interface.

[0166] Clause 18. The method of Clause 1, wherein the one or more traffic intersection control messages are received via a Uu interface.

[0167] Clause 19. The method of clause 1, wherein the one or more traffic intersection control messages are received via a device-to-device protocol.

[0168] Clause 20. A device comprising: a memory; at least one transceiver; at least one processor, which is communicatively coupled to the memory and the at least one transceiver and is configured to: receive vehicle information associated with a plurality of neighboring vehicles; generate one or more vehicle groups based on the vehicle information; generate a traffic control plan based at least in part on the one or more vehicle groups; and send one or more traffic intersection control messages to one or more of the plurality of neighboring vehicles based at least in part on the traffic control plan.

[0169] Clause 21. The apparatus of clause 20, wherein the vehicle information comprises a basic safety message sent by one or more of the plurality of neighboring vehicles.

[0170] Clause 22. An apparatus as described in clause 20, wherein one or more vehicle groups are based on the location of the vehicle, the number of vehicles in a neighborhood, the density of traffic flowing in a direction, the configuration of the intersection, the size associated with the vehicle, the priority value associated with one or more vehicles, or any combination thereof.

[0171] Clause 23. The apparatus of Clause 20, wherein the at least one processor is further configured to receive vehicle group information from a network resource as at least a portion of the vehicle information associated with the plurality of neighboring vehicles.

[0172] Clause 24. The apparatus of clause 20, wherein the traffic control plan is based at least in part on a time of day, a date, a current density of traffic, a turn lane configuration, or any combination thereof.

[0173] Clause 25. The apparatus of clause 20, wherein the at least one processor is further configured to unicast a vehicle control message to one or more of the plurality of neighboring vehicles as the one or more traffic intersection control messages, the vehicle control message comprising forward information.

[0174] Clause 26. The apparatus of clause 20, wherein the at least one processor is further configured to multicast a vehicle control message including a list of vehicle identification values ​​as the one or more traffic intersection control messages.

[0175] Clause 27. The apparatus of clause 20, wherein the one or more traffic intersection control messages are sent via a PC5 interface.

[0176] Clause 28. The apparatus of clause 20, wherein the one or more traffic intersection control messages are sent via a Uu interface.

[0177] Clause 29. The apparatus of clause 20, wherein the one or more traffic intersection control messages are sent via a device-to-device protocol.

[0178] Clause 30. An apparatus comprising: a memory; at least one transceiver; at least one processor communicatively coupled to the memory and the at least one transceiver and configured to: send one or more basic safety messages; receive one or more traffic intersection control messages including proceeding information; and provide instructions to proceed or stop proceeding through an intersection based at least in part on the one or more traffic intersection control messages.

[0179] Clause 31. The apparatus of clause 30, wherein the at least one processor is further configured to send vehicle priority information.

[0180] Clause 32. The apparatus of clause 30, wherein the at least one processor is further configured to receive a unicast message including the forward information as the one or more traffic intersection control messages.

[0181] Clause 33. The apparatus of clause 30, wherein the at least one processor is further configured to receive a multicast message comprising a list of vehicle identification values ​​as the one or more traffic intersection control messages.

[0182] Clause 34. The apparatus of clause 30, wherein the at least one processor is further configured to provide instructions to a controller in an autonomous or semi-autonomous vehicle as an indication to proceed or to stop proceeding through an intersection.

[0183] Clause 35. The apparatus of clause 30, wherein the at least one processor is further configured to activate a driver alert device as an indication to proceed or to stop proceeding through the intersection.

[0184] Clause 36. The apparatus of clause 30, wherein the one or more traffic intersection control messages are received via a PC5 interface.

[0185] Clause 37. The apparatus of clause 30, wherein the one or more traffic intersection control messages are received via a Uu interface.

[0186] Clause 38. The apparatus of clause 30, wherein the one or more traffic intersection control messages are received via a device-to-device protocol.

[0187] Clause 39. An apparatus for providing traffic intersection control messages, comprising: a component for receiving vehicle information associated with a plurality of adjacent vehicles; a component for generating one or more vehicle groups based on the vehicle information; a component for generating a traffic control plan based at least in part on the one or more vehicle groups; and a component for sending one or more traffic intersection control messages to one or more of the plurality of adjacent vehicles based at least in part on the traffic control plan.

[0188] Clause 40. An apparatus for receiving traffic intersection control messages, comprising: a component for sending one or more basic safety messages; a component for receiving one or more traffic intersection control messages including proceeding information; and a component for providing instructions to proceed or stop proceeding through an intersection based at least in part on the one or more traffic intersection control messages.

[0189] Clause 41. A non-transitory processor-readable storage medium comprising processor-readable instructions configured to cause one or more processors to provide traffic intersection control messages, the processor-readable instructions comprising code for: receiving vehicle information associated with a plurality of neighboring vehicles; generating one or more vehicle groups based on the vehicle information; generating a traffic control plan based at least in part on the one or more vehicle groups; and sending one or more traffic intersection control messages to one or more of the plurality of neighboring vehicles based at least in part on the traffic control plan.

[0190] Clause 42. A non-transitory processor-readable storage medium comprising processor-readable instructions, the processor-readable instructions being configured to cause one or more processors to receive traffic intersection control messages, the processor-readable instructions comprising code for: sending one or more basic safety messages; receiving one or more traffic intersection control messages including proceeding information; and providing instructions to proceed or stop proceeding through an intersection based at least in part on the one or more traffic intersection control messages.

Claims

1. A method for providing a traffic intersection control message, comprising: receiving vehicle information associated with a plurality of neighboring vehicles; generating one or more vehicle groups based on the vehicle information; generating a traffic control plan based at least in part on the one or more vehicle groups; as well as One or more traffic intersection control messages are sent to one or more neighboring vehicles of the plurality of neighboring vehicles based at least in part on the traffic control plan.

2. The method according to claim 1, wherein: The vehicle information includes a basic safety message sent by one or more vehicles of the plurality of neighboring vehicles.

3. The method of claim 1, wherein the one or more vehicle groups are based on the location of the vehicle, the number of vehicles in a neighborhood, the density of traffic flowing in one direction, the configuration of the intersection, the size associated with the vehicle, the priority value associated with one or more vehicles, or any combination thereof.

4. The method according to claim 1, wherein: Receiving the vehicle information includes: receiving vehicle group information from a network resource.

5. The method according to claim 1, wherein: The traffic control plan is based at least in part on the time of day, date, current density of traffic, turn lane configuration, or any combination thereof.

6. The method according to claim 1, wherein: Sending the one or more traffic intersection control messages includes: unicasting a vehicle control message to one or more vehicles among the plurality of neighboring vehicles, the vehicle control message including forward information.

7. The method according to claim 1, wherein: Sending the one or more traffic intersection control messages includes multicasting a vehicle control message including a list of vehicle identification values.

8. The method according to claim 1, wherein: The one or more traffic intersection control messages are sent via a PC5 interface, a Uu interface, a device-to-device protocol, or any combination thereof.

9. A method for receiving a traffic intersection control message, comprising: sending one or more basic safety messages; receiving one or more traffic intersection control messages including forward information; as well as An instruction to proceed or to cease proceeding through the intersection is provided based at least in part on the one or more traffic intersection control messages.

10. The method of claim 9, further comprising sending vehicle priority information.

11. The method according to claim 9, wherein: Receiving one or more traffic intersection control messages includes receiving a unicast message including the forward information.

12. The method according to claim 9, wherein: Receiving the one or more traffic intersection control messages includes: receiving a multicast message including a list of vehicle identification values.

13. The method according to claim 9, wherein: Providing instructions to proceed or to cease proceeding through the intersection includes providing instructions to a controller in the autonomous or semi-autonomous vehicle.

14. The method according to claim 9, wherein: Providing an instruction to proceed or to cease proceeding through the intersection includes activating a driver alert device.

15. The method according to claim 9, wherein: The one or more traffic intersection control messages are received via a PC5 interface, a Uu interface, a device-to-device protocol, or any combination thereof.

16. An apparatus comprising: Memory; at least one transceiver; at least one processor communicatively coupled to the memory and the at least one transceiver and configured to: receiving vehicle information associated with a plurality of neighboring vehicles; generating one or more vehicle groups based on the vehicle information; generating a traffic control plan based at least in part on the one or more vehicle groups; as well as One or more traffic intersection control messages are sent to one or more neighboring vehicles of the plurality of neighboring vehicles based at least in part on the traffic control plan.

17. The device according to claim 16, wherein: The vehicle information includes a basic safety message sent by one or more vehicles of the plurality of neighboring vehicles.

18. The apparatus of claim 16, wherein the one or more vehicle groups are based on the location of the vehicle, the number of vehicles in a neighborhood, the density of traffic flowing in one direction, the configuration of the intersection, the size associated with the vehicle, a priority value associated with one or more vehicles, or any combination thereof.

19. The device according to claim 16, wherein: The at least one processor is further configured to receive vehicle group information from a network resource as at least a portion of the vehicle information associated with the plurality of neighboring vehicles.

20. The device according to claim 16, wherein: The traffic control plan is based at least in part on the time of day, date, current density of traffic, turn lane configuration, or any combination thereof.

21. The device according to claim 16, wherein: The at least one processor is further configured to unicast a vehicle control message to one or more vehicles of the plurality of neighboring vehicles as the one or more traffic intersection control messages, the vehicle control message comprising forward information.

22. The device according to claim 16, wherein: The at least one processor is further configured to multicast a vehicle control message including a list of vehicle identification values ​​as the one or more traffic intersection control messages.

23. The device according to claim 16, wherein: The one or more traffic intersection control messages are sent via a PC5 interface, a Uu interface, a device-to-device protocol, or any combination thereof.

24. An apparatus comprising: Memory; at least one transceiver; at least one processor communicatively coupled to the memory and the at least one transceiver and configured to: sending one or more basic safety messages; receiving one or more traffic intersection control messages including forward information; and An instruction to proceed or to cease proceeding through the intersection is provided based at least in part on the one or more traffic intersection control messages.

25. The device according to claim 24, wherein: The at least one processor is also configured to transmit vehicle priority information.

26. The device according to claim 24, wherein: The at least one processor is further configured to receive a unicast message including the forward information as the one or more traffic intersection control messages.

27. The device according to claim 24, wherein: The at least one processor is further configured to receive a multicast message including a list of vehicle identification values ​​as the one or more traffic intersection control messages.

28. The device according to claim 24, wherein: The at least one processor is further configured to provide instructions to a controller in the autonomous or semi-autonomous vehicle as an indication to proceed or to stop proceeding through the intersection.

29. The device according to claim 24, wherein: The at least one processor is further configured to activate a driver alert device as an indication to proceed or to stop proceeding through the intersection.

30. The device according to claim 24, wherein: The one or more traffic intersection control messages are received via a PC5 interface, a Uu interface, a device-to-device protocol, or any combination thereof.

Images