Patent Description:
In some wireless communications systems, communications may occur between vehicles and systems that use such communications. Accordingly, these systems may sometimes be referred to as vehicle-to-anything (V2X) communication systems. V2X communication links may convey important information to or from vehicles regarding inclement weather, nearby accidents, road conditions, and/or the activities of nearby vehicles, for example. V2X communication systems may also be used by autonomous or semi-autonomous vehicles (e.g., self-driving vehicles or vehicles that provide driver assistance) and may provide extra information beyond the reach of the vehicle's existing system. Such V2X communications links may provide certain safety-related information (e.g., location, direction of travel, velocity, etc.) in messages so that other vehicles may receive such information. In certain implementations, a communication device, such as, a roadside unit (RSU) may be dedicated or otherwise (temporarily) provisioned to coordinate the movement (travel) of compatible UEs with regard to an intersection or some portion thereof. However, at times, an RSU or the like may be unavailable for a given region and/or intersection. Accordingly, techniques that provide for use in intersection travel coordination without an RSU or the like may be beneficial.

<CIT> relates generally to vehicle communication and traffic merging behaviors. <CIT> relates to the field of vehicular traffic control, in particular to methods and software for managing vehicle priority in a self-organizing traffic control system.

In accordance with claim <NUM>, a method is provided for use at a first user equipment (UE) associated with a first vehicle.

[<NUM>] Active traffic planning techniques are provided herein that may be implemented, at least in part, using one or more user equipments (UEs). All or some of the UEs involved in traffic planning may be associated with respective vehicles that may at times traverse all or part of a region having one or more paths applicable for a given type of vehicle. Within such a region, one or more paths may include an "intersection" of some type that causes path(s) to meet or otherwise change in some manner. Some example types of intersections include a shared intersection where two or more paths meet one another, a merge intersection where two or more paths merge to form a fewer number of paths, and a divide intersection where a path divides (splits) to form two or more paths. Active traffic planning may assist one or more of the vehicles with regard to such intersections which may bring vehicle(s) nearby other stationary or moving vehicles, obstacles, pedestrians, or other characteristics regarding an intersection that may be considered in planning safe traversal (e.g., navigation) within the region.

In certain instances, a UE may be a part of a vehicle having been included in the vehicle's manufacture, or perhaps subsequently added (affixed) to the vehicle in a similar manner so that it becomes part of the vehicle. Thus, for example, a UE may be provisioned in a truck or automobile, possibly as part of a navigation system, an entertainment system, an autonomous driving system, an onboard computing system, etc. In other instances, a UE may be associated with a vehicle despite not being part of the vehicle. For example, a UE may take the form of a portable wireless communication device that may be carried by a vehicle (at times) and when carried by a vehicle may or may not be configured to operate with other devices or like capabilities of the vehicle. Such a portable wireless communication device may take the form of a smart phone, a satellite-based navigation unit or the like, that may operate as a standalone device providing turn-by-turn navigation assistance or other useful information to a person driving a vehicle. Such portable wireless devices may, for example, be (removably) connected to a vehicle possibly by a mechanical support, an electrical power connection, a wired or wireless data connection, etc. Accordingly, in certain instances, a vehicle may be UE-enabled by way of either an affixed UE, a removably connected UE, or some combination thereof.

In certain implementations, the techniques provided herein may allow two or more vehicles that are UE-enabled to exchange traffic information regarding at least a portion of the region and at least portion of an intersection therein. The exchanged information may be useful for traffic planning by one or more of the vehicles. Such techniques may, for example, help to reduce traffic congestion, increase safety, improve driver/passenger awareness or experience, etc..

In certain instances, the active traffic planning techniques presented herein may allow two or more UEs to negotiate or otherwise coordinate their respective travel within at least a portion of a region that includes one or more intersections. In certain instances, some intersections may be associated with a roadside unit (RSU) or other like network device/service that may be configured to manage or otherwise assist in traffic planning with regard to the intersection. In certain instances, such capabilities may be part of the active traffic planning techniques provided herein. For example, in certain implementations an RSU or other like (perhaps stationary) wireless communication device/service associated with an intersection may be configured to directly or indirectly share (exchange) traffic information with one or more vehicles that are UE-enabled. Indeed, such intersection associated devices may be considered as comprising UEs in accordance with certain aspects. Thus, some UEs may be associated with an intersection or nearby part of a region and may generate, gather, store, share, combine, various types of traffic information, some of which may be considered in the traffic planning techniques herein. So, as described in greater detail herein, various types vehicles/UEs may be configured to support traffic planning for at least one participating vehicle that is expected to traverse or may currently be traversing the intersection in some manner.

The terms "vehicle" and "UE" may be used interchangeably in certain sections herein to represent vehicles that are UE-enabled and configured to provide or otherwise support the active traffic planning technique being described. Wherein a vehicle or UE may be intended to represent a differently operating, provisioned or configured vehicle or device, an appropriate description is provided. For example, in certain aspects an active traffic planning technique may consider traffic information indicating at least an expected/current presence with regard to an intersection, of a "detected" vehicle, or a "known" vehicle (or likewise, a detected or known UE).

While many of the examples described herein include traditional vehicles such as, for example, automobiles, trucks, busses, motorcycles, and the like, it should be understood that the techniques presented herein may apply to a variety of less traditional vehicles such as, for example, bicyclists, pedestrians, equestrians, trains, robotic machines, scooters, etc., which may comprise or otherwise be provisioned with a UE, and/or may become known or detected by one or more of the UEs that may be more directly involved in an active traffic planning process as presented herein.

By way of an example, an active traffic planning process may be performed by an automobile and a commuter bus, each comprising compatible UEs. In addition to considering traffic information associated with their own intended/desired movements through the region and/or intersection, one or both of these vehicles, e.g., the automobile and bus, may also consider traffic information regarding a detected vehicle (e.g., a truck) sans a compatible UE. In certain instances, for example, at least a portion of the traffic information relating to the truck may be based, at least in part, on corresponding data gathered using one or more sensor(s) of the automobile, the bus, another UE (e.g., an RSU), etc., and/or from traffic information obtained for a network resource.

