Evaluation of hypotheses associated with vehicle features

Abstract

Techniques for vehicle feature hypothesis assessment are disclosed. In one aspect, a hypothesis associated with a vehicle feature defines (i) at least one response of a focused driver to at least one in-vehicle human machine communication interface stimulus, (ii) timing information associated with at least one in-vehicle driver action, or (iii) a combination thereof. A driver-focused behavior is monitored and used to calculate a confidence level associated with the hypothesis validity based on the monitoring.

Description

BACKGROUND 1. TECHNICAL FIELD

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

[0003] 2. DESCRIPTION OF RELATED ART

[0004] Wireless communication systems have developed through several generations, including first-generation analog wireless telephones, second-generation (2G) digital wireless telephones, and third-generation (3G) high speed data, Internet-capable wireless phones with high speed data services. Today's fourth-generation (4G) wireless systems continue to push the evolution of faster, more reliable, and more sophisticated wireless services.

[0005] The fifth generation (5G) wireless standard, referred to as New Radio (NR), enables higher data transfer speeds, more capacity, and better coverage than previous standards. According to the Next Generation Mobile Networks Alliance, 5G technology should provide bitrates on the order of 100 megabits per second (Mbps) to one gigabit per second (Gbps), with reduced latency and improved coverage levels as compared to previous standards. 5G deployment is expected to be in spectrum bands from 600 to 3000 megahertz (MHz), which is significantly higher than the 1 to 10 gigahertz (GHz) bands used by 4G systems. SUMMARY

[0006] The following presents a simplified summary related to one or more aspects disclosed herein. Thus, the following summary should not be considered an extensive overview relating to all contemplated aspects, nor should the following summary be considered to identify key or critical elements relating to all contemplated aspects or to delineate the scope associated with any particular aspect. Accordingly, the following summary has the sole purpose to present certain concepts relating to one or more aspects disclosed herein in a simplified form to precede the detailed description presented below.

[0007] In an aspect, a method of operating a device includes receiving a hypothesis associated with a vehicle feature, the hypothesis defining (i) at least one response of an attentive driver to at least one vehicle-mounted human-machine communication interface stimulus, (ii) timing information associated with at least one vehicle-mounted driver action, or (iii) a combination thereof; monitoring behavior of one or more attentive drivers; computing, based on the monitoring, a confidence level associated with the hypothesis being valid; and performing one or more actions based on the confidence level.

[0008] In an aspect, a method of operating a network component includes transmitting a hypothesis associated with a vehicle feature, the hypothesis defining (i) at least one response of an attentive driver to at least one vehicle-mounted human-machine communication interface stimulus, (ii) timing information associated with at least one vehicle-mounted driver action, or (iii) a combination thereof; and receiving, in response to the transmitting, a confidence level associated with the hypothesis being valid, the confidence level being based on monitoring behavior of one or more attentive drivers.

[0009] In an aspect, a device includes one or more memories; and one or more processors communicatively coupled to the one or more memories, the one or more processors individually or in combination configured to: receive a hypothesis associated with a vehicle feature, the hypothesis defining (i) at least one response of an attentive driver to at least one vehicle-mounted human-machine communication interface stimulus, (ii) timing information associated with at least one vehicle-mounted driver action, or (iii) a combination thereof; monitor behavior of one or more attentive drivers; compute, based on the monitoring, a confidence level associated with the hypothesis being valid; and perform one or more actions based on the confidence level.

[0010] In an aspect, a network component includes one or more memories; and one or more processors communicatively coupled to the one or more memories, the one or more processors individually or in combination configured to: transmit a hypothesis associated with a vehicle feature, the hypothesis defining (i) at least one response of an attentive driver to at least one vehicle-mounted human-machine communication interface stimulus, (ii) timing information associated with at least one vehicle-mounted driver action, or (iii) a combination thereof; and receive, in response to the transmitting, a confidence level associated with the hypothesis being valid, the confidence level being based on monitoring behavior of one or more attentive drivers.

[0011] In an aspect, an apparatus comprises: means for receiving a hypothesis associated with a vehicle feature, the hypothesis defining (i) at least one response of an attentive driver to at least one vehicle-mounted human-machine communication interface stimulus, (ii) timing information associated with at least one vehicle-mounted driver action, or (iii) a combination thereof; monitoring behavior of one or more attentive drivers; means for calculating, based on the monitoring, a confidence level associated with the hypothesis being valid; and means for performing one or more actions based on the confidence level.

[0012] In an aspect, a network component comprises: means for sending a hypothesis associated with a vehicle feature, the hypothesis defining (i) at least one response of an attentive driver to at least one vehicle-mounted human-machine communication interface stimulus, (ii) timing information associated with at least one vehicle-mounted driver action, or (iii) a combination thereof; and means for receiving, in response to the sending, a confidence level associated with the hypothesis being valid, the confidence level being based on monitoring behavior of one or more attentive drivers.

[0013] In an aspect, a non-transitory computer-readable medium storing computer- executable instructions that, when executed by an apparatus, cause the apparatus to: receive a hypothesis associated with a vehicle feature, the hypothesis defining (i) at least one response of an attentive driver to at least one vehicle-mounted human-machine communication interface stimulus, (ii) timing information associated with at least one vehicle-mounted driver action, or (iii) a combination thereof; monitor behavior of one or more attentive drivers; calculate, based on the monitoring, a confidence level associated with the hypothesis being valid; and perform one or more actions based on the confidence level.

[0014] In an aspect, a non-transitory computer-readable medium storing computer- executable instructions that, when executed by a network component, cause the network component to: send a hypothesis associated with a vehicle feature, the hypothesis defining (i) at least one response of an attentive driver to at least one vehicle-mounted human-machine communication interface stimulus, (ii) timing information associated with at least one vehicle-mounted driver action, or (iii) a combination thereof; and receive, in response to the sending, a confidence level associated with the hypothesis being valid, the confidence level being based on monitoring behavior of one or more attentive drivers.

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

[0016] The accompanying drawings are presented to aid in the description of various aspects of the disclosure and are provided solely for illustration of the aspects and are not intended to limit the aspects in any way.

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

[0018] FIG. 2A 、 FIG. 2B and FIG. 2C An example wireless network architecture is illustrated in accordance with aspects of the present disclosure.

[0019] FIG. 3A 、 FIG. 3B and FIG. 3C are simplified block diagrams of several example aspects of components that can be employed in a user equipment (UE), a base station, and a network entity, respectively, and configured to support communications as taught herein.

[0020] FIG. 4 An example on-board computer architecture is illustrated in accordance with various aspects of the present disclosure.

[0021] FIG. 5 An example process of communication is illustrated in accordance with an aspect of the present disclosure.

[0022] FIG. 6 An example process of communication is illustrated in accordance with an aspect of the present disclosure.

[0023] FIG. 7 A table 700 is illustrated in accordance with an aspect of the present disclosure.

[0024] FIG. 8 Example implementations of processes of FIGS. 5-6 are illustrated in accordance with aspects of the present disclosure.

[0025] FIG. 9 Example implementations of processes of FIGS. 5-6 are illustrated in accordance with aspects of the present disclosure.

[0026] FIG. 10 Example implementations of processes of FIGS. 5-6 are illustrated in accordance with aspects of the present disclosure.

[0027] FIG. 11 A vehicle hypothesis evaluation system 1100 is illustrated in accordance with aspects of the present disclosure. DETAILED DESCRIPTION

[0028] Aspects of the present disclosure are provided in the following description and related drawings directed to various examples provided for illustration purposes. Alternative aspects can be devised without departing from the scope of the present disclosure. Additionally, well-known elements of the present disclosure will not be described in detail or will be omitted so as not to unnecessarily obscure the relevant details of the examples.

[0029] Various aspects generally relate to vehicle feature assumption analysis and tracking. Assumptions shape how technology is shaped and how technology is used. Outdated assumptions and unknown dependencies can have an impact on hazard recognition, misuse, disuse in assisted driving or autonomous driving functions. Aggregated thinking and directed motivated thinking during design leads to predetermined conclusions and assumptions. Given the incentive for specific conclusions that do not contradict these assumptions and defend preconceived notions, this cognitive bias can lead to skewed methods of post-deployment evidence evaluation. There is a need for less subjectivity and more objectivity and adaptability in assumption evaluation during design, pre-deployment, and post-deployment of safety-critical, user-friendly products.

[0030] Particular aspects of the subject matter described in this disclosure can be implemented to realize one or more of the following potential advantages. Some aspects of the disclosure generally relate to listing all assumptions associated with a driver and ensuring sufficient confidence in those assumptions prior to deployment and tracking these assumptions periodically after deployment, thereby promoting correct usage while maintaining necessary safety margins. To this end, aspects of the disclosure relate to assumption verification (e.g., at a driver level, a fleet level, pre-deployment, post-deployment, etc.), whereby a confidence level validly associated with a certain assumption is determined based on monitoring behavior of a focused driver. Such aspects can provide various technical advantages, such as improved vehicle safety, improved user (i.e., driver) experience, improved engagement between a driver and one or more available vehicle features, etc. For example, these vehicle features can include advanced driver assistance system (ADAS) features and / or autonomous driving system (ADS) features.

[0031] 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.

[0032] Those skilled in the art will appreciate that information and signals can be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that can be referenced throughout the above description can be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof, depending in part on the particular applications, embodiments, and / or technologies involved. Further, the various technologies and techniques described above can be used alone or in combination with one another.

[0033] Furthermore, many aspects are described according to a sequence of actions to be performed by elements of, for example, a computing device. It will be appreciated that the various actions described herein can be performed by specific circuitry (e.g., an application-specific integrated circuit (ASIC)), by program instructions executed by one or more processors, or by a combination of both. Additionally, the sequence of actions described herein can be considered to be entirely embodied in any form of non-transitory computer-readable storage medium storing a corresponding set of computer instructions that, when executed, will cause or command the associated processor of the device to perform the functionality described herein. Therefore, various aspects of this disclosure can be embodied in a variety of different forms, all of which are contemplated within the scope of the claimed subject matter. Furthermore, for each aspect described herein, any corresponding form of any such aspect may be described herein as, for example, "a logical component configured to perform the described actions."

[0034] As used herein, unless otherwise stated, the terms “User Equipment” (UE) and “Base Station” are not intended to be specific or otherwise limited to any particular Radio Access Technology (RAT). Generally, a UE can be any wireless communication device used by a user to communicate over a wireless communication network (e.g., mobile phone, router, tablet computer, laptop computer, consumer asset positioning device, wearable device (e.g., smartwatch, glasses, augmented reality (AR) / virtual reality (VR) headset, etc.), vehicle (e.g., car, motorcycle, bicycle, etc.), Internet of Things (IoT) device, etc.). A UE can be mobile or can (e.g., at certain times) be stationary and can communicate with a Radio Access Network (RAN). As used herein, the term “UE” can be interchangeably referred to as “Access Terminal” or “AT,” “Client Equipment,” “Wireless Equipment,” “Subscriber Equipment,” “Subscriber Terminal,” “Subscriber Station,” “User Terminal” or “UT,” “Mobile Equipment,” “Mobile Terminal,” “Mobile Station,” or variations thereof. Generally, a UE can communicate with a core network via the RAN, and through the core network, a UE can connect to external networks such as the Internet and to other UEs. Of course, other mechanisms for connecting to the core network and / or the Internet are also possible for the UE, such as through wired access networks, wireless local area network (WLAN) networks (e.g., based on the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard, etc.).

[0035] A base station can operate according to one of a number of RATs in dependence on the network in which the base station is deployed to communicate with UEs and can alternatively be referred to as an access point (AP), a network node, a NodeB, an evolved NodeB (eNB), a next generation eNB (ng-eNB), a New Radio (NR) Node B (also referred to as a gNB or gNodeB), etc. The base station can be used primarily to support wireless access by UEs, including supporting data, voice, and / or signaling connections for the supported UEs. In some systems, the base station can provide only edge node signaling functions, whereas in other systems, the base station can provide additional control and / or network management functions. A communication link through which UEs can send signals to a base station is called an uplink (UL) channel (e.g., a reverse traffic channel, a reverse control channel, an access channel, etc.). A communication link through which the base station can send signals to a UE is called 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) can refer to an uplink / reverse traffic channel or a downlink / forward traffic channel.

[0036] The term “base station” can refer to a single physical transmission-reception point (TRP) or to multiple physical TRPs that can or can not be co-located. For example, where the term “base station” refers to a single physical TRP, the physical TRP can be an antenna of the base station corresponding to a cell (or cell sector) of the base station. Where the term “base station” refers to multiple co-located physical TRPs, the physical TRPs can be an array of antennas 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 TRPs can be a distributed antenna system (DAS) (a network of spatially separated antennas connected to a common source via a transmission medium) or remote radio heads (RRHs) (remote base stations connected to a serving base station). Alternatively, the non-co-located physical TRPs can be the serving base station receiving the measurement report from the UE and a neighbor base station whose reference radio frequency (RF) signals the UE is measuring. Because a TRP is a point from or to which the base station transmits and receives wireless signals as used herein, a reference to transmitting from or receiving at a base station should be understood to refer to a particular TRP of the base station.

[0037] In some implementations that support positioning of UEs, a base station can not support wireless access by UEs (e.g., can not support data, voice, and / or signaling connections for UEs), but can instead transmit reference signals to UEs to be measured by the UEs and / or can receive and measure signals transmitted by the UEs. Such a base station can be referred to as a positioning beacon (e.g., where signals are transmitted to UEs) and / or as a location measurement unit (e.g., where signals from UEs are received and measured).

[0038] An “RF signal” comprises an electromagnetic wave of a given frequency that transports information through the space between a transmitter and a receiver. As used herein, a transmitter can transmit a single “RF signal” or multiple “RF signals” to a receiver. However, due to the propagation characteristics of RF signals over multi-path channels, the receiver can receive multiple “RF signals” corresponding to each transmitted RF signal. The same transmitted RF signal on different paths between the transmitter and receiver can be referred to as a “multi-path” RF signal. As used herein, where the term “signal” clearly refers to a wireless signal or an RF signal, depending on the context, an RF signal can also be referred to as a “wireless signal” or simply a “signal.”

[0039] FIG. 1 An example wireless communications system 100, in accordance with aspects of the present disclosure, is illustrated. The wireless communications system 100, which can also be referred to as a wireless wide area network (WW AN), can include various base stations 102, labeled “BS,” and various UEs 104. The base stations 102 can include macro cell base stations (high power cellular base stations) and / or small cell base stations (low power cellular base stations). In an aspect, the macro cell base station can include eNBs and / or ng-eNBs (where the wireless communications system 100 corresponds to an LTE network), or gNBs (where the wireless communications system 100 corresponds to an NR network), or a combination of both, and the small cell base stations can include femto cells, pico cells, micro cells, and the like.

[0040] The base stations 102 can collectively form a RAN and interface with a core network 170 (e.g., an evolved packet core (EPC) or a 5G core (5GC)) through backhaul links 122 (e.g., SI, X2, Xn, etc. interfaces), and 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 can be part of the core network 170 or can be external to the core network 170. The location server 172 can be integrated with the base stations 102. The UEs 104 can communicate directly with the location server 172, either directly or indirectly. For example, the UEs 104 can communicate with the location server 172 via a base station 102 that is currently serving the UE 104. The UEs 104 can 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. The communication between the UEs 104 and the location server 172 can be represented as an indirect connection (e.g., through the core network 170, etc.) or a direct connection (e.g., as shown via the direct connection 128) for signaling purposes, with intermediate nodes (if any) omitted from the signaling diagrams for the sake of clarity.

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

