User interface assisted vehicle positioning

Abstract

Techniques for vehicle positioning are disclosed. In one aspect, a positioning engine aggregator of a host vehicle: determines a position estimate of the host vehicle based on one or more position orientations determined by one or more positioning engines of the host vehicle; receiving an input from a user interface (UI) of the host vehicle to correct the position estimate of the host vehicle; and updating the position estimate of the primary vehicle based on the input from the UI.

Description

Background Art 1. Technical Field

[0002] Aspects of the present disclosure relate generally to wireless communications.

[0003] 2. Description of related technologies

[0004] Wireless communication systems have evolved over many generations, including first generation analog wireless telephone service (1G), second generation (2G) digital wireless telephone service (including transitional 2.5G and 2.75G networks), third generation (3G) high speed data, wireless service with Internet capabilities, and fourth generation (4G) services (e.g., Long Term Evolution (LTE) or WiMax). There are many different types of wireless communication systems in use today, including cellular systems and personal communications service (PCS) systems. Examples of known cellular systems include the cellular analog Advanced Mobile Phone System (AMPS), and digital cellular systems based on code division multiple access (CDMA), frequency division multiple access (FDMA), time division multiple access (TDMA), Global System for Mobile Communications (GSM), and the like.

[0005] The fifth generation (5G) wireless standard, known as New Radio (NR), enables higher data transfer speeds, a greater number of connections, and better coverage, among other improvements. According to the Next Generation Mobile Networks Alliance, the 5G standard is designed to provide higher data rates, more accurate positioning (e.g., based on reference signals for positioning (RS-P), such as downlink, uplink, or sidelink positioning reference signals (PRS)), and other technical enhancements compared to previous standards. These enhancements, along with the use of higher frequency bands, advances in PRS processes and technologies, and high-density deployments of 5G, enable high-precision positioning based on 5G.

[0006] Vehicle-to-everything (V2X) communication technologies are being implemented to support autonomous driving applications, such as wireless communication between vehicles, between vehicles and roadside infrastructure, and between vehicles and pedestrians, especially taking advantage of the increased data rates and reduced latency of 5G. As a result, modern motor vehicles are increasingly adopting technologies to help drivers avoid drifting into adjacent lanes or making unsafe lane changes (such as lane departure warning (LDW)), or to warn drivers of other vehicles behind them when they are backing up, or to automatically brake when the vehicle in front of them suddenly stops or slows down (such as forward collision warning (FCW)), etc. The continued evolution of automotive technology aims to provide even greater safety benefits and ultimately provide automated driving systems (ADS) that can take charge of the entire driving task without user intervention.

[0007] There are six levels defined to achieve full automation. At level 0, human drivers do all the driving. At level 1, the advanced driver assistance system (ADAS) on the vehicle can sometimes assist the human driver in steering or braking / acceleration, but not both at the same time. At level 2, the ADAS on the vehicle can actually control both steering and braking / acceleration at the same time in some cases. The human driver must continue to focus all his attention at all times and perform the remaining driving tasks. At level 3, the ADS on the vehicle itself can perform all aspects of the driving task in some cases. In these cases, the human driver must be ready to take back control at any time when the ADS requests the human driver to take back control. In all other cases, the human driver performs the driving task. At level 4, the ADS on the vehicle itself can perform all driving tasks and monitor the driving environment, and basically do all the driving in some cases. In these cases, humans do not need to concentrate their attention. At level 5, the ADS on the vehicle can perform all driving in all cases. The human occupant is just a passenger and never needs to be involved in driving. Summary of the invention

[0008] The following presents a simplified summary of the invention related to one or more aspects disclosed herein. Therefore, the following summary of the invention should neither be considered as an exhaustive overview related to all conceived aspects, nor should it be considered to identify key or decisive elements related to all conceived aspects or to delineate the scope associated with any particular aspect. Therefore, the sole purpose of the following summary of the invention is to present certain concepts related to one or more aspects of the mechanisms disclosed herein in a brief form before the detailed embodiments presented below.

[0009] In one aspect, a method for vehicle positioning performed by a positioning engine aggregator of a host vehicle includes: determining a position estimate of the host vehicle based on one or more position fixes determined by one or more positioning engines of the host vehicle; receiving input from a user interface (UI) of the host vehicle to correct the position estimate of the host vehicle; and updating the position estimate of the host vehicle based on the input from the UI.

[0010] In one aspect, a positioning engine aggregator includes: a memory; at least one transceiver; and at least one processor, the at least one processor being communicatively coupled to the memory and the at least one transceiver, the at least one processor being configured to: determine a position estimate of a host vehicle based on one or more position fixes determined by one or more positioning engines of the host vehicle; receive input from a user interface (UI) of the host vehicle via the at least one transceiver to correct the position estimate of the host vehicle; and update the position estimate of the host vehicle based on the input from the UI.

[0011] In one aspect, the positioning engine aggregator includes components for determining a position estimate of a host vehicle based on one or more position fixes determined by one or more positioning engines of the host vehicle; components for receiving input from a user interface (UI) of the host vehicle to correct the position estimate of the host vehicle; and components for updating the position estimate of the host vehicle based on the input from the UI.

[0012] In one aspect, a non-transitory computer-readable medium stores computer-executable instructions that, when executed by a positioning engine aggregator, cause the positioning engine aggregator to: determine a position estimate of a host vehicle based on one or more position fixes determined by one or more positioning engines of the host vehicle; receive input from a user interface (UI) of the host vehicle to correct the position estimate of the host vehicle; and update the position estimate of the host vehicle based on the input from the UI.

[0013] Other objects and advantages associated with the various aspects disclosed herein will be apparent to those skilled in the art based on the drawings and detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The accompanying drawings are presented to aid in describing various aspects of the present disclosure and are provided solely for illustration and not limitation of the various aspects.

[0015] Figure 1 An example wireless communication system in accordance with aspects of the present disclosure is illustrated.

[0016] Figure 2A and Figure 2B Example wireless network structures according to aspects of the present disclosure are illustrated.

[0017] Figure 3 is a top view of a vehicle employing an integrated radar camera sensor behind a windshield in accordance with various aspects of the present disclosure.

[0018] Figure 4 An onboard computer architecture according to various aspects of the present disclosure is illustrated.

[0019] Figure 5 A comparison between an example of an existing sensor fusion system according to aspects of the present disclosure and an example of a sensor fusion system utilizing user interface (UI) information is illustrated.

[0020] Figure 6 is a diagram illustrating an example scenario in which one of the location fixes input to a positioning engine aggregator is incorrect in accordance with aspects of the present disclosure.

[0021] Figure 7An example method of correcting lane-level positioning errors using UI inputs according to aspects of the present disclosure is illustrated.

[0022] Figure 8 An example touch screen of an advanced driver assistance system (ADAS) of a vehicle according to aspects of the present disclosure is illustrated.

[0023] Fig. 9 Example methods of vehicle positioning according to aspects of the present disclosure are illustrated. DETAILED DESCRIPTION

[0024] Various aspects of the present disclosure are provided in the following description and related drawings for various examples provided for illustrative purposes. Alternative aspects may be designed without departing from the scope of the present disclosure. In addition, well-known elements of the present disclosure will not be described in detail or will be omitted to avoid making the relevant details of the present disclosure difficult to understand.

[0025] The words "exemplary" and / or "example" are used herein to mean "serving as an example, instance, or illustration." Any aspect described herein as "exemplary" and / or "example" is not necessarily to be construed as preferred or advantageous over other aspects. Likewise, the term "aspects of the disclosure" does not require that all aspects of the disclosure include the discussed feature, advantage, or mode of operation.

[0026] Those skilled in the art will appreciate that any of a variety of different techniques and methods may be used to represent the information and signals described below. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be mentioned throughout the following description may be represented by voltage, current, electromagnetic waves, magnetic fields or magnetic particles, light fields or optical particles, or any combination thereof, which depends in part on the specific application, in part on the desired design, in part on the corresponding technology, and so on.

[0027] In addition, many aspects are described in terms of a sequence of actions to be performed by, for example, elements of a computing device. It will be appreciated that the various actions described herein may be performed by a specific circuit (e.g., an application specific integrated circuit (ASIC)), by program instructions executed by one or more processors, or by a combination of the two. In addition, the sequence of actions described herein may be considered to be fully embodied in any form of non-transitory computer-readable storage medium, in which a corresponding computer instruction set is stored, which, when executed, will cause or command the associated processor of the device to perform the functions described herein. Therefore, various aspects of the present disclosure may be embodied in a variety of different forms, all of which have been contemplated to be within the scope of the claimed subject matter. In addition, for each of the various aspects described herein, the corresponding form of any such aspect may be described herein as, for example, "logic configured to perform the described actions."

[0028] As used herein, unless otherwise specified, the terms "user equipment" (UE) and "base station" are not intended to be specific or otherwise limited to any specific radio access technology (RAT). In general, a UE may be any wireless communication device (e.g., a mobile phone, a router, a tablet computer, a laptop computer, a consumer asset location device, a wearable device (e.g., a smart watch, glasses, an augmented reality (AR) / virtual reality (VR) head-mounted device, etc.), a vehicle (e.g., a car, a motorcycle, a bicycle, etc.), an Internet of Things (IoT) device, etc.) used by a user to communicate over a wireless communication network. A UE 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 device", "subscriber terminal", "subscriber station", "user terminal" or "UT", "mobile device", "mobile terminal", "mobile station" or variations thereof. In general, a UE may communicate with a core network via a RAN, and through the core network, the UE may connect to external networks such as the Internet and to other UEs. Of course, other mechanisms are also possible for the UE to connect to the core network and / or the Internet, such as through a wired access network, a wireless local area network (WLAN) network (eg, based on the Institute of Electrical and Electronics Engineers (IEEE) 802.11 specification, etc.), etc.

[0029] A base station may operate according to one of several RATs to communicate with a UE, depending on the network in which the base station is deployed, and may alternatively be referred to as an access point (AP), a network node, a Node B, an evolved Node B (eNB), a next generation eNB (ng-eNB), a new radio (NR) Node B (also referred to as a gNB or gNodeB), etc. A base station may be primarily used to support wireless access for UEs, including supporting data, voice, and / or signaling connections for supported UEs. In some systems, a base station may provide only edge node signaling functions, while in other systems, it may provide additional control and / or network management functions. The communication link by which a UE may transmit a signal to a base station is referred to as an uplink (UL) channel (e.g., a reverse traffic channel, a reverse control channel, an access channel, etc.). The communication link by which a base station may transmit a signal to a UE is referred to as a downlink (DL) or forward link channel (e.g., a paging channel, a control channel, a broadcast channel, a forward traffic channel, etc.). As used herein, the term "traffic channel (TCH)" may refer to an uplink / reverse traffic channel or a downlink / forward traffic channel.

[0030] The term "base station" may refer to a single physical transmit-receive point (TRP) or multiple physical TRPs that may or may not be co-located. For example, where the term "base station" refers to a single physical TRP, the physical TRP may be an antenna of the base station corresponding to a cell (or several cell sectors) of the base station. Where the term "base station" refers to multiple co-located physical TRPs, the physical TRP may be an antenna array of the base station (e.g., as in a multiple-input multiple-output (MIMO) system or where the base station employs beamforming). Where the term "base station" refers to multiple non-co-located physical TRPs, the physical TRP may be a distributed antenna system (DAS) (a network of spatially separated antennas connected to a common source via a transmission medium) or a remote radio head (RRH) (a remote base station connected to a serving base station). Alternatively, the non-co-located physical TRP may be a serving base station that receives measurement reports from a UE and a neighboring base station whose reference radio frequency (RF) signal the UE is measuring. Because, as used herein, a TRP is a point by which a base station transmits and receives wireless signals, references to transmitting from a base station or receiving at a base station should be understood to refer to a specific TRP of a base station.