In certain aspects, active traffic planning may consider traffic information regarding various types of paths within the region or the intersection. By way of some examples, a route for a vehicle through an intersection may be determined, at least in part, using traffic planning techniques as presented herein. Such a route may, for example, indicate one or more paths applicable to the traffic. In certain instances, a path may correspond to a particular lane or other like portion of a roadway, a bridge, an intersection, a bike path, etc. Thus, a multiple lane highway may comprise a plurality of paths, as might an intersection with multiple lane roadways, turn lanes, etc. The traffic intended for a given path may be limited by design to a particular form of traffic in certain instances. In certain instances, an intended traffic use of a lane may vary dynamically in some manner. For example, the direction of travel for certain lanes (paths) of an expressway or tollway may change at times to accommodate rush hour traffic. In another example, an entire roadway having multiple lanes (paths) may be closed to vehicular traffic at times to accommodate pedestrian traffic. In certain instances, traffic information may include map information or the like regarding a region and an intersection, and which may also indicate the presence of other types of paths, possibly for other types of traffic within or nearby the intersection. Thus, in certain aspects active traffic planning may consider other types of traffic and paths based, at least in part, on the traffic information. For example, in some example implementations, one or more paths and applicable types of traffic that may be considered for traffic planning may correspond to one or more pedestrian walkways/crosswalks, bike lanes, bus lanes, trolley lanes, HOV lanes, toll lanes, roadside parking sections, parking structure entrances/exits, passenger pick-up/drop-off sections, just to name a few examples.

In certain instances, active traffic planning techniques may also consider traffic information that may indicate in some manner that one or more paths may or may not affected by traffic conditions, accidents, construction, environmental conditions, regulations, etc. For example, a network server may provide such information to a UE by a base station or other like device.

Given the above basic examples, it should be understood that the traffic planning techniques provided herein may be used for a variety of differently designed traffic regions and intersections and that claimed subject matter in not necessarily limited by the examples provided herein.

As used herein, the term "intersection" is intended to represent various types of junctions or the like wherein two or more paths cross, merge/combine, split/divide, etc. Thus, in certain instances, an intersection may comprise a two-way junction, a three-way junction,. , or other multiple way junction, as are well known, a lane merge, a multiple-lane merge, a lane split, a multiple lane split, a roundabout, a multiple lane round about, or other junction layout/design. Unless otherwise specified, claimed subject matter in not necessarily intended to be limited to such examples.

Some wireless communication systems may be used to facilitate communications with and/or between various devices, which may include UEs that may be provisioned in vehicles and these systems may support vehicle-to-everything (V2X) communications. As an example, UEs may employ V2X communication to convey information (data) between vehicles, etc. Some V2X communications may be unicast (e.g., between two UEs) or possible groupcast (e.g., between various UEs within a group, such as, a platoon, etc.). In still other instances, some V2X communications may be broadcast (e.g., one UE to many other devices).

It should be understood, that the term V2X communication as used herein is not intended to necessarily limit the techniques presented herein. Instead, the term V2X is used simply just to represent various forms of UEs communicating with one or more other devices, whether provisioned as part of the vehicle or other machine, carried by a person or animal, moving or stationary, etc. In certain instances, a V2X communication may referred to as a sidelink communication, with these terms being interchangeable. Further, the term V2X is intended to represent various technologies that may support V2X communication. By way of some non-limiting examples, a V2X communication may comprise a cellular-V2X (C-V2X) communication, a device-to-device (D2D) communication, and/or the like or some combination thereof.

In accordance with certain aspects, a V2X communication may be conducted, at least in part, using one or more communication resource allocation grants. In certain instances, a communication resource allocation may be requested by a "scheduled" device (e.g., via one or more communication resource allocation requests) and granted by a "scheduling" device (e.g., via one or more communication resource allocation grants). In certain instances, a UE may comprise either a scheduled device or a scheduling device. Thus, as a scheduled device, a UE may receive communication resource allocation grants from another device, e.g., another UE, a base station, etc. Conversely, as a scheduling device, a UE may grant a communication resource allocation to another device, e.g., another UE, a base station, etc..

Attention is now drawn to <FIG>, which illustrates an example of a wireless communications system <NUM> that may support V2X communication and traffic planning in accordance with aspects of the present disclosure. The wireless communications system <NUM> includes base stations <NUM>, UEs <NUM>, and a core network <NUM>. In some examples, the wireless communications system <NUM> may be a Long Term Evolution (LTE) network, an LTE-Advanced (LTE-A) network, an LTE-A Pro network, or a New Radio (NR) network. In some cases, wireless communications system <NUM> may support enhanced broadband communications, ultra-reliable (e.g., mission critical) communications, low latency communications, or communications with low-cost and low-complexity devices.

A UE <NUM> may be a personal electronic device such as a cellular phone, a personal digital assistant (PDA), a tablet computer, a laptop computer, or a personal computer.

Wireless communications system <NUM> may support direct communication between UEs <NUM> over a sidelink <NUM> (e.g., using a peer-to-peer (P2P), device-to-device (D2D) protocol, ProSe direct communications). Sidelink communication may be used for D2D media-sharing, vehicle-to-vehicle (V2V) communication, V2X communication, enhanced V2X (eV2X) communication, etc.), emergency rescue applications, etc. One or more of a group of UEs <NUM> utilizing D2D communications may be within the geographic coverage area <NUM> of a base station <NUM>. In some cases, groups of UEs <NUM> communicating via D2D communications may utilize a one-to-many (<NUM> :M) system in which each UE <NUM> transmits to every other UE <NUM> in the group.

For example, wireless communications system <NUM> may use a transmission scheme between a transmitting device (e.g., a first UE <NUM> of a sidelink connection) and a receiving device (e.g., a second UE <NUM> of a sidelink connection), where the transmitting device is equipped with multiple antennas and the receiving device is equipped with one or more antennas. Each of the multiple signals may be referred to as a separate spatial stream and may carry bits associated with the same data stream (e.g., the same codeword) or different data streams.

Both digital and analog beaming techniques are well known.

In one example, a base station <NUM> or UE <NUM> may use multiple antennas or antenna arrays to conduct beamforming operations for directional communications with a UE <NUM> recipient. For instance, some signals (e.g. synchronization signals, reference signals, beam selection signals, or other control signals) may be transmitted by a base station <NUM> multiple times in different directions, which may include a signal being transmitted according to different beamforming weight sets associated with different directions of transmission. Transmissions in different beam directions may be used to identify (e.g., by the base station <NUM>, a first UE <NUM>, or a receiving device, such as a second UE <NUM>) a beam direction for subsequent transmission and/or reception by the base station <NUM>.

Some signals, such as data signals associated with a particular receiving device, may be transmitted by a base station <NUM> or a first UE <NUM> in a single beam direction (e.g., a direction associated with the receiving device, such as a second UE <NUM>). In some examples, the beam direction associated with transmissions along a single beam direction may be determined based at least in in part on a signal that was transmitted in different beam directions. For example, a receiving UE <NUM> may receive one or more of the signals transmitted by a base station <NUM> or a transmitting UE <NUM> in different directions, and the receiving UE <NUM> may report to the base station <NUM> or the transmitting UE <NUM> an indication of the signal it received with a highest signal quality, or an otherwise acceptable signal quality. Although these techniques are described with reference to signals transmitted in one or more directions by a base station <NUM>, a UE <NUM> may employ similar techniques for transmitting signals multiple times in different directions (e.g., for identifying a beam direction for subsequent transmission or reception by the UE <NUM>) or transmitting a signal in a single direction (e.g., for transmitting data to a receiving device).