[0042] The base stations 102 can wirelessly communicate with the UEs 104. Each of the base stations 102 can provide communication coverage for a respective geographic coverage area 110. In an aspect, one or more cells can be supported by the base station 102 in each geographic coverage area 110. A “cell” is a logical communication entity used to provide communication coverage for a particular area in which UE communication is supported by a base station, such as through a certain frequency or frequencies (e.g., frequency carriers, component carriers, carriers, bands, etc.). Different protocols, such as machine type communication (MTC), narrowband IoT (NB-IoT), enhanced mobile broadband (eMBB), or other protocol types, can be configured according to different protocol types that can provide access for different types of UEs. Because cells are supported by a particular base station, the term “cell” can refer to either or both of a logical communication entity and a base station supporting the logical communication entity, depending on context. Also, since a TRP is typically a physical transmission point of a cell, the terms “cell” and “TRP” can be used interchangeably. In some cases, the term “cell” can also refer to a base station’s geographic coverage area (e.g., a sector), as long as a carrier frequency can be detected and used for communication within the geographic coverage area 110.

[0043] Although the geographic coverage area 110 for each of the base stations 102 can overlap in order to provide stronger indoor and / or outdoor coverage, the same base station 102, or different base stations 102, can be responsible for the geographic coverage area 110 at any given moment. The base stations 102 can serve any number of mobile devices 104

[0044] The communication links 120 between the base stations 102 and the UEs 104 can include uplink (also referred to as reverse link) transmissions from a UE 104 to a base station 102 and / or downlink (DL) (also referred to as forward link) transmissions from a base station 102 to a UE 104. The communication links 120 can use MIMO antenna technology, including spatial multiplexing, beamforming, and / or transmit diversity. The communication links 120 can be through one or more carrier frequencies. Allocation of carriers can be asymmetric with respect to downlink and uplink (e.g., more or less carriers can be allocated for downlink than for uplink).

[0045] Wireless communications system 100 can also include a wireless local area network (WLAN) access point (AP) 150 in communication with WLAN stations (STAs) 152 via communication links 154 in an unlicensed frequency spectrum (e.g., 5 GHz). When communicating in an unlicensed frequency spectrum, the WLAN STAs 152 and / or the WLAN AP 150 can perform clear channel assessment (CCA) or listen before talk (LBT) procedures prior to communicating to determine whether the channel is available.

[0046] The small cell base stations 102' can operate in a licensed or an unlicensed frequency spectrum. When operating in an unlicensed frequency spectrum, the small cell base stations 102' can employ LTE or NR technology and use the same 5 GHz unlicensed frequency spectrum as the WLAN AP 150. A small cell base station 102' employing LTE / 5G in an unlicensed frequency spectrum can boost coverage of the access network and / or increase capacity of the access network. NR in unlicensed frequency spectrum can be referred to as NR-U. LTE in unlicensed frequency spectrum can be referred to as LTE-U, License Assisted Access (LAA), or MulteFire ® .

[0047] The wireless communications system 100 can also include millimeter wave (mmW) base stations 180 that can operate in mmW frequencies and / or near mmW frequencies in communication with UEs 182. Extremely high frequency (EHF) is the part of the radio frequency spectrum between 30 GHz and 300 GHz. EHF has a wavelength of 1 millimeter to 10 millimeters. Radio waves in this band can be referred to as a millimeter wave. Near mmW can extend down to a frequency of 3 GHz with a wavelength of 100 millimeters. The super high frequency (SHF) band extends between 3 GHz and 30 GHz, which is also referred to as centimeter wave. Communications using the mmW / near mmW radio frequency band have high path loss and a relatively short range. The mmW base stations 180 and the UEs 182 can utilize beamforming (transmit and / or receive) over mmW communication links 184 to compensate for the extremely high path loss and short range. Further, it should be appreciated that in alternative configurations, one or more base stations 102 can also transmit using mmW or near mmW and beamforming. Thus, it should be appreciated that the preceding illustration is merely an example and should not be construed as a limitation of the various aspects disclosed herein.

[0048] Transmit beamforming is a technique for focusing the RF signal in a specific direction. Traditionally, when a network node (e.g., a base station) broadcasts a signal, it broadcasts the signal in all directions (omni-directionally). 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 and stronger RF signal (in terms of data rate) for the receiving device. 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 in the broadcast. For example, the network node can use an array of antennas (referred to as a “phased array” or “antenna array”), which in effect moves the beam without actually moving the antennas. Specifically, the RF current from the transmitter is fed to the individual antennas with the correct phase relationship so that the radio waves from the separate antennas add together to increase the radiation in a desired direction, while cancelling to suppress radiation in undesired directions.

[0049] The transmit beams can be quasi co-located, meaning that they appear to the receiver (e.g., a 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 a second reference RF signal on a second beam (e.g., a transmit beam or a receive beam) can be derived from information about a source reference RF signal on a source beam (e.g., a receive beam or a transmit beam). Thus, if the source reference RF signal is QCL Type A, the receiver can use the source reference RF signal to estimate the Doppler shift, the Doppler spread, the average delay, and the delay spread of a second reference RF signal transmitted on the same channel. If the source reference RF signal is QCL Type B, the receiver can use the source reference RF signal to estimate the Doppler shift and the Doppler spread of a second reference RF signal transmitted on the same channel. If the source reference RF signal is QCL Type C, the receiver can use the source reference RF signal to estimate the Doppler shift and the average delay of a second reference RF signal transmitted on the same channel. If the source reference RF signal is QCL Type D, the receiver can use the source reference RF signal to estimate the spatial receive parameters of a second reference RF signal transmitted on the same channel.

[0050] In receive beamforming, the receiver uses a receive beam to amplify an RF signal detected on a given channel. For example, the receiver can increase a gain setting and / or adjust a phase setting of an antenna array in a particular direction to amplify an RF signal received from that direction (e.g., increase its gain level). Thus, when a receiver is said to beamform in a certain direction, this means that the beam gain in that direction is high relative to the beam gain along other directions, or that the beam gain in that direction is the highest compared to the beam gain of all other receive beams available to the receiver in that direction. 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.) for the RF signal received from that direction.

[0051] The transmit beams and the receive beams can be spatially related. Spatial relation means that parameters for a second beam (e.g., a transmit beam or a receive beam) for a second reference signal can 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 can use a particular receive beam to receive a reference downlink reference signal (e.g., a synchronization signal block (SSB)) from a base station. The UE can then form a transmit beam for transmitting an uplink reference signal (e.g., a sounding reference signal (SRS)) to that base station based on parameters of the receive beam.

[0052] 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 transmit a reference signal to a UE, the downlink beam is a transmit beam. However, if the UE is forming a downlink beam, the downlink beam is a receive beam to receive the 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, the uplink beam is an uplink receive beam, while if the UE is forming an uplink beam, the uplink beam is an uplink transmit beam.

[0053] The electromagnetic spectrum is often subdivided based on frequency / wavelength into various classes, bands, channels, and so forth. In 5G NR, two initial operating bands have been identified as frequency range designations FR1 (410 MHz to 7. 125 GHz) and FR2 (24.25 GHz to 52.6 GHz). It should be understood that although a portion of FR1 is greater than 6 GHz, FR1 is often referred to (interchangeably) as a “Sub-6 GHz” band in various documents and articles. A similar nomenclature issue sometimes occurs with regard to FR2, which is often referred to (interchangeably) as a “millimeter wave” band in documents and articles, despite being different from the “millimeter wave” frequencies designated as such by the International Telecommunications Union (ITU) and used in other contexts. It is to be understood that the electromagnetic spectrum is a continuous structure with no sharp boundaries, and thus bands and ranges can overlap and / or span across multiple bands and ranges. ® The extremely high frequency (EHF) band (30 GHz to 300 GHz) which has been identified as a “millimeter wave” frequency band by the International Telecommunications Union (ITU).

[0054] The frequencies between FR1 and FR2 are often referred to as mid-band frequencies. Recent 5G NR studies have identified an operating band for these mid-band frequencies as frequency range designation FR3 (7. 125 GHz to 24.25 GHz). Bands falling within FR3 can inherit FR1 and / or FR2 characteristics, and thus can effectively extend the features of FR1 and / or FR2 to mid-band frequencies. Moreover, even higher bands are currently being explored to extend 5G NR operations beyond 52.6 GHz. For example, three higher operating bands have been identified as frequency range designations FR4a or FR4-1 (52.6 GHz to 71 GHz), FR4 (52.6 GHz to 114.25 GHz), and FR5 (114.25 GHz to 300 GHz). Each of these higher bands falls within the EHF band.

[0055] With the above aspects in mind, unless specifically stated otherwise, it should be understood that the term “sub-6 GHz” or the like, if used herein, can broadly represent frequencies that can be less than 6 GHz, can be within FR1, or can include mid-band frequencies. Further, unless specifically stated otherwise, it should be understood that the term “millimeter wave” or the like, if used herein, can broadly represent frequencies 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 frequency band.

[0056] 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 the 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 a RRC connection reestablishment procedure. The primary carrier carries all common and UE-specific control channels and can be a carrier in a licensed frequency (although this is not always the case). The secondary carrier is a carrier operating on a second frequency (e.g., FR2) that can be configured and can be 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 can contain only necessary signaling information and signals, e.g., those that are UE-specific can not be present in the secondary carrier since both the primary uplink and primary downlink carriers are typically UE-specific. This means that different UEs 104 / 182 in a cell can have different downlink primary carriers. The same is true for the uplink primary carrier. The network is able to change the primary carrier for any UE 104 / 182 at any time. This is done, for example, to balance the load on different carriers. Since a “serving cell” (whether a PCell or an SCell) corresponds to the carrier frequency / component carrier through which a certain base station communicates, the terms “cell”, “serving cell”, “component carrier”, “carrier frequency”, and the like can be used interchangeably.

[0057] For example, still referring to FIG. 1One of the frequencies used by the macrocell base station 102 can be an anchor carrier (or "PCell"), and other frequencies used by the macrocell base station 102 and / or mmW base station 180 can 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 doubling the data rate as compared to a single 20 MHz carrier (i.e., 40 MHz).

[0058] The wireless communications system 100 can also include a UE 164 that can communicate with macro cell base station 102 over a communication link 120 and / or with mmW base station 180 over a mmW communication link 184. For example, the macro cell base station 102 can support a PCell and one or more SCells for the UE 164, and the mmW base station 180 can support one or more SCells for the UE 164.

[0059] In some cases, the UEs 164 and 182 can be capable of sidelink communication. Sidelink-capable UEs (SL-UEs) can communicate with base station 102 using a Uu interface (i.e., the air interface between a UE and a base station) over communication link 120. SL-UEs (e.g., UEs 164, 182) can also directly communicate with each other using a PC5 interface (i.e., the air interface between sidelink-capable UEs) over wireless sidelink 160. Wireless sidelink (or simply "sidelink") is an adaptation of core cellular technology (e.g., LTE, NR) that allows direct communication between two or more UEs without communicating through a base station. Sidelink communication can be unicast or multicast, and can be used for device-to-device (D2D) media sharing, vehicle-to-vehicle (V2V) communications, vehicle-to-everything (V2X) communications (e.g., cellular V2X (cV2X) communications, enhanced V2X (eV2X) communications, etc.), emergency rescue applications, etc. One or more of the SL-UEs in a group utilizing sidelink communication can be within the geographic coverage area 110 of a base station 102. Other SL-UEs in such a group can be outside the geographic coverage area 110 of a base station 102, or be unable to receive transmissions from base stations 102 for other reasons. In some cases, groups of SL-UEs communicating via sidelink communication can utilize a one-to-many (1 :M) system, where each SL-UE transmits to every other SL-UE in the group. In some cases, the base station 102 facilitates scheduling of resources for sidelink communications. In other cases, sidelink communications are performed between SL-UEs without involvement of base station 102.

[0060] In an aspect, the sidelink 160 can operate over a wireless communication medium of interest that can be shared with other wireless communications between other vehicles and / or infrastructure access points and other RATs. A "medium" can include one or more time, frequency, and / or space communication resources (e.g., encompassing one or more channels across one or more carriers) associated with wireless communications between one or more transmitter / receiver pairs. In an aspect, the medium of interest can correspond to at least a portion of an unlicensed band that is shared between various RATs. Although different licensed frequency bands have been reserved for certain communication systems (e.g., by a government entity such as the Federal Communications Commission (FCC)), these systems, particularly those employing small cell access points, have recently extended 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.1 lx WLAN technologies commonly referred to as "Wi-Fi." Example systems of this type include different variations of CDMA systems, TDMA systems, FDMA systems, Orthogonal FDMA (OFDMA) systems, Single-Carrier FDMA (SC-FDMA) systems, etc.

[0061] Note that although FIG. 1 Only two of these UEs are illustrated as SL-UEs (i.e., UE 164 and UE 182), but any of the illustrated UEs can be SL-UEs. Further, although only UE 182 is described as being capable of beamforming, any of the illustrated UEs, including UE 164, can be capable of beamforming. Where the SL-UEs are capable of beamforming, they can beamform toward one another (i.e., toward other SL-UEs), toward other UEs (e.g., UE 104), toward base stations (e.g., base station 102, base station 180, small cell 102', access point 150), etc. Thus, in some cases, UE 164 and UE 182 can utilize beamforming over sidelink 160.

[0062] In FIG. 1 the illustrated UEs (for simplicity, in FIG. 1Any of the UEs 104 (shown as a single UE 104) can receive signals 124 from one or more Earth orbiting space vehicles (SVs) 112, such as satellites. In an aspect, the SVs 112 can be part of a satellite positioning system of which the UEs 104 can use as an independent source of location information. A satellite positioning system typically includes a system of transmitters (e.g., SVs 112) positioned in orbit about the Earth that transmit signals (e.g., signals 124) that a receiver (e.g., a UE 104) can use to determine its location on or above the Earth based, at least in part, on known positions of the transmitters. Such transmitters typically transmit signals marked with a repeating pseudo-random noise (PN) code of a set number of chips. While typically located in SVs 112, transmitters can sometimes be located on ground-based control stations, base stations 102, and / or other UEs 104. The UEs 104 can include one or more specialized receivers designed specifically for receipt of the signals 124 in order to derive geographic location information from the SVs 112.

[0063] In a satellite positioning system, use of the signals 124 can be augmented by various satellite-based augmentation systems (SBAS), which can be associated with one or more global and / or regional navigation satellite systems and / or based on one or more global and / or regional navigation satellite systems. For example, the SBAS may

[0064] In an aspect, the SVs 112 additionally or alternatively can be part of one or more non-terrestrial networks (NTNs). In an NTN, the SVs 112 connect to an Earth station (also referred to as a ground station, NTN gateway, or gateway), which in turn connects to elements in the 5G network, such as a modified base station 102 (without a terrestrial antenna) or a network node in the 5GC. This element in turn will provide access to other elements in the 5G network, and ultimately to entities outside the 5G network, such as Internet web servers and other user equipment. In this way, the UEs 104 can receive communication signals (e.g., signals 124) from the SVs 112 as an alternative or supplement to communication signals from terrestrial base stations 102.

[0065] The wireless communications system 100 can also include one or more UEs, such as UE 190, that indirectly connect to one or more communication networks via one or more device-to-device (D2D) peer-to-peer (P2P) links (referred to as “sidelinks”). In FIG. 1 In an example, the UE 190 has a D2D P2P link 192 with one of the UEs 104 connected to one of the base stations 102 (e.g., with which the UE 190 can indirectly obtain cellular connectivity), and a D2D P2P link 194 with WLAN STA 152 connected to the WLAN AP 150 (with which the UE 190 can indirectly obtain WLAN-based Internet connectivity). In an example, the D2D P2P links 192, 194 can be supported with any well-known D2D RAT (such as LTE Direct (LTE-D), WI-FI DIRECT (e.g., Wi-Fi), BLUETOOTH®, etc.). ® ® Etc.).

[0066] FIG. 2A An example wireless network structure 200 is illustrated. For example, a 5GC 210 (also referred to as Next Generation Core (NGC)) can be functionally

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

[0068] FIG. 2B Another example wireless network structure 240 is illustrated. A 5GC 260 (which can correspond to the 5GC 210) is shown that includes an AMF 262, a UDM 264, and a location management function (LMF) 266. The AMF 262 can communicate with a base station 220 (which can correspond to the base stations 220a, 220b, 220c) over an N2 interface 268. The base station 220 can also FIG. 2AThe 5GC 210) can be viewed functionally as control plane functions provided by an access and mobility management function (AMF) 264, user plane functions provided by a user plane function (UPF) 262, which operate cooperatively to form the core network (i.e., 5GC 260). The functions of the AMF 264 include registration management, connection management, reachability management, mobility management, lawful interception, transport for one or more UE 204 (e.g., any of the UEs described herein) session management (SM) messages between the UE 204 and a session management function (SMF) 266, transparent proxy services for routing SM messages, access authentication and access authorization, transport for short message service (SMS) messages between the UE 204 and an SMS 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 ®

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