[0031] In some implementations of supporting UE positioning, a base station may not support wireless access by the UE (e.g., may not support data, voice, and / or signaling connections for the UE), but may instead send a reference signal to be measured by the UE and / or may receive and measure a signal sent by the UE. Such a base station may be referred to as a positioning beacon (e.g., in the case of sending a signal to the UE) and / or as a position measurement unit (e.g., in the case of receiving and measuring a signal from the UE).

[0032] An "RF signal" includes an electromagnetic wave of a given frequency that transmits information through the space between a transmitter and a receiver. As used herein, a transmitter may transmit a single "RF signal" or multiple "RF signals" to a receiver. However, due to the propagation characteristics of RF signals through multipath channels, a receiver may receive multiple "RF signals" corresponding to each transmitted RF signal. The same transmitted RF signal on different paths between a transmitter and a receiver may be referred to as a "multipath" RF signal. As used herein, an RF signal may also be referred to as a "wireless signal" or simply a "signal" where it is clear from the context that the term "signal" refers to a wireless signal or an RF signal.

[0033] Figure 1An example wireless communication system 100 according to various aspects of the present disclosure is illustrated. The wireless communication system 100 (which may also be referred to as a wireless wide area network (WWAN)) may include various base stations 102 (labeled as "BS") and various UEs 104. The base stations 102 may include macrocell base stations (high-power cellular base stations) and / or small cell base stations (low-power cellular base stations). In one aspect, the macrocell base stations 102 may include eNBs and / or ng-eNBs (where the wireless communication system 100 corresponds to an LTE network) or gNBs (where the wireless communication system 100 corresponds to an NR network) or a combination of both, and the small cell base stations may include femtocells, picocells, microcells, etc.

[0034] The base stations 102 may collectively form a RAN and interface with a core network 170 (e.g., an evolved packet core (EPC) or a 5G core (5GC)) through a backhaul link 122, and interface with one or more location servers 172 (e.g., a location management function (LMF) or a secure user plane location (SUPL) location platform (SLP)) through the core network 170. The location server 172 may be part of the core network 170 or may be external to the core network 170. The location server 172 may be integrated with the base station 102. The UE 104 may communicate with the location server 172 directly or indirectly. For example, the UE 104 may communicate with the location server 172 via the base station 102 currently serving the UE 104. The UE 104 may also communicate with the location server 172 through another path, such as via an application server (not shown), via another network, such as via a wireless local area network (WLAN) access point (AP) (e.g., the AP 150 described below), etc. For signaling purposes, communications between UE 104 and location server 172 may be represented as an indirect connection (e.g., through core network 170, etc.) or a direct connection (e.g., as shown via direct connection 128), with intermediate nodes (if any) omitted from the signaling diagram for clarity.

[0035] Among other functions, the base station 102 may perform functions related to one or more of the following: delivering user data, radio channel encryption and decryption, integrity protection, header compression, mobility control functions (e.g., handover, dual connectivity), inter-cell interference coordination, connection establishment and release, load balancing, distribution of non-access stratum (NAS) messages, NAS node selection, synchronization, RAN sharing, multimedia broadcast multicast service (MBMS), subscriber and equipment tracking, RAN information management (RIM), paging, positioning, and delivery of warning messages. The base stations 102 may communicate with each other directly or indirectly (e.g., through EPC / 5GC) over a backhaul link 134, which may be wired or wireless.

[0036] Base station 102 may communicate wirelessly with UE 104. Each of base stations 102 may provide communication coverage for a corresponding geographic coverage area 110. In one aspect, one or more cells may be supported by base station 102 in each geographic coverage area 110. A "cell" is a logical communication entity used to communicate with a base station (e.g., on a certain frequency resource, which is referred to as a carrier frequency, component carrier, carrier, frequency band, etc.), and may be associated with an identifier (e.g., a physical cell identifier (PCI), an enhanced cell identifier (ECI), a virtual cell identifier (VCI), a cell global identifier (CGI), etc.) used to distinguish cells operating via the same or different carrier frequencies. In some cases, different cells may be configured according to different protocol types (e.g., machine type communication (MTC), narrowband IoT (NB-IoT), enhanced mobile broadband (eMBB), or other protocol types) that may provide access to different types of UEs. Because a cell is supported by a specific base station, the term "cell" may refer to one or both of the logical communication entity and the base station supporting it, depending on the context. In some cases, the term “cell” may also refer to a geographic coverage area (eg, a sector) of a base station, so long as a carrier frequency can be detected and used for communications within some portion of the geographic coverage area 110 .

[0037] Although the geographic coverage areas 110 of neighboring macrocell base stations 102 may partially overlap (e.g., in a handover area), some of the geographic coverage areas 110 may substantially overlap with the larger geographic coverage areas 110. For example, a small cell base station 102' (labeled "SC" for "small cell") may have a geographic coverage area 110' that substantially overlaps with the geographic coverage areas 110 of one or more macrocell base stations 102. A network that includes both small cell base stations and macrocell base stations may be referred to as a heterogeneous network. A heterogeneous network may also include a home eNB (HeNB), which may provide services to a restricted group called a closed subscriber group (CSG).

[0038] The communication link 120 between the base station 102 and the UE 104 may include uplink (also referred to as reverse link) transmissions from the UE 104 to the base station 102 and / or downlink (DL) (also referred to as forward link) transmissions from the base station 102 to the UE 104. The communication link 120 may use MIMO antenna technology, including spatial multiplexing, beamforming, and / or transmit diversity. The communication link 120 may be over one or more carrier frequencies. The allocation of carriers may be asymmetric for the downlink and uplink (e.g., more or fewer carriers may be allocated to the downlink than to the uplink).

[0039] The wireless communication system 100 may also include a WLAN access point (AP) 150 that communicates with a wireless local area network (WLAN) station (STA) 152 in an unlicensed spectrum (e.g., 5 GHz) via a communication link 154. When communicating in the unlicensed spectrum, the WLAN STA 152 and / or the WLAN AP 150 may perform a clear channel assessment (CCA) or a listen before talk (LBT) procedure prior to communication to determine whether a channel is available.

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

[0041] The wireless communication system 100 may also include a mmW base station 180 that can operate in millimeter wave (mmW) frequencies and / or near mmW frequencies to communicate with UE 182. Extremely high frequency (EHF) is part of the RF in the electromagnetic spectrum. EHF has a range of 30 GHz to 300 GHz, with a wavelength between 1 mm and 10 mm. Radio waves in this band may be referred to as millimeter waves. Near mmW can extend down to a frequency of 3 GHz, with a wavelength of 100 mm. The super high frequency (SHF) band extends between 3 GHz and 30 GHz, which is also referred to as centimeter waves. Communications using mmW / near mmW radio frequency bands have high path loss and relatively short distances. The mmW base station 180 and the UE 182 may utilize beamforming (transmitting and / or receiving) on ​​the mmW communication link 184 to compensate for the extremely high path loss and short distance. In addition, it should be understood that in an alternative configuration, one or more base stations 102 may also use mmW or near mmW and beamforming for transmission. Therefore, it should be understood that the foregoing illustrations are merely examples and should not be construed as limiting the various aspects disclosed herein.

[0042] Transmit beamforming is a technique for focusing an RF signal in a specific direction. Traditionally, when a network node (e.g., a base station) broadcasts an RF signal, it broadcasts the signal in all directions (omnidirectionally). With transmit beamforming, the network node determines where a given target device (e.g., a UE) is located (relative to the transmitting network node) and projects a stronger downlink RF signal in that specific direction, thereby providing a faster (in terms of data rate) and stronger RF signal to the receiving device. In order to change the directionality of the RF signal when transmitting, the network node can control the phase and relative amplitude of the RF signal at each of the one or more transmitters that broadcast the RF signal. For example, a network node can use an array of antennas (called a "phased array" or "antenna array") that creates RF beams that can be "steered" to point in different directions without actually moving the antennas. Specifically, the RF current from the transmitter is fed to each antenna in the correct phase relationship so that the radio waves from the separate antennas are added together to increase the radiation in the desired direction while canceling to suppress the radiation in the undesired direction.

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

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

[0045] The transmit beam and the receive beam may be spatially correlated. The spatial relationship means that parameters of a second beam (e.g., a transmit beam or a receive beam) for a second reference signal may be derived from information about a first beam (e.g., a receive beam or a transmit beam) for a first reference signal. For example, a UE may use a specific receive beam to receive a reference downlink reference signal (e.g., a synchronization signal block (SSB)) from a base station. The UE may then form a transmit beam for transmitting an uplink reference signal (e.g., a sounding reference signal (SRS)) to the base station based on the parameters of the receive beam.

[0046] Note that depending on the entity forming the "downlink" beam, the beam can be a transmit beam or a receive beam. For example, if the base station is forming a downlink beam to send a reference signal to the UE, the downlink beam is a transmit beam. However, if the UE is forming a downlink beam, the downlink beam is a receive beam that receives a downlink reference signal. Similarly, depending on the entity forming the "uplink" beam, the beam can be a transmit beam or a receive beam. For example, if the base station is forming an uplink beam, it is an uplink receive beam, while if the UE is forming an uplink beam, it is an uplink transmit beam.

[0047] The electromagnetic spectrum is typically subdivided into various categories, bands, channels, etc. based on frequency / wavelength. In 5G NR, two initial operating bands have been identified as frequency range designations FR1 (410 MHz–7.125 GHz) and FR2 (24.25 GHz–52.6 GHz). It should be understood that, despite the portion of FR1 being greater than 6 GHz, FR1 is often (interchangeably) referred to as the “sub-6 GHz” band in various documents and articles. A similar naming issue sometimes occurs with respect to FR2, which is often (interchangeably) referred to as the “millimeter wave” band in documents and articles, despite being distinct from the extremely high frequency (EHF) band (30 GHz–300 GHz) identified as the “millimeter wave” band by the International Telecommunication Union (ITU).

[0048] Frequencies between FR1 and FR2 are generally referred to as mid-band frequencies. Recent 5G NR research has identified the operating bands for these mid-band frequencies as frequency range designation FR3 (7.125 GHz–24.25 GHz). The bands falling within FR3 can inherit FR1 characteristics and / or FR2 characteristics, and thus can effectively extend the features of FR1 and / or FR2 to mid-band frequencies. In addition, higher frequency bands are currently being explored to extend 5G NR operations to more than 52.6 GHz. For example, three higher operating bands have been identified as frequency range designations FR4a or FR4-1 (52.6 GHz–71 GHz), FR4 (52.6 GHz–114.25 GHz), and FR5 (114.25 GHz–300 GHz). Each of these higher frequency bands falls within the EHF band.

[0049] In view of the above aspects, unless otherwise specifically stated, it should be understood that if the term "below 6 GHz" or the like is used herein, it can be broadly referred to as a frequency that can be less than 6 GHz, can be within FR1, or can include mid-band frequencies. In addition, unless otherwise specifically stated, it should be understood that if the term "millimeter wave" or the like is used herein, it can be broadly referred to as a frequency that can include mid-band frequencies, can be within FR2, FR4, FR4-a or FR4-1 and / or FR5, or can be within the EHF band.