In the user plane, communications at the bearer or PDCP layer may be IP-based. In cases where D2D or V2X communications are used, a V2X layer may provide related protocols, and in some cases may use ProSe direct communications protocols (e.g., PC5 signaling). A RLC layer may perform packet segmentation and reassembly to communicate over logical channels. A MAC layer may perform priority handling and multiplexing of logical channels into transport channels. In the control plane, the RRC protocol layer may provide establishment, configuration, and maintenance of an RRC connection between a UE <NUM> and a base station <NUM> or core network <NUM> supporting radio bearers for user plane data. At the PHY layer, transport channels may be mapped to physical channels.

A carrier may be associated with a pre-defined frequency channel (e.g., an evolved universal mobile telecommunication system terrestrial radio access (E-UTRA) absolute radio frequency channel number (EARFCN)) and may be positioned according to a channel raster for discovery by UEs <NUM>. In some examples, signal waveforms transmitted over a carrier may be made up of multiple sub-carriers (e.g., using multi-carrier modulation (MCM) techniques such as orthogonal frequency division multiplexing (OFDM) or discrete Fourier transform spread OFDM (DFT-S-OFDM)).

The organizational structure of the carriers may be different for different radio access technologies (e.g., LTE, LTE-A, LTE-A Pro, NR).

Devices of the wireless communications system <NUM> (e.g., base stations <NUM> or UEs <NUM>) may have a hardware configuration that supports communications over a particular carrier bandwidth or may be configurable to support communications over one of a set of carrier bandwidths. In some examples, the wireless communications system <NUM> may include base stations <NUM> and/or UEs <NUM> that support simultaneous communications via carriers associated with more than one different carrier bandwidth.

Wireless communications system <NUM> may support communication with a UE <NUM> on multiple cells or carriers, a feature which may be referred to as carrier aggregation or multi-carrier operation.

In some cases, an eCC may utilize a different symbol duration than other component carriers, which may include use of a reduced symbol duration as compared with symbol durations of the other component carriers.

Wireless communications system <NUM> may be an NR system that may utilize any combination of licensed, shared, and unlicensed spectrum bands, among others. The flexibility of eCC symbol duration and subcarrier spacing may allow for the use of eCC across multiple spectrums. In some examples, NR shared spectrum may increase spectrum utilization and spectral efficiency, specifically through dynamic vertical (e.g., across the frequency domain) and horizontal (e.g., across the time domain) sharing of resources.

In some wireless communications systems, data transmissions (e.g., target traffic) may be periodically broadcasted from a UE <NUM> or base station <NUM>. For example, in V2X communications, a vehicle (e.g., or a UE <NUM>) may broadcast safety messages at times, possibly periodically, to enable nearby vehicles, sensors, or additional UEs <NUM> to receive traffic or other like information about the transmitting vehicle, etc..

Wireless communications system <NUM> may support efficient techniques for establishing a unicast link (e.g., connection) between two wireless devices (e.g., UEs <NUM>, vehicles, sensors, etc.). For example, a connection-oriented link may be established by a V2X layer of a protocol stack between the two wireless devices that supports an optimized AS layer configuration (e.g., over-the-air) for higher throughput (e.g., <NUM> quadrature amplitude modulation (QAM), CA, etc.), supports enhanced security protection, and allows more efficient resource usage (e.g., power control, beam management, etc.). In some cases, the unicast connection may be established over a sidelink <NUM> between the two wireless devices, for example, without going through a base station. To establish the unicast connection over the sidelink <NUM>, a first UE <NUM> may transmit a request message to a second UE <NUM>, and the second UE <NUM> may transmit a response message accepting the request to the first UE <NUM>.

Additionally, the first UE <NUM> may transmit a connection complete message to the second UE <NUM> and establish a security context with the second UE <NUM> as part of establishing a connection over the sidelink <NUM>. In some cases, the request message, the response message, and the connection complete message may be transmitted via RRC signaling (e.g., over PC5 to have unified PC5 and Uu management). Additionally, a connection may be established based on parameters (e.g., capabilities, connection parameters, etc.) for the first UE <NUM> and/or the second UE <NUM> that are transmitted in the respective request message and/or response message. For example, the parameters may include PDCP parameters, RLC parameter, MAC parameters, PHY layer parameters, capabilities of either UE <NUM>, or a combination thereof. Such communications may be performed as part of a link management process.

Attention is drawn next to <FIG>, which is a block diagram illustrating some features of an example apparatus for use as or use in a UE <NUM> configured for V2X communications or the like and traffic planning, in accordance with certain aspects of the present disclosure.

Referring to <FIG>, one example of an implementation of the UE <NUM> may include a variety of components including components such as one or more processing units <NUM> and memory <NUM> and transceiver <NUM> in communication via one or more buses <NUM>, which may operate in conjunction with the modem <NUM> and the communication component <NUM> to enable one or more of the functions described herein related to V2X and related communications supportive of traffic planning. Further, the one or more processing unit(s) <NUM>, modem <NUM>, memory <NUM>, transceiver <NUM>, RF front end <NUM> and one or more antennas <NUM>, may be configured to support voice and/or data calls (simultaneously or non-simultaneously) in one or more radio access technologies.

In an aspect, the one or more processing unit(s) <NUM> may include modem <NUM> that uses one or more modem processors. The various functions related to a communication component <NUM> may be included or otherwise implemented, at least in part, in modem <NUM> and/or processing unit(s) <NUM> and, in an aspect, may be executed by a single processor, while in other aspects, different ones of the functions may be executed by a combination of two or more different processors. For example, in an aspect, the one or more processing unit(s) <NUM> may include any one or any combination of a modem processor, or a baseband processor, or a digital signal processor, or a transmit processor, or a receiver processor, or a transceiver processor associated with transceiver <NUM>. In other aspects, some of the features of the one or more processing unit(s) <NUM> and/or the modem <NUM> associated with the communication component <NUM> may be performed by transceiver <NUM>.

Also, memory <NUM> may be configured to store data used herein and/or local versions of applications <NUM> for the communication component <NUM> and/or one or more subcomponents of the communication component <NUM> being executed by at least one processing unit(s) <NUM>. Memory <NUM> can include any type of computer-readable medium usable by a computer or at least one processing unit(s) <NUM>, such as random access memory (RAM), read only memory (ROM), tapes, magnetic discs, optical discs, volatile memory, non-volatile memory, and any combination thereof. In an aspect, for example, memory <NUM> may be a non-transitory computer-readable storage medium that stores one or more computer-executable codes defining all or part of communication component <NUM> and/or one or more of its subcomponents, and/or data associated therewith, when UE <NUM> is operating at least one processing unit(s) <NUM> to execute the communication component <NUM> and/or one or more of its subcomponents.