[0070] The SMF 266 functions include session management, UE Internet protocol (IP) address allocation and management, selection and control of user plane functions, configuration of traffic steering at the UPF 262 for proper

[0071] Another optional aspect can include an LMF 270, which can be in communication with the 5GC 260 to provide location assistance for UEs 204. The LMF 270 can be implemented as a plurality of separate servers (e.g., physically separate servers, different software modules on a single server, different software modules spread across multiple physical servers, etc.), or alternately can each correspond to a single server. The LMF 270 can be configured to support one or more location services for UEs 204, which can connect to the LMF 270 via the core network, 5GC 260, and / or via the Internet (not illustrated). The SLP 272 can support similar functions as the LMF 270, but whereas the LMF 270 can communicate with the AMF 264, NG-RAN 220, and UEs 204 over the control plane (e.g., using interfaces and protocols intended to carry signaling messages, rather than voice or data), the SLP 272 can communicate with UEs 204 and external clients (e.g., third-party servers 274) over the user plane (e.g., using protocols intended to carry voice and / or data, such as transmission control protocol (TCP) and / or IP).

[0072] Yet another optional aspect can include a third party server 274 that can 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) for the UE 204. Thus, in some cases, the third party server 274 can be referred to as a Location Services (LCS) client or an external client. The third party server 274 can be implemented as a plurality of 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.

[0073] The user plane interface 263 and control plane interface 265 connect the 5GC 260, and in particular the UPF 262 and AMF 264, respectively, to one or more gNBs 222 and / or ng-eNBs 224 in the NG-RAN 220. The interface between gNBs 222 and / or ng-eNBs 224 and AMF 264 is referred to as the “N2” interface, while the interface between gNBs 222 and / or ng-eNBs 224 and UPF 262 is referred to as the “N3” interface. The gNBs 222 and / or ng-eNBs 224 of the NG-RAN 220 can communicate with one another directly via a backhaul connection 223 referred to as an “Xn-C” interface. One or more of the gNBs 222 and / or ng-eNBs 224 can communicate with one or more UEs 204 over a wireless interface referred to as the “Uu” interface.

[0074] The functionality of a gNB 222 can be divided between a gNB central unit (gNB-CU) 226, one or more gNB distributed units (gNB-DUs) 228, and one or more gNB radio units (gNB-RUs) 229. The gNB-CU 226 is a logical node that includes base station functionality other than that specifically allocated to the gNB-DUs 228, including transfer of user data, mobility control, radio access network sharing, positioning, session management, etc. More specifically, the gNB-CU 226 typically 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 typically 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 can 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 the one or more gNB-DUs 228 is referred to as the “Fl” interface. The physical (PHY) layer functionality of the gNB 222 is typically hosted by one or more standalone gNB-RUs 229 that 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, with the gNB-DU 228 via the RLC layer and the MAC layer, and with the gNB-RU 229 via the PHY layer.

[0075] Deployments of communication systems, such as 5G NR systems, can be arranged in a variety of ways with various components or constituent parts. In a 5G NR system or network, a network node, network entity, mobility element of a network, RAN node, core network node, network element, or network equipment, such as a base station or one or more elements (or one or more components) performing base station functionality, can be implemented in an aggregated or disaggregated architecture. For example, a base station, such as a Node B (NB), an evolved NB (eNB), an NR base station, a 5G NB, an access point (AP), a transmission reception point (TRP), or a cell, etc., can be implemented as an aggregated base station (also referred to as a standalone base station or a monolithic base station) or a disaggregated base station.

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