[0050] In a multi-carrier system (such as 5G), one of the carrier frequencies is referred to as the "primary carrier" or "anchor carrier" or "primary serving cell" or "PCell", and the remaining carrier frequencies are referred to as "secondary carriers" or "secondary serving cells" or "SCells". In carrier aggregation, the anchor carrier is a carrier operating on the primary frequency (e.g., FR1) used by the UE 104 / 182 and the cell in which the UE 104 / 182 performs an initial radio resource control (RRC) connection establishment procedure or initiates an RRC connection reestablishment procedure. The primary carrier carries all common and UE-specific control channels and can be a carrier in a licensed frequency (however, this is not always the case). A secondary carrier is a carrier operating on a second frequency (e.g., FR2), which can be configured and used to provide additional radio resources once an RRC connection is established between the UE 104 and the anchor carrier. In some cases, the secondary carrier can be a carrier in an unlicensed frequency. The secondary carrier may contain only necessary signaling information and signals, for example, since the primary uplink carrier and the primary downlink carrier are usually UE-specific, those UE-specific signaling information and signals may not be present in the secondary carrier. This means that different UEs 104 / 182 in a cell may have different downlink primary carriers. The same is true for the uplink primary carrier. The network is able to change the primary carrier of any UE 104 / 182 at any time. This is done, for example, to balance the load on different carriers. Because a "serving cell" (whether PCell or SCell) corresponds to a carrier frequency / component carrier on which a base station communicates, the terms "cell", "serving cell", "component carrier", "carrier frequency", etc. are used interchangeably.

[0051] For example, still referring to Figure 1 , one of the frequencies used by the macrocell base station 102 may be an anchor carrier (or "PCell"), and the other frequencies used by the macrocell base station 102 and / or the mmW base station 180 may be secondary carriers ("SCells"). Simultaneous transmission and / or reception of multiple carriers enables the UE 104 / 182 to significantly increase its data transmission and / or reception rate. For example, two 20 MHz aggregated carriers in a multi-carrier system would theoretically result in a doubling of the data rate (i.e., 40 MHz) compared to the data rate obtained with a single 20 MHz carrier.