Receiver <NUM> may include hardware, firmware, and/or software code executable by a processor for receiving data, the code comprising instructions and being stored in a memory (e.g., computer-readable medium). Transmitter <NUM> may include hardware, firmware, and/or software code executable by a processor for transmitting data, the code comprising instructions and being stored in a memory (e.g., computer-readable medium).

RF front end <NUM> may be coupled with one or more antennas <NUM> and can include one or more low-noise amplifiers (LNAs) <NUM>, one or more switches <NUM>, one or more power amplifiers (PAs) <NUM>, and one or more filters <NUM> for transmitting and receiving RF signals.

In an aspect, RF front end <NUM> may use one or more switches <NUM> to select a particular LNA <NUM> and the specified gain value based on a desired gain value for a particular application.

In an aspect, RF front end <NUM> may use one or more switches <NUM> to select a particular PA <NUM> and the specified gain value based on a desired gain value for a particular application.

In an aspect, each filter <NUM> can be coupled with a specific LNA <NUM> and/or PA <NUM>. In an aspect, RF front end <NUM> can use one or more switches <NUM> to select a transmit or receive path using a specified filter <NUM>, LNA <NUM>, and/or PA <NUM>, based on a configuration as specified by transceiver <NUM> and/or processing unit(s) <NUM>.

In an aspect, for example, the modem <NUM> can configure transceiver <NUM> to operate at a specified frequency and power level based on the UE configuration of the UE <NUM> and the communication protocol used by the modem <NUM>. All or part of either or both, transceiver <NUM> and RF front end <NUM> may be configured, at least in part, as representing an NR RAT, and possibly also as representing an LTE RAT, and/or the like.

In an aspect, the modem <NUM> can be a multiband-multimode modem, which can process digital data and communicate with transceiver <NUM> such that the digital data is sent and received using transceiver <NUM>. In an aspect, the modem <NUM> can be multiband and be configured to support multiple frequency bands for a specific communications protocol. In an aspect, the modem <NUM> can be multimode and be configured to support multiple operating networks and communications protocols. In an aspect, the modem <NUM> can control one or more components of UE <NUM> (e.g., RF front end <NUM>, transceiver <NUM>) to enable transmission and/or reception of signals from the network based on a specified modem configuration.

As illustrated in <FIG>, an example communication component <NUM> may be configured, at least in part, based on all or part of one or more layers of a communication protocol stack represented herein by communication capability <NUM>, some of which may support V2X communication supportive of traffic planning techniques presented herein. In certain instances, two or more UEs having applicable communication capabilities may be involved in traffic planning, e.g., through sharing traffic information and/or various parameters, negotiating traffic plan(s) via request and acknowledgement messaging, etc..

Accordingly, as illustrated in <FIG>, processing unit(s) <NUM> may comprise or otherwise process traffic information <NUM>, some of which may be locally generated or obtained by the UE <NUM> and some of which may be received from one or more other UEs supporting traffic planning. The traffic information <NUM> from another UE may, for example, comprise information that is locally generated or obtained by that UE. Traffic information, regardless as to its source, may correspond to one or more vehicles that may be of interest in traffic planning for a region and/or intersection therein. Various examples of possible traffic information are described herein.

One or more processing unit(s) <NUM> may comprise or otherwise process a traffic plan <NUM>. Here, for example, a traffic plan <NUM> may comprise one or more parameters <NUM> that may be used by applicable UEs to coordinate traffic within a region and/or intersection as part of a traffic planning technique provided herein. In certain implementations a traffic plan may be used as part of a negotiation process <NUM> to negotiate intersection traversal via request and acknowledgement messaging between applicable UEs. Various routing information <NUM> corresponding to various routes within a region and/or intersection that may, for example, be used for traffic plan <NUM> and/or parameter(s) <NUM>. By way of an example, a map or other like resource may define certain pathways through the region or intersection. Some non-limiting examples of various types of useful information and parameters are described in greater detail herein.

Additionally, as illustrated by dashed-line boxes indicating optional aspects in certain implementations, one or more processing unit(s) <NUM> may comprise or otherwise process a driving capability <NUM>, a routing capability <NUM>, a location capability <NUM>, a sensor capability <NUM>, or the like or some combination thereof. By way of an example, a driving capability <NUM> may provide an ability to assist human driving of a vehicle, or possibly to provide a form of semi-autonomous or even fully-autonomous driving in certain instances. Thus, (optional) driving capability <NUM> may act in some manner to control some aspect of the movement of an applicable vehicle comprising UE <NUM>. In using an example routing capability <NUM>, UE <NUM> may be able to provide routing information to a user (e.g., driver) and/or a driving capability <NUM>, wherein the routing information may correspond to all or part of the region and/or intersection, the traffic plan, a map resource, etc. Similarly useful, a location capability <NUM> may provide location information relating to the position and/or movement of the vehicle associated with UE <NUM>. For example, a location capability may use satellite positioning system (SPS), terrestrial positioning, and/or the like or some combination thereof to determine an estimated location and/or movement of the UE with regard to one or more coordinates, etc. Such location techniques are well-known and include GNSS, cellular and/or other wireless signal location determination, e.g., via multi-lateration measurements, etc. Sensor capability <NUM> is representative of one or more capabilities that may generate and/or otherwise process traffic information that may be of use for traffic planning. In certain implementations, one or more sensors <NUM> may be provided within UE <NUM> and/or within a vehicle (not shown) associated with UE <NUM>. The sensor(s) <NUM> and/or sensor capability <NUM> may, for example, be configured to support object detection, recognition, classification, etc., for use in traffic planning. By way of some non-limiting examples, a sensor capability <NUM> may comprise or otherwise correspond capabilities associated with one or more sensors, such as, a radar, a LIDAR, a sonar, a camera, a microphone, and/or the like or some combination thereof, which may be used, at least in part, to generate or affect traffic information <NUM>, traffic plan <NUM>, one or more parameters <NUM>, or the like or some combination thereof. In certain instances, sensor capability <NUM> may, for example, generate or otherwise process one or more of the various example types of information illustrated in <FIG> as traffic information <NUM> and/or in accordance with the other example blocks in the distributed negotiation process <NUM>.