[0077] Base station type operations or network designs can take into account the disaggregated nature of base station functionality. For example, a disaggregated base station can be used in an integrated access backhaul (IAB) network, an open radio access network (O-RAN (such as the network configuration by the O-RAN Alliance ® Disaggregation can include distributing functionality across two or more units at various physical locations, as well as virtually distributing functionality of at least one unit, which can enable flexibility in network design. The various units of a disaggregated base station or disaggregated RAN architecture can be configured for wired or wireless communication with at least one other unit.

[0078] FIG. 2C An example disaggregated base station architecture 250 is illustrated in accordance with aspects of the present disclosure. The disaggregated base station architecture 250 can include one or more central units (CUs) 280 (e.g., gNB-CUs 226) that can communicate directly with a core network 267 (e.g., 5GC 210, 5GC 260) via a backhaul link, or indirectly with the core network 267 through one or more disaggregated base station units, such as a near real-time (near-RT) RAN intelligent controller (RIC) 259 via an E2 link or a non-real-time (non-RT) RIC 257 associated with a service management and orchestration (SMO) framework 255, or both. The CUs 280 can communicate with one or more DUs 285 (e.g., gNB-DUs 228) via respective fronthaul links, such as an Fl interface. The DUs 285 can communicate with one or more radio units (RUs) 287 (e.g., gNB-RUs 229) via respective front-haul links. The RUs 287 can communicate with respective UEs 204 via one or more radio frequency (RF) access links. In some implementations, a UE 204 can be simultaneously served by multiple RUs 287.

[0079] Each of these units (i.e., CU 280, DU 285, RU 287, and near-RT RIC 259, non-RT RIC 257, and SMO framework 255) can include or be coupled to one or more interfaces configured to receive or transmit signals, data, or information (collectively, signals) via wired or wireless transmission media. The associated processor or controller of each of these units, or to which instructions are provided for the communication interface of these units, can be configured to communicate with one or more of the other units via the transmission media. For example, the units can include a wired interface configured to receive or transmit signals to one or more of the other units over a wired transmission medium. Additionally, the units can include a wireless interface, which can include a receiver, a transmitter, or a transceiver (such as a RF transceiver) configured to receive or transmit signals to one or more of the other units over a wireless transmission medium, or both.

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

[0081] DU 285 can correspond to a logical unit that includes one or more base station functions for controlling operation of one or more RUs 287. In some aspects, DU 285 can be at least partially in accordance with a functional split, such as a functional split by the third generation partnership project (3GPP ®) to host one or more of the RLC layer, the MAC layer, and one or more high-PHY layers (such as modules for forward error correction (FEC) encoding and decoding, scrambling, modulation and demodulation, etc.). In some aspects, the DU 285 can also host one or more low-PHY layers. Each layer (or module) can be implemented with an interface configured to communicate signals with other layers (and modules) hosted by the DU 285 or with control functions hosted by the CU 280.

[0082] Lower layer functionality can be implemented by one or more RUs 287. In some deployments, an RU 287 controlled by a DU 285 can correspond to a logical node that hosts RF processing functions or low-PHY layer functions (such as performing fast Fourier transforms (FFTs), inverse FFTs (iFFTs), digital beamforming, physical random access channel (PRACH) extraction and filtering, etc.), or both, based at least in part on a functional split, such as a lower layer functional split. In such an architecture, an RU 287 can be implemented to handle over-the-air (OTA) communications with one or more UEs 204. In some implementations, real-time and non-real-time aspects of control plane and user plane communications with an RU 287 can be controlled by a corresponding DU 285. In some scenarios, this configuration can enable the DUs 285 and CUs 280 to be implemented in a cloud-based RAN architecture, such as a vRAN architecture.

[0083] The SMO framework 255 can be configured to support RAN deployment and orchestration of non-virtualized network elements and virtualized network elements. For non- virtualized network elements, the SMO framework 255 can be configured to support deployment of dedicated physical resources for RAN coverage requirements, which can be managed via an operations and maintenance interface, such as an Ol interface. For virtualized network elements, the SMO framework 255 can be configured to interact with a cloud computing platform, such as an Open Cloud (O-Cloud) 269, to perform network element lifecycle management, such as to instantiate a virtualized network element, via a cloud computing platform interface, such as an 02 interface. Such virtualized network elements can include, but are not limited to, the CU 280, the DU 285, the RU 287, and the near-RT RIC 259. In some implementations, the SMO framework 255 can communicate with hardware aspects of a 4G RAN, such as an Open eNB (O-eNB) 261, via the Ol interface. Additionally, in some implementations, the SMO framework 255 can communicate directly with one or more RUs 287 via the Ol interface. The SMO framework 255 can also include the non-RT RIC 257, which is configured to support the functionality of the SMO framework 255.

[0084] The non-RT RIC 257 can be configured to include logical functions that enable non-real-time control and optimization of RAN elements and resources, including model training and update, AI / ML workflow or policy-based steering of applications / features in the near-RT RIC 259. The non-RT RIC 257 can be coupled to or in communication with the near-RT RIC 259, such as via an Al interface. The near-RT RIC 259 can be configured to include logical functions that enable near-real-time control and optimization of RAN elements and resources via data collection and actions by interfacing, such as via an E2 interface, one or more CUs 280, one or more DUs 285, or both, as well as an O-eNB with the near-RT RIC 259.

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

[0086] FIG. 3A , FIG. 3B and FIG. 3C Illustrated are UE 302, which can correspond to any of the UEs described herein, a base station 304, which can correspond to any of the base stations described herein, and a network entity 306, which can correspond to or embody any of the network functions described herein, including the location server 230 and the LMF 270, or alternatively can be independent of the above-described network functions. FIG. 2A and FIG. 2BA number of example components (represented by corresponding blocks) in the NG-RAN 220 and / or 5GC 210 / 260 infrastructure (such as a dedicated network) depicted in FIG. 3 are illustrated to support operations as described herein. It is contemplated that these components can be implemented in different embodiments in different types of devices (e.g., in ASICs, in SoCs, etc.) with different

[0087] The UE 302 and the base stations 304 each include one or more wireless wide area network (WWAN) transceiver components 310 and 350, respectively, that provide

[0088] In at least some cases, UE 302 and base station 304 each further include one or more short-range wireless transceivers 320 and 360, respectively. Short-range wireless transceivers 320 and 360 can be connected to one or more antennas 326 and 366, respectively, and provide access over a wireless communication medium of interest via at least one designated RAT (e.g., Wi-Fi, LTE Direct, Bluetooth). ® ZIGBEE ® Z-WAVE ® Components (e.g., components for transmitting, components for receiving, components for measuring, components for tuning, components for blocking transmission, etc.) that enable communication between PC5, Dedicated Short-Range Communication (DSRC), Wireless Access for Vehicle Environments (WAVE), Near Field Communication (NFC), Ultra-Wideband (UWB), etc.) and other network nodes (such as other UEs, access points, base stations, etc.). Short-range transceivers 320 and 360 can be configured in different ways to transmit and encode signals 328 and 368 (e.g., messages, indications, information, etc.) respectively according to a specified RAT, and conversely, to receive and decode signals 328 and 368 (e.g., messages, indications, information, pilots, etc.) respectively. Specifically, the short-range wireless transceiver 320 and short-range wireless transceiver 360 each include: one or more transmitters 324 and 364 respectively for transmitting and encoding signals 328 and 368, and one or more receivers 322 and 362 respectively for receiving and decoding signals 328 and 368. As a specific example, the short-range wireless transceiver 320 and short-range wireless transceiver 360 can be Wi-Fi transceivers, Bluetooth transceivers, etc. ® Transceiver, Zigbee ® and / or Z-WAVE ® Transceivers, NFC transceivers, UWB transceivers, or vehicle-to-vehicle (V2V) and / or vehicle-to-everything (V2X) transceivers.

[0089] In at least some cases, UE 302 and base station 304 also include satellite signal receivers 330 and 370. Satellite signal receivers 330 and 370 can be connected to one or more antennas 336 and 376 respectively, and can provide components for receiving and / or measuring satellite positioning / communication signals 338 and 378 respectively. Where satellite signal receivers 330 and 370 are satellite positioning system receivers, satellite positioning / communication signals 338 and 378 can be Global Positioning System (GPS) signals, Global Navigation Satellite System (GLONASS) signals, etc. ®signals, Galileo signals, Beidou signals, Indian Regional Navigational Satellite System (NAVIC), Quasi-Zenith Satellite System (QZSS), etc. In cases where satellite signal receivers 330 and 370 are non-terrestrial network (NTN) receivers, satellite positioning / communication signals 338 and 378 can be communication signals originating from a 5G network (e.g., carrying control data and / or user data). Satellite signal receivers 330 and 370 can include any suitable hardware and / or software for receiving and processing satellite positioning / communication signals 338 and 378, respectively. Satellite signal receivers 330 and 370 can request information and operations from other systems as appropriate, and in at least some cases perform calculations using measurements obtained by any suitable satellite positioning system algorithm to determine the location of UE 302 and base station 304, respectively.

[0090] Base stations 304 and network entities 306 each include one or more network transceivers 380 and 390, respectively, which provide means for communicating (e.g., means for transmitting, means for receiving, etc.) with other network entities (e.g., other base stations 304, other network entities 306). For example, base stations 304 can employ one or more network transceivers 380 to communicate with other base stations 304 or network entities 306 over one or more wired or wireless backhaul links. As another example, network entities 306 can employ one or more network transceivers 390 to communicate with one or more base stations 304 over one or more wired or wireless backhaul links, or with other network entities 306 over one or more wired or wireless core network interfaces.

[0091] The transceiver can be configured to communicate over wired or wireless links. The transceiver, whether a wired or wireless transceiver, includes transmitter circuitry (e.g., transmitters 314, 324, 354, 364) and receiver circuitry (e.g., receivers 312, 322, 352, 362). In some implementations, the transceiver can be an integrated device (e.g., implementing the transmitter circuitry and receiver circuitry in a single device), can include separate transmitter circuitry and separate receiver circuitry in some implementations, or can be implemented in other manners in other implementations. The transmitter circuitry and receiver circuitry of a wired transceiver (e.g., network transceiver 380 and network transceiver 390 in some implementations) can be coupled to one or more wired network interface ports. The wireless transmitter circuitry (e.g., transmitters 314, 324, 354, 364) can include or be coupled to a plurality of antennas (e.g., antennas 316, 326, 356, 366), such as an antenna array, which allows the respective apparatus (e.g., UE 302, base station 304) to perform transmit “beamforming,” as described herein. Similarly, the wireless receiver circuitry (e.g., receivers 312, 322, 352, 362) can include or be coupled to a plurality of antennas (e.g., antennas 316, 326, 356, 366), such as an antenna array, which allows the respective apparatus (e.g., UE 302, base station 304) to perform receive beamforming, as described herein. In an aspect, the transmitter circuitry and receiver circuitry can share the same plurality of antennas (e.g., antennas 316, 326, 356, 366), such that the respective apparatus can only receive or transmit at a given moment in time, not both at the same time. The wireless transceivers (e.g., WWAN transceivers 310 and 350, short-range wireless transceivers 320 and 360) can also include a network listen module (NLM) or the like for performing various measurements.

[0092] As used herein, the various wireless transceivers (e.g., transceivers 310, 320, 350, and 360, and network transceivers 380 and 390 in some implementations) and wired transceivers (e.g., network transceivers 380 and 390 in some implementations) can be generally referred to as “transceivers,” “at least one transceiver,” or “one or more transceivers.” Thus, whether a particular transceiver is a wired or wireless transceiver can be inferred from the type of communication being performed. For example, backhaul communications between network devices or servers typically involve signaling via wired transceivers, while wireless communications between a UE (e.g., UE 302) and a base station (e.g., base station 304) will typically involve signaling via wireless transceivers.

[0093] The UEs 302, the base stations 304, and the network entity 306 also include other components that can be used in conjunction with the operations as disclosed herein. The UEs 302, the base stations 304, and the network entity 306 each include one or more processors 332, 384, and 394, for providing functionality as described herein, as well as for providing other processing functionality. For example, the processors 332, 384, and 394 can include one or more central processing units (CPUs), application specific integrated circuits (ASICs), field

[0094] The UEs 302, the base stations 304, and the network entity 306 each include memory circuitry that implements memory 340, 386, and 396 (e.g., including a memory device, respectively), for maintaining information (e.g., information indicative of reserved resources, thresholds, parameters, etc.). The memory 340, 386, and 396 can therefore provide means for storing, means for retrieving, means for maintaining, etc. In some cases, the UEs 302, the base stations 304, and the network entity 306 can each include a vehicle feature component 342, 388, and 398, respectively. The vehicle feature component 342, 388, and 398 can be hardware circuits that are part of or coupled to the processors 332, 384, and 394, respectively, which when executed, cause the UEs 302, the base stations 304, and the network entity 306 to perform the functionality described herein. In other aspects, the vehicle feature component 342, 388, and 398 can be external to the processors 332, 384, and 394 (e.g., as part of a modem processing system, integrated with another processing system, etc.). Alternatively, the vehicle feature component 342, 388, and 398 can be a memory module stored in the memory 340, 386, and 396, respectively, which when executed by the processors 332, 384, and 394 (or a modem processing system, another processing system, etc.) cause the UEs 302, the base stations 304, and the network entity 306 to perform the functionality described herein. FIG. 3A Possible locations for the vehicle feature component 342 are illustrated, which can be part of, for example, the one or more WWAN transceivers 310, the memory 340, the one or more processors 332, or any combination thereof, or can be a standalone component. FIG. 3BPossible locations of vehicle feature components 388 are illustrated, which can be part of, for example, one or more WWAN transceivers 350, memory 386, one or more processors 384, or any combination thereof, or can be standalone components. FIG. 3C Possible locations of vehicle feature components 398 are illustrated, which can be part of, for example, one or more network transceivers 390, memory 396, one or more processors 394, or any combination thereof, or can be standalone components.

[0095] The UE 302 can include one or more sensors 344 coupled to the one or more processors 332 to provide means for sensing or detecting movement and / or orientation information unrelated to motion data derived from signals received by the one or more WWAN transceivers 310, the one or more short-range wireless transceivers 320, and / or the satellite signal receiver 330. By way of example, the sensors 344 can include an accelerometer (e.g., a micro-electrical- mechanical system (MEMS) device), a gyroscope, a geomagnetic sensor (e.g., a compass), an altimeter (e.g., a barometric altimeter), and / or any other type of movement detection sensor. Moreover, the sensors 344 can include multiple different types of devices and combine their outputs in order to provide motion information. For example, the sensors 344 can use a combination of a multi-axis accelerometer and an orientation sensor to provide the ability to compute positioning in two-dimensional (2D) and / or three-dimensional (3D) coordinate systems.

[0096] Further, the UE 302 includes a user interface 346 that provides means for providing indications (e.g., audible and / or visual indications) to a user and / or for receiving user input (e.g., upon the user actuating a sensing device, such as a keypad, a touchscreen, a microphone, etc.). Although not shown, the base station 304 and the network entity 306 can also include user interfaces.

[0097] Referring to the one or more processors 384 in more detail, in the downlink, IP packets from the network entity 306 can be provided to the processor 384. The one or more processors 384 can implement functionality for the RRC layer, a packet data convergence protocol (PDCP) layer, a radio link control (RLC) layer, and a medium access control (MAC) layer. The one or more processors 384 can provide RRC layer functionality associated with broadcasting of system information (e.g., master information block (MIB), system information blocks (SIBs)), RRC connection control (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), inter-RAT mobility, and measurement configuration for UE measurement reporting; PDCP layer functionality associated with header compression / decompression, security (ciphering, deciphering, integrity protection, integrity verification), and handover support functions; RLC layer functionality associated with the transfer of upper layer PDUs, error detection on the SDCU, concatenation, segmentation, and reassembly of RLC data PDUs, re-segmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functionality associated with mapping between logical channels and transport channels, scheduling information reporting, error correction, priority handling, and logical channel prioritization.

[0098] The transmitter 354 and the receiver 352 can implement layer 1 (LI) functionality associated with various signal processing functions. Layer 1, which includes a physical (PHY) layer, can include error detection on the transport channels, forward error correction (FEC) coding / decoding of the transport channels, interleaving, rate matching, mapping to physical channels, modulation / demodulation of physical channels, and MIMO antenna processing. The transmitter 354 handles mapping to signal constellations based on various modulation schemes (e.g., binary phase-shift keying (BPSK), quadrature phase-shift keying (QPSK), M-phase-shift keying (M-PSK), M-quadrature amplitude modulation (M-QAM)). The coded and modulated symbols can then be split into parallel streams. Each stream can then be mapped to a subcarrier, multiplexed with a reference signal (e.g., pilot) in the time and / or frequency domain, and then combined together using an inverse fast Fourier transform (IFFT) to produce a physical channel carrying a time domain OFDM symbol stream. The OFDM symbol stream is spatially precoded to produce multiple spatial streams if multiple antennas are used. Channel estimates from a channel estimator can be used to determine the spatial

[0099] At UE 302, receiver 312 receives signals via its corresponding antenna 316. Receiver 312 recovers the information modulated onto the RF carrier and provides this information to one or more processors 332. Transmitter 314 and receiver 312 implement Layer 1 functionality associated with various signal processing functions. Receiver 312 can perform spatial processing on the information to recover any spatial streams destined for UE 302. If multiple spatial streams are destined for UE 302, they can be combined by receiver 312 into a single OFDM symbol stream. Receiver 312 then uses a Fast Fourier Transform (FFT) to transform the OFDM symbol stream from the time domain to the frequency domain. The frequency domain signal includes a separate OFDM symbol stream for each subcarrier of the OFDM signal. The symbols on each subcarrier, along with the reference signal, are recovered and demodulated by determining the most probable signal constellation points transmitted by base station 304. These soft decisions can be based on channel estimates calculated by a channel estimator. The soft decisions are then decoded and deinterleaved to recover the data and control signals originally transmitted by base station 304 on the physical channel. Then, data and control signals are provided to one or more processors 332, which implement layer 3 (L3) and layer 2 (L2) functionality.

[0100] In the downlink, one or more processors 332 provide demultiplexing, packet reassembly, decryption, header decompression, and control signal processing between the transport and logical channels to recover IP packets from the core network. One or more processors 332 are also responsible for error detection.

[0101] Similar to the functionality described in conjunction with downlink transmissions performed by base station 304, one or more processors 332 provide: RRC layer functionality associated with system information (e.g., MIB, SIB) acquisition, RRC connectivity, and measurement reporting; PDCP layer functionality associated with header compression / decompression and security (encryption, decryption, integrity protection, integrity verification); RLC layer functionality associated with the delivery of upper-layer PDUs, error correction via ARQ, concatenation, segmentation, and reassembly of RLC SDUs, resegmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functionality associated with mapping between logical channels and transport channels, multiplexing of MAC SDUs onto transport blocks (TBs), demultiplexing of MAC SDUs from TBs, scheduling information reporting, error correction via Hybrid Automatic Repeat Request (HARQ), priority handling, and logical channel priority ordering.

[0102] Channel estimates derived by the channel estimator from a reference signal or feedback transmitted by the base station 304 can be used by the transmitter 314 to select the appropriate coding and modulation schemes, and to facilitate spatial processing. The spatial streams generated by the transmitter 314 can be provided to different antennas 316. The transmitter 314 can utilize a respective spatial stream to modulate an RF carrier.

[0103] The uplink transmission is processed at the base station 304 in a manner similar to that described in connection with the receiver function at the UE 302. A receiver 352 receives the signal through its respective antenna 356. The receiver 352 recovers information modulated onto an RF carrier and provides the information to the one or more processors 384.

[0104] On the uplink, the one or more processors 384 provide demultiplexing between transport and logical channels, packet reassembly, deciphering, header decompression, control signal processing to recover IP packets from the UE 302. IP packets from the one or more processors 384 can be provided to a core network. The one or more processors 384 are also responsible for error detection.

[0105] For convenience, the UE 302, base station 304, and / or network entity 306 are shown FIG. 3A , FIG. 3B and FIG. 3C as including various components that can be configured according to various examples described herein. It should be understood, however, that the illustrated components can have different functionality in different designs. In particular, FIGS. 3A-3C various components in FIG. 3A may be optional in alternative configurations, and various aspects include configurations that can vary due to design choices, cost, use of the device, or other considerations. For example, in the case of ® the UE 302, a particular implementation can omit the WWAN transceiver 310 (e.g., a wearable device or tablet computer or personal computer (PC) or laptop can have Wi-Fi and / or Bluetooth ® capability without cellular capability), or can omit the short-range wireless transceiver 320 (e.g., cellular-only, etc.), or can omit the satellite signal receiver 330, or can omit the sensors 344, etc. As another example, in the case of FIG. 3B the base station 304, a particular implementation can omit the WWAN transceiver 350 (e.g., a Wi-Fi “hotspot” access point without cellular capability), or can omit the short-range wireless transceiver 360 (e.g., cellular-only, etc.), or can omit the satellite signal receiver 370, etc. For brevity, examples of various alternative configurations are not provided herein, but would be readily understandable to one of skill in the art.

[0106] Various components of UE 302, base station 304, and network entity 306 can be communicatively coupled to each other via data buses 334, 382, ​​and 392, respectively. In one aspect, data buses 334, 382, ​​and 392 can form or be part of the communication interfaces of UE 302, base station 304, and network entity 306, respectively. For example, in cases where different logical entities are embodied in the same device (e.g., gNB and location server functionality integrated into the same base station 304), data buses 334, 382, ​​and 392 can provide communication between these different logical entities.

[0107] FIG. 3A , FIG. 3B and FIG. 3C The components can be implemented in various ways. In some specific implementations, FIG. 3A , FIG. 3B and FIG. 3C The components can be implemented in one or more circuits, such as, for example, one or more processors and / or one or more ASICs (which may include one or more processors). Here, each circuit may use and / or combine at least one memory component for storing information or executable code used by the circuit to provide that functionality. For example, some or all of the functionalities represented by blocks 310 to 346 may be implemented by the processor and memory components of UE 302 (e.g., by executing appropriate code and / or by appropriate configuration of the processor components). Similarly, some or all of the functionalities represented by blocks 350 to 388 may be implemented by the processor and memory components of base station 304 (e.g., by executing appropriate code and / or by appropriate configuration of the processor components). Moreover, some or all of the functionalities represented by blocks 390 to 398 may be implemented by the processor and memory components of network entity 306 (e.g., by executing appropriate code and / or by appropriate configuration of the processor components). For simplicity, various operations, actions, and / or functions are described herein as being performed "by the UE," "by the base station," "by the network entity," etc. However, it should be understood that such operations, actions and / or functions can actually be performed by specific components or combinations of components of the UE 302, base station 304, network entity 306, etc. (such as processors 332, 384, 394, transceivers 310, 320, 350 and 360, memory 340, 386 and 396, vehicle feature components 342, 388 and 398, etc.).

[0108] In some designs, the network entity 306 can be implemented as a component of a core network. In other designs, the network entity 306 can be distinct from the operations of a network operator or cellular network infrastructure (e.g., NG RAN 220 and / or 5GC 210 / 260). For example, the network entity 306 can be a component of a private network that can be configured to communicate with the UE 302 via the base station 304 or independent of the base station 304 (e.g., through a non-cellular communication link such as Wi-Fi).

[0109] Autonomous and semi-autonomous safety technology uses a combination of hardware (sensors, cameras, and radar) and software to help vehicles identify specific safety risks so that they can alert the driver to take action (in the case of advanced driver assistance systems (ADAS)) or take action themselves (in the case of autonomous driving systems (ADS)) to avoid a collision. Vehicles equipped with ADAS or ADS include one or more camera sensors mounted on the vehicle that capture images of the scene in front of the vehicle, and possibly also behind and to the sides of the vehicle. Radar systems can also be used to detect objects along the road of travel and possibly behind and to the sides of the vehicle. Radar systems utilize RF waves to determine the range, direction, speed, and / or height of objects along the road. More specifically, a transmitter sends out pulses of RF waves that bounce off any objects in their path. The pulses reflected from the objects return a small portion of the RF wave’s energy to a receiver, which is typically located at the same location as the transmitter. Cameras and radar are typically oriented to capture their respective versions of the same scene.

[0110] Processors within the vehicle, such as digital signal processors (DSPs), analyze the captured camera images and radar frames and attempt 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 under a variety of weather conditions. However, radar systems typically do not have sufficient resolution to identify features of the detected objects. Camera sensors, however, typically do provide sufficient resolution to identify object features. Cues of object shape and appearance extracted from the captured images can provide sufficient characteristics for classification of different objects. Given the complementary nature of the two sensors, data from both sensors can be combined (referred to as “fused”) in a single system for improved performance.

[0111] Modern vehicles are increasingly incorporating technologies that help drivers avoid drifting into adjacent lanes or making unsafe lane changes (e.g., lane departure warnings (LDW)), or warn drivers of other vehicles behind them when they are backing up, or automatically brake in the event of a sudden stop or deceleration of a vehicle in front of them (e.g., forward collision warnings (FCW)), and so on. Continued evolution of automotive technology aims to provide greater safety benefits, and ultimately to provide ADSs that can handle the entire driving task without user intervention.

[0112] There are six levels defined to achieve full automation. At Level 0, a human driver does all the driving. At Level 1, advanced driver assistance systems (ADAS) on the vehicle can sometimes assist the human driver with steering or braking / accelerating, but not both at the same time. At Level 2, ADAS on the vehicle can itself actually control both steering and braking / accelerating at the same time in some situations. The human driver must continue to focus full attention and perform the rest of the driving tasks at all times. At Level 3, an ADS on the vehicle can itself perform all aspects of the driving task in certain situations. In those situations, the human driver must be ready to take back control at any time the ADS requests the human driver to do so. In all other situations, the human driver performs the driving tasks. At Level 4, an ADS on the vehicle can itself perform all driving tasks and monitor the driving environment, essentially doing all the driving in certain situations. The human passenger does not need to focus attention in those situations. At Level 5, an ADS on the vehicle can do all the driving in all situations. The human occupants are just passengers, and never need to be involved in driving.

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

[0114] Note that an autonomous or semi-autonomous vehicle can be, but is not necessarily, a vehicle UE (V-UE). Likewise, a V-UE can be, but is not necessarily, an autonomous or semi-autonomous vehicle. An autonomous or semi-autonomous vehicle is a vehicle equipped with an ADAS or an 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.

[0115] FIG. 4 An example architecture of an on-board computer (OBC) 400 of a vehicle is illustrated in accordance with various aspects of the present disclosure. In an aspect, the OBC 400 can be part of an ADAS or an ADS of a vehicle. The OBC 400 can also be a V-UE of a vehicle. The OBC 400 includes a non-transitory computer-readable storage medium (i.e., memory 404) and one or more processors 406 in communication with the memory 404 via a data bus 408. The memory 404 includes one or more storage modules storing computer-readable instructions that are executable 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 the various operations described herein.

[0116] One or more radar camera sensor modules 420 are coupled to the OBC 400 (for simplicity, only one is shown). In some aspects, the radar camera sensor module 420 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 the one or more processors 406 to the radar camera sensor module 420, and optionally to other vehicle subsystems (not shown), over the data bus 408. FIG. 4

[0117] In an aspect, the camera 412 can capture image frames (also referred to herein as camera frames) of a scene within a viewing area of the camera 412 at some periodic rate. Likewise, the radar 414 can capture radar frames of a scene within a viewing area of the radar 414 at some periodic rate. The periodic rates at which the camera 412 and the radar 414 capture their respective frames can be the same or different. Each camera and radar frame can be time-stamped. Thus, in the case of different periodic rates, the time stamps can be used to select captured camera frames and radar frames at the same or nearly the same time for further processing (e.g., fusion).

[0118] ​OBC 400 also includes, at least in some cases, one or more wireless wide area network (WW AN) transceivers 430 configured to communicate via one or more wireless communication networks (not shown), such as an NR network, an LTE network, and / or a Global System for Mobile Communications (GSM) network, etc. The one or more WW AN transceivers 430 can be connected to one or more antennas (not shown) for use in communicating with other network nodes, such as other V-UEs, pedestrian UEs, infrastructure access points, road side 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 (e.g., certain set of time / frequency resources in a particular frequency spectrum) of interest. The one or more WW AN transceivers 430 can be variously configured for transmitting and encoding signals (e.g., messages, indications, information, and so on) and, conversely, for receiving and decoding signals (e.g., messages, indications, information, pilots, and so on) in accordance with the designated RAT.

[0119] OBC 400 also includes, at least in some cases, one or more short-range wireless transceivers 440 (e.g., Wi-Fi transceivers, Bluetooth transceivers, Zigbee transceivers, etc.). The one or more short-range wireless transceivers 440 can be connected to one or more antennas (not shown) for use in 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 ® Vehicles Environments (WAVE), dedicated short-range communications (DSRC), etc.) over a wireless communication medium of interest. The one or more short-range wireless transceivers 440 can be variously configured for transmitting and encoding signals (e.g., messages, indications, information, and so on) and, conversely, for receiving and decoding signals (e.g., messages, indications, information, pilots, and so on) in accordance with the designated RAT.