[0052] exist Figure 1 In the example of FIG. 1 , the UE illustrated (for simplicity, in Figure 1Any of the UEs 104 (shown as a single UE 104 in FIG. 1 ) may receive a signal 124 from one or more earth-orbiting space vehicles (SVs) 112 (e.g., satellites). In one aspect, the SVs 112 may be part of a satellite positioning system that the UEs 104 may use as an independent source of location information. A satellite positioning system typically includes a transmitter system (e.g., SVs 112) positioned to enable a receiver (e.g., UE 104) to determine its position on or above the earth based at least in part on a positioning signal (e.g., signal 124) received from the transmitter. Such a transmitter typically transmits a signal that is marked with a repeating pseudo-random noise (PN) code of a set number of chips. Although typically located in the SVs 112, the transmitters may sometimes be located on ground-based control stations, base stations 102, and / or other UEs 104. The UEs 104 may include one or more dedicated receivers that are specifically designed to receive the signal 124 in order to derive geographic location information from the SVs 112.

[0053] In a satellite positioning system, the use of signal 124 may be enhanced by various satellite-based augmentation systems (SBAS) that may be associated with or otherwise enabled for use with one or more global and / or regional navigation satellite systems. For example, SBAS may include augmentation systems that provide integrity information, differential corrections, etc., such as Wide Area Augmentation System (WAAS), European Geostationary Navigation Overlay Service (EGNOS), Multifunction Satellite Augmentation System (MSAS), Global Positioning System (GPS) Assisted Geographic Augmented Navigation or GPS and Geographic Augmented Navigation System (GAGAN), etc. Thus, as used herein, a satellite positioning system may include any combination of one or more global and / or regional navigation satellites associated with such one or more satellite positioning systems.

[0054] In one aspect, SV 112 may additionally or alternatively be part of one or more non-terrestrial networks (NTNs). In an NTN, SV 112 is connected to an earth station (also referred to as a ground station, NTN gateway, or gateway), which in turn is connected to an element in a 5G network, such as an improved base station 102 (without a ground antenna) or a network node in a 5GC. This element in turn will provide access to other elements in the 5G network, and ultimately provide access to entities outside the 5G network (such as Internet web servers and other user devices). In this way, instead of or in addition to communication signals from a ground base station 102, a UE 104 can receive communication signals (e.g., signal 124) from a SV 112.

[0055] In particular, leveraging the increased data rates and reduced latency of NR, vehicle-to-everything (V2X) communication technology is being implemented to support intelligent transportation system (ITS) applications, such as wireless communications between vehicles (vehicle-to-vehicle (V2V)), between vehicles and roadside infrastructure (vehicle-to-infrastructure (V2I)), and between vehicles and pedestrians (vehicle-to-pedestrian (V2P)). The goal is to enable vehicles to sense the environment around them and communicate that information to other vehicles, infrastructure, and personal mobile devices. Such vehicle communications will enable safety, mobility, and environmental advances that current technology cannot provide. Once fully implemented, the technology is expected to reduce non-fault vehicle collisions by 80%.

[0056] Still reference Figure 1 , the wireless communication system 100 may include a plurality of V-UEs 160 that may communicate with a base station 102 over a communication link 120 using a Uu interface (i.e., an air interface between a UE and a base station). The V-UEs 160 may also communicate directly with each other over a wireless side link 162, with a roadside unit (RSU) 164 (roadside access point) over a wireless side link 166, or with a sidelink-capable UE 104 over a wireless side link 168 using a PC5 interface (i.e., an air interface between sidelink-capable UEs). A wireless side link (or simply "sidelink") is an adaptation of a core cellular network (e.g., LTE, NR) standard that allows direct communication between two or more UEs without communicating through a base station. Sidelink communications may be unicast or multicast and may be used for device-to-device (D2D) media sharing, V2V communications, V2X communications (e.g., cellular V2X (cV2X) communications, enhanced V2X (eV2X) communications, etc.), emergency rescue applications, etc. One or more V-UEs in a group of V-UEs 160 utilizing sidelink communication may be within the geographic coverage area 110 of the base station 102. Other V-UEs 160 in such a group may be outside the geographic coverage area 110 of the base station 102, or otherwise unable to receive transmissions from the base station 102. In some cases, each group of V-UEs 160 communicating via sidelink communication may utilize a one-to-many (1:M) system, where each V-UE 160 transmits to each other V-UE 160 in the group. In some cases, the base station 102 facilitates the scheduling of resources for sidelink communication. In other cases, the sidelink communication is performed between the V-UEs 160 without involving the base station 102.

[0057] In one aspect, the sidelinks 162, 166, 168 can operate over a wireless communication medium of interest that can be shared with other vehicles and / or infrastructure access points and other wireless communications between other RATs. A "medium" can include one or more time, frequency, and / or spatial communication resources (e.g., covering one or more channels across one or more carriers) associated with wireless communications between one or more transmitter / receiver pairs.

[0058] In one aspect, the sidelinks 162, 166, 168 may be cV2X links. The first generation of cV2X has been standardized in LTE, and the next generation is expected to be defined in NR. cV2X is a cellular technology that also enables device-to-device communications. In the United States and Europe, cV2X is expected to operate in the licensed ITS bands below 6 GHz. Other frequency bands may be allocated in other countries. Thus, as a specific example, the medium of interest utilized by the sidelinks 162, 166, 168 may correspond to at least a portion of the licensed ITS bands below 6 GHz. However, the present disclosure is not limited to this frequency band or cellular technology.

[0059] In one aspect, the side links 162, 166, 168 may be dedicated short-range communication (DSRC) links. DSRC is a unidirectional or bidirectional short-range to medium-range wireless communication protocol that uses the Wireless Access to Vehicular Environment (WAVE) protocol (also known as IEEE 802.11p) for V2V, V2I, and V2P communications. IEEE 802.11p is an approved modification to the IEEE 802.11 standard and operates in the licensed ITS band of 5.9 GHz (5.85 GHz-5.925 GHz) in the United States. In Europe, IEEE 802.11p operates in the ITS G5A band (5.875 GHz-5.905 MHz). Other frequency bands may be allocated in other countries. The V2V communications briefly described above occur on a safety channel, which is typically a 10 MHz channel dedicated to safety purposes in the United States. The rest of the DSRC band (total bandwidth is 75 MHz) is intended for other services of interest to drivers, such as road regulations, toll collection, parking automation, etc. Thus, as a specific example, the medium of interest utilized by the sidelinks 162, 166, 168 may correspond to at least a portion of the licensed ITS band at 5.9 GHz.

[0060] Alternatively, the medium of interest may correspond to at least a portion of an unlicensed frequency band shared among various RATs. Although different licensed frequency bands have been reserved for certain communication systems (e.g., by government entities such as the Federal Communications Commission (FCC) in the United States), these systems (particularly those employing small cell access points) have recently expanded operations into unlicensed frequency bands such as the Unlicensed National Information Infrastructure (U-NII) band used by wireless local area network (WLAN) technologies (most notably the IEEE 802.11x WLAN technology commonly referred to as "Wi-Fi"). Example systems of this type include different variants of CDMA systems, TDMA systems, FDMA systems, orthogonal FDMA (OFDMA) systems, single carrier FDMA (SC-FDMA) systems, and the like.

[0061] Communication between V-UEs 160 is referred to as V2V communication, communication between V-UEs 160 and one or more RSUs 164 is referred to as V2I communication, and communication between V-UEs 160 and one or more UEs 104 (where these UEs 104 are P-UEs) is referred to as V2P communication. V2V communication between V-UEs 160 may include, for example, information about the position, speed, acceleration, heading, and other vehicle data of these V-UEs 160. V2I information received at the V-UE 160 from one or more RSUs 164 may include, for example, road rules, parking automation information, etc. V2P communication between V-UEs 160 and UEs 104 may include information about, for example, the position, speed, acceleration, and heading of the V-UEs 160 and the position, speed (for example, in the case where the UE 104 is carried by a user on a bicycle), and heading of the UEs 104.

[0062] Note that although Figure 1 Only two of the UEs are illustrated as V-UEs (V-UE 160), but any of the illustrated UEs (e.g., UE 104, 152, 182, 190) may be V-UEs. In addition, although only these V-UEs 160 and a single UE 104 have been illustrated as being connected via a side link, Figure 1Any of the illustrated UEs, whether V-UEs, P-UEs, etc., may be capable of sidelink communications. Furthermore, although only UE 182 is described as being capable of beamforming, any of the illustrated UEs (including V-UE 160) may be capable of beamforming. In the event that V-UEs 160 are capable of beamforming, they may beamform toward each other (i.e., toward other V-UEs 160), toward RSUs 164, toward other UEs (e.g., UEs 104, 152, 182, 190), etc. Thus, in some cases, V-UE 160 may utilize beamforming on sidelinks 162, 166, and 168.

[0063] The wireless communication system 100 may also include one or more UEs (such as UE 190) indirectly connected to one or more communication networks via one or more device-to-device (D2D) peer-to-peer (P2P) links. Figure 1 In the example of FIG. 1 , UE 190 has a D2D P2P link 192 with one of UEs 104 connected to one of base stations 102 (e.g., UE 190 can indirectly obtain cellular connectivity through the D2D P2P link), and has a D2D P2P link 194 with WLAN STA 152 connected to WLAN AP 150 (UE 190 can indirectly obtain WLAN-based Internet connectivity through the D2D P2P link). In an example, D2D P2P links 192 and 194 can be supported by any well-known D2D RAT, such as LTE Direct (LTE-D), WiFi Direct (WiFi-D), Bluetooth ® Etc. As another example, D2D P2P links 192 and 194 may be side links, as described above with reference to side links 162 , 166 , and 168 .

[0064] Figure 2AAn example wireless network structure 200 is illustrated. For example, the 5GC 210 (also referred to as the Next Generation Core (NGC)) can be functionally viewed as a control plane (C-plane) function 214 (e.g., UE registration, authentication, network access, gateway selection, etc.) and a user plane (U-plane) function 212 (e.g., UE gateway function, access to data networks, IP routing, etc.), which operate in conjunction to form a core network. The user plane interface (NG-U) 213 and the control plane interface (NG-C) 215 connect the gNB 222 to the 5GC 210, and specifically to the user plane function 212 and the control plane function 214, respectively. In an additional configuration, the ng-eNB 224 can also be connected to the 5GC 210 via the NG-C 215 to the control plane function 214 and the NG-U 213 to the user plane function 212. In addition, the ng-eNB 224 can communicate directly with the gNB 222 via the backhaul connection 223. In some configurations, the next generation RAN (NG-RAN) 220 may have one or more gNBs 222, while other configurations include one or more of ng-eNBs 224 and gNBs 222. Either gNB 222 or ng-eNB 224 (or both) may communicate with one or more UEs 204 (e.g., any of the UEs described herein), in Figure 2A In the example, the one or more UEs are V-UEs.

[0065] Another optional aspect may include a location server 230 that can communicate with the 5GC 210 to provide location assistance for the UE 204. The location server 230 may be implemented as multiple separate servers (e.g., physically separate servers, different software modules on a single server, different software modules distributed across multiple physical servers, etc.), or alternatively may each correspond to a single server. The location server 230 may be configured to support one or more location services for the UE 204 that may be connected to the location server 230 via the core network, the 5GC 210, and / or via the Internet (not illustrated). In addition, the location server 230 may be integrated into a component of the core network, or alternatively may be external to the core network (e.g., a third-party server, such as an original equipment manufacturer (OEM) server or a service server).

[0066] Figure 2B Another example wireless network structure 240 is illustrated. 5GC 260 (which may correspond to Figure 2AThe 5GC 210 in the 5GC 210 can be functionally viewed as a control plane function provided by an access and mobility management function (AMF) 264, and a user plane function provided by a user plane function (UPF) 262, which operate in conjunction to form a core network (i.e., 5GC 260). The functions of the AMF 264 include: registration management, connection management, reachability management, mobility management, lawful interception, transmission of session management (SM) messages between one or more UEs 204 (e.g., V-UE) and a session management function (SMF) 266, a transparent proxy service for routing SM messages, access authentication and access authorization, transmission of short message service (SMS) messages between the UE 204 and a short message service function (SMSF) (not shown), and security anchor functionality (SEAF). The AMF 264 also interacts with an authentication server function (AUSF) (not shown) and the UE 204, and receives an intermediate key established as a result of the UE 204 authentication process. In the case of authentication based on the UMTS (Universal Mobile Telecommunications System) Subscriber Identity Module (USIM), the AMF 264 retrieves security material from the AUSF. The functionality of the AMF 264 also includes security context management (SCM). The SCM receives keys from the SEAF, which it uses to derive access network-specific keys. The functionality of the AMF 264 also includes location service management for regulatory services, for the transmission of location service messages between the UE 204 and the Location Management Function (LMF) 270 (which acts as a location server 230), for the transmission of location service messages between the NG-RAN 220 and the LMF 270, for the allocation of Evolved Packet System (EPS) bearer identifiers for interoperation with EPS, and UE 204 mobility event notifications. In addition, the AMF 264 also supports functionality for non-3GPP (Third Generation Partnership Project) access networks.

[0067] The functions of UPF 262 include: acting as an anchor point for intra-RAT / inter-RAT mobility (when applicable), acting as an external protocol data unit (PDU) session point for interconnection to a data network (not shown), providing packet routing and forwarding, packet inspection, user plane policy rule enforcement (e.g., gating, redirection, traffic steering), lawful interception (user plane collection), traffic usage reporting, user plane quality of service (QoS) handling (e.g., uplink / downlink rate enforcement, reflective QoS marking in downlink), uplink traffic verification (service data flow (SDF) to QoS flow mapping), transport level packet marking in uplink and downlink, downlink packet buffering and downlink data notification triggering, and transmitting and forwarding one or more "end markers" to the source RAN node. UPF 262 may also support the delivery of location service messages between UE 204 and a location server (such as SLP 272) on the user plane.

[0068] The functions of SMF 266 include session management, UE Internet Protocol (IP) address allocation and management, selection and control of user plane functions, traffic steering configuration for routing traffic to the correct destination at UPF 262, partial control of policy enforcement and QoS, and downlink data notification. The interface through which SMF 266 communicates with AMF 264 is called the N11 interface.

[0069] Another optional aspect may include an LMF 270 that can communicate with the 5GC 260 to provide location assistance for the UE 204. The LMF 270 can be implemented as multiple separate servers (e.g., physically separate servers, different software modules on a single server, different software modules distributed across multiple physical servers, etc.), or alternatively can each correspond to a single server. The LMF 270 can be configured to support one or more location services for the UE 204, which can be connected to the LMF 270 via the core network, the 5GC 260, and / or via the Internet (not illustrated). SLP 272 may support similar functionality as LMF 270, but LMF 270 may communicate with AMF 264, NG-RAN 220, and UE 204 on a control plane (e.g., using interfaces and protocols intended to carry signaling messages rather than voice or data), and SLP 272 may communicate with UE 204 and external clients (e.g., third-party servers 274) on a user plane (e.g., using protocols intended to carry voice and / or data, such as Transmission Control Protocol (TCP) and / or IP).

[0070] Yet another optional aspect may include a third-party server 274 that may communicate with the LMF 270, the SLP 272, the 5GC 260 (e.g., via the AMF 264 and / or the UPF 262), the NG-RAN 220, and / or the UE 204 to obtain location information (e.g., a location estimate) of the UE 204. Thus, in some cases, the third-party server 274 may be referred to as a location service (LCS) client or an external client. The third-party server 274 may be implemented as multiple separate servers (e.g., physically separate servers, different software modules on a single server, different software modules distributed across multiple physical servers, etc.), or alternatively may each correspond to a single server.

[0071] The user plane interface 263 and the control plane interface 265 connect the 5GC 260, and specifically the UPF 262 and the AMF 264, respectively, to one or more gNBs 222 and / or ng-eNBs 224 in the NG-RAN 220. The interface between the gNB 222 and / or ng-eNB 224 and the AMF 264 is referred to as the "N2" interface, and the interface between the gNB 222 and / or ng-eNB 224 and the UPF 262 is referred to as the "N3" interface. The gNBs 222 and / or ng-eNBs 224 of the NG-RAN 220 may communicate directly with each other via a backhaul connection 223 referred to as an "Xn-C" interface. One or more of the gNBs 222 and / or ng-eNBs 224 may communicate with one or more UEs 204 via a wireless interface referred to as a "Uu" interface.

[0072] The functionality of the gNB 222 may be divided between a gNB central unit (gNB-CU) 226, one or more gNB distributed units (gNB-DU) 228, and one or more gNB radio units (gNB-RU) 229. The gNB-CU 226 is a logical node that includes base station functions other than those specifically assigned to the gNB-DU 228, including delivery of user data, mobility control, radio access network sharing, positioning, session management, and the like. More specifically, the gNB-CU 226 generally hosts the radio resource control (RRC), service data adaptation protocol (SDAP), and packet data convergence protocol (PDCP) protocols of the gNB 222. The gNB-DU 228 is a logical node that generally hosts the radio link control (RLC) and medium access control (MAC) layers of the gNB 222. Its operation is controlled by the gNB-CU 226. One gNB-DU 228 may support one or more cells, and one cell is supported by only one gNB-DU 228. The interface 232 between the gNB-CU 226 and one or more gNB-DUs 228 is referred to as the "F1" interface. The physical (PHY) layer functionality of the gNB 222 is typically hosted by one or more independent gNB-RUs 229, which perform functions such as power amplification and signal transmission / reception. The interface between the gNB-DU 228 and the gNB-RU 229 is referred to as the "Fx" interface. Thus, the UE 204 communicates with the gNB-CU 226 via the RRC layer, the SDAP layer, and the PDCP layer, communicates with the gNB-DU 228 via the RLC layer and the MAC layer, and communicates with the gNB-RU 229 via the PHY layer.

[0073] Autonomous and semi-autonomous driving safety technologies use a combination of hardware (sensors, cameras, and radars) and software to help vehicles identify specific safety risks so that they can warn the driver to take action (in the case of advanced driver assistance systems (ADAS)) or they can take action themselves (in the case of automated driving systems (ADS)) to avoid collisions. Vehicles equipped with ADAS or ADS include one or more camera sensors mounted on the vehicle, which capture images of the front, and possibly the rear and side scenes of the vehicle. Radar systems can also be used to detect objects along the road and possibly behind and on the side of the vehicle. Radar systems use RF waves to determine the range, direction, speed, and / or height of objects along the road. More specifically, a transmitter sends a pulse of an RF wave that bounces back from any object in its path. The pulse reflected from the object returns a small portion of the energy of the RF wave to the receiver, which is usually located at the same location as the transmitter. Cameras and radars are usually oriented to capture their respective versions of the same scene.

[0074] A processor within the vehicle, such as a digital signal processor (DSP), analyzes the captured camera images and radar frames and attempts to identify objects within the captured scene. Such objects can be other vehicles, pedestrians, road signs, objects within the road of travel, etc. Radar systems provide reasonably accurate measurements of object distance and speed in all weather conditions. However, radar systems typically do not have sufficient resolution to identify features of detected objects. However, camera sensors typically do provide sufficient resolution to identify object features. Cues to object shape and appearance extracted from the captured images can provide sufficient characteristics for the classification of different objects. Given the complementary nature of the two sensors, data from the two sensors can be combined (called "fusion") in a single system for improved performance.

[0075] To further enhance ADAS and ADS systems, especially at Level 3 and above, autonomous and semi-autonomous vehicles can take advantage of high-definition (HD) map data sets that contain significantly more detailed information and true ground absolute accuracy than currently found in conventional resources. Such HD maps can provide accuracy within 7cm to 10cm absolute range, a highly detailed catalog of all fixed physical assets associated with the road, such as road lanes, road edges, shoulders, dividers, traffic signals, signage, paint markings, poles and other data that helps autonomous / semi-autonomous vehicles safely navigate roads and intersections. HD maps can also provide electronic horizon predictive awareness, which enables autonomous / semi-autonomous vehicles to know what is ahead.

[0076] Note that an autonomous or semi-autonomous vehicle may be, but need not be, a V-UE. Likewise, a V-UE may be, but need not be, an autonomous or semi-autonomous vehicle. An autonomous or semi-autonomous vehicle is a vehicle equipped with ADAS or ADS. A V-UE is a vehicle with cellular connectivity to a 5G or other cellular network. An autonomous or semi-autonomous vehicle that uses or is capable of using cellular technology for positioning and / or navigation is a V-UE.

[0077] Reference now Figure 3 , illustrates a vehicle 300 (referred to as the “ego vehicle” or “host vehicle”) that includes a radar camera sensor module 320 located in an interior compartment behind a windshield 312 of the vehicle 300. The radar camera sensor module 320 includes a radar assembly that is configured to transmit radar signals through the windshield 312 in a horizontal coverage area 350 (shown by a dashed line) and receive reflected radar signals reflected from any object within the coverage area 350. The radar camera sensor module 320 also includes a camera assembly that is used to capture images based on light waves seen and captured through the windshield 312 in a horizontal coverage area 360 (shown by a dashed line).

[0078] Although Figure 3 An example is illustrated in which the radar assembly and the camera assembly are co-located components in a shared housing, but as will be appreciated, they may be separately housed in different locations within the vehicle 300. For example, the camera may be Figure 3 , and the radar assembly may be located in the guardrail or front bumper of the vehicle 300. In addition, although Figure 3 The radar camera sensor module 320 is illustrated as being located behind the windshield 312, but it may alternatively be located in the top sensor array or elsewhere. Figure 3 Only a single radar camera sensor module 320 is illustrated, but as will be appreciated, the vehicle 300 may have multiple radar camera sensor modules 320 pointing in different directions (to the side, forward, rearward, etc.). The various radar camera sensor modules 320 may be under the "skin" of the vehicle (e.g., behind the windshield 312, door panels, bumpers, guardrails, etc.) or in an overhead sensor array.

[0079] Radar camera sensor module 320 may detect one or more objects (or no objects) relative to vehicle 300. Figure 3In the example of FIG. 3 , there are two objects that the camera radar sensor module 320 can detect within the horizontal coverage areas 350 and 360: vehicles 330 and 340. The radar camera sensor module 320 can estimate parameters of the detected objects, such as location, range, direction, speed, size, classification (e.g., vehicle, pedestrian, road sign, etc.), etc. The radar camera sensor module 320 can be used onboard the vehicle 300 for automotive safety applications, such as adaptive cruise control (ACC), forward collision warning (FCW), collision mitigation or avoidance via autonomous braking, lane departure warning (LDW), etc.

[0080] Co-locating the camera and radar permits these components to share electronics and signal processing, and in particular enables early radar camera data fusion. For example, the radar and camera can be integrated onto a single board. Joint radar camera alignment techniques can be employed to align both the radar and the camera. However, co-location of the radar and camera is not required for practicing the techniques described herein.

[0081] Figure 4 An onboard computer (OBC) 400 of a vehicle 300 according to various aspects of the present disclosure is illustrated. In one aspect, the OBC 400 may be part of an ADAS or ADS. The OBC 400 may also be a V-UE of the vehicle 300. The OBC 400 includes a non-transitory computer-readable storage medium (i.e., a memory 404) and one or more processors 406 that communicate with the memory 404 via a data bus 408. The memory 404 includes one or more storage modules storing computer-readable instructions that can be executed by the one or more processors 406 to perform the functions of the OBC 400 described herein. For example, the one or more processors 406 in combination with the memory 404 can implement various operations described herein.

[0082] One or more radar camera sensor modules 320 are coupled to the OBC 400 (for simplicity, Figure 4 In some aspects, the radar camera sensor module 320 includes at least one camera 412, at least one radar 414, and optionally a light detection and ranging (LiDAR) sensor 416. The OBC 400 also includes one or more system interfaces 410 that connect one or more processors 406 to the radar camera sensor module 320 via a data bus 408, and optionally, to other vehicle subsystems (not shown).

[0083] At least in some cases, the OBC 400 also includes one or more wireless wide area network (WWAN) transceivers 430 configured to communicate via one or more wireless communication networks (not shown) (such as NR networks, LTE networks, global system for mobile communications (GSM) networks, etc.). The one or more WWAN transceivers 430 can be connected to one or more antennas (not shown) for communicating with other network nodes (such as other V-UEs, pedestrian UEs, infrastructure access points, roadside units (RSUs), base stations (e.g., eNBs, gNBs), etc.) via at least one designated RAT (e.g., NR, LTE, GSM, etc.) over a wireless communication medium of interest (e.g., certain time / frequency resource sets in a specific spectrum). The one or more WWAN transceivers 430 can be configured in various ways for transmitting and encoding signals (e.g., messages, indications, information, etc.) according to the designated RAT and vice versa for receiving and decoding signals (e.g., messages, indications, information, pilots, etc.).

[0084] At least in some cases, the OBC 400 also includes one or more short-range wireless transceivers 440 (e.g., Wi-Fi transceivers, Bluetooth transceivers, etc.). The one or more short-range wireless transceivers 440 may be connected to one or more antennas (not shown) for communicating with other network nodes (such as other V-UEs, pedestrian UEs, infrastructure access points, RSUs, etc.) via at least one designated RAT (e.g., cellular vehicle-to-everything (C-V2X), IEEE 802.11p (also known as wireless access for vehicle environments (WAVE)), dedicated short-range communications (DSRC), etc.) over a wireless communication medium of interest. The one or more short-range wireless transceivers 440 may be configured in various ways for sending and encoding signals (e.g., messages, indications, information, etc.) according to the designated RAT and conversely for receiving and decoding signals (e.g., messages, indications, information, pilots, etc.).

[0085] As used herein, a "transceiver" may include transmitter circuitry, receiver circuitry, or a combination thereof, but need not provide both transmit and receive functionality in all designs. For example, low-functionality receiver circuitry may be employed in some designs to reduce cost (e.g., a receiver chip or similar circuitry that simply provides low-level sniffing) when it is not necessary to provide full communication.

[0086] At least in some cases, the OBC 400 also includes a global navigation satellite system (GNSS) receiver 450. The GNSS receiver 450 may be connected to one or more antennas (not shown) for receiving satellite signals. The GNSS receiver 450 may include any suitable hardware and / or software for receiving and processing GNSS signals. The GNSS receiver 450 requests information and operations from other systems as appropriate, and performs the calculations required to determine the position of the vehicle 300 using measurements obtained by any suitable GNSS algorithm.

[0087] In one aspect, the OBC 400 may utilize one or more WWAN transceivers 430 and / or one or more short-range wireless transceivers 440 to download one or more maps 402, which may then be stored in the memory 404 and used for vehicle navigation. The map 402 may be one or more high-definition (HD) maps that may provide a highly detailed inventory of all fixed physical assets associated with the road, such as road lanes, road edges, shoulders, dividers, traffic signals, signs, paint markings, poles, and other data that assists the vehicle 300 in safely navigating roads and intersections, with an accuracy within an absolute range of 7 cm to 10 cm. The map 402 may also provide electronic horizon prediction awareness, which enables the vehicle 300 to know what is ahead.

[0088] The vehicle 300 may include one or more sensors 420 that may be coupled to the one or more processors 406 via one or more system interfaces 410. The one or more sensors 420 may provide components for sensing or detecting information related to the state and / or environment of the vehicle 300, such as speed, heading (e.g., compass heading), headlight status, fuel consumption, etc. By way of example, the one or more sensors 420 may include an odometer, a speedometer, a tachometer, an accelerometer (e.g., a micro-electromechanical system (MEMS) device), a gyroscope, a geomagnetic sensor (e.g., a compass), an altimeter (e.g., a barometric altimeter), etc. Although shown as being located external to the OBC 400, some of these sensors 420 may be located on the OBC 400 and some may be located elsewhere in the vehicle 300.

[0089] The OBC 400 may also include a positioning component 418. The positioning component 418 may include a hardware circuit that is part of or coupled to the one or more processors 406, which, when executed, causes the OBC 400 to perform the functionality described herein. In other aspects, the positioning component 418 may be external to the one or more processors 406 (e.g., part of a positioning processing system, integrated with another processing system, etc.). Alternatively, the positioning component 418 may be one or more memory modules stored in the memory 404, which, when executed by the one or more processors 406 (or the positioning processing system, another processing system, etc.), causes the OBC 400 to perform the functionality described herein. As a specific example, the positioning component 418 may include multiple positioning engines, a positioning engine aggregator, a sensor fusion module, etc. Figure 4 Possible locations for a location component 418 are illustrated, which may be, for example, part of the memory 404, the one or more processors 406, or any combination thereof, or may be a separate component.

[0090] In one aspect, camera 412 may capture the viewing area of ​​camera 412 at some periodic rate (e.g., Figure 3 In one aspect, radar 414 may capture image frames (also referred to herein as camera frames) of a scene within the viewing area of ​​camera 414 (illustrated as horizontal coverage area 360 in FIG. 1 ). Figure 3 4 and 5. The radar frames of the scene within the horizontal coverage area 350 (illustrated in FIG. 4 ) are shown. The periodicity rate at which the camera 412 and the radar 414 capture their respective frames may be the same or different. Each camera and radar frame may be time stamped. Thus, in the case of different periodicity rates, the timestamps may be used to select the captured camera and radar frames simultaneously or nearly simultaneously for further processing (e.g., fusion).

[0091] In modern positioning, navigation, and timing (PNT) technologies, most solutions are developed in a way that the algorithms are automated, with very little human interaction after the estimation process begins. To improve PNT performance for lane-level navigation, for example, recent advances are closely related to more sensors for perception and fusion to improve localization accuracy and ultimately determine exactly in which lane a vehicle is located.

[0092] The benefits of lane-level navigation solutions include: (1) navigation route determination and planning; (2) arrival time estimation, (3) speed limit determination and input for autonomous driving, and (4) safety information warnings and real-time updates to navigation decisions. However, humans can be another "sensor" for autonomous or semi-autonomous driving purposes. Specifically, user interaction or user interface (UI) can be utilized to assist PNT algorithms and achieve the next level of accuracy, precision, robustness, and usability.

[0093] Therefore, the present disclosure provides techniques for utilizing UI feedback information for real-time PNT scenarios. These techniques improve real-time PNT performance in lane-level navigation, such as error correction across tracks (i.e., wrong lane) and along tracks on the fly, and reduce convergence time (e.g., first position determination and recovery from signal outage environments). From a protocol perspective, the following considerations are raised: (1) when to actively request UI information, (2) after receiving UI information, how to verify the information and correct potential PNT problems, and (3) what methods to use to obtain UI input.

[0094] Figure 5 A comparison between an example of an existing sensor fusion system according to various aspects of the present disclosure and an example of a sensor fusion system utilizing UI information is illustrated. As shown in Figure 500, an existing sensor fusion system may include multiple sensor systems and positioning engines, such as a global navigation satellite system (GNSS), an inertial measurement unit (IMU), a terrestrial location engine (TLE) (using a cellular positioning method such as time difference of arrival (TDOA), round trip time (RTT), etc.), one or more maps (e.g., map 402), an odometer, a camera, and a computer vision engine, etc. These sensor systems / positioning engines may be given a priority order, with GNSS generally being given the highest priority. Each sensor system / positioning engine may also use different sensors. For example, GNSS may use a GNSS receiver (e.g., GNSS receiver 450), TLE may use a WWAN transceiver (e.g., one or more WWAN transceivers 430), IMU may use various motion sensors (e.g., gyroscopes, compasses, accelerometers, magnetometers, etc.), cameras and computer vision engines may use radar camera sensor modules (e.g., radar camera sensor modules 320), etc.

[0095] Existing sensor fusion systems use multiple sensors to collect more information for the sensor fusion module to process. This results in higher hardware costs. Although the system is highly autonomous, there is low recoverability when problems occur (for example, the system remains "stuck" in the wrong lane), which reduces the user / driver experience. In contrast, as shown in Figure 550, a sensor fusion system that utilizes UI information can use fewer sensors because it allows the UI to participate in user feedback. This can result in lower hardware costs (due to the need for fewer sensors) and higher recoverability when problems occur. Specifically, when a problem occurs, the system can seek user input via the UI to resolve the problem, which can improve user experience, recovery speed, and lane-level navigation performance. Note that the UI that replaces the TLE, odometer, and camera and computer vision engine is only an example of a sensor fusion system that requires fewer sensors and is not meant to be a limiting example.

[0096] Regarding when to actively request UI input, there are various events that can trigger a request for UI input. For example, the occurrence of inconsistent estimation events (including differences between different GNSS engines) from different positioning engines (PEs) can trigger a request for UI input. As another example, if the lane data from the map is outdated or does not match the real-time perception information (e.g., from the camera and computer vision engine), it can trigger a request for UI input. As another example, if there is a sensory data interruption due to a bad sensing environment, it can trigger a request for UI input. The bad sensing environment can be attributed to heavy snow, rain or fog on the road that affects camera sensing, or to no GNSS signal strength or low GNSS signal strength in tunnels or deep urban canyons. As another example, when the incoming crowdsourced lane-level information update requires UI verification, a request for UI input can be triggered. For example, if a particular lane is in a temporary construction, then check with the UI to determine whether the lane-level information is up to date. Or as another example, a request for UI input can be triggered to determine whether a previously reported car accident still exists.

[0097] Regarding how to verify UI information and correct potential PNT problems, in a GNSS-based positioning engine, for example, when the wrong integer ambiguity resolution (IAR) is fixed, UI-assisted technology can correct inaccurate horizontal positioning solutions (e.g., which channel). More specifically, if the unique properties of the received carrier signal can be utilized, the highest GNSS accuracy can be achieved. These properties include millimeter-level precision with which the carrier phase can be tracked, the frequency diversity of the carrier, and the knowledge that certain functions of the carrier are integer values. The process of utilizing these properties is called IAR. If a GNSS-based positioning engine calculates an incorrect IAR, the UI input can be used to correct the error. However, when the wrong IAR is "fixed", this means that the carrier phase ambiguity is fixed to an integer value (ie, IAR). In this case, the positioning solution does not move until the carrier phase value is reset. During the IAR fixed mode, the positioning result is also stable, which means that the solution may be sure to be wrong (wrong orientation).

[0098] As another example, a precise positioning engine (PPE) or a positioning engine aggregator receives input from multiple positioning engines, such as a real-time kinematic (RTK) engine, a precise point positioning (PPP) engine, a sensor-assisted positioning (SAP) engine, and a standard positioning engine (SPE). RTK is a positioning technique that uses surveying to correct common errors in GNSS systems. More specifically, in addition to the information content of the signal, RTK also uses the measurement of the phase of the carrier wave of the signal, and relies on a single reference station or an interpolated virtual station to provide real-time corrections, thereby providing up to centimeter-level accuracy. PPP is a positioning technique that removes GNSS system errors or models the GNSS system errors to provide a high level of position accuracy from a single receiver (e.g., GNSS receiver 450). The PPP solution depends on GNSS satellite clock and orbit corrections generated from a network of global reference stations. These corrections are used by the receiver, resulting in centimeter-level positioning without the need for a base station.

[0099] The SAP engine uses both GNSS and IMU engines for positioning. An IMU is an electronic device that uses a combination of accelerometers, gyroscopes, and sometimes magnetometers to measure and report specific forces, angular velocity, and sometimes the orientation of a subject (e.g., vehicle 300). An IMU allows a GNSS receiver (e.g., GNSS receiver 450) to continue operating when GNSS signals are unavailable (such as in a tunnel, inside a building) or when there is electronic interference. In contrast, SPE uses only GNSS-based positioning, and may use only traditional pseudorange-based GNSS positioning instead of carrier phase-based GNSS positioning (e.g., RTK).

[0100] Figure 6600 is a diagram illustrating an example scenario in which one of the position fixes input to the positioning engine aggregator 610 is incorrect in accordance with aspects of the present disclosure. In one aspect, the positioning engine aggregator 610 may be implemented by one or more processors 406, memory 404, and / or positioning component 418. Figure 6 As shown in FIG. , the positioning engine aggregator 610 collects information from different positioning engines (such as Figure 6 In the example of FIG. 6 , an RTK / PPP positioning engine, a SAP engine, and an SPE engine) receive as input a positioning fix (i.e., a position estimate). The positioning engine aggregator 610 may weight or prioritize one of the positioning engines, and thus a position fix from that positioning engine is higher than other positioning engines. For example, the RTK / PPP engine may have the highest priority, followed by the SAP engine, and then the SPE. The positioning engine aggregator 610 combines different position fixes from different positioning engines based on their weights to provide a final position fix.

[0101] exist Figure 6 In the example of , due to IAR errors, RTK / PPP produces an incorrect position with a low horizontal estimated positioning error (HEPE) (uncertainly). More specifically, as described above, an incorrect fixed IAR may result in a positioning solution that is believed to be incorrect. In this case, the HEPE or uncertainty may be relatively low, while the actual position error is large. Since the RTK / PPP engine has the highest priority, the positioning engine aggregator 610 weighs the incorrect position from the RTK / PPP engine higher than the correct position from the SAP engine and SPE when combining the incorrect position from the RTK / PPP engine, the correct position from the SAP engine and SPE into a final solution. This will result in a final solution in which the position of the vehicle can be shown as being in the wrong lane. This is a case where UI input can help identify and resolve such issues.

[0102] Figure 7 An example method 700 for correcting lane-level positioning errors using UI inputs according to aspects of the present disclosure is illustrated. At stage 710, input is received from a UI indicating that a PPE (e.g., positioning engine aggregator 610) position solution is showing that a vehicle is in the wrong lane. The input from the UI may be received based on a request for UI input, and the request may have been received based on a request from a Figure 6 The position fix of the RTK / PPP engine in the SPE is not consistent with the position fix from the SAP engine and the SPE and is sent. Alternatively, the user (eg, the driver of the vehicle) may actively provide input to the UI.

[0103] At stage 720, the UI input is validated by cross-checking it with the vehicle's internal sensors (e.g., GNSS receiver 450, one or more sensors 420, radar camera sensor module 320, etc.). For example, if the current position is primarily based on a position fix from an RTK / PPP engine, such as in Figure 7 In the example of , the position fix can then be cross-checked with the position fix from the SAP engine and the SPE. If it is determined that there is an inconsistency between the various position engines, then the verification is checked. The inconsistency may be that the position fix of one positioning engine differs from the position fix of the other positioning engines by more than a certain threshold, optionally taking into account the accuracy that can be achieved by the different positioning engines.

[0104] At stage 730, to resolve the now verified positioning engine error, the offending positioning engine may be reset (e.g., Figure 7 RTK / PPP engine in the example of ). This may involve flushing the memory / cache of the positioning engine, reinitializing the positioning engine, etc. Resetting the positioning engine can potentially fix cross-track level errors in lane-level navigation. If the error is not corrected after resetting the positioning engine, or cannot be corrected for some reason (e.g., unavailability of sensors and / or signals that the offending positioning engine relies on), then the position fix from a second positioning engine (e.g., a SAP engine) can be used as the vehicle's position.

[0105] At stage 740, the position fix output by the PPE (eg, positioning engine aggregator 610) is updated based on the operations at stage 730. This will result in the vehicle being displayed on the UI as being in the correct lane.

[0106] Referring now to methods of obtaining UI input, there are various sources of UI input. Feedback may be obtained directly from the user / driver (when applicable and safe), nearby users (e.g., passengers), user environment sensing (e.g., other vehicle sensors such as cameras and computer vision), or a remote server (e.g., crowdsourcing). Direct user feedback may be received through different types of application programming interfaces (APIs), such as text (via typing), voice (via microphone), user selection of prompts displayed on a touchscreen of the vehicle's ADAS, etc. Indirect user feedback may be obtained through communication with a navigation application running on the user's smartphone or user input on the touchscreen of the vehicle's ADAS. For example, a user may tap an on-screen representation of the correct lane in which the vehicle should be located, such as Figure 8 as shown in .

[0107] Specifically, Figure 8 An example touch screen 800 for an ADAS of a vehicle according to aspects of the present disclosure is illustrated. Figure 8 , the ego vehicle is displayed in the left lane based on the current position position output by the positioning engine aggregator (e.g., positioning engine aggregator 610). However, the current position position is incorrect, and the user is shown tapping the correct lane to indicate to the positioning engine aggregator that the current position position is wrong.

[0108] In one aspect, UI information communications may include events sensed from the vehicle environment or driven by an external API. For example, if the driver enables cruise control, then the speed information of the vehicle may be used as a PVT integrity constraint. As another example, when the driver uses a turn signal, an additional lane switching algorithm may be performed by applying a larger weight to the additional lane switching algorithm (e.g., by the positioning engine aggregator 610). As yet another example, if the vehicle is determined to be in a high occupancy vehicle (HOV) lane, then the vehicle sensors (e.g., one or more sensors 420) can be used to determine the number of passengers in the vehicle and cross-check that number with map data (e.g., the number of passengers allowed in the lane associated with the determined location). Sensors used to determine passenger occupancy may include, for example, interior cameras, seat sensors, etc.

[0109] Note that the UI input may not be a geographic (e.g., latitude and longitude) point received from the user. For example, if the user taps in the correct lane (e.g., Figure 8 ), then the indication may be used to correct only one dimension (e.g., the x-axis of the displayed map indicating which lane is in which lane) and leave the second dimension (e.g., the y-axis of the displayed map indicating where in the lane is) uncorrected. In this case, the GNSS positioning engine may, for example, determine whether the GNSS measurements allow for the position or whether the second dimension must also be recalculated by removing some measurements (e.g., non-line-of-sight (NLOS) measurements for one or more SVs).

[0110] Fig. 9 An example method 900 of vehicle positioning according to aspects of the present disclosure is illustrated. In one aspect, the method 900 may be performed by a positioning engine aggregator (eg, positioning engine aggregator 610) of a host vehicle (eg, vehicle 300).

[0111] At 910, the positioning engine aggregator determines a position estimate of the host vehicle based on one or more position fixes determined by one or more positioning engines of the host vehicle. In an aspect, operation 910 may be performed by one or more processors 406, memory 404, and / or positioning component 418, any or all of which may be considered means for performing the operation.

[0112] At 920, the positioning engine aggregator receives input from a user interface (UI) of the host vehicle to correct the position estimate of the host vehicle. In one aspect, operation 920 may be performed by one or more processors 406, memory 404, and / or positioning component 418, any or all of which may be considered means for performing the operation.

[0113] At 930, the location engine aggregator updates the location estimate of the host vehicle based on the input from the UI. In one aspect, operation 930 may be performed by one or more processors 406, memory 404, and / or location component 418, any or all of which may be considered means for performing the operation.

[0114] As will be appreciated, a technical advantage of the method 900 is improved real-time PNT performance in, for example, lane-level navigation, first fix convergence time and accuracy, and positioning scenarios with adverse environmental conditions.

[0115] In the above detailed description, it can be seen that different features are grouped together in each example. This disclosure should not be understood as an intention that the example clauses have more features than the features explicitly mentioned in each clause. On the contrary, various aspects of the present disclosure may include less than all the features of the disclosed individual example clauses. Therefore, the following clauses should be considered to be incorporated into the description accordingly, wherein each clause itself can be used as a separate example. Although each subordinate clause may refer to a specific combination of one clause with other clauses in a clause, the aspects of the subordinate clause are not limited to a specific combination. It should be understood that other example clauses may also include a combination of the subject matter of the subordinate clause aspect with any other subordinate clause or independent clause or any feature with other subordinate clauses and independent clauses. Various aspects disclosed herein explicitly include these combinations, unless it is clearly expressed or can be easily inferred that a specific combination is not intended to be used (e.g., contradictory aspects, such as defining an element as both an electrical insulator and an electrical conductor). In addition, it is also expected that various aspects of the clause may be included in any other independent clause, even if the clause is not directly dependent on the independent clause.

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

[0117] Clause 1. A method for vehicle positioning performed by a positioning engine aggregator of a host vehicle, the method comprising: determining a position estimate of the host vehicle based on one or more position fixes determined by one or more positioning engines of the host vehicle; receiving input from a user interface (UI) of the host vehicle to correct the position estimate of the host vehicle; and updating the position estimate of the host vehicle based on the input from the UI.

[0118] Clause 2. The method of clause 1, further comprising: in response to receiving the input from the UI, validating the input from the UI based on a cross-check of the input from the UI with one or more other sensors of the host vehicle.

[0119] Clause 3. The method according to Clause 2 further includes: resetting at least one of the one or more positioning engines in response to verification of the input from the UI; determining a different position estimate of the main vehicle based on at least one position fix from at least one other of the one or more positioning engines; or any combination thereof.

[0120] Clause 4. The method of clause 3, wherein the position fix determined by the at least one positioning engine is inconsistent with the position fix determined by the remaining positioning engines of the one or more positioning engines.

[0121] Clause 5. The method of any one of clauses 3 to 4, wherein the at least one positioning engine has a higher priority than remaining positioning engines of the one or more positioning engines.

[0122] Clause 6. A method according to any one of clauses 3 to 5, wherein updating the position estimate comprises: determining a second position estimate of the main vehicle based on one or more second position positions determined by the one or more positioning engines after resetting the at least one positioning engine; or setting the position estimate of the main vehicle to the different position estimate of the main vehicle.

[0123] Clause 7. The method of any one of clauses 1 to 6, wherein the position estimate indicates that the host vehicle is located in the wrong lane.

[0124] Clause 8. A method according to any one of clauses 1 to 7, wherein the one or more positioning engines include: a real-time kinematics (RTK) engine, a precise point positioning (PPP) engine, a sensor-assisted positioning (SAP) engine, a standard positioning engine (SPE), or any combination thereof.

[0125] Clause 9. The method of any one of clauses 1 to 8, further comprising: determining that the position estimate is potentially incorrect; and requesting the input from the UI based on the position estimate being determined to be potentially incorrect.

[0126] Clause 10. A method according to clause 9, wherein the position estimate is determined to be potentially incorrect based on: a position fix determined by at least one of the one or more positioning engines being inconsistent with a position fix determined by the remaining one of the one or more positioning engines, map data not matching real-time vehicle perception information, sensor data being interrupted due to environmental conditions, incoming crowdsourced lane-level information, or any combination thereof.

[0127] Clause 11. A method according to any one of clauses 9 to 10, wherein the position estimate is determined to be potentially incorrect based on: the speed of the host vehicle differing from the set cruise control speed of the host vehicle by more than a threshold, the turn signal of the host vehicle being activated, the host vehicle being determined to be in a high occupancy vehicle (HOV) lane, or any combination thereof.

[0128] Clause 12. A method according to any one of clauses 1 to 11, wherein the input from the UI includes: text input to an advanced driver assistance system (ADAS) or an automated driving system (ADS) of the host vehicle, voice input to the ADAS or ADS of the host vehicle, message prompt selection to the ADAS or ADS of the host vehicle, touch input to a touch screen of the ADAS or ADS of the host vehicle, or any combination thereof.

[0129] Clause 13. The method of any one of clauses 1 to 12, wherein the position estimate of the host vehicle indicates a lane in which the host vehicle is determined to be located, and the input from the UI indicates a lane in which the host vehicle is physically located.

[0130] Clause 14. A positioning engine aggregator, the positioning engine aggregator comprising: a memory; at least one transceiver; and at least one processor, the at least one processor being communicatively coupled to the memory and the at least one transceiver, the at least one processor being configured to: determine a position estimate of the host vehicle based on one or more position fixes determined by one or more positioning engines of the host vehicle; receive input from a user interface (UI) of the host vehicle via the at least one transceiver to correct the position estimate of the host vehicle; and update the position estimate of the host vehicle based on the input from the UI.

[0131] Clause 15. A positioning engine aggregator according to clause 14, wherein the at least one processor is further configured to: in response to receiving the input from the UI, verify the input from the UI based on a cross-check of the input from the UI with one or more other sensors of the host vehicle.

[0132] Clause 16. A positioning engine aggregator according to clause 15, wherein the at least one processor is further configured to: reset at least one of the one or more positioning engines in response to verification of the input from the UI; determine a different position estimate of the host vehicle based on at least one position fix from at least one other of the one or more positioning engines; or any combination thereof.

[0133] Clause 17. The positioning engine aggregator of Clause 16, wherein the location fix determined by the at least one positioning engine is inconsistent with the location fix determined by the remaining positioning engines of the one or more positioning engines.

[0134] Clause 18. The positioning engine aggregator of any of Clauses 16 to 17, wherein the at least one positioning engine has a higher priority than remaining positioning engines of the one or more positioning engines.

[0135] Clause 19. A positioning engine aggregator according to any one of clauses 16 to 18, wherein the at least one processor configured to update the position estimate includes the at least one processor configured to perform the following operations: determine a second position estimate of the main vehicle based on one or more second position positions determined by the one or more positioning engines after resetting the at least one positioning engine; or set the position estimate of the main vehicle to the different position estimate of the main vehicle.

[0136] Clause 20. The positioning engine aggregator of any of Clauses 14 to 19, wherein the position estimate indicates that the host vehicle is located in the wrong lane.

[0137] Clause 21. A positioning engine aggregator according to any one of clauses 14 to 20, wherein the one or more positioning engines include: a real-time kinematic (RTK) engine, a precise point positioning (PPP) engine, a sensor-assisted positioning (SAP) engine, a standard positioning engine (SPE), or any combination thereof.

[0138] Clause 22. A positioning engine aggregator according to any one of clauses 14 to 21, wherein the at least one processor is further configured to: determine that the location estimate is potentially incorrect; and request the input from the UI based on the location estimate being determined to be potentially incorrect.

[0139] Clause 23. A positioning engine aggregator according to clause 22, wherein the position estimate is determined to be potentially incorrect based on: a position fix determined by at least one of the one or more positioning engines being inconsistent with a position fix determined by the remaining ones of the one or more positioning engines, map data not matching real-time vehicle perception information, sensor data being interrupted due to environmental conditions, incoming crowdsourced lane-level information, or any combination thereof.

[0140] Clause 24. A positioning engine aggregator according to any of clauses 22 to 23, wherein the position estimate is determined to be potentially incorrect based on: the speed of the host vehicle differing from the set cruise control speed of the host vehicle by more than a threshold, the turn signal of the host vehicle being activated, the host vehicle being determined to be in a high occupancy vehicle (HOV) lane, or any combination thereof.

[0141] Clause 25. A positioning engine aggregator according to any one of clauses 14 to 24, wherein the input from the UI includes: text input to an advanced driver assistance system (ADAS) or an automated driving system (ADS) of the host vehicle, voice input to the ADAS or ADS of the host vehicle, message prompt selection to the ADAS or ADS of the host vehicle, touch input to a touch screen of the ADAS or ADS of the host vehicle, or any combination thereof.

[0142] Clause 26. The positioning engine aggregator of any of clauses 14 to 25, wherein the position estimate of the host vehicle indicates a lane in which the host vehicle is determined to be located, and the input from the UI indicates a lane in which the host vehicle is physically located.

[0143] Clause 27. A positioning engine aggregator, the positioning engine aggregator comprising: components for determining a position estimate of the host vehicle based on one or more position fixes determined by one or more positioning engines of the host vehicle, components for receiving input from a user interface (UI) of the host vehicle to correct the position estimate of the host vehicle, and components for updating the position estimate of the host vehicle based on the input from the UI.

[0144] Clause 28. The positioning engine aggregator of clause 27, further comprising: a component for, in response to receiving the input from the UI, verifying the input from the UI based on a cross-check of the input from the UI with one or more other sensors of the host vehicle.

[0145] Clause 29. The positioning engine aggregator of Clause 28, further comprising: a component for resetting at least one of the one or more positioning engines in response to verification of the input from the UI, a component for determining a different position estimate of the main vehicle based on at least one position fix from at least one other of the one or more positioning engines; or any combination thereof.

[0146] Clause 30. The positioning engine aggregator of Clause 29, wherein the position fix determined by the at least one positioning engine is inconsistent with the position fix determined by the remaining positioning engines of the one or more positioning engines.

[0147] Clause 31. The positioning engine aggregator of any one of clauses 29 to 30, wherein the at least one positioning engine has a higher priority than remaining positioning engines of the one or more positioning engines.

[0148] Clause 32. A positioning engine aggregator according to any one of clauses 29 to 31, wherein the component for updating the position estimate includes: a component for determining a second position estimate of the main vehicle based on one or more second position positions determined by the one or more positioning engines after resetting the at least one positioning engine; or a component for setting the position estimate of the main vehicle to the different position estimate of the main vehicle.

[0149] Clause 33. The positioning engine aggregator of any of Clauses 27 to 32, wherein the position estimate indicates that the host vehicle is located in the wrong lane.

[0150] Clause 34. A positioning engine aggregator according to any one of clauses 27 to 33, wherein the one or more positioning engines include: a real-time kinematic (RTK) engine, a precise point positioning (PPP) engine, a sensor-assisted positioning (SAP) engine, a standard positioning engine (SPE), or any combination thereof.

[0151] Clause 35. A positioning engine aggregator according to any one of clauses 27 to 34, further comprising: a component for determining that the location estimate is potentially incorrect; and a component for requesting the input from the UI based on the location estimate being determined to be potentially incorrect.

[0152] Clause 36. A positioning engine aggregator according to clause 35, wherein the position estimate is determined to be potentially incorrect based on: a position fix determined by at least one of the one or more positioning engines being inconsistent with a position fix determined by the remaining ones of the one or more positioning engines, map data not matching real-time traffic perception information, sensor data being interrupted due to environmental conditions, incoming crowdsourced lane-level information, or any combination thereof.

[0153] Clause 37. A positioning engine aggregator according to any of clauses 35 to 36, wherein the position estimate is determined to be potentially incorrect based on: the speed of the host vehicle differing from the set cruise control speed of the host vehicle by more than a threshold, the turn signal of the host vehicle being activated, the host vehicle being determined to be in a high occupancy vehicle (HOV) lane, or any combination thereof.

[0154] Clause 38. A positioning engine aggregator according to any one of clauses 27 to 37, wherein the input from the UI includes: text input to an advanced driver assistance system (ADAS) or an automated driving system (ADS) of the host vehicle, voice input to the ADAS or ADS of the host vehicle, message prompt selection to the ADAS or ADS of the host vehicle, touch input to a touch screen of the ADAS or ADS of the host vehicle, or any combination thereof.

[0155] Clause 39. A positioning engine aggregator as described in any of clauses 27 to 38, wherein the position estimate of the host vehicle indicates a lane in which the host vehicle is determined to be located, and the input from the UI indicates a lane in which the host vehicle is physically located.

[0156] Clause 40. A non-transitory computer-readable medium storing computer-executable instructions that, when executed by a positioning engine aggregator, cause the positioning engine aggregator to: determine a position estimate of the host vehicle based on one or more position fixes determined by one or more positioning engines of the host vehicle; receive input from a user interface (UI) of the host vehicle to correct the position estimate of the host vehicle; and update the position estimate of the host vehicle based on the input from the UI.

[0157] Clause 41. The non-transitory computer-readable medium of clause 40, further comprising computer-executable instructions which, when executed by the positioning engine aggregator, cause the positioning engine aggregator to: in response to receiving the input from the UI, verify the input from the UI based on a cross-check of the input from the UI with one or more other sensors of the host vehicle.

[0158] Clause 42. The non-transitory computer-readable medium of clause 41, further comprising computer-executable instructions which, when executed by the positioning engine aggregator, cause the positioning engine aggregator to: reset at least one of the one or more positioning engines in response to verification of the input from the UI; determine a different position estimate of the main vehicle based on at least one position fix from at least one other of the one or more positioning engines; or any combination thereof.

[0159] Clause 43. The non-transitory computer-readable medium of Clause 42, wherein the position fix determined by the at least one positioning engine is inconsistent with the position fix determined by the remaining positioning engines of the one or more positioning engines.

[0160] Clause 44. The non-transitory computer-readable medium of any one of Clauses 42 to 43, wherein the at least one positioning engine has a higher priority than remaining positioning engines of the one or more positioning engines.

[0161] Clause 45. A non-transitory computer-readable medium according to any one of clauses 42 to 44, wherein the computer executable instructions that, when executed by the positioning engine aggregator, cause the positioning engine aggregator to update the position estimate include computer executable instructions that, when executed by the positioning engine aggregator, cause the positioning engine aggregator to perform the following operations: determine a second position estimate of the main vehicle based on one or more second position positions determined by the one or more positioning engines after resetting the at least one positioning engine; or set the position estimate of the main vehicle to the different position estimate of the main vehicle.

[0162] Clause 46. The non-transitory computer-readable medium of any one of Clauses 40 to 45, wherein the position estimate indicates that the host vehicle is located in the wrong lane.

[0163] Clause 47. A non-transitory computer-readable medium as described in any one of clauses 40 to 46, wherein the one or more positioning engines include: a real-time kinematics (RTK) engine, a precise point positioning (PPP) engine, a sensor-assisted positioning (SAP) engine, a standard positioning engine (SPE), or any combination thereof.

[0164] Clause 48. A non-transitory computer-readable medium according to any one of clauses 40 to 47, wherein the non-transitory computer-readable medium further comprises computer executable instructions that, when executed by the positioning engine aggregator, cause the positioning engine aggregator to: determine that the location estimate is potentially incorrect; and request the input from the UI based on the location estimate being determined to be potentially incorrect.

[0165] Clause 49. A non-transitory computer-readable medium as described in clause 48, wherein the position estimate is determined to be potentially incorrect based on: a position fix determined by at least one of the one or more positioning engines being inconsistent with a position fix determined by the remaining ones of the one or more positioning engines, map data not matching real-time vehicle perception information, sensor data being interrupted due to environmental conditions, incoming crowdsourced lane-level information, or any combination thereof.

[0166] Clause 50. A non-transitory computer-readable medium as described in any of clauses 48 to 49, wherein the position estimate is determined to be potentially incorrect based on: the speed of the host vehicle differing from the set cruise control speed of the host vehicle by more than a threshold, the turn signal of the host vehicle being activated, the host vehicle being determined to be in a high occupancy vehicle (HOV) lane, or any combination thereof.

[0167] Clause 51. A non-transitory computer-readable medium as described in any one of clauses 40 to 50, wherein the input from the UI includes: text input to an advanced driver assistance system (ADAS) or an automated driving system (ADS) of the host vehicle, voice input to the ADAS or ADS of the host vehicle, message prompt selection to the ADAS or ADS of the host vehicle, touch input to a touch screen of the ADAS or ADS of the host vehicle, or any combination thereof.

[0168] Clause 52. A non-transitory computer-readable medium as described in any of clauses 40 to 51, wherein the position estimate of the host vehicle indicates a lane in which the host vehicle is determined to be located, and the input from the UI indicates a lane in which the host vehicle is physically located.

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

[0170] In addition, it will be appreciated by those skilled in the art that the various exemplary logic blocks, modules, circuits and algorithmic steps described in conjunction with the various aspects disclosed herein can be implemented as electronic hardware, computer software or a combination of the two. In order to clearly illustrate this interchangeability of hardware and software, various exemplary components, blocks, modules, circuits and steps have been generally described above in terms of their functionality. Whether such functions are implemented as hardware or software depends on specific applications and the design constraints proposed to the entire system. Those skilled in the art can implement the described functionality in different ways for each specific application, but such specific implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

[0171] The various illustrative logical blocks, modules, and circuits described in conjunction with the various aspects disclosed herein may be implemented or executed with a general purpose processor, a digital signal processor (DSP), an ASIC, a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in an alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, a plurality of microprocessors, a combination of one or more microprocessors and a DSP core, or any other such configuration.

[0172] The methods, sequences and / or algorithms described in conjunction with the various aspects disclosed herein may be directly embodied in hardware, in a software module executed by a processor, or in a combination of the two. The software module may reside in a random access memory (RAM), a flash memory, a read-only memory (ROM), an erasable programmable ROM (EPROM), an electrically erasable programmable ROM (EEPROM), a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An example storage medium is coupled to the processor so that the processor can read information from the storage medium and write information to the storage medium. In an alternative, the storage medium may be integral with the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal (e.g., UE). In an alternative, the processor and the storage medium may reside in a user terminal as discrete components.

[0173] In one or more example aspects, the function may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the function may be stored on a computer-readable medium or sent via a computer-readable medium as one or more instructions or codes. Computer-readable media include both computer storage media and communication media, including any medium that facilitates the transfer of a computer program from one place to another. The storage medium may be any available medium that can be accessed by a computer. By way of example and not limitation, such computer-readable media may include RAM, ROM, EEPROM, CD-ROM, or other optical disk storage devices, disk storage devices, or other magnetic storage devices, or any other medium that can be used to carry or store the desired program code in the form of an instruction or data structure and can be accessed by a computer. Moreover, any connection is appropriately referred to as a computer-readable medium. For example, if the software is sent from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwaves, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwaves are included in the definition of the medium. Disk and disc, as used herein, include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0174] Although the foregoing disclosure illustrates the exemplary aspects of the present disclosure, it should be noted that various changes and modifications may be made herein without departing from the scope of the present disclosure as defined by the appended claims. In addition, the functions, steps and / or actions of the method claims according to the various aspects of the present disclosure described herein do not need to be performed in any particular order. In addition, although the elements of the present disclosure may be described or claimed in singular form, plural forms may also be considered unless explicitly stated to be limited to the singular form.

Claims

1. A method for vehicle positioning performed by a positioning engine aggregator of a host vehicle, the method comprising: determining a position estimate of the host vehicle based on one or more position fixes determined by one or more positioning engines of the host vehicle; receiving input from a user interface (UI) of the host vehicle to correct the position estimate of the host vehicle; as well as The position estimate of the host vehicle is updated based on the input from the UI.

2. The method according to claim 1, further comprising: In response to receiving the input from the UI, the input from the UI is validated based on a cross-check of the input from the UI with one or more other sensors of the host vehicle.

3. The method according to claim 2, further comprising: responsive to validation of the input from the UI, resetting at least one of the one or more positioning engines; determining a different position estimate of the host vehicle based on at least one position fix from at least one other of the one or more positioning engines; or Any combination of them. 4 . The method of claim 3 , wherein the position fix determined by the at least one positioning engine is inconsistent with the position fixes determined by the remaining positioning engines of the one or more positioning engines. The method of claim 3 , wherein the at least one positioning engine has a higher priority than the remaining positioning engines of the one or more positioning engines.

6. The method of claim 3, wherein updating the position estimate comprises: determining a second position estimate of the host vehicle based on one or more second position fixes determined by the one or more positioning engines after resetting the at least one positioning engine; or The position estimate of the host vehicle is set to the different position estimate of the host vehicle. The method of claim 1 , wherein the position estimate indicates that the host vehicle is located in the wrong lane.

8. The method of claim 1, wherein the one or more positioning engines include: Real-time kinematics (RTK) engine, Precise Point Positioning (PPP) engine, Sensor Assisted Positioning (SAP) engine, Standard Positioning Engine (SPE) or Any combination of them.

9. The method according to claim 1, further comprising: determining that the position estimate is potentially incorrect; as well as The input from the UI is requested based on the position estimate being determined to be potentially incorrect.

10. The method of claim 9, wherein the position estimate is determined to be potentially incorrect based on: a position fix determined by at least one of the one or more positioning engines is inconsistent with a position fix determined by the remaining positioning engines of the one or more positioning engines, Map data does not match real-time traffic perception information, Sensor data is interrupted due to environmental conditions, Incoming crowdsourced lane-level information or Any combination of them.

11. The method of claim 9, wherein the position estimate is determined to be potentially incorrect based on: The speed of the host vehicle differs from the set cruise control speed of the host vehicle by more than a threshold, The host vehicle's turn signal is activated, The host vehicle is determined to be in a high occupancy vehicle (HOV) lane or Any combination of them.

12. The method of claim 1, wherein the input from the UI comprises: text input to an advanced driver assistance system (ADAS) or automated driving system (ADS) of the host vehicle, voice input to the ADAS or ADS of the host vehicle, message prompt selection to the ADAS or ADS of the host vehicle, Touch input to the touch screen of the ADAS or ADS of the host vehicle or Any combination of them.

13. The method of claim 1, wherein: The position estimate of the host vehicle indicates a lane in which the host vehicle is determined to be located, and The input from the UI indicates a lane in which the host vehicle is physically located.

14. A positioning engine aggregator, the positioning engine aggregator comprising: Memory; at least one transceiver; and at least one processor, the at least one processor being communicatively coupled to the memory and the at least one transceiver, the at least one processor being configured to: determining a position estimate of the host vehicle based on one or more position fixes determined by one or more positioning engines of the host vehicle; receiving input from a user interface (UI) of the host vehicle via the at least one transceiver to correct the position estimate of the host vehicle; as well as The position estimate of the host vehicle is updated based on the input from the UI.

15. The positioning engine aggregator of claim 14, wherein the at least one processor is further configured to: In response to receiving the input from the UI, the input from the UI is validated based on a cross-check of the input from the UI with one or more other sensors of the host vehicle.

16. The positioning engine aggregator of claim 15, wherein the at least one processor is further configured to: responsive to validation of the input from the UI, resetting at least one of the one or more positioning engines; determining a different position estimate of the host vehicle based on at least one position fix from at least one other of the one or more positioning engines; or Any combination of them.

17. The positioning engine aggregator of claim 16, wherein the position fix determined by the at least one positioning engine is inconsistent with the position fixes determined by the remaining positioning engines of the one or more positioning engines.

18. The positioning engine aggregator of claim 16, wherein the at least one positioning engine has a higher priority than the remaining positioning engines of the one or more positioning engines.

19. The positioning engine aggregator of claim 16, wherein the at least one processor configured to update the location estimate comprises the at least one processor configured to: determining a second position estimate of the host vehicle based on one or more second position fixes determined by the one or more positioning engines after resetting the at least one positioning engine; or The position estimate of the host vehicle is set to the different position estimate of the host vehicle.

20. The positioning engine aggregator of claim 14, wherein the position estimate indicates that the host vehicle is located in a wrong lane.

21. The positioning engine aggregator of claim 14, wherein the one or more positioning engines include: Real-time kinematics (RTK) engine, Precise Point Positioning (PPP) engine, Sensor Assisted Positioning (SAP) engine, Standard Positioning Engine (SPE) or Any combination of them.

22. The positioning engine aggregator of claim 14, wherein the at least one processor is further configured to: determining that the position estimate is potentially incorrect; and The input from the UI is requested based on the position estimate being determined to be potentially incorrect.

23. The positioning engine aggregator of claim 22, wherein the location estimate is determined to be potentially incorrect based on: a position fix determined by at least one of the one or more positioning engines is inconsistent with a position fix determined by the remaining positioning engines of the one or more positioning engines, Map data does not match real-time traffic perception information, Sensor data is interrupted due to environmental conditions, Incoming crowdsourced lane-level information or Any combination of them.

24. The positioning engine aggregator of claim 22, wherein the location estimate is determined to be potentially incorrect based on: The speed of the host vehicle differs from the set cruise control speed of the host vehicle by more than a threshold, The host vehicle's turn signal is activated, The host vehicle is determined to be in a high occupancy vehicle (HOV) lane or Any combination of them.

25. The positioning engine aggregator of claim 14, wherein the input from the UI comprises: text input to an advanced driver assistance system (ADAS) or automated driving system (ADS) of the host vehicle, voice input to the ADAS or ADS of the host vehicle, message prompt selection to the ADAS or ADS of the host vehicle, Touch input to the touch screen of the ADAS or ADS of the host vehicle or Any combination of them.

26. The positioning engine aggregator of claim 14, wherein: The position estimate of the host vehicle indicates a lane in which the host vehicle is determined to be located, and The input from the UI indicates a lane in which the host vehicle is physically located.

27. A positioning engine aggregator, the positioning engine aggregator comprising: means for determining a position estimate of the host vehicle based on one or more position fixes determined by one or more positioning engines of the host vehicle; means for receiving input from a user interface (UI) of the host vehicle to correct the position estimate of the host vehicle; and Components for updating the position estimate of the host vehicle based on the input from the UI.

28. The positioning engine aggregator of claim 27, further comprising: Means for, in response to receiving the input from the UI, validating the input from the UI based on a cross-check of the input from the UI with one or more other sensors of the host vehicle.

29. The positioning engine aggregator of claim 27, further comprising: means for determining that the position estimate is potentially incorrect; and Means for requesting the input from the UI based on the position estimate being determined to be potentially incorrect.

30. A non-transitory computer readable medium storing computer executable instructions that, when executed by a positioning engine aggregator, cause the positioning engine aggregator to: determining a position estimate of the host vehicle based on one or more position fixes determined by one or more positioning engines of the host vehicle; receiving input from a user interface (UI) of the host vehicle to correct the position estimate of the host vehicle; as well as The position estimate of the host vehicle is updated based on the input from the UI.

Images