In certain implementations, one or more of traffic information <NUM>, traffic plan <NUM>, an intersection traversal request, an intersection traversal acknowledgement, or the like may comprises one or more parameters <NUM> indicative of or otherwise associated with an open road space start location, an open road space stop location, an open road space distance measurement, a path or road indication, a lane indication, an observation field of view or area (e.g., of object sensing, detection), an unobserved area (e.g., lacking object sensing, detection, etc.), a region identifier, an intersection identifier, a vehicle ingress point, a vehicle egress point, an estimated time of arrival (ETA), an estimated time to pass (ETP), a right-of-way (ROW) start time, a ROW end time, an intersection clearance indication (e.g., relating to one, two, or possibly three dimensions) , or some combination thereof corresponding, at least in part, to the region or the intersection, the vehicle, at least one of the one or more vehicles, or some combination thereof.

It should be noted that, features in dashed lined boxes may be optional in certain implementations. Of course, features in solid lined boxes may also be optional in certain other implementations. Claimed subject matter is not intended to be as limited as the various examples presented herein.

Attention is drawn next to <FIG>, which is a flow-diagram illustrating some aspects that may be useful to a UE-based, distributed negotiation process <NUM> (e.g., a traffic planning method) for use in intersection travel coordination between two or more UEs, in accordance with certain aspects of the present disclosure. All or part of process <NUM> may be supported, at least in part, by example UE <NUM> of <FIG>.

At block <NUM>, the UE which is associated with the Ego vehicle may determine (e.g., from routing information <NUM>, routing capability <NUM>, etc.) that a route planned for a particular destination or course includes a region comprising an intersection. As shown, vehicle sensor inputs, such as GNSS information, map data, and/or the like or some combination thereof may be considered, at least in part, in making the determination at block <NUM>.

At block <NUM>, the UE may determine one or more intersection traversal parameters (e.g., one or more of which may be provided in traffic plan <NUM>, parameter(s) <NUM>, etc.) based, at least in part, on traffic information <NUM>. As shown in this example, traffic information <NUM> may comprise a variety of useful information, some of which may be locally-generated or otherwise obtained by the (Ego, CV2X) UE, some of which may be received from one or more other (non-Ego, CV2X) UEs (associated with other vehicles) and which may correspond to the transmitting (non-Ego, CV2X) UE and its associated vehicle or to one or more other (non-Ego, non-CV2X) vehicles that may be known or otherwise detected by the transmitting UE, or some combination of such. Thus, for example, as shown, traffic information <NUM> may comprise Ego vehicle sensor input(s) or the like, non-Ego vehicle sensor input(s) or the like for a UE having an applicable communication capability (e.g., CV2X), reported characteristics of detected (non-Ego, non-CV2X) vehicles, reported characteristics of (non-Ego, non-CV2X) detected "vehicles" comprising road users and/or objects, reported detected open road and/or intersection space or other like measurements, etc., that may be provided by a non-Ego, CV2X UE to the Ego UE.

At block <NUM> a determination may be made as to whether the Ego UE (vehicle) may or may not be able to (safely) traverse the intersection with no change in speed based, at least in part on the parameters determined at block <NUM>. If block <NUM> results in a YES decision, then process <NUM> may continue at block <NUM>. In response to a NO decision at block <NUM>, process <NUM> may continue at block <NUM> in which a determination is made as to whether the Ego UE (vehicle) may be able to (safely) traverse the intersection with an increase in speed based, at least in part on the parameters determined at block <NUM>. If block <NUM> results in a YES decision, then process <NUM> may continue at block <NUM>. In response to a NO decision at block <NUM>, process <NUM> may continue at block <NUM> in which a determination is made as to whether the Ego UE (vehicle) may be able to (safely) traverse the intersection by reducing speed based, at least in part on the parameters determined at block <NUM>. If block <NUM> results in a YES decision, then process <NUM> may continue at block <NUM>. In response to a NO decision at block <NUM>, process <NUM> may continue at block <NUM> in which applicable changes may be made to the intersection traversal parameters that may permit a YES decision at one of blocks <NUM>, <NUM>, and <NUM>.

Once example process has reached block <NUM>, the Ego UE (vehicle) may transmit an intersection traversal request (herein shown as a ROW request). In other words, at example block <NUM>, the Ego UE (vehicle) has determined a safe way for it to proceed to traverse the intersection safely based on the traffic information <NUM>, and has requested a ROW based on the resulting traffic plan. At example block <NUM>, a non-Ego CV2X UE, in response to the requested ROW may transmit back an intersection traversal acknowledgment, which may serve as an indication of acceptance of the Ego UE (vehicle) traffic plan. Thus, at block <NUM>, the Ego UE (vehicle) may initiate its traffic plan and traverse the intersection accordingly. Conversely, if no acknowledgement timely received, or a non-acknowledgment is timely received, then rather than continuing at block <NUM>, the process <NUM> may end without successfully negotiating a traffic plan. Alternatively, process <NUM> may be repeated in some manner if time permits, e.g., from blocks <NUM> or <NUM>, so as to possibly negotiate a modified traffic plan and/or parameter(s) that may lead to the non-Ego UE acknowledging (accepting) such as block <NUM>. Hence, in certain instances, negotiations between applicable UEs may be based on repeated attempts to complete process <NUM>.

By way of some none-limiting examples, traffic information <NUM> in <FIG> includes some potential Ego vehicle sensor input examples associated with a camera, a GNSS, an inertial navigation unit, a speed, a heading, a radar, a LIDAR, and map data. Of course, it should be recognized that other types of information associated with and/or produced by the Ego vehicle (UE) may be provided in traffic information <NUM>.

Traffic information <NUM> in <FIG> includes some potential non-Ego CV2X vehicle sensor input examples associated with characteristics (local) of the non-Ego CV2X vehicle itself, characteristics of (other) detected vehicles (e.g., possibly non-CV2X compliant vehicles), characteristics of detected road users and/or objects/environment, information regarding open road space, intersection space and/or distance measurements, and/or or the like or some combination thereof. Of course, it should be recognized that other types of information associated with and/or produced by the Ego vehicle (UE) may be provided in traffic information <NUM>.

By way of some none-limiting examples, potential non-Ego CV2X vehicle sensor input examples associated with characteristics (local) of the non-Ego CV2X vehicle itself may correspond to location, speed, heading, an intersection ETA, an intersection ETP, a priority (e.g., relating to one or more other vehicles), an intersection ingress point (e.g., road, lane, location), an intersection egress point (e.g., road, lane, location), and intersection clearance aspects/requirements/limitations (e.g., relating to an intersection or vehicle size/dimension aspect, turn or merge aspect, weight aspect, etc.).

By way of some none-limiting examples, potential non-Ego CV2X vehicle sensor input examples associated with characteristics of (other) detected vehicles (e.g., possibly non-CV2X compliant vehicles) may correspond to size, type, location, speed, heading, and/or the like or some combination thereof.