[0120] As used herein, a “transceiver” can include transmitter circuitry, receiver circuitry, or a combination thereof. In some implementations, a transceiver can be an integrated device (e.g., implementing transmitter circuitry and receiver circuitry in a single device), in some implementations can include a separate transmitter circuitry and a separate receiver circuitry, or in other implementations can be implemented in other manners. Wireless transmitter circuitry can include or be coupled to a plurality of antennas (such as an antenna array) that allow the respective device (e.g., OBC 400) to perform transmit “beamforming,” as described herein. Similarly, wireless receiver circuitry can include or be coupled to a plurality of antennas (such as an antenna array) that allow the respective device (e.g., OBC 400) to perform receive beamforming, as described herein. In an aspect, the transmitter circuitry and receiver circuitry can share the same plurality of antennas, such that the respective device can only receive or transmit at a given time, not both. A transceiver need not provide both transmit and receive functionality in all designs. For example, in some designs a low functionality receiver circuitry can be employed to reduce cost when there is no need to provide full communication (e.g., a simple receiver chip or similar circuitry that provides low level sniffing). Wireless transceivers (e.g., one or more WWAN transceivers 430) can also include a network listen module (NLM) or the like for performing various measurements.

[0121] OBC 400 also includes, at least in some cases, a global navigation satellite system (GNSS) receiver 450. GNSS receiver 450 can be connected to one or more antennas (not shown) for receiving satellite signals. GNSS receiver 450 can include any suitable hardware and / or software for receiving and processing GNSS signals. GNSS receiver 450 requests information and operates from other systems as appropriate, and performs calculations needed to determine the positioning of the vehicle using measurements obtained through any suitable GNSS algorithm.

[0122] In an aspect, the OBC 400 can 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 can then be stored in the memory 404 and used to obtain navigation map data for vehicle navigation. The maps 402 can be one or more HD maps that can provide accuracy within 7 cm to 10 cm absolute range, a highly detailed catalog of all fixed physical assets related to roads, such as road lanes, road edges, shoulders, dividers, traffic signals, signs, painted markings, poles, and other data that facilitate safe navigation of a vehicle on roads and intersections. The maps 402 can also provide electronic horizon prediction awareness, which enables a vehicle to know what is ahead. Information about road lanes can include number of lanes, width, type (e.g., high-occupancy vehicle (HOV) or non-HOV), direction of traffic, etc. Alternatively, the maps 402 can be more generic or simplified, where roads are represented as linear segments and / or road headings. Thus, the range of navigation map data that can be obtained from the maps 402 can range from locations and dimensions of fixed physical assets related to roads and paths to just road headings.

[0123] One or more sensors 460 of the vehicle can be coupled to the one or more processors 406 via the one or more system interfaces 410. The one or more sensors 460 can provide components for sensing or detecting information related to a state and / or environment of the vehicle, such as speed, heading (e.g., compass heading), headlight status, fuel consumption, etc. By way of example, the one or more sensors 460 can 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 outside of the OBC 400, some of these sensors 460 can be located on the OBC 400 and some can be located elsewhere in the vehicle.

[0124] OBC 400 can also include a vehicle controller 418. Vehicle controller 418 can be hardware circuitry that is part of or coupled to the one or more processors 406 that, when executed, cause OBC 400 to perform the functionality described herein. In other aspects, vehicle controller 418 can be external to the one or more processors 406 (e.g., as part of a positioning processing system, integrated with another processing system, etc.). Alternatively, vehicle controller 418 can be one or more memory modules stored in memory 404 that, when executed by the one or more processors 406 (or a positioning processing system, another processing system, etc.) cause OBC 400 to perform the functionality described herein. As a particular example, vehicle controller 418 can include a plurality of positioning engines, a positioning engine aggregator, and / or a sensor fusion module, among others. FIG. 4 Possible locations of vehicle controller 418 are illustrated, which can be part of, for example, memory 404, the one or more processors 406, or any combination thereof, or can be a standalone component.

[0125] Although not shown, OBC 400 can include or be coupled to a user interface (e.g., a touchscreen) for providing indications (e.g., audible and / or visual indications) to a user and / or for receiving user inputs (e.g., upon user actuation of a sensing device such as a keypad, touchscreen, microphone, etc.).

[0126] For convenience, OBC 400 is shown in FIG. 4 as including various components that can be configured in accordance with the various examples described herein. However, it should be understood that the illustrated components can have different functionality in different designs. Specifically, FIG. 4 Various components in are optional in alternative configurations, and various aspects include configurations that can vary due to design choices, cost, use of the device, or other considerations. For example, a particular implementation of OBC 400 can omit WWAN transceiver 430 (e.g., a V-UE can have Wi-Fi and / or Bluetooth ® functionality without cellular functionality), or can omit short-range wireless transceiver 440 (e.g., cellular only, etc.), among other possibilities. For brevity, illustration of various alternative configurations is not provided herein, but would be readily understood by one of skill in the art.

[0127] FIG. 4 Components of can be implemented in various ways. In some implementations, FIG. 4Components of the system can be implemented in one or more circuits, such as, for example, one or more processors and / or one or more Application Specific Integrated Circuits (ASICs) (which can include one or more processors). Here, each circuit can use and / or incorporate at least one memory component for storing information or executable code used by the circuit to provide the functionality. For simplicity, various operations, actions, and / or functions are described herein as being performed “by the OBC,” “by the V-UE,” or “by the vehicle,” etc. However, it will be understood that such operations, actions and / or functions can actually be performed by specific components of the OBC 400 or combinations of components, such as the one or more processors 406, the one or more transceivers 430 and 440, the memory 404, the vehicle controller 418, etc.

[0128] Assumptions about how technology is shaped and how technology is used. Outdated assumptions and unknown dependencies can have an impact on the recognition of hazards, misuse, and disuse in assisted driving and autonomous driving functions. Aggregative thinking and directional motivated thinking during design can lead to predetermined conclusions and assumptions.

[0129] Given the incentive to arrive at specific conclusions that are not contradictory to these assumptions and that defend preconceived notions, this cognitive bias can lead to skewed methods of post-deployment evidence evaluation.

[0130] There is a need to reduce subjectivity and introduce more objectivity and adaptability in assumption evaluation during the design, pre-deployment, and post-deployment of safety-critical, user-friendly products.

[0131] Some aspects of the present disclosure generally relate to listing all assumptions associated with a driver and ensuring sufficient confidence in those assumptions prior to deployment and tracking those assumptions periodically after deployment, thereby promoting correct usage while maintaining necessary safety margins. To this end, aspects of the present disclosure relate to assumption verification (e.g., at a driver level, a fleet level, pre-deployment, post-deployment, etc.), whereby a confidence level validly associated with a certain assumption is determined based on monitoring behavior of a focused driver. Such aspects can provide various technical advantages, such as improved vehicle safety, improved user (i.e., driver) experience, improved engagement between a driver and one or more available vehicle features, etc.

[0132] FIG. 5 An exemplary process 500 of communication is illustrated in accordance with an aspect of the present disclosure. FIG. 5 The process 500 is performed by a device such as the UE 302 or gNB / BS 304 or an O-RAN device (e.g., RU / DU / CU / etc.) or a network server such as the network entity 306, etc.

[0133] Reference FIG. 5At 510, the device (e.g., receiver 312 or 322 or 352 or 362, network transceiver 380 or 390, etc.) receives a hypothesis associated with a vehicle feature, the hypothesis defining (i) at least one response of an attentive driver to at least one in-vehicle human-machine communication interface stimulus, (ii) timing information associated with at least one in-vehicle driver action, or (iii) a combination thereof. For example, the vehicle feature can correspond to an advanced driver assistance system (ADAS) feature or an autonomous driving system (ADS) feature.

[0134] Referring to FIG. 5, example operations 500 for communicating in a wireless communication system are illustrated. The example operations 500 can be implemented by a network component, such as a UE 302 or a gNB / BS 304 or an O-RAN device (e.g., a RU / DU / CU / etc.) or a network server, such as a network entity 306, etc. FIG. 5 At 520, the device (e.g., receiver 312 or 322 or 352 or 362, sensor 344, network transceiver 380 or 390, vehicle feature component 342 or 388 or 398, processor 332 or 384 or 394, etc.) monitors behavior of one or more attentive drivers. In some designs, the monitoring at 520 can involve coordination between the device and one or more V-UEs coupled to a vehicle being driven by the attentive driver. In some designs, the attentive driver can include a single driver or a small group of drivers (e.g., post-deployment), while in other designs, the attentive driver can include a fleet of drivers (e.g., pre-deployment).

[0135] Referring to FIG. 5, example operations 500 for communicating in a wireless communication system are illustrated. The example operations 500 can be implemented by a network component, such as a UE 302 or a gNB / BS 304 or an O-RAN device (e.g., a RU / DU / CU / etc.) or a network server, such as a network entity 306, etc. FIG. 5 At 530, the device (e.g., vehicle feature component 342 or 388 or 398, processor 332 or 384 or 394, etc.) computes a confidence level associated with the hypothesis being valid based on the monitoring. For example, for a stimulus-driven hypothesis, assume that the stimulus occurs N times, and that the driver performed the expected / hypothesized response X times out of those N times. In this case, the confidence level can be X / N.

[0136] Referring to FIG. 5, example operations 500 for communicating in a wireless communication system are illustrated. The example operations 500 can be implemented by a network component, such as a UE 302 or a gNB / BS 304 or an O-RAN device (e.g., a RU / DU / CU / etc.) or a network server, such as a network entity 306, etc. FIG. 5 At 540, the device (e.g., receiver 312 or 322 or 352 or 362, transmitter 314 or 324 or 354 or 364, network transceiver 380 or 390, vehicle feature component 342 or 388 or 398, processor 332 or 384 or 394, etc.) performs one or more actions based on the confidence level.

[0137] FIG. 6 An example process 600 of communicating according to an aspect of the present disclosure is illustrated. FIG. 6 The process 600 is performed by a network component, such as a UE 302 or a gNB / BS 304 or an O-RAN device (e.g., a RU / DU / CU / etc.) or a network server, such as a network entity 306, etc.

[0138] Referring to FIG. 6, example operations 600 for communicating in a wireless communication system are illustrated. The example operations 600 can be implemented by a network component, such as a UE 302 or a gNB / BS 304 or an O-RAN device (e.g., a RU / DU / CU / etc.) or a network server, such as a network entity 306, etc. FIG. 6At 610, the network component (e.g., transmitter 314 or 324 or 354 or 364, network transceiver 380 or 390, etc.) transmits, to a device, a hypothesis associated with a vehicle feature, the hypothesis defining (i) at least one response of an attentive driver to at least one in-vehicle human-machine communication interface stimulus, (ii) timing information associated with at least one in-vehicle driver action, or (iii) a combination thereof. For example, the vehicle feature can correspond to an advanced driver assistance system (ADAS) feature or an autonomous driving system (ADS) feature.

[0139] Referring to FIG. 6 At 620, the device (e.g., receiver 312 or 322 or 352 or 362, network transceiver 380 or 390, etc.) receives, in response to the transmitting, a confidence level associated with the hypothesis validity, the confidence level being based on monitoring of behavior of one or more attentive drivers.

[0140] Referring to FIGS. 5-6 In some designs, the confidence level is greater than 0% and less than 100%. In some designs, the confidence level comprises a Bayesian confidence level.

[0141] Referring to FIGS. 5-6 In some designs, the hypothesis defines the at least one response of the attentive driver to the at least one in-vehicle human-machine communication interface stimulus. In one aspect, the at least one in-vehicle human-machine communication interface stimulus comprises a status indicator associated with a battery charge state, a fuel level, a vehicle temperature, or any combination thereof, or an alert message, or any combination thereof. In yet another aspect, the at least one response comprises, within a threshold time period after the stimulus: a gaze direction of the attentive driver, or a hand movement or gesture of the attentive driver, or a combination thereof.

[0142] Referring to FIGS. 5-6 In some designs, the hypothesis defines the timing information associated with at least one in-vehicle driver action, and the timing information comprises a timing pattern associated with the attentive driver engaging or disengaging the vehicle feature.

[0143] Referring to FIGS. 5-6 In some designs, the one or more attentive drivers comprise one or more test drivers associated with a fleet of test vehicles in a pre-deployment phase of the vehicle feature, or the one or more attentive drivers comprise one or more consumer drivers in a post-deployment phase of the vehicle feature.

[0144] Referring to FIGS. 5-6In some designs, the vehicle feature includes a safety feature or a user experience feature. For example, the safety feature or the user experience feature can correspond to an ADAS feature or an ADS feature.

[0145] Referring to FIGS. 5-6 In some designs, the confidence level is below a threshold, and

[0146] wherein the one or more actions include:

[0147] • sending an indication to a developer of the vehicle feature that the confidence level is below the threshold, or

[0148] • performing one or more mitigation operations associated with the vehicle feature in response to the confidence level being below the threshold, or

[0149] • continuing to track the confidence level to determine whether the confidence level increases above the threshold, or

[0150] • any combination thereof.

[0151] Referring to FIGS. 5-6 In some designs, the attentive driver associated with the hypothesis is associated with a default attentive driver profile, or the attentive driver associated with the hypothesis is associated with a particular kind or class of driver, or the attentive driver associated with the hypothesis is associated with a particular driver.

[0152] Referring to FIGS. 5-6 In some designs, the device further receives (and the network component further sends) a hypothesis evaluation schedule associated with the vehicle feature, wherein the monitoring, the calculating the execution is performed in accordance with the hypothesis evaluation schedule.

[0153] Referring to FIGS. 5-6 In some designs, the network component further determines that the confidence level is below a threshold, and updates the hypothesis associated with the vehicle feature based on the confidence level. In yet another aspect, the network component further modifies the vehicle feature based on the updated hypothesis associated with the vehicle feature. In yet another aspect, the network component further sends the updated hypothesis associated with the vehicle feature, and receives an updated confidence level associated with the updated hypothesis being valid (e.g., from the device) in response to the sending of the updated hypothesis. In other words, hypothesis evaluation can be part of a continuous feedback loop to improve or tune the hypothesis until the hypothesis is generally valid in order to tune / modify the vehicle feature accordingly.