By way of some none-limiting examples, potential non-Ego CV2X vehicle sensor input examples associated with characteristics of detected road users and/or objects/environment may correspond to size, type, location, speed, heading, etc., of detected non-CV2X road users, or other objects that may be of interest in traffic planning.

By way of some none-limiting examples, potential non-Ego CV2X vehicle sensor input examples associated with information regarding open road space, intersection space and/or distance measurements, and/or or the like may correspond to detected certain roads, lanes, intersection, or other like regions or areas that may be of interest in traffic planning.

As may be appreciated, in certain instances, it may be useful for process <NUM> and/or the other example techniques provided herein to identify traffic planning that safely permits the various "vehicles" within a region or intersection to safely traverse such in an efficient manner (e.g., time efficient, energy efficient, etc.).

Attention is drawn next to <FIG>, which is a diagram illustrating some features of an example region <NUM> comprising an intersection <NUM> and a plurality of UEs (represented by vehicles) and a flow-diagram illustrating an example negotiation process <NUM> for use in intersection travel coordination between at least two of the illustrated UEs, in accordance with certain aspects of the present disclosure.

In this example, intersection <NUM> comprises a four-way intersection formed by a roadway shown as having a dashed-line dividing a traffic lane <NUM>-<NUM> (for traffic in a positive x-direction) and a traffic lane <NUM>-<NUM> (for traffic in a negative x-direction), and another roadway <NUM> also supporting bidirectional travel extending along a y-axis perpendicular to an x-axis. Shown as approaching the intersection on lane <NUM>-<NUM> are vehicles <NUM>, <NUM>, and <NUM> (in order, with <NUM> closest to the intersection), and of which only vehicle <NUM> is illustrated as being a CV2X vehicle (UE). On roadway <NUM>, heading towards the intersection in a negative y-direction are vehicles <NUM> and <NUM> (in order with <NUM> closest to the intersection), both of which are illustrated as being CV2X vehicles (UEs). Also on roadway <NUM>, but heading towards the intersection in a positive y-direction are vehicles <NUM>, <NUM> and <NUM> (in order with <NUM> closest to the intersection), of which only vehicles <NUM> and <NUM> are illustrated as being CV2X vehicles (UEs). Thus, as illustrated some of the vehicles within region <NUM> approaching intersection <NUM> are CV2X vehicles (UEs) and some are not. Accordingly, the CV2X vehicles (UEs) will need to take into consideration the non-CV2X vehicles in their traffic planning. In this example, it may be assumed that vehicle <NUM> may have detected or otherwise been made aware of non-CV2X vehicle <NUM> travel behind it and non-CV2X vehicle <NUM> traveling in front of it. Similarly, in this example, it may be assumed that non-CV2X vehicle <NUM> may have been detected or otherwise been made aware of by one or both of CV2X vehicles (UEs) <NUM> and <NUM>.

With this example intersection and vehicle arrangement in mind, example process <NUM> may be considered to show how an example traffic planning technique may be performed by two or more of the CV2X vehicles (UEs). At block <NUM>, the CV2X vehicles in region <NUM> may broadcast traffic information <NUM>. At block <NUM>, two or more of the CV2X vehicles may determine/suggest/approve or otherwise negotiate acceptable parameters for safe intersection traversal of all or some of the various vehicles shown. For example, CV2X vehicle <NUM> and <NUM> which are approaching the intersection may need to consider reported/detected non-CV2X vehicles <NUM> and <NUM> for traffic planning because non-CV2X vehicle <NUM> is close to entering the intersection on lane <NUM>-<NUM>, and one CV2X vehicle <NUM> has traversed the intersection safely, non-CV2X vehicle <NUM> may be about to enter the intersection. In other words, the CV2X vehicles (UEs) that are able to support traffic planning will need to consider the seemingly unaware non-CV2X vehicles in the traffic planning. Thus, in this example, CV2X vehicles <NUM> and <NUM> may need plan for non-CV2X vehicle <NUM> to traverse the intersection before either enter the intersection. However, once the intersection is safe, CV2X vehicles <NUM> and <NUM> may be able to plan their respective traversal routes in a safe manner, e.g., depending on their routes. This may occur, for example at blocks <NUM>, <NUM>, <NUM>, and <NUM>, possibly with some repetition and refinement as part of a negotiation. Also, in this example, CV2X vehicle <NUM> may become involved in some manner to possibly wait for vehicles <NUM>, <NUM>, <NUM>, and <NUM> to clear the intersection so that non-CV2X vehicle <NUM> is not permitted to enter the intersection until after CV2X vehicle <NUM> has traversed the intersection. Hence, in this example, where possible the CV2X-vehicles that are ahead of non-CV2X vehicles may be used to control to some extent the time at which the non-CV2X vehicle may enter the intersection. At block <NUM> a CV2X vehicle may traverse the intersection accordingly, e.g., per the accepted traffic plan. As two or more CV2X vehicles become the next vehicles to possibly traverse the intersection, they may use process <NUM> or the like to plan their traversals in some safe manner, and with non-CV2X vehicles that may be nearby considered accordingly.

In certain aspects a CV2X vehicle may use the information received in <NUM> along with information from its own sensors to determine what its trajectory (speed, heading and so on) will allow it to safely traverse the intersection. Once it has determined such, a "Right-Of-Way" (ROW) message or the like may act as a claim to or a lock down regarding the vehicles ability/intention to traverse the intersection accordingly. It's certainly the case that other vehicles/UEs may not acknowledge or may decline such a request, but such a decline would likely be rare, and possibly result from some previously unforeseen event or change having occurred. Thus, in certain instances, a claim or assertion of right-of-way based on the initial sensor sharing and negotiation, e.g., for example as shown in <FIG>, may provide traffic planning that is predisposed or otherwise likely to be agreed to by one or more other involved vehicles.

In certain implementations, negotiations between CV2X vehicles (UEs) may comprise all or part of processes <NUM>, <NUM>, <NUM>/<NUM>' (<FIG>/B below), and/or <NUM>/<NUM>' (<FIG>/B below). Shared (broadcast) traffic information may continually or otherwise inform the traffic planning process from time to time, and either through dedicated negotiation messaging, and/or travel plan based request and acknowledgement/non-acknowledgment messaging CV2X vehicles (UEs) may coordinate safe intersection traffic even in the presence of the non-CV2X vehicles.

Attention is drawn next to <FIG> and <FIG>, which are related flow-diagrams illustrating some example methods <NUM> and <NUM>', respectively, for use by a first UE to support intersection travel coordination with at least a second UE via transmission of an intersection traversal request, in accordance with certain aspects of the present disclosure. Here, for example, both the first and second UEs comprise compatible communication capabilities.