[0154] Referring to FIGS. 5-6 In a specific example, divergent thinking and critical thinking can be used to objectify a hypothesis and reduce systematic bias.FIGS. 5-6 The process of 405 can facilitate truth-seeking patterns during aided or automated feature design during pre-deployment phases and post-deployment phases. In an aspect, the goal of the vehicle feature is to go out and objectively look at the outside world and form an accurate mental model that includes areas of uncertainty. In an aspect, the vehicle feature uses the process of 405 as a calibration pattern that continually or continuously updates an internal checklist of assumptions about driver behavior and a confidence metric for each assumption prior to deployment (pre-deployment pattern) to feedback learning to the designer and seek opportunities to invalidate these assumptions periodically (periodically in a post-deployment pattern) in the post-deployment cycle. FIGS. 5-6

[0155] Referring to FIGS. 5-6 , in particular examples, learning can then be applied to system design changes that can be used as software updates and / or leveraged in future system designs. In some designs, if the process of 405 learns some dangerous information about driver behavior or driver misuse of the system, one or more mitigation actions can be built into the next software update or system version of the system. In an aspect, this can be implemented as a software component within the pattern manager that tracks these metrics to eliminate inherent biases of the driver to proper system usage during design. FIG. 7

[0156] FIGS. 8-9 Example use cases of the process of 405 are depicted in Table 700 of 405 and will be described in more detail below with reference to 405. FIGS. 5-6 FIGS. 5-6 Referring to , in particular examples,

[0157] the process of 405 can use confidence as a metric to decide the type of mitigation and iteratively close the gap between the driver mental model and the designer mental model based on the following assumption classifications, for example: FIGS. 5-6 FIG. 8 • If the gap in the assumption is safety critical ( ), help the driver to achieve the best behavior, for example, modify the alert and improve the HMI interaction to ensure safe cooperation and re-evaluate the confidence in the subsequent driving cycle, or feedback to the designer to modify the assumption if the confidence remains below a threshold (e.g., 50%) at all times.

[0158] • If the gap in the assumption is state dependent (like pattern information), adjust the feature behavior, for example, display information in the area of frequent gaze direction instead of trying to shift the gaze to where the information is located, and re-evaluate the confidence or modify the assumption in the subsequent driving cycle, with the goal of keeping the confidence above a threshold (e.g., 50%).

[0159] • If the gap in the assumption is state dependent (like pattern information), adjust the feature behavior, for example, display information in the area of frequent gaze direction instead of trying to shift the gaze to where the information is located, and re-evaluate the confidence or modify the assumption in the subsequent driving cycle, with the goal of keeping the confidence above a threshold (e.g., 50%).

[0160] ​​​• If the gap in the assumption is related to abandonment or suboptimal use, help the driver in the learning curve for that particular aspect and reevaluate the confidence in the subsequent driving cycles, or feedback to the designer to modify the assumption if the confidence remains below a threshold (e.g., 50%) at all times.

[0161] In yet another aspect, the device can continue to periodically monitor the confidence threshold to evaluate the validity and adjust the mitigation accordingly to reach and maintain in the high confidence region (e.g., > 50%?).

[0162] In yet another aspect, the driver attempts to terminate the DMS alert by a slight movement of the steering wheel (Phase 1: EOR). The driver only briefly orients his / her eyes to the road (approximately 92 ms). The discovery of the collision only occurs after the DMS state 1 alert. In this case, due to the participant’s (in real life) previous L2H onboarding experience, there can be confusion between the hands-on request and the eyes-on request. Thus, via the process of FIGS. 5-6 , an improved DMS design can be derived to make adjustments for the observed problematic driver behavior (i.e., new criteria to guide the termination of the DMS alert).

[0163] FIG. 8 Example implementations 800 of the processes 500-600 of FIG. 8 are illustrated, in accordance with aspects of the present disclosure. At the start of FIG. 9 , the assumption has been made prior to the standard operating procedure (SOP) based on existing research. In this case, the assumption at 802 is that a hands-off driver takeover can be expected to remain engaged when the host vehicle deviates from the lane near a construction zone.

[0164] FIGS. 5-6 Pre-deployment (804-810) and post-deployment (812-814, 808, 810) operational sequences are depicted.

[0165] For the pre-deployment operational sequence, at 804, the assumption of 802 is true at the pre-deployment phase. At 806, the intervention behavior of other drivers is monitored. At 808, based on the behavior monitoring at 806, the confidence of the assumption is determined to be 80%. At 810, based on the confidence from 808, the vehicle feature enables the hands-off mode as long as the confidence is above a threshold.

[0166] For the post-deployment sequence of operations, at 812, the hypothesis of 802 is assumed to be true in the post-deployment phase. At 814, future intervention behavior of other drivers in similar scenarios is tracked. At 808, based on the behavior monitoring at 814, the confidence of the hypothesis is determined to be 80%. At 810, based on the confidence from 808, the vehicle feature enables hands-off mode as long as the confidence is above a threshold.

[0167] FIG. 9 Example implementations 900 of processes 500-600 are illustrated with respect to FIGS. 9A-9B, respectively, in accordance with aspects of the present disclosure. FIG. 9 FIG. 10 At the beginning of the process, a hypothesis has been formulated prior to the standard operating procedure (SOP) based on existing research. In this case, at 902, the hypothesis is: a driver who is expected to remain engaged, hands-off, continues to look at the road after system-initiated deactivation, so the reason for deactivation can be shown on the head-up display.

[0168] FIGS. 5-6 Pre-deployment (904-910) and post-deployment (912-914, 908, 910) sequences of operations are depicted.

[0169] For the pre-deployment sequence of operations, at 904, the hypothesis of 902 is assumed to be true in the pre-deployment phase. At 906, customer fleet data related to take-over manual transitions within x kilometers in the target operational design domain (ODD) is tracked. At 908, based on the behavior monitoring at 906, the confidence of the hypothesis is determined to be 40%. At 910, based on the confidence from 908, the vehicle feature next system version is updated so that the reason for deactivation is shown in the instrument cluster. In other words, the hypothesis is updated, and the process can return to 902 using the updated hypothesis.

[0170] For the post-deployment sequence of operations, at 912, the hypothesis of 902 is determined to be false in the post-deployment phase. Specifically, at 914, the driver instead looks at the instrument cluster after deactivation from hands-off to manual in multiple drives. At 908, based on the behavior monitoring at 914, the confidence of the hypothesis is determined to be 40%. At 910, based on the confidence from 908, the vehicle feature next system version is updated so that the reason for deactivation is shown in the instrument cluster. In other words, the hypothesis is updated, and the process can return to 902 using the updated hypothesis.

[0171] FIG. 10 Example implementations 1000 of processes 500-600 are illustrated with respect to FIGS. 10A-10B, respectively, in accordance with aspects of the present disclosure. FIG. 10 FIGS. 8-10 ​​At the beginning, assume that a hypothesis has been formulated prior to the standard operating procedure (SOP) based on existing research. In this case, at 1002, the hypothesis is that the driver is expected to remain engaged, and the driver disengages the autonomous feature while navigating through the toll road.

[0172] FIG. 11 The pre-deployment (1004-1010) and post-deployment (1012-1014, 1008, 1010) operational sequences are depicted.

[0173] For the pre-deployment operational sequence, at 1004, the hypothesis of 1002 is assumed to be true at the pre-deployment stage. At 1006, the hypothesis from 1002 is evaluated only in a simulation study of untrained drivers. At 1008, based on the simulated behavior monitoring at 1006, the confidence of the hypothesis is determined to be 20%. At 1010, based on the confidence from 1008, the text system version is updated such that the human-machine interface (HMI) provides expected information about the availability of the toll station. In other words, the hypothesis is updated, and the process can return to 1002 using the updated hypothesis.

[0174] For the post-deployment operational sequence, at 1012, the hypothesis of 1002 is determined to be false at the post-deployment stage. Specifically, at 1014, the driver instead deactivates the system while moving through the toll station and reactivates it after passing through. At 1008, based on the behavior monitoring at 1014, the confidence of the hypothesis is determined to be 20%. At 1010, based on the confidence from 1008, the vehicle feature next system version is updated such that the reason for deactivation is shown in the instrument cluster. In other words, the hypothesis is updated, and the process can return to 1002 using the updated hypothesis.

[0175] Reference FIGS. 5-6 In some designs, different transfers of control of a vehicle feature can be defined. Examples of transfer types include strategic transfers, maneuver transfers, and control transfers.

[0176] In some designs, strategic transfers of control relate to the planning of a trip and long-term goals (e.g., time scale is minutes - proactive). Examples of strategic transfers include pulling off a maneuver, changing lanes in preparation for pulling off, and merging onto a new route (within the ODD).

[0177] In some designs, maneuver transfers of control involve tactical transfers of actions taken to meet overall goals and in conjunction with environmental factors (e.g., time scale is seconds - proactive and reactive). Examples of maneuver transfers include passing a slow vehicle in front, accelerating to pass a neighboring vehicle, and disengaging from a merge to change lanes manually.

[0178] In some designs, the control transfer includes a driver disengagement that is specifically related to operational control of the vehicle in response to environmental stimuli (e.g., time scale is milliseconds - passive). Examples of control transfers include an increase in traffic density or loss of free flow, merging vehicles, unexpected road changes (e.g., construction), and law enforcement or emergency vehicles.

[0179] FIG. 11 A vehicle assumption evaluation system 1100 is illustrated in accordance with aspects of the present disclosure. The vehicle assumption evaluation system 1100 depicts logical modules and performs processes 500-600 of FIG. 5 The devices and network components that perform processes 500-600 can map to certain groups of the logical modules depicted FIG. 6 Generally, the devices that perform process 500 map to the false setting confidence tracker module 1110 and the backend / cloud module 1130, while the network components that perform process 600 map to the OEM 1134. FIG. 11 FIG. 11 Referring to

[0180] The vehicle assumption evaluation system 1100 includes a false setting confidence tracker module 1110, a perception / localization module 1112, an environment modeler 1114, a DMS / steering module 1116, an engagement manager 1118, an HMI 1120, a UX manager 1122, a mode manager 1124, a backend / cloud module 1130, an assumption lookup table 1132, an OEM 1134, and a fleet 1136. FIGS. 5-6 The perception / localization module 1112 provides a world model to the environment modeler 1114, which provides a current ODD to the false setting confidence tracker module 1110. The DMS / steering module 1116 provides eye / hand tracking data to the engagement manager 1118. The engagement manager 1118 provides a current engagement to the false setting confidence tracker module 1110, and the false setting confidence tracker module 1110 returns a confidence-based modification. The HMI 1120 provides a use contact point to the UX manager 1122. The UX manager provides a current use to the false setting confidence tracker module 1110, and the false setting confidence tracker module 1110 returns a confidence-based modification. The mode manager 1124 provides a trigger to the false setting confidence tracker module 1110 to evaluate false setting confidence, and the false setting confidence tracker module 1110 returns a confidence-based modification.

[0181]

[0182] ​​The false setup confidence tracker module 1110 provides self-vehicle false hypothesis uploads to the backend / cloud module 1130. The false setup confidence tracker module 1110 provides context / updates to the false hypothesis lookup table 1132, and the false hypothesis lookup table 1132 provides context-based filtering to the false setup confidence tracker module 1110. The false hypothesis lookup table 1132 receives false hypothesis logs from the backend / cloud module 1130, and the false hypothesis lookup table 1132 provides updates to the false hypotheses to the backend / cloud module 1130. The OEM 1134 uploads hypotheses to the backend / cloud module 1130, and the backend / cloud module 1130 feeds back false hypotheses to the OEM 1134. The backend / cloud module 1130 provides fleet recommendations to the fleet 1136, and the fleet 1136 returns updates to false hypotheses to the backend / cloud module 1130.

[0183] Reference ​ In more detail, the cloud / backend module 1130 receives feedback from the fleet 1136, the OEM 1134, and the self-vehicle. This forms the basis of learning as well as additions to the false hypothesis lookup table 1132, which is a local copy of the latest list of driver-related hypotheses used by the self-vehicle in the false hypothesis evaluation mode, while being evaluated by the false setup confidence tracker module 1110. The false setup confidence tracker module 1110 subsequently tracks this self-vehicle context and associated self-driver responses to periodically provide a runtime confidence level for each of these hypotheses. The false setup confidence tracker module 1110 is periodically triggered by the mode manager, and while active, the false setup confidence tracker module 1110 runs confidence assessments on filtered hypotheses based on categorization according to safety, status, usage according to current ODD, and proposes policy modifications for relevant architectural elements if needed to reduce the gap in case the confidence metric drops below a threshold (e.g., < 50%).

[0184] Reference ​ In some designs, incorrect outdated hypotheses during design, followed by false sensing of confidence in features during deployment and in drivers during usage, hinder today’s safe assisted driving or autonomous driving experiences. Systematically evaluating these hypotheses and eliminating inherent biases in the design helps to address this problem by unanchoring and embracing uncertainty. Driver-related triggers are incorporated into the logging solution, and each trigger is used to compute the confidence that the driver will behave in a certain way given a particular context. So far, confidence tracking has been used in sensor fusion for detection evaluation, and the concept tries to use it as a framework to introduce an exclusive reconnaissance mode as a meta-mode before / during / after feature operation.

[0185] In the detailed description above, various features are grouped together in examples. This manner of disclosure should not be understood as an intention that the examples are to be taken in a way that any particular feature is required to be in every example. The various aspects of the disclosure can include fewer than all the features of each disclosed example. Therefore, the following clauses should be taken to be incorporated by reference into the description in which each clause can stand on its own as a separate example. Although each dependent clause can refer to a particular combination of features in a clause, aspects of that dependent clause are not limited to the specific combination or combinations. It is to be understood that other example clauses can include combinations of aspects from a dependent clause and any other dependent clause or independent clause. The various aspects disclosed herein expressly include these combinations unless it is explicitly expressed or can be readily inferred that a particular combination is not intended (e.g., contradictory aspects such as defining an element as both an electrical insulator and an electrical conductor). Further, it is contemplated that aspects of a clause can be included in any other independent clause even if the clause does not directly depend on the independent clause.

[0186] Various implementation examples are described in the following numbered clauses:

[0187] Clause 1. A method of operating a device, the method comprising: receiving a hypothesis associated with a vehicle feature, the hypothesis defining (i) at least one response of an attentive driver to at least one in-vehicle human-machine communication interface stimulus, (ii) timing information associated with at least one in-vehicle driver action, or (iii) a combination thereof; monitoring behavior of one or more attentive drivers; computing, based on the monitoring, a confidence level validly associated with the hypothesis; and performing one or more actions based on the confidence level.

[0188] Clause 2. The method of clause 1, wherein the confidence level is greater than 0% and less than 100%.

[0189] Clause 3. The method of any one of clauses 1-2, wherein the confidence level comprises a Bayesian confidence level.

[0190] Clause 4. The method of any one of clauses 1-3, wherein the hypothesis defines the at least one response of the attentive driver to the at least one in-vehicle human-machine communication interface stimulus.

[0191] Clause 5. The method of clause 4, wherein the at least one in-vehicle human-machine communication interface stimulus comprises: a status indicator associated with a battery charge state, a fuel level, a vehicle temperature, or any combination thereof, or an alert message, or any combination thereof.

[0192] Clause 6. The method of any one of clauses 4-5, wherein the at least one response includes, within a threshold period of time after the stimulus: a gaze direction of the focused driver, or a hand movement or gesture of the focused driver, or a combination thereof.

[0193] Clause 7. The method of any one of clauses 1-6, wherein the hypothesis defines the timing information associated with at least one in-vehicle driver action, and wherein the timing information includes a timing pattern associated with the focused driver engaging or disengaging the vehicle feature.

[0194] Clause 8. The method of any one of clauses 1-7, wherein the one or more focused drivers include one or more test drivers associated with a fleet of test vehicles in a pre-deployment phase of the vehicle feature, or wherein the one or more focused drivers include one or more consumer drivers in a post-deployment phase of the vehicle feature.

[0195] Clause 9. The method of any one of clauses 1-8, wherein the vehicle feature includes a safety feature or a user experience feature.

[0196] Clause 10. The method of any one of clauses 1-9, wherein the confidence level is below a threshold, and wherein the one or more actions include: sending an indication to a developer of the vehicle feature that the confidence level is below the threshold, or performing one or more mitigation operations associated with the vehicle feature in response to the confidence level being below the threshold, or continuing to track the confidence level to determine whether the confidence level increases above the threshold, or any combination thereof.

[0197] Clause 11. The method of any one of clauses 1-10, wherein the focused driver associated with the hypothesis is associated with a default focused driver profile, or wherein the focused driver associated with the hypothesis is associated with a specific kind or class of driver, or wherein the focused driver associated with the hypothesis is associated with a specific driver.

[0198] Clause 12. The method of any one of clauses 1-11, further comprising: receiving a hypothesis evaluation schedule associated with the vehicle feature, wherein monitoring, computing the execution is performed in accordance with the hypothesis evaluation schedule.

[0199] Clause 13. A method of operating a network component, the method comprising: transmitting a hypothesis associated with a vehicle feature, the hypothesis defining (i) at least one response of an attentive driver to at least one in-vehicle human-machine communication interface stimulus, (ii) timing information associated with at least one in-vehicle driver action, or (iii) a combination thereof; and receiving, in response to the transmitting, a confidence level associated with the hypothesis being valid, the confidence level being based on monitoring of behavior of one or more attentive drivers.

[0200] Clause 14. The method of any one of clauses 12-13, the method further comprising: determining that the confidence level is below a threshold value; and updating the hypothesis associated with the vehicle feature based on the confidence level.

[0201] Clause 15. The method of any one of clauses 13-14, the method further comprising: modifying the vehicle feature based on the updated hypothesis associated with the vehicle feature.

[0202] Clause 16. The method of any one of clauses 13-15, the method further comprising: transmitting the updated hypothesis associated with the vehicle feature; and receiving, in response to the transmitting of the updated hypothesis, an updated confidence level associated with the updated hypothesis being valid.

[0203] Clause 17. The method of any one of clauses 13-16, wherein the confidence level is greater than 0% and less than 100%.

[0204] Clause 18. The method of any one of clauses 13-17, wherein the confidence level comprises a Bayesian confidence level.

[0205] Clause 19. The method of any one of clauses 13-18, wherein the hypothesis defines the at least one response of the attentive driver to the at least one in-vehicle human-machine communication interface stimulus.

[0206] Clause 20. The method of clause 19, wherein the at least one in-vehicle human- machine communication interface stimulus comprises: a status indicator associated with a battery charge state, a fuel level, a vehicle temperature, or any combination thereof, or an alert message, or any combination thereof.

[0207] Clause 21. The method of any one of clauses 19-20, wherein the at least one response comprises, within a threshold period of time after the stimulus: a gaze direction of the attentive driver, or a hand movement or gesture of the attentive driver, or a combination thereof.

[0208] Clause 22. The method of any one of clauses 13-21, wherein the hypothesis defines the timing information associated with at least one in-vehicle driver action, and wherein the timing information comprises a timing pattern associated with the engaged or disengaged of the focused driver with the vehicle feature.

[0209] Clause 23. The method of any one of clauses 13-22, wherein the one or more focused drivers comprise one or more test drivers associated with a fleet of test vehicles in a pre-deployment phase of the vehicle feature, or wherein the one or more focused drivers comprise one or more consumer drivers in a post-deployment phase of the vehicle feature.

[0210] Clause 24. The method of any one of clauses 13-23, wherein the vehicle feature comprises a safety feature or a user experience feature.

[0211] Clause 25. The method of any one of clauses 13-24, wherein the focused driver associated with the hypothesis is associated with a default focused driver profile, or wherein the focused driver associated with the hypothesis is associated with a specific kind or class of driver, or wherein the focused driver associated with the hypothesis is associated with a specific driver.

[0212] Clause 26. The method of any one of clauses 13-25, further comprising: transmitting a hypothesis evaluation schedule associated with the vehicle feature, wherein the confidence level is received in accordance with the hypothesis evaluation schedule.

[0213] Clause 27. An apparatus comprising: one or more memories; and one or more processors communicatively coupled to the one or more memories, the one or more processors, individually or in combination, configured to: receive a hypothesis associated with a vehicle feature, the hypothesis defining (i) at least one response of a focused driver to at least one in-vehicle human-machine communication interface stimulus, (ii) timing information associated with at least one in-vehicle driver action, or (iii) a combination thereof; monitor behavior of one or more focused drivers; compute, based on the monitoring, a confidence level validly associated with the hypothesis; and perform one or more actions based on the confidence level.

[0214] Clause 28. The apparatus of clause 27, wherein the confidence level is greater than 0% and less than 100%.

[0215] Clause 29. The apparatus of any one of clauses 27-28, wherein the confidence level comprises a Bayesian confidence level.

[0216] Clause 30. The device of any one of clauses 27-29, wherein the hypothesis defines the at least one response of the attentive driver to the at least one in-vehicle human-machine communication interface stimulus.

[0217] Clause 31. The device of clause 30, wherein the at least one in-vehicle human- machine communication interface stimulus comprises a status indicator associated with a battery charge state, a fuel level, a vehicle temperature, or any combination thereof, or an alert message, or any combination thereof.

[0218] Clause 32. The device of any one of clauses 30-31, wherein the at least one response comprises, within a threshold time period after the stimulus: a gaze direction of the attentive driver, or a hand movement or gesture of the attentive driver, or a combination thereof.

[0219] Clause 33. The device of any one of clauses 27-32, wherein the hypothesis defines the timing information associated with at least one in-vehicle driver action, and wherein the timing information comprises a timing pattern associated with the attentive driver engaging or disengaging the vehicle feature.

[0220] Clause 34. The device of any one of clauses 27-33, wherein the one or more attentive drivers comprise one or more test drivers associated with a fleet of test vehicles in a pre-deployment phase of the vehicle feature, or wherein the one or more attentive drivers comprise one or more consumer drivers in a post-deployment phase of the vehicle feature.

[0221] Clause 35. The device of any one of clauses 27-34, wherein the vehicle feature comprises a safety feature or a user experience feature.

[0222] Clause 36. The device of any one of clauses 27-35, wherein the confidence level is below a threshold, and wherein the one or more actions comprise: sending an indication to a developer of the vehicle feature that the confidence level is below the threshold, or performing one or more mitigation operations associated with the vehicle feature in response to the confidence level being below the threshold, or continuing to track the confidence level to determine whether the confidence level increases above the threshold, or any combination thereof.

[0223] Clause 37. The device of any one of clauses 27-36, wherein the attentive driver associated with the hypothesis is associated with a default attentive driver profile, or wherein the attentive driver associated with the hypothesis is associated with a particular kind or class of driver, or wherein the attentive driver associated with the hypothesis is associated with a particular driver.

[0224] Clause 38. The device of any one of clauses 27-37, wherein the one or more processors are further configured, individually or in combination, to: receive a hypothesis evaluation schedule associated with the vehicle feature, wherein the monitoring, the calculating the execution is performed in accordance with the hypothesis evaluation schedule.

[0225] Clause 39. The device of any one of clauses 37-38, wherein the one or more processors are further configured, individually or in combination, to: determine that the confidence level is below a threshold; and update the hypothesis associated with the vehicle feature based on the confidence level.

[0226] Clause 40. A network component comprising: one or more memories; and one or more processors communicatively coupled to the one or more memories, the one or more processors configured, individually or in combination, to: transmit a hypothesis associated with a vehicle feature, the hypothesis defining (i) at least one response of an attentive driver to at least one in-vehicle human-machine communication interface stimulus, (ii) timing information associated with at least one in-vehicle driver action, or (iii) a combination thereof; and receive, in response to the transmitting, a confidence level associated with the hypothesis being valid, the confidence level based on monitoring of behavior of one or more attentive drivers.

[0227] Clause 41. The network component of any one of clauses 39-40, wherein the hypothesis defines the at least one response of the attentive driver to the at least one in-vehicle human-machine communication interface stimulus.

[0228] Clause 42. The network component of any one of clauses 45-41, wherein the at least one in-vehicle human-machine communication interface stimulus comprises: a status indicator associated with a battery charge state, a fuel level, a vehicle temperature, or any combination thereof, or an alert message, or any combination thereof.

[0229] Clause 43. The network component of any one of clauses 45-42, wherein the at least one response comprises, within a threshold period of time after the stimulus: a gaze direction of the attentive driver, or a hand movement or gesture of the attentive driver, or a combination thereof.

[0230] Clause 44. The network component of any one of Clauses 39-43, wherein the hypothesis defines timing information associated with at least one on-board driver action, and wherein the timing information comprises a timing pattern associated with the engaged or disengaged of the focused driver with the vehicle feature.

[0231] Clause 45. The network component of any one of Clauses 39-44, wherein the one or more focused drivers comprise one or more test drivers associated with a fleet of test vehicles in a pre-deployment phase of the vehicle feature, or wherein the one or more focused drivers comprise one or more consumer drivers in a post-deployment phase of the vehicle feature.

[0232] Clause 46. The network component of any one of Clauses 39-45, wherein the vehicle feature comprises a safety feature or a user experience feature.

[0233] Clause 47. The network component of any one of Clauses 39-46, wherein the focused driver associated with the hypothesis is associated with a default focused driver profile, or wherein the focused driver associated with the hypothesis is associated with a specific kind or class of driver, or wherein the focused driver associated with the hypothesis is associated with a specific driver.

[0234] Clause 48. The network component of any one of Clauses 39-47, wherein the one or more processors are further configured, individually or in combination, to: transmit a hypothesis evaluation schedule associated with the vehicle feature, wherein the confidence level is received in accordance with the hypothesis evaluation schedule.

[0235] Clause 49. A device comprising: means for receiving a hypothesis associated with a vehicle feature, the hypothesis defining (i) at least one response of a focused driver to at least one on-board human-machine communication interface stimulus, (ii) timing information associated with at least one on-board driver action, or (iii) a combination thereof; monitoring behavior of one or more focused drivers; means for calculating a confidence level associated with the validity of the hypothesis based on the monitoring; and means for performing one or more actions based on the confidence level.

[0236] Clause 50. The device of any one of Clauses 53-49, wherein the confidence level is greater than 0% and less than 100%.

[0237] Clause 51. The device of any one of Clauses 53-50, wherein the confidence level comprises a Bayesian confidence level.

[0238] Clause 52. The device of any one of clauses 53-51, wherein the hypothesis defines the at least one response of the attentive driver to the at least one in-vehicle human-machine communication interface stimulus.

[0239] Clause 53. The device of any one of clauses 56-52, wherein the at least one in- vehicle human-machine communication interface stimulus comprises a status indicator associated with a battery charge state, a fuel level, a vehicle temperature, or any combination thereof, or an alert message, or any combination thereof.

[0240] Clause 54. The device of any one of clauses 56-53, wherein the at least one response comprises, within a threshold time period after the stimulus: a gaze direction of the attentive driver, or a hand movement or gesture of the attentive driver, or a combination thereof.

[0241] Clause 55. The device of any one of clauses 53-54, wherein the hypothesis defines the timing information associated with at least one in-vehicle driver action, and wherein the timing information comprises a timing pattern associated with the attentive driver engaging or disengaging the vehicle feature.

[0242] Clause 56. The device of any one of clauses 53-55, wherein the one or more attentive drivers comprise one or more test drivers associated with a fleet of test vehicles in a pre-deployment phase of the vehicle feature, or wherein the one or more attentive drivers comprise one or more consumer drivers in a post-deployment phase of the vehicle feature.

[0243] Clause 57. The device of any one of clauses 53-56, wherein the vehicle feature comprises a safety feature or a user experience feature.

[0244] Clause 58. The device of any one of clauses 53-57, wherein the confidence level is below a threshold, and wherein the one or more actions comprise: means for sending an indication to a developer of the vehicle feature that the confidence level is below the threshold, or means for performing one or more mitigation operations associated with the vehicle feature in response to the confidence level being below the threshold, or continuing to track the confidence level to determine whether the confidence level increases above the threshold, or any combination thereof.

[0245] Clause 59. The device of any one of clauses 53-58, wherein the attentive driver associated with the hypothesis is associated with a default attentive driver profile, or wherein the attentive driver associated with the hypothesis is associated with a particular kind or class of driver, or wherein the attentive driver associated with the hypothesis is associated with a particular driver.

[0246] Clause 60. The device of any one of clauses 53-59, further comprising means for receiving a hypothesis evaluation schedule associated with the vehicle feature, wherein monitoring, computing the execution is performed in accordance with the hypothesis evaluation schedule.

[0247] Clause 61. The device of any one of clauses 63-60, further comprising means for determining that the confidence level is below a threshold; and means for updating the hypothesis associated with the vehicle feature based on the confidence level.

[0248] Clause 62. A network component comprising: means for sending a hypothesis associated with a vehicle feature, the hypothesis defining (i) at least one response of an attentive driver to at least one in-vehicle human-machine communication interface stimulus, (ii) timing information associated with at least one in-vehicle driver action, or (iii) a combination thereof; and means for receiving, in response to the sending, a confidence level associated with the hypothesis being valid, the confidence level being based on monitoring of behavior of one or more attentive drivers.

[0249] Clause 63. The network component of any one of clauses 65-62, further comprising means for modifying the vehicle feature based on an updated hypothesis associated with the vehicle feature.

[0250] Clause 64. The network component of any one of clauses 65-63, further comprising means for sending the updated hypothesis associated with the vehicle feature; and means for receiving, in response to the sending of the updated hypothesis, an updated confidence level associated with the updated hypothesis being valid.

[0251] Clause 65. The network component of any one of clauses 65-64, wherein the confidence level is greater than 0% and less than 100%.

[0252] Clause 66. The network component of clause 65, wherein the confidence level comprises a Bayesian confidence level.

[0253] Clause 67. The network component of any one of Clauses 65-66, wherein the hypothesis defines the at least one response of the focused driver to the at least one in-vehicle human-machine communication interface stimulus.

[0254] Clause 68. The network component of any one of Clauses 71-67, wherein the at least one in-vehicle human-machine communication interface stimulus comprises a status indicator associated with a battery charge state, a fuel level, a vehicle temperature, or any combination thereof, or an alert message, or any combination thereof.

[0255] Clause 69. The network component of any one of Clauses 71-68, wherein the at least one response comprises, within a threshold time period after the stimulus: a gaze direction of the focused driver, or a hand movement or gesture of the focused driver, or a combination thereof.

[0256] Clause 70. The network component of any one of Clauses 65-69, wherein the hypothesis defines the timing information associated with at least one in-vehicle driver action, and wherein the timing information comprises a timing pattern associated with the focused driver engaging or disengaging the vehicle feature.

[0257] Clause 71. The network component of any one of Clauses 65-70, wherein the one or more focused drivers comprise one or more test drivers associated with a fleet of test vehicles in a pre-deployment phase of the vehicle feature, or wherein the one or more focused drivers comprise one or more consumer drivers in a post-deployment phase of the vehicle feature.

[0258] Clause 72. The network component of any one of Clauses 65-71, wherein the vehicle feature comprises a safety feature or a user experience feature.

[0259] Clause 73. The network component of any one of Clauses 65-72, wherein the focused driver associated with the hypothesis is associated with a default focused driver profile, or wherein the focused driver associated with the hypothesis is associated with a specific kind or class of driver, or wherein the focused driver associated with the hypothesis is associated with a specific driver.

[0260] Clause 74. The network component of any one of Clauses 65-73, further comprising: means for transmitting a hypothesis evaluation schedule associated with the vehicle feature, wherein the confidence level is received in accordance with the hypothesis evaluation schedule.