With reference first to method <NUM> in <FIG>, at example block <NUM>, a first UE associated with a first vehicle may receive traffic information corresponding to at least one or more other vehicles. In certain instances, traffic information may be received from one or more other UEs some or all of which may be associated with vehicles. In certain instances, traffic information may be received from one or more devices that may also be associated with the first vehicle. In certain instances, traffic information may be received from one or more wireless network devices, possibly from one or more servers or other devices connected to the wireless network.

At example block <NUM> the first UE may determine, based at least in part on the traffic information, that a second vehicle of the one or more other vehicles is currently within or is expected to be within a proximate vicinity of the first vehicle, a region comprising an intersection, or both. For example, traffic information may indicate that some vehicles may already be within, at or nearby the intersection, while other vehicles may be within the region have yet to reach the intersection or may have already traversed the intersection but are still with the region, while still other vehicles may have yet to reach the region or may have just left the region but may still be within some proximate vicinity that makes them of potential interest in routing and/or traffic planning. As previously described, one or more of the vehicles identified in the traffic information may not comprise a UE with a compatible or otherwise applicable communication capability (e.g., V2X, etc.) to support method <NUM> based traffic planning.

At example block <NUM>, the first UE may identify, based at least in part on the traffic information associated with the second vehicle, a traffic plan for the first vehicle to traverse at least a portion of the region. The traffic information may comprise, for example, all or some of the traffic information per block <NUM> of <FIG> in certain implementations.

At example block <NUM>, the first UE may transmit an intersection traversal request to a second UE associated with the second vehicle, the intersection traversal request being based, at least in part, on the traffic plan. For example, an intersection traversal request may comprise a ROW request with some or all of the information per block <NUM> of <FIG>.

At example block <NUM>, the first UE may receive an intersection traversal acknowledgement transmitted by at least the second UE. The intersection traversal acknowledgement may indicate that the second device approves of a traffic plan transmitted by the first UE, e.g., block <NUM>.

At example block <NUM>, the first UE (vehicle) may initiate traversal of the at least a portion of the region by the first vehicle with respect to at least the second vehicle in response to the intersection traversal acknowledgement. In certain example implementations, the first UE (vehicle) may be referred to as an Ego vehicle, e.g., as per <FIG> example.

Reference is made next to method <NUM>' in <FIG>. Method <NUM>' is similar to method <NUM> of <FIG>, but further includes some example optional blocks.

At (optional) block <NUM>, the first UE may determine that a region and/or an intersection within the region may not be supported by a device, such as, e.g., an RSU, for traffic control. By way of an example, the first UE may consider information from one or more other devices which may be indicative of the presence or absence of an RSU or the like for a particular intersection or region. Thus, a network resource such as a base station, location or map service, etc., may provide such information in some implementations. In certain instances, such a decision at block <NUM> may be based, at least in part, on the absence of signaling from such an RSU or other like device as the first UE moves within some expect range of the region and/or intersection. In another example, a first UE may be informed as to the presence or absence of an RSU or the like by one or more other UEs. A decision at optional block <NUM> may indicate whether the first UE should attempt to coordinate intersection travel with one or more other compatible UEs per other aspects of method <NUM>'.

At example block <NUM>, the first UE associated with a first vehicle may receive traffic information corresponding to at least one or more other vehicles, wherein at least a portion of the traffic information is received from a second UE associated (e.g., being transported by a second vehicle) of the one or more other vehicles. At optional block <NUM>, at least a portion of the traffic information may comprise locally obtained traffic information from the first vehicle (UE).

At example block <NUM> the first UE may determine, based at least in part on the traffic information, that at least one of the one or more other vehicles is currently within or is expected to be within: (<NUM>) a proximate vicinity of the vehicle, (<NUM>) a region comprising an intersection, or (<NUM>) both. For example, traffic information may indicate that some vehicles may already be within, at or nearby the intersection, while other vehicles may be within the region have yet to reach the intersection or may have already traversed the intersection but are still with the region, while still other vehicles may have yet to reach the region or may have just left the region but may still be within some proximate vicinity that makes them of potential interest in routing and/or traffic planning. As previously described, one or more of the vehicles identified in the traffic information may not comprise a UE with a compatible or otherwise applicable communication capability (e.g., V2X, etc.) to support method <NUM>' based traffic planning.