[0261] Clause 75. A non-transitory computer-readable medium storing computer-executable instructions that, when executed by a device, cause the device to: receive a hypothesis associated with a vehicle feature, the hypothesis defining (i) at least one response of an attentive driver to at least one in-vehicle human-machine communication interface stimulus, (ii) timing information associated with at least one in-vehicle driver action, or (iii) a combination thereof; monitor behavior of one or more attentive drivers; compute, based on the monitoring, a confidence level validly associated with the hypothesis; and perform one or more actions based on the confidence level.

[0262] Clause 76. The non-transitory computer-readable medium of any one of Clauses 79-75, wherein the confidence level is greater than 0% and less than 100%.

[0263] Clause 77. The non-transitory computer-readable medium of any one of Clauses 79-76, wherein the confidence level comprises a Bayesian confidence level.

[0264] Clause 78. The non-transitory computer-readable medium of any one of Clauses 79-77, wherein the hypothesis defines the at least one response of the attentive driver to the at least one in-vehicle human-machine communication interface stimulus.

[0265] Clause 79. The non-transitory computer-readable medium of any one of Clauses 82-78, wherein the at least one in-vehicle human-machine communication interface stimulus comprises: a status indicator associated with a battery charge state, a fuel level, a vehicle temperature, or any combination thereof, or an alert message, or any combination thereof.

[0266] Clause 80. The non-transitory computer-readable medium of any one of Clauses 82-79, wherein the at least one response comprises, within a threshold period of time after the stimulus: a gaze direction of the attentive driver, or a hand movement or gesture of the attentive driver, or a combination thereof.

[0267] Clause 81. The non-transitory computer-readable medium of any one of Clauses 79-80, wherein the hypothesis defines the timing information associated with at least one in-vehicle driver action, and wherein the timing information comprises a timing pattern associated with the attentive driver engaging or disengaging the vehicle feature.

[0268] Clause 82. The non-transitory computer-readable medium of any one of clauses 79-81, wherein the one or more focused drivers comprise one or more test drivers associated with a fleet of test vehicles in a pre-deployment phase of the vehicle feature, or wherein the one or more focused drivers comprise one or more consumer drivers in a post-deployment phase of the vehicle feature.

[0269] Clause 83. The non-transitory computer-readable medium of any one of clauses 79-82, wherein the vehicle feature comprises a safety feature or a user experience feature.

[0270] Clause 84. The non-transitory computer-readable medium of any one of clauses 79-83, wherein the confidence level is below a threshold, and wherein the one or more actions comprise sending an indication to a developer of the vehicle feature that the confidence level is below the threshold, or performing one or more mitigation operations associated with the vehicle feature in response to the confidence level being below the threshold, or continuing to track the confidence level to determine whether the confidence level increases above the threshold, or any combination thereof.

[0271] Clause 85. The non-transitory computer-readable medium of any one of clauses 79-84, wherein the focused driver associated with the hypothesis is associated with a default focused driver profile, or wherein the focused driver associated with the hypothesis is associated with a particular kind or class of driver, or wherein the focused driver associated with the hypothesis is associated with a particular driver.

[0272] Clause 86. The non-transitory computer-readable medium of any one of clauses 79-85, further comprising computer-executable instructions that, when executed by the device, cause the device to: receive a hypothesis evaluation schedule associated with the vehicle feature, wherein monitoring, computing the execution is performed in accordance with the hypothesis evaluation schedule.

[0273] Clause 87. The non-transitory computer-readable medium of any one of clauses 89-86, further comprising computer-executable instructions that, when executed by the device, cause the device to: determine that the confidence level is below a threshold; and update the hypothesis associated with the vehicle feature based on the confidence level.

[0274] Clause 88. A non-transitory computer-readable medium storing computer-executable instructions that, when executed by a network component, cause the network component to: transmit a hypothesis associated with a vehicle feature, the hypothesis defining (i) at least one response of an attentive driver to at least one in-vehicle human-machine communication interface stimulus, (ii) timing information associated with at least one in-vehicle driver action, or (iii) a combination thereof; and receive, in response to the transmitting, a confidence level associated with the hypothesis being valid, the confidence level being based on monitoring of behavior of one or more attentive drivers.

[0275] Clause 89. The non-transitory computer-readable medium of any one of Clauses 91-88, further comprising computer-executable instructions that, when executed by the network component, cause the network component to: modify the vehicle feature based on an updated hypothesis associated with the vehicle feature.

[0276] Clause 90. The non-transitory computer-readable medium of any one of Clauses 91-89, further comprising computer-executable instructions that, when executed by the network component, cause the network component to: transmit the updated hypothesis associated with the vehicle feature; and receive, in response to the transmitting of the updated hypothesis, an updated confidence level associated with the updated hypothesis being valid.

[0277] Clause 91. The non-transitory computer-readable medium of any one of Clauses 91-90, wherein the confidence level is greater than 0% and less than 100%.

[0278] Clause 92. The non-transitory computer-readable medium of Clause 91, wherein the confidence level comprises a Bayesian confidence level.

[0279] Clause 93. The non-transitory computer-readable medium of any one of Clauses 91-92, wherein the hypothesis defines the at least one response of the attentive driver to the at least one in-vehicle human-machine communication interface stimulus.

[0280] Clause 94. The non-transitory computer-readable medium of any one of Clauses 97-93, wherein the at least one in-vehicle human-machine communication interface stimulus comprises: a status indicator associated with a battery charge state, a fuel level, a vehicle temperature, or any combination thereof, or an alert message, or any combination thereof.

[0281] Clause 95. The non-transitory computer-readable medium of any one of clauses 97 to 94, wherein the at least one response includes, within a threshold period of time after the stimulus: a gaze direction of the focused driver, or a hand movement or gesture of the focused driver, or a combination thereof.

[0282] Clause 96. The non-transitory computer-readable medium of any one of clauses 91 to 95, wherein the hypothesis defines the timing information associated with at least one in-vehicle driver action, and wherein the timing information includes a timing pattern associated with the focused driver engaging or disengaging the vehicle feature.

[0283] Clause 97. The non-transitory computer-readable medium of any one of clauses 91 to 96, wherein the one or more focused drivers include one or more test drivers associated with a fleet of test vehicles in a pre-deployment phase of the vehicle feature, or wherein the one or more focused drivers include one or more consumer drivers in a post-deployment phase of the vehicle feature.

[0284] Clause 98. The non-transitory computer-readable medium of any one of clauses 91 to 97, wherein the vehicle feature includes a safety feature or a user experience feature.

[0285] Clause 99. The non-transitory computer-readable medium of any one of clauses 91 to 98, wherein the focused driver associated with the hypothesis is associated with a default focused driver profile, or wherein the focused driver associated with the hypothesis is associated with a specific kind or class of driver, or wherein the focused driver associated with the hypothesis is associated with a specific driver.

[0286] Clause 100. The non-transitory computer-readable medium of any one of clauses 91 to 99, further comprising computer-executable instructions that, when executed by the network component, cause the network component to: transmit a hypothesis evaluation schedule associated with the vehicle feature, wherein the confidence level is received in accordance with the hypothesis evaluation schedule.

[0287] Those skilled in the art will understand that information and signals can be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that can be referenced throughout the above description can be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[0288] Moreover, those skilled in the art will appreciate that the functions of the various example logical blocks, modules, circuits, and algorithm steps described in connection with the aspects disclosed herein can be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various example components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans can implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

[0289] The various illustrative logical blocks, modules, and circuits described in connection with the aspects disclosed herein can be implemented or performed 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 can be a microprocessor, but in the alternative, the processor can be any conventional processor, controller, microcontroller, or state machine. A processor can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

[0290] The methods, sequences, and / or algorithms described in connection with the aspects disclosed herein can be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module can reside in Random-Access Memory (RAM), flash memory, Read-Only Memory (ROM), Erasable Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium can be integral to the processor. The processor and the storage medium can reside in an ASIC. The ASIC can reside in a user terminal (e.g., an UE). In the alternative, the processor and the storage medium can reside as discrete components in a user terminal.

[0291] In one or more example aspects, the functions described can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions can be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media can be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted 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 microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0292] While the foregoing disclosure shows illustrative aspects of the disclosure, it should be noted that various changes and modifications could be made therein without departing from the scope of the disclosure as defined by the appended claims. For example, the functions, steps and / or actions of the methods described herein need not be performed in any particular order. Furthermore, although elements of certain features can be described or claimed in particular combinations, each combination should be considered as having been separately described or claimed. Additionally, some elements of the disclosure can be described or claimed in alternative language, and the language used herein has not been intended to limit the scope of the disclosure but only to describe elements in the particular forms in which they are described. Furthermore, the terms “comprises,” “comprising,” “includes,” “including,” and the like, when used in the present disclosure have not been intended to exclude the presence of one or more additional elements unless specifically recited in the claims. Also, the terms “first,” “second,” and the like, merely mean “one,” “two,” and the like, unless otherwise explicitly recited in the claims. Moreover, the terms “front,” “back,” “forward,” “rearward,” and the like, merely relate to the orientation of the components as shown in the drawings and unless otherwise specifically recited in the claims. The terms “plurality” and “a plurality” contain the meaning of “multiple” or “two or more” unless otherwise explicitly indicated in the claims. Furthermore, the term “exemplary” is not used in the following claims to denote that a particular aspect is preferred or desirable, but rather merely to state that the particular aspect is an example. Moreover, the terms “include,” “have,” “with,” “contain,” “encompass,” “comprise,” “comprising,” “including,” “comprise,” “comprising,” “including” and the like, as used herein, are specifically intended not to be limiting. Rather, they are specifically intended to encompass the stated elements or steps, and also any additional elements or steps.

Claims

1. A method of operating a device, the method comprising: receiving a hypothesis associated with a vehicle feature, the hypothesis defining (i) at least one response of an attentive driver to at least one in-vehicle human-machine communication interface stimulus, (ii) timing information associated with at least one in-vehicle driver action, or (iii) a combination thereof; monitoring behavior of one or more attentive drivers; computing, based on the monitoring, a confidence level validly associated with the hypothesis; and performing one or more actions based on the confidence level.

2. The method of claim 1, wherein the confidence level is greater than 0% and less than 100%.

3. The method of claim 1, wherein the confidence level comprises a Bayesian confidence level.

4. The method of claim 1, wherein the hypothesis defines the at least one response of the attentive driver to the at least one in-vehicle human-machine communication interface stimulus.

5. The method of claim 4, wherein the at least one in-vehicle human-machine communication interface stimulus comprises: a status indicator associated with a battery charge state, a fuel level, a vehicle temperature, or any combination thereof, or an alert message, or any combination thereof.

6. The method of claim 4, wherein the at least one response comprises, within a threshold period of time after the stimulus: a gaze direction of the attentive driver, or a hand movement or gesture of the attentive driver, or a combination thereof.

7. The method of claim 1, wherein the hypothesis defines the timing information associated with at least one in-vehicle driver action, and wherein the timing information comprises a timing pattern associated with the attentive driver engaging or disengaging the vehicle feature.

8. The method of claim 1, wherein the one or more attentive drivers comprise one or more test drivers associated with a fleet of test vehicles in a pre-deployment phase of the vehicle feature, or wherein the one or more attentive drivers comprise one or more consumer drivers in a post-deployment phase of the vehicle feature.

9. The method of claim 1, wherein the vehicle feature comprises a safety feature or a user experience feature.

10. The method of claim 1, wherein the confidence level is below a threshold, and wherein the one or more actions comprise: sending an indication to a developer of the vehicle feature that the confidence level is below the threshold, or performing one or more mitigation operations associated with the vehicle feature in response to the confidence level being below the threshold, or continuing to track the confidence level to determine whether the confidence level increases above the threshold, or any combination thereof.

11. The method of claim 1, wherein the attentive driver associated with the hypothesis is associated with a default attentive driver profile, or wherein the attentive driver associated with the hypothesis is associated with a specific kind or class of driver, or wherein the attentive driver associated with the hypothesis is associated with a specific driver.

12. The method of claim 1, further comprising: receiving a hypothesis evaluation schedule associated with the vehicle feature, wherein monitoring, computing the execution is performed in accordance with the hypothesis evaluation schedule.

13. A method of operating a network component, the method comprising: sending a hypothesis associated with a vehicle feature, the hypothesis defining (i) at least one response of an attentive driver to at least one in-vehicle human-machine interface stimulus, (ii) timing information associated with at least one in-vehicle driver action, or (iii) a combination thereof; and receiving, in response to the sending, a confidence level associated with the hypothesis being valid, the confidence level being based on monitoring behavior of one or more attentive drivers.

14. The method of claim 12, further comprising: determining that the confidence level is below a threshold value; and updating the hypothesis associated with the vehicle feature based on the confidence level.

15. The method of claim 14, further comprising: modifying the vehicle feature based on the updated hypothesis associated with the vehicle feature.

16. The method of claim 13, further comprising: sending an updated hypothesis associated with the vehicle feature; and receiving, in response to the sending of the updated hypothesis, an updated confidence level associated with the updated hypothesis being valid.

17. The method of claim 13, wherein the confidence level is greater than 0% and less than 100%.

18. The method of claim 13, wherein the confidence level comprises a Bayesian confidence level.

19. The method of claim 13, wherein the hypothesis defines the at least one response of the attentive driver to the at least one in-vehicle human-machine interface stimulus.

20. The method of claim 19, wherein the at least one in-vehicle human-machine interface stimulus comprises: a status indicator associated with a battery state of charge, a fuel level, a vehicle temperature, or any combination thereof, or an alert message, or any combination thereof.

21. The method of claim 19, wherein the at least one response comprises, within a threshold period of time after the stimulus: a gaze direction of the attentive driver, or a hand movement or gesture of the attentive driver, or a combination thereof.

22. The method of claim 13, wherein the hypothesis defines the timing information associated with at least one in-vehicle driver action, and wherein the timing information comprises a timing pattern associated with the attentive driver engaging or disengaging the vehicle feature.

23. The method of claim 13, wherein the one or more attentive drivers comprise one or more test drivers associated with a fleet of test vehicles in a pre-deployment phase of the vehicle feature, or wherein the one or more attentive drivers comprise one or more consumer drivers in a post-deployment phase of the vehicle feature.

24. The method of claim 13, wherein the vehicle feature comprises a safety feature or a user experience feature.

25. The method of claim 13, wherein the attentive driver associated with the hypothesis is associated with a default attentive driver profile, or wherein the attentive driver associated with the hypothesis is associated with a particular kind or class of driver, or wherein the attentive driver associated with the hypothesis is associated with a particular driver.

26. The method of claim 13, further comprising: sending a hypothesis evaluation schedule associated with the vehicle feature, wherein the confidence level is received in accordance with the hypothesis evaluation schedule.

27. An apparatus, comprising: one or more memories; and one or more processors communicatively coupled to the one or more memories, the one or more processors individually or in combination configured to: receive a hypothesis associated with a vehicle feature, the hypothesis defining (i) at least one response of an attentive driver to at least one in-vehicle human-machine communication interface stimulus, (ii) timing information associated with at least one in-vehicle driver action, or (iii) a combination thereof; monitor behavior of one or more attentive drivers; compute, based on the monitoring, a confidence level validly associated with the hypothesis; and perform one or more actions based on the confidence level.

28. The apparatus of claim 27, wherein the hypothesis defines the at least one response of the attentive driver to the at least one in-vehicle human-machine communication interface stimulus.

29. A network component, comprising: one or more memories; and one or more processors communicatively coupled to the one or more memories, the one or more processors individually or in combination configured to: send a hypothesis associated with a vehicle feature, the hypothesis defining (i) at least one response of an attentive driver to at least one in-vehicle human-machine communication interface stimulus, (ii) timing information associated with at least one in-vehicle driver action, or (iii) a combination thereof; and receive, in response to the sending, a confidence level validly associated with the hypothesis, the confidence level based on monitoring of behavior of one or more attentive drivers.

30. The network component of claim 29, wherein the hypothesis defines the at least one response of the attentive driver to the at least one in-vehicle human-machine communication interface stimulus.

Images