At example block <NUM>, the first UE may identify, based at least in part on the traffic information, a traffic plan for the first vehicle to safely traverse at least a portion of the region, the intersection, or both. The traffic information may comprise, for example, all or some of the traffic information per block <NUM> of <FIG> in certain implementations. At example block <NUM>, the first UE may transmit an intersection traversal request to at least the second UE (which comprises a compatible or otherwise applicable communication capability. Here, for example, an intersection traversal request may be based, at least in part, on the traffic plan. For example, an intersection traversal request may comprise a ROW request with some or all of the information per block <NUM> of <FIG>.

As illustrated by optional block <NUM>, to support negotiation of one or more parameters or other aspects as part of method <NUM>', all or part of one or more of blocks <NUM>, <NUM>, <NUM>, and/or <NUM> may be repeated. For example, block <NUM> may occur if an intersection acknowledgement is not received in a timely manner per block <NUM>. For example, block <NUM> may occur if a NACK is received in response to the request transmitted at block <NUM>. At example block <NUM>, which is optional, as part of block <NUM> all or part of a traffic plan may be modified as part of the negotiation process supported at block <NUM>.

In certain example implementations, as part of a negotiation process with the second UE, per block <NUM>, one or more of blocks <NUM>, <NUM>, <NUM>, <NUM>, or some combination may be repeated, e.g., thereof prior to block <NUM> wherein an indication that an agreement has been reached is received. Block <NUM> may further comprise receiving additional traffic information from the second UE in response to at least the intersection traversal request transmitted at block <NUM>. Block <NUM>/<NUM> may further comprise modifying at least a portion of the traffic plan for the first vehicle based, at least in part on the additional traffic information. Block <NUM> may further comprise transmitting a second intersection traversal request to at least the second UE, the second intersection traversal request being based, at least in part, on the traffic plan as modified at block <NUM>/<NUM>. At block <NUM>, for example, the intersection traversal acknowledgement may be indicative of the second UE accepting the second intersection traversal request. Block <NUM> may further comprise initiating the traversal by the first vehicle based at least in part on the traffic plan, e.g., as modified at block <NUM>/<NUM>.

At example block <NUM>, the first UE may receive an intersection traversal acknowledgement transmitted by at least the second UE in response to the intersection traversal request. At example block <NUM>, the first UE (vehicle) may initiate traversal of the at least a portion of the region, the intersection, or both by the vehicle based at least in part on the traffic plan. In certain example implementations, the first UE (vehicle) may be referred to as an Ego vehicle, e.g., as per <FIG> example.

With regard to <FIG>, blocks <NUM> and <NUM> may be similar, blocks <NUM>, <NUM> and <NUM> may be similar, blocks <NUM>, <NUM>,<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> may be similar, blocks <NUM>, <NUM> and <NUM> may be similar, blocks <NUM>, <NUM> and <NUM> may be similar, and blocks <NUM>, <NUM> and <NUM> may be similar with regard to certain aspects of the traffic planning techniques presented herein by non-limiting examples.

Attention is drawn next to <FIG> and <FIG>, which may serve as a counterpart to <FIG>/B, because they show flow-diagrams illustrating example methods <NUM> and <NUM>' for use by a first UE to support intersection travel coordination via transmission of an intersection traversal acknowledgement, in accordance with certain aspects of the present disclosure. In certain example implementations, this first UE (vehicle) may be referred to as a non-Ego vehicle, e.g., as per <FIG> example.

At example block <NUM>, the first UE may receive an intersection traversal request from a second UE associated with a second vehicle, the intersection traversal request being based, at least in part, on traffic information corresponding to at least the first vehicle, the second vehicle, at least one or more other vehicles, or some combination thereof.

At example block <NUM>, the first UE may determine whether the intersection traversal request is acceptable to the first vehicle based, at least in part, on a traffic plan for the first vehicle. In certain example implementations, the first UE may determine, at least in part, whether an intersection traversal request is acceptable based on traffic information, or other information or capabilities per the processing unit(s) <NUM> of the <FIG> example.

At example block <NUM>, in response to a determination that the intersection traversal request is acceptable to the first vehicle, the first UE may transmit an intersection traversal acknowledgement to at least the second UE. In certain example implementations, the first UE may determine, at least in part, whether an intersection traversal request is acceptable based on traffic information, or other information or capabilities per the processing unit(s) <NUM> of the <FIG> example.

Reference is made next to method <NUM>' in <FIG>. Method <NUM>' is similar to method <NUM> of <FIG>, but further includes some example optional blocks.

At example block <NUM>, which may be optional, the UE may determine that a region and/or an intersection lack an RSU or other like device to support traffic planning/control. Block <NUM> may be similar to block <NUM>.

At example block <NUM>, the UE may transmit traffic information corresponding to the vehicle, at least one or more other vehicles, or some combination thereof. For example, block <NUM> may be similar to block <NUM> and may comprise all or part of the traffic information <NUM> of <FIG> or the like. Optional block <NUM> indicates that some of the traffic information by be obtained locally, e.g., by a sensor capability or the like. In certain example implementations, block <NUM> may be optional.

At example block <NUM>, the UE may receive an intersection traversal request from a second UE (e.g., from an Ego vehicle per <FIG> example) associated with another vehicle of the one or more other vehicles. If applicable, the intersection traversal request may be based, at least in part, on the traffic information transmitted at (optional) block <NUM>. For example, such a request may comprise one or more parameters per block <NUM>, and/or the like. In certain implementations such a request may comprise a ROW request which may be accepted by way of an acknowledgment or rejected by a non-acknowledgement. In some implementations such a request may comprise a ROW demand that may require an acknowledgement. Here, for example, a ROW demand may be associated with a particular UE, vehicle, entity, etc., such as an emergency responder seeking priority traffic access.

At example block <NUM>, in response to a determination that the intersection traversal request is acceptable to the vehicle (UE), the UE may transmit an intersection traversal acknowledgement to at least the second UE. At optional block <NUM>, the UE may determine the intersection traversal request is acceptable, e.g., based on traffic information, or other information or capabilities per the processing unit(s) <NUM> of the <FIG> example.

At optional block <NUM>, all or part of one or more of the aspects of example blocks <NUM>, <NUM>, and/or <NUM> may be repeated in some manner to support a negotiation between at least the UE and the second UE.

At example block <NUM>, the UE may initiate traversal of the at least a portion of a region comprising an intersection by the vehicle based at least in part on the intersection traversal request determined to be acceptable. For example, in certain instances the UE may allow one or more of the other vehicles (with or without compatible communication capabilities) traverse the intersection before initiating traversal of the vehicle.

IS-<NUM> Releases may be commonly referred to as CDMA2000 1X, 1X, etc. IS-<NUM> (TIA-<NUM>) is commonly referred to as CDMA2000 1xEV-D0, High Rate Packet Data (HRPD), etc. UTRA includes Wideband CDMA (WCDMA) and other variants of CDMA.

For synchronous operation, the UEs may have similar frame timing, and transmissions from different UEs may be approximately aligned in time. For asynchronous operation, the UEs may have different frame timing, and transmissions from different UEs may not be aligned in time.

The various illustrative blocks and modules described in connection with the disclosure herein may be implemented or performed with a general-purpose processor, a DSP, an ASIC, an FPGA, or other PLD, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein, e.g., with regard to one or more processing units.

By way of example, and not limitation, non-transitory computer-readable media may include RAM, ROM, electrically erasable programmable ROM (EEPROM), flash memory, compact disk (CD) ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other non-transitory medium that can be used to carry or store desired program code means in the form of instructions or data structures and that can be accessed by a general-purpose or special-purpose computer, or a general-purpose or special-purpose processor.

Claim 1:
A method for use at a first user equipment, UE (<NUM>), associated with a first vehicle (<NUM>), the method comprising, at the first UE (<NUM>):
(a) receiving (<NUM>) traffic information corresponding to at least two or more other vehicles;
(b) determining (<NUM>), based at least in part on the traffic information (<NUM>), that a second vehicle (<NUM>) and a third vehicle (<NUM>) of the two or more other vehicles is expected to be within a region comprising an intersection, the third vehicle (<NUM>) travelling behind the second vehicle (<NUM>) and in a same direction as the second vehicle (<NUM>);
(c) identifying (<NUM>), based at least in part on the traffic information , a traffic plan (<NUM>) for the first vehicle (<NUM>) to traverse at least a portion of the region;
(d) transmitting (<NUM>) an intersection traversal request to a second UE associated with the second vehicle (<NUM>), the intersection traversal request being based, at least in part, on the traffic plan (<NUM>), the intersection traversal request indicating that the second UE is to cause the second vehicle (<NUM>) to control a time at which the third vehicle (<NUM>) enters the region comprising the intersection, wherein the first UE and the second UE each comprise a compatible wireless communication capability, and the third vehicle does not comprise the compatible wireless communication capability;
(e) receiving (<NUM>) an intersection traversal acknowledgement transmitted by the second UE; and
(f) initiating (<NUM>) traversal of the region comprising the intersection by the first vehicle with respect to at least the second vehicle and the third vehicle based at least in part on the intersection traversal acknowledgement.