Mobile device for communicating and ranging with access control system for automatic functionality

Abstract

To provide further improved accuracy for a distance (ranging) between a mobile device and an access control system (e.g., vehicle).SOLUTION: A method for ranging between a mobile device and an access control system (e.g., a vehicle) using two different wireless protocols includes using a first wireless protocol (e.g., Bluetooth (R)) to perform authentication of the vehicle and exchanging ranging capabilities between a mobile device (e.g., a phone or watch) and the vehicle. A second wireless protocol (e.g., ultra-wideband, UWB) can use a pulse width that is less than a pulse width used by the first wireless protocol (e.g., 1 ns vs. 1 MS). The narrower pulse width can provide greater accuracy for distance (ranging) measurements.SELECTED DRAWING: Figure 9

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application is a PCT application of U.S. Provisional Patent Application No. 15 / 983,388, entitled "Mobile Device For Communicating And Ranging With Access Control System For Automatic Functionality," filed May 18, 2018, which claims the benefit of U.S. Provisional Patent Application No. 62 / 565,637, entitled "Mobile Device For Communicating And Ranging With Access Control System For Automatic Functionality," filed September 29, 2017, the disclosure of which is incorporated herein by reference in its entirety. [Background technology]

[0002] Automobiles often come with proximity key fobs that can automatically unlock the vehicle doors when the person carrying the fob approaches. People often carry their phone or smartwatch along with the key fob. Carrying both items can be inconvenient. However, using standard communication protocols typically used between phones and cars (e.g., Bluetooth), it can be difficult to obtain accurate distance measurements between the phone and the car, thereby making proper control of door unlocking difficult. Summary of the Invention

[0003] To provide accurate distance measurements, embodiments may use two different wireless protocols. A first wireless protocol (e.g., Bluetooth) may be used to perform vehicle authentication and exchange ranging capabilities between a mobile device (e.g., a phone or watch) and the vehicle. A second wireless protocol (e.g., ultra-wideband, UWB) may use a smaller pulse width than that used by the first wireless protocol (e.g., 1 ns vs. 1 μs). Narrower pulse widths may provide improved accuracy for distance (ranging) measurements.

[0004] Exemplary ranging capabilities may include specifying a format for ranging messages between the mobile device and the vehicle, a frequency range to use, a number of antenna units on the vehicle, and an encryption protocol for ranging messages using the second wireless protocol. Using the first wireless protocol to specify such ranging capabilities enables the mobile device to connect to and use a variety of vehicles, each with different configurations and capabilities.

[0005] The mobile device can transmit a ranging request message including a first set of pulses to one or more antenna units of the vehicle and receive one or more ranging response messages including a second set of pulses. In various embodiments, the times of transmission and reception of such pulses can be determined and transmitted to the vehicle to enable the vehicle to determine the distance between the mobile device and the vehicle, or to enable the mobile device to determine a distance for transmission to the vehicle. Various functions (e.g., set by a user) can be automatically performed based on the distance crossing a threshold or the rate of change of the distance above a threshold.

[0006] Other embodiments are directed to systems, portable consumer devices, and computer-readable media associated with the methods described herein.

[0007] A better understanding of the nature and advantages of the embodiments of the present disclosure can be obtained by reference to the following detailed description and accompanying drawings. [Brief explanation of the drawings]

[0008] [Figure 1] 1 is a flowchart illustrating a method for automated distance-based access control for vehicles, according to an embodiment of the present invention.

[0009] [Figure 2] 1 illustrates exaggerated movements of a mobile device communicating with a vehicle using a first wireless protocol and authenticating and preparing to participate in ranging and ranging using a second wireless protocol, according to an embodiment of the present invention.

[0010] [Figure 3] 2 shows a sequence diagram of communication between a mobile device and a vehicle involving BT and UWB protocols according to an embodiment of the present invention;

[0011] [Figure 4] 1 illustrates a sequence diagram of a ranging operation involving a mobile device and three antennas on a vehicle according to an embodiment of the present invention.

[0012] [Figure 5] 1 shows a sequence diagram of a pairing process according to an embodiment of the present invention.

[0013] [Figure 6] 1 illustrates ranging interval negotiation according to an embodiment of the present invention.

[0014] [Figure 7] 1 illustrates a key refresh negotiation according to an embodiment of the present invention.

[0015] [Figure 8] 1 illustrates one-to-many ranging according to an embodiment of the present invention.

[0016] [Figure 9] 4 is a flowchart of a method for performing communication between a mobile device and an access control system according to an embodiment of the present invention.

[0017] [Figure 10] FIG. 1 is a block diagram of an exemplary mobile device. DETAILED DESCRIPTION OF THE INVENTION

[0018] In embodiments, a mobile device (e.g., a phone or watch or other accessory) may be provided that securely communicates with a vehicle for authentication and ranging, unlocking the doors in a timely manner when the user approaches the vehicle. It may also provide other actions besides unlocking, such as turning on the lights, engine, heater, air conditioning, or providing information from the vehicle to the mobile device. The secure communication may involve not only the key exchange typically associated with a first wireless protocol, but also key negotiation that occurs in the first wireless protocol, but the key is subsequently used with a second wireless protocol, for example, used in ultra-wideband (UWB) ranging. The cryptographic key may also be used as part of a challenge-response message to mutually authenticate the mobile device and the vehicle.

[0019] As part of the authentication, different access privileges can be provided. For example, if the owner's child has the phone, the phone's access privileges can be limited to only unlocking the back seat and not starting the engine. In various embodiments, such access privileges can be programmed into the phone (e.g., if commands are provided to the car from the phone for specific functions) or can be programmed into the car for a particular phone, and a device identifier can be used to determine when a particular phone is communicating with the vehicle. Some embodiments can be extended to multiple people approaching the vehicle, each with a separate mobile device that can perform ranging independently.

[0020] In some embodiments, Bluetooth® (e.g., Classic, High Speed, or Low Energy (BTLE), collectively referred to as BT) can be used to authenticate a mobile device with a vehicle. However, BT pulses are wide (e.g., 1 microsecond) and do not allow for accurate distance measurements. Instead, UWB can be used for distance measurements when the pulses are narrower (e.g., ∼1 nanosecond), thereby allowing for better time-of-flight calculations. UWB may not be suitable for authentication and other data communications where guaranteed data transfer delays are desired.

[0021] Thus, a mobile device can use a first wireless protocol (e.g., BT) to exchange authentication and ranging capabilities (e.g., ranging message format, number of antenna units, encryption protocol, etc.) with an access control system, such as a vehicle or building (e.g., as part of a home lock). Examples of vehicles include cars, trucks, boats, and trains. Additionally, a first wireless message can initiate a ranging process, which uses a second wireless protocol (e.g., UWB) with narrower pulses than those used in the first wireless protocol to determine the distance between the two devices. The defined functions can be performed at various distances from the vehicle (or other access control system, such as a building or other structure (e.g., a fence) that includes locks on gates, doors, etc.), e.g., turning on lights at 5 meters away and unlocking the vehicle at 2 meters away. Any of the following discussions regarding vehicles are also applicable to other access control systems. I. Communication and Ranging Using Two Protocols

[0022] A first wireless protocol link between a mobile device (e.g., a phone, tablet, or watch) and a vehicle can be used for authentication, and then a second wireless protocol (e.g., UWB) can be used to initiate and control ranging and exchange of distance information. For example, the first wireless protocol can provide a low-power framework for negotiating security keys, ranging intervals, and initiating ranging via UWB.

[0023] 1 is a flow chart illustrating a method 100 for automated distance-based access control for a vehicle according to an embodiment of the present invention. The method 100 is generally presented to both devices to affect the operation of the vehicle. Those skilled in the art will understand which steps are performed by which devices.

[0024] At block 110, the mobile device and vehicle are paired using a first wireless protocol. As described in more detail below, pairing (e.g., BT pairing) may involve authentication between the mobile device and the vehicle via any one of a variety of techniques. Pairing may result in a shared secret being stored on both devices, which can be used for future authentication (e.g., via challenge-response) and / or encryption of messages between the mobile device and the vehicle. The mobile device may assume a central role during initial setup and pairing.

[0025] The identity addresses (e.g., Media Access Control (MAC) addresses) of the mobile device and vehicle can be exchanged during pairing. For example, a unique 48-bit address can be used for each BT device. The mobile device can use a resolvable private address and periodically rotate the address, changing the random value at timing intervals, for example, which can occur when a BTLE privacy mode is used. In addition, a resolution key (e.g., a BT Identity Resolution Key (IRK)) can be exchanged during pairing, allowing the devices to translate random MAC addresses in advertisement packets into actual MAC addresses for authentication purposes. If the vehicle supports multiple BT controllers, all controllers may use the same identity address and resolution key. Each controller may have a different random resolvable address at any given time.

[0026] In block 120, the vehicle and / or mobile device can be authenticated using the first wireless protocol when the mobile device is present. This authentication may occur immediately after pairing or at some later point. For example, the mobile device can be paired with the vehicle, and then the user can leave the vehicle. The user can then return the next day or at any later time and perform authentication using information obtained during the pairing process. As an example, once paired, the mobile device can always be in advertisement mode and assume a peripheral role in all subsequent connections to the vehicle. The mobile device may send multiple advertisement packets, each with a different payload. The resolvable random address in the payload can be used by the vehicle to identify paired devices, for example, using the IRK. The vehicle can filter advertisement packets based on the payload.

[0027] When a vehicle receives an advertisement packet from a paired mobile device, it can initiate a BT (e.g., BTLE) connection to the mobile device, with the vehicle acting as the central device for this connection. The BT connection can be initiated by the vehicle sending a response message indicating a desire to create a connection and including the vehicle's identifier. A connection interval (e.g., 30 ms) may be required by the mobile device.

[0028] At block 130, the mobile device and the vehicle may exchange ranging capabilities using the first wireless protocol. Exchanging ranging capabilities may ensure that signaling between the mobile device and the vehicle is performed in a consistent manner by both devices. Such an exchange may enable the mobile device to adapt to new vehicles, e.g., vehicles with different numbers and types of antenna units. Exemplary ranging capabilities may include specifying a format for ranging messages between the mobile device and the vehicle, a frequency range to use, the number of antenna units on the vehicle, and an encryption protocol for ranging messages using the second wireless protocol.

[0029] At block 140, ranging can be initiated using a first wireless protocol. In some implementations, initiation can be initiated by a ranging request message sent from a mobile device or vehicle. Responding devices can respond with a start notification event (message). Once the start notification event occurs, ranging can be performed using a second wireless protocol, for example, by turning on the corresponding radio within a specific time of receiving the start message. Further examples and details are provided herein.

[0030] In block 150, ranging can be performed using a second wireless protocol (e.g., UWB). After a start signal using the first wireless protocol, the vehicle can begin scanning for ranging signals at a specific time using one or more vehicle antenna units corresponding to the second wireless protocol. The one or more vehicle antenna units can receive one or more ranging request messages and transmit one or more ranging response messages. A control unit, located in each of the one or more vehicle antenna units or shared among them, can perform various levels of processing of such ranging messages, for example, to determine timestamps. The mobile device can receive the ranging response messages and determine timestamps for the transmission of the one or more ranging request messages and timestamps for the one or more ranging response messages. The mobile device can transmit these timestamps to the vehicle to determine the distance between the mobile device and the vehicle. In other implementations, the mobile device can determine the distance based on the transmission and reception times of the ranging signals. Ranging can continue until a stop ranging request is processed.

[0031] In block 160, the vehicle can perform a predetermined action based on the distance measurement. For example, the vehicle can determine that the mobile device is within a first threshold, thereby performing a first action, such as turning on the vehicle's lights. Further distance measurements can be performed to determine distance over time. When the mobile device is within a closer threshold, a second action can be performed, such as unlocking the doors.

[0032] In some embodiments, the action may depend on the trajectory of the mobile device, for example, which side of the vehicle the mobile device is approaching. For example, if the mobile device is approaching the passenger side, potentially only the passenger door may be unlocked. If the mobile device is approaching the rear of the vehicle, the trunk or hatch may be unlocked.

[0033] FIG. 2 illustrates exaggerated movements of a mobile device 210 communicating with a vehicle 205 using a first wireless protocol to authenticate and prepare for ranging. The mobile device then participates in ranging using a second wireless protocol according to an embodiment of the present invention. Assume that the mobile device 210 and the vehicle 205 are already paired, e.g., a secure channel has already been established between the two devices via a shared secret. The mobile device 210 is shown at three times T1 through T3. The actual movements of the mobile device 210 during these times are typically less than those shown, as distances are exaggerated for ease of illustration. The vehicle 205 includes a Bluetooth antenna and four UWB antennas 1 through 4, although other numbers of UWB antennas are possible.

[0034] At a first instance of T1, the mobile device 210 can authenticate the vehicle using the first wireless protocol, or vice versa. For example, the mobile device 210 can send an unencrypted random number to the vehicle 205. The vehicle 205 can encrypt the random number using a shared secret established during pairing and send the encrypted value in a message to the mobile device 210, which decrypts the message to verify that the same random number was received.

[0035] After authentication, still nominally at T1, the mobile device 210 and the vehicle 205 can exchange information about ranging that will occur at subsequent times (e.g., times T2 and T3). The exchanged information can ensure that both devices perform ranging in the same way and that ranging occurs in a synchronized manner.

[0036] At time T2, mobile device 210 or vehicle 205 can transmit an initial ranging message, which can include a series of pulses. These pulses are narrower than the pulses used in the first wireless protocol at time T1. Mobile device 210 can broadcast the initial ranging message so that each of the vehicle's four UWB antennas 1-4 can receive it. Mobile device 210 can track (e.g., to nanosecond accuracy) the exact time the initial ranging message was transmitted. Each of the UWB antennas can transmit a ranging response message, which can include an identifier that identifies which UWB antenna transmitted the particular response message. Mobile device 210 can track the exact time to receive the four UWB ranging response messages.

[0037] In some embodiments, mobile device 210 can transmit tracking times to vehicle 205, and the vehicle can use its own tracking times for receiving the initial ranging message at each of UWB antennas 1-4 and the times for transmitting each of the four ranging response messages to determine the distance between the mobile device and the vehicle. For example, when the clocks of the two devices are synchronized, the difference between the time each message is transmitted and the time it is received can be used to determine the distance. As another example, the time delay between receiving the initial ranging response message and transmitting the ranging response message can be subtracted from the transmit time and receive time at mobile device 210 to obtain the round-trip time. The round-trip time can be converted to distance based on the speed of the electromagnetic signal. The known locations of different UWB antennas in the vehicle can be used to triangulate the position of mobile device 210 relative to vehicle 205.

[0038] In other embodiments, the mobile device 210 can determine the distance from the vehicle 205. For example, if the ranging information exchanged by the vehicles includes the relative positions of the vehicle's UWB antennas and the expected delay between receiving a ranging request message and sending a ranging response message, the mobile device 210 can determine the distance using the tracking times of sending and receiving the ranging message. II. Exemplary Protocols and Signaling

[0039] The two wireless protocols can be BT and UWB, details of each wireless protocol are provided below along with further details regarding the messaging sequence between the mobile device and the vehicle. A. A first wireless protocol (e.g., Bluetooth)

[0040] The mobile device and the vehicle may have multiple antennas for a first wireless protocol (e.g., BT), which can use short-wavelength ultra-high frequency (UHF) radio waves in the ISM band from 2.4 to 2.485 GHz.

[0041] Certain modes of the first wireless protocol can be used over relatively long ranges. For example, a single BT radio can increase its communication range by using lower packet encoding at 125 kbps or 500 kbps and by increasing its maximum transmit power (e.g., to +20 dBm). Such a radio can be used for both advertising and data packets and can provide a range of up to 100 meters, as opposed to lower power modes that can only function up to 20 meters. Thus, if a user is approaching a vehicle while moving at a speed of 1.5 meters per second, a range of 100 meters may still provide sufficient time for authentication, negotiation of ranging parameters, and transmission of a ranging start message. Such additional time to establish communication may be advantageous in cases where interference from other vehicles may be present, which could otherwise delay the initiation of mobile device detection and ranging.

[0042] However, these packets are not suitable for ranging because they can be approximately 2-8 times longer in duration, e.g., up to about 16 ms. A 1 microsecond pulse provides a range of + / - 300 meters. Also, even the normal power mode for BT provides pulses that are not suitable for ranging. B.UWB

[0043] The second wireless protocol has narrower pulses than the first wireless protocol, e.g., narrower full width at half maximum (FWHM). In some implementations, the second wireless protocol (e.g., UWB) can provide distance accuracy of 5 cm or better. In various embodiments, the frequency range can be 3.1 to 10.6 GHz. Multiple channels can be used, e.g., one channel at 6.5 GHz and another at 8 GHz. As such, in some cases, the second wireless protocol does not overlap with the frequency range of the first wireless protocol. Mobile devices and vehicles may have multiple antennas for the second wireless protocol.

[0044] The second wireless protocol can be specified by IEEE 802.15.4, a type of UWB. Historically, UWB was used for high-bandwidth communications but interfered with GPS. Each pulse in a pulse-based UWB system can occupy the entire UWB bandwidth (e.g., 500 MHz), allowing the pulse to be localized in time (i.e., a narrow time width, e.g., 0.5 ns to a few nanoseconds). In terms of distance, the pulse can be less than 60 cm wide for a 500 MHz wide pulse and less than 23 cm wide for a 1.3 GHz wide pulse. With such a wide bandwidth and such a narrow width in real space, very accurate time-of-flight measurements can be obtained. C. Sequence diagram

[0045] 3 shows a sequence diagram of communication between a mobile device 300 and a vehicle 350 involving BT and UWB protocols according to an embodiment of the present invention. It is assumed that the mobile device 300 and the vehicle 350 are already paired, so the vehicle has the mobile device's credentials and the mobile device has the vehicle's credentials. The mobile device 300 may be in a screen-off state or may be actively being used by a user. Steps in the sequence diagram may be optional.

[0046] At 301, the BT antenna of the mobile device 300 transmits an advertising signal, for example, in low energy (LE) mode. The mobile device can broadcast the advertising signal at several duty cycles without the user having to provide any user input. Having the mobile device 300 transmit the advertising signal may be preferable to having the vehicle 350 transmit the advertising signal. If the vehicle were advertising, there could be excessive advertising. For example, if all the cars in a parking lot were advertising (e.g., if there were only three channels available for beacon signal advertising use), the channel could become saturated. Another issue is that if the mobile device is in a pocket, it may go into battery save mode and need to scan at a very low duty cycle, while the vehicle must scan at a high rate, for example, every 20 milliseconds, to establish a connection.

[0047] At 302, the BT antenna of the vehicle 350 scans with a duty cycle. In some embodiments, the vehicle 350 may have more than one BT antenna, any of which may detect an advertising signal from the mobile device 300. Advertising and scanning may be part of a discovery process by which two devices detect each other so that a connection can be created.

[0048] At 303, a BT connection is created between the two devices. For example, the vehicle 350 can respond with a message including the vehicle's 350 credentials (e.g., an identifier), and the mobile device 300 can respond with its credentials. In some implementations, each device can check the network address with addresses stored for previously paired devices to obtain, for example, a cryptographic key, among other information used in the connection.

[0049] At 304, the processors of the two devices are awakened to communicate with their respective BT antenna devices to perform signal processing and provide control signals to the BT antenna devices for transmitting signals. For example, the operating system of the mobile device 300 can access a database (e.g., a table) of paired devices to match stored credentials with credentials obtained from the vehicle 350. Similarly, the engine control unit (ECU) of the vehicle 350 can access a database of paired devices to match stored credentials with credentials obtained from the mobile device 300. Information from each of the device's profiles can be used in later stages of communication.

[0050] In some embodiments, the ECU may be programmed with such functionality. In other embodiments, a software upgrade may be applied to the ECU. Additionally, the ECU may include one or more hardware devices added after manufacture, such one or more hardware devices capable of interfacing with an antenna implementing the first or second wireless protocol. Such antennas may also be added after manufacture, for example, as part of an aftermarket installation.

[0051] At 305, an encryption key is derived by each of the two devices. For example, the corresponding profile that matches the received credentials may contain a shared secret that can be used to derive the encryption key. The derivation may be performed according to a default procedure, for example, based on a counter or a timestamp.

[0052] As part of this stage, a first level challenge-response may be performed as part of the authentication. For example, the mobile device 300 may provide a random number to the vehicle 350, and the vehicle 350 may provide a response using an encryption key. The mobile device 300 may match the response to an expected encryption value that corresponds to the random number.

[0053] At 306, a communication channel is set up. The communication channel may include an intermediate layer between the application layer and a lower layer, such as a Host Controller Interface (HCI). In some embodiments, the intermediate layer may be a Logical Link Control and Adaptation Protocol (L2CAP) layer. This layer may be responsible for protocol multiplexing capabilities, segmentation, and reassembly operations on data exchanged between the host and the protocol stack.

[0054] At 307, a security handshake is performed between the mobile device 300 and the vehicle 350. The security handshake can provide an additional level of protection for unlocking the vehicle above and beyond typical BT authentication. The mobile device 300 and the vehicle 350 can each have a hardware secure element that can store a key. The key in the secure element can be used in a challenge-response for the additional level of authentication. In various embodiments, the key can be a hardware key added by the manufacturer or obtained in a provisioning process. For the provisioning process, each of the devices can communicate with a server (e.g., a website), which can provide the key to be stored in the hardware secure element. The hardware secure element can be a tamper-resistant platform (typically a one-chip secure microcontroller) that can securely host applications and their sensitive and encrypted data (e.g., key management).

[0055] An application on the mobile device 300 communicating with the BT circuitry (e.g., as part of the operating system or an application installed on the operating system) can communicate with the secure element and notify the secure element of the connection to a particular vehicle. The secure element can generate a challenge (e.g., a random number) that is sent to the vehicle 350. Once received, the vehicle 350 can send the challenge to its secure element, which can generate a response. The secure element on the mobile device 300 can verify the response, for example, by knowing the hardware key of the provisioned device. The secure element can store the matching vehicle's credentials in a key that can be retrieved from the provisioning server after the vehicles are paired.

[0056] In other embodiments, the mobile device 300 can track which vehicles it is paired with and determine which vehicle is currently connected. The secure element can generate a challenge based on key provisioning for that vehicle. Through authentication, the vehicle 350 knows which mobile device corresponds to the current link and therefore which key to use to respond to the challenge. The vehicle 350 can obtain the key corresponding to the mobile device during the pairing process. In other embodiments, the challenge can be initiated by the vehicle 350.

[0057] The challenge message may include information indicating that the type of the message is a challenge, and the location of such information in the packet definition of such a message may be added as part of the ranging service via a first wireless protocol defined by the operating system or an installed application.

[0058] In other embodiments, one or more new keys (e.g., shared secrets) for this security handshake can be exchanged after every interaction session, e.g., after the vehicle is unlocked. Then, for the next interaction session (i.e., the next time the user uses the vehicle), one device can send data to the other device as part of a challenge, and the other device can encrypt the data or perform a transformation to obtain a response that is compared to an expected value.

[0059] Any additional data is exchanged at 308. For example, the vehicle may transmit information about the fuel in the tank or other information, such as may be defined by the user. In some embodiments, the information may appear as a notification or pop-up window.

[0060] At 309, a ranging setup handshake is exchanged between the mobile device 300 and the vehicle 350. The ranging setup handshake can include the ranging capabilities of the two devices. Information about the UWB receivers on the vehicle can be provided because different vehicles may have different numbers of UWB receivers, or the vehicle may only want to turn on a few. Coarse ranging may occur first, and finer ranging may occur using the UWB receivers after the mobile device is closer. For example, more receivers may be turned on if the mobile device is estimated to be in the vehicle so that high accuracy can be achieved before the user is allowed to start the vehicle's engine. Which UWB receiver is turned on first may depend on which side of the vehicle the user is approaching. Other settings / parameters may be provided after pairing or during the ranging procedure, for example, as part of dynamic determination or updates of software or physical components.

[0061] Other examples of ranging capabilities include the number of antennas, the locations of those antennas (e.g., the relative distance between antennas and / or between origins within the vehicle such as ECUs), the number of antennas used, encryption protocols, packet formats, operating modes, and supported frequency ranges. Such capabilities may reflect software updates to the vehicle or mobile device, resulting in new or different capabilities.

[0062] The ranging setup handshake may include negotiation of how to perform ranging, such as the frequency of ranging or how to schedule ranging (e.g., if there are multiple vehicles or multiple mobile devices—round robin, one at a time, or other options). For example, there may be multiple devices near a vehicle (e.g., an entire family driving in one car) or multiple vehicles near a mobile device (e.g., three cars in a garage). Because the mobile device may know it is connected to three different vehicles, it may want a lower rate of ranging measurements (e.g., 25 ms) for each vehicle or schedule a specific time / frequency to perform ranging on each vehicle. Similarly, a vehicle may perform such scheduling when multiple devices are nearby. The ranging setup handshake may also depend on whether the vehicles are communicating with each other.

[0063] The ranging setup handshake can specify the time when ranging begins, for example, by coordinating the time when the vehicle should turn on its UWB radio and begin searching for packets. A start message sent via BT can be used, for example, using specific messages detailed below. The duty cycle when the UWB radio is on can be specified, for example, to be 1 KHz or 10 KHz. For example, when a start message is received, the devices can agree to begin ranging 100 ms (or 90 ms for additional margin) from the start message, and further every 1 KHz thereafter.

[0064] The ranging setup handshake can derive a new set of session keys for UWB ranging. The keys can be updated periodically, for example, for each session or every Nth session. In some embodiments, the session keys can be derived from a common shared secret used in the challenge-response to the security handshake, and the derivation uses a default or negotiation procedure. Thus, the ranging setup handshake can serve as a control channel to inform the vehicle and mobile device about what to expect for ranging.

[0065] At 310, ranging is performed, for example, using UWB messages. In some embodiments, ranging can be performed by the mobile transmitting a ranging request message to one or more antennas on the vehicle. The vehicle antennas can respond, and the mobile device can potentially receive the ranging response message at different times. An example of such a system using three antenna nodes is provided in FIG. 4. Other implementations may include more antenna nodes, for example, six to eight. A single node may have one transceiver and potentially two or more antennas.

[0066] FIG. 4 illustrates a sequence diagram of a ranging operation involving a mobile device 400 and three vehicle antennas 452-456, according to an embodiment of the present invention. In this example of FIG. 4, the mobile device 400 broadcasts a single packet that is received by the antennas 452-456 (e.g., each of the different nodes). In another implementation, the mobile device 400 can send a packet to each node and have each node respond with a separate packet. The vehicle can listen to a specific antenna so both devices know which vehicle antenna is involved, or the packet can indicate which antenna the message is for. For example, a first antenna can respond to a received packet and, once a response is received, send another packet to a different antenna. However, this alternative procedure takes more time and power.

[0067] 4 shows ranging request 410 transmitted at T1 and received by antennas 452-456 at times T2, T3, and T4, respectively. Thus, the antennas (e.g., UWB antennas) listen substantially simultaneously and respond independently. Antennas 452-456 provide ranging responses 420, which are transmitted at times T5, T6, and T7, respectively. Mobile device 400 receives the ranging responses at times T8, T9, and T10, respectively. Optional ranging messages 430 can be transmitted (shown at T11), which are received by antennas 452-456 at times T12, T13, and T14, respectively. Distance / time information 440 can be transmitted after the ranging message is set and may only need to be received by one antenna, which can relay the information to the control unit. In the illustrated example, the timestamp tracked by mobile device 400 is transmitted to at least one of antennas 452-456, allowing the vehicle to determine its distance from the vehicle, for example, based on the location of the antenna within the vehicle. In other examples, mobile device 400 can determine the distance and transmit the distance to the vehicle.

[0068] In some embodiments, to determine which ranging response is from which antenna, the vehicle can inform the mobile device of the order in which response messages to send, for example, during the ranging setup handshake. In other embodiments, the ranging response can include an identifier indicating which antenna sent the message. These identifiers can be negotiated during the ranging setup handshake.

[0069] The ranging message 430 can enable improved accuracy. While the antennas can be clocked synchronously with each other, the response times (e.g., the delay between T2 and T5) can vary. For example, T5-T2 can be different from T6-T3. The ranging message 430 can provide resilience to different turnaround times for each of the antenna nodes. Such differences in turnaround times can result in ranging errors of one or two meters. By adding the ranging message 430, embodiments can reduce errors caused by different turnaround times.

[0070] Messages 410-430 can contain very little data in the payload, for example, by including a small number of pulses. Using fewer pulses can be advantageous. The environment of the vehicle and the mobile device (potentially in a pocket) can make measurements difficult. As another example, the vehicle antenna may be pointing in a different direction than the mobile device is approaching. Therefore, while it is desirable to use high and low pulses for each pulse, there are government regulations (as well as battery concerns) regarding how much power can be used within a certain time window (e.g., averaged over 1 millisecond). Packet frames in these messages can be on the order of 150-180 microseconds long. Packet frames in message 440 can be longer, for example, 200 or 250 microseconds long.

[0071] At 311, further ranging measurements can be performed. For example, two or more distances can be determined, which can be used to determine a trajectory. If the trajectory indicates movement toward the vehicle (e.g., smaller distances for a specified number of measurements), the vehicle can infer the user's intent to enter the vehicle. As another example, different actions can be performed at different distance thresholds, such as turning on lights at one distance threshold, unlocking the vehicle at a closer distance threshold, and allowing the engine to turn on (e.g., after the user presses a button) at an even closer distance threshold.

[0072] At 312, the engine control unit of the vehicle 350 can determine what action(s) to perform based on the distance and / or rate of change of distance and trajectory. The particular action(s) can depend on the setting(s) programmed into the mobile device and / or vehicle by the user. Further communication between the mobile device and the vehicle can also be used to determine the action to perform, including communication via Bluetooth, for example, to prompt the user as to whether to turn on the air conditioning or heater.

[0073] D. Pulse Each one of the ranging messages (also called a frame or packet) can include a sequence of pulses that can represent modulated information. Each data symbol within a frame can be a sequence. A packet has a preamble that includes header information, e.g., physical and MAC layer, and can include a destination address. In some embodiments, a packet frame can include a synchronization portion and a start frame delimiter (SFD) that can line up timing.

[0074] The packet can include how security is configured and can include encrypted information, such as an identifier for which antenna is transmitting the packet. The encrypted information can be used for authentication. For ranging operations, the content of the data may not need to be determined. In some embodiments, a timestamp for the pulse of a particular piece of data can be used to track the difference between transmission and reception. Thus, the content can be used to match the pulses. In some implementations, the encrypted information can include an indicator that authenticates the stage to which the message corresponds; for example, ranging request 410 can correspond to stage 1, ranging response 420 can correspond to stage 2, and ranging message 430 can correspond to stage 3.

[0075] E. Distance Judgment Narrow pulses (e.g., ~1 ns wide) can be used to accurately determine distance. High bandwidth (e.g., 500 MHz spectrum) allows for narrow pulses and accurate position determination. Cross-correlation of pulses can provide timing accuracy that is a small fraction of the width of the pulse, providing accuracy within hundreds or tens of picoseconds, for example, providing sub-meter level ranging accuracy. Pulses can represent plus-one and minus-one ranging waveforms in several patterns that are recognized by the receiver.

[0076] Distance measurements can use round-trip time measurements, also called time-of-flight measurements. As mentioned above, the mobile device can transmit a set of timestamps, which can eliminate the need for clock synchronization between the two devices. III. Authentication and Secure Channel Establishment (Pairing)

[0077] As described above, a BT communication channel (or a portion thereof) can be established during a pairing process, for example, when a user acquires a new mobile device and / or a new vehicle. In some implementations, pairing is initiated by the vehicle initiating a BT advertisement. The advertisement payload for initiating pairing can include various data. In other implementations, the mobile device can initiate pairing with the vehicle. Once pairing is complete, the mobile device can set up a channel (e.g., a connection-oriented L2CAP channel). The connection-oriented channel can be used to exchange ranging service messages to exchange capabilities and to exchange security keys to complete the UWB pairing.

[0078] Once the vehicle and iOS device are paired, subsequent BT connections can be initiated by the vehicle. The vehicle can also initiate a standard BT encryption handshake to set up an encrypted link using the link key created during pairing. The mobile device or vehicle can initiate UWB ranging by first initiating a ranging handshake over BT. Further details regarding pairing are provided below.

[0079] Pairing is a method by which two devices (e.g., a phone and a vehicle's control unit) associate with each other and create a connection (e.g., a Bluetooth connection). Once pairing occurs, the two devices can communicate with each other. Pairing is generally initiated manually by a user, for example, by selecting a discovered device on the initiator device's settings page. The initiator device can then send a pairing request to a responder device that is not yet paired. Pairing typically occurs once between two devices. After pairing, the connection between the two devices is automatically authenticated.

[0080] To proceed with pairing, an authentication password or "passkey" may be exchanged between the two devices. The passkey is used to verify that both devices agree to pair with each other. Once two devices are paired, the devices can verify the identity of the other device. To complete the pairing, the two devices generate a shared secret key(s) that will be used for all future communication between the devices.

[0081] For Bluetooth® (BT) Low Energy, the Security Manager Protocol (SMP) performs pairing in three phases. In Phase 1, two devices advertise their input and output capabilities, which are used to determine a preferred method for Phase 2. In Phase 2, the two devices authenticate each other and determine a key generation method for the keys to be used in Phase 3. More specifically, in Phase 2, the two devices use the IO capabilities from the pairing request and pairing response packets in Phase 1 to determine which authentication method to use. Four authentication techniques are typically available: Just Works®, numeric comparison, passkey, and out-of-band (OOB). In Phase 3, each device can distribute one or more keys to the other device for future communication. Exemplary keys include (a) a long-term key (LTK) used to generate a session key for encrypted connections, (b) a connection signature resolution key (CSRK) used to sign data and verify signatures, and (c) an identity resolution key (IRK) used to generate private addresses. Bluetooth® 4.2 devices exchange / generate the LTK using Elliptic Curve Diffie Hellman (ECDH) public key cryptography.

[0082] In Just Works®, devices exchange their public keys. The responder device then generates a nonce (e.g., a random seed value) and uses the nonce and both public keys to generate a confirmation value Cb. The responder device then sends Cb along with the nonce to the initiator device. The initiator device then uses the responder device's nonce (along with both public keys) to generate its own confirmation value Ca, which should match Cb. If the confirmation values ​​match, the connection proceeds. The initiator device can generate its own nonce and send it to the responder device, and can perform its own verification.

[0083] Numeric comparison follows the same procedure as Just Works®, but adds another step at the end. Once the two devices confirm that the verification values ​​match, they independently generate a final six-digit verification value using both nonces. Both devices display these calculated values ​​to the user. The user then manually checks that both values ​​match, confirming the connection. This additional step allows this pairing method to provide protection against man-in-the-middle (MITM) attacks.

[0084] With a passkey, a six-digit number is entered into one or both devices. The two devices authenticate the connection using the password, a previously exchanged public key, and a nonce. This process can be done bit-by-bit for all bits of the passkey. For example, one device calculates a verification value for one bit of the passkey and reveals it to the other device. The other device then calculates its own verification value for the first bit of the passkey and reveals it to the first device. This process continues until all bits of the passkey have been exchanged and are verified to match. This passkey method is resilient to MITM attacks.

[0085] Out-of-band (OOB) uses external communication means such as Near Field Communication (NFC) to exchange some information (e.g., public keys, nonce, and verification values) used in the pairing process. Pairing is completed using the Bluetooth radio but requires information from the OOB mechanism. This only provides the level of MITM protection present within the OOB mechanism.

[0086] 5 shows a sequence diagram of a pairing process 500 according to an embodiment of the present invention. The pairing process involves an initiator device 502 (e.g., a phone) and a responder device 504 (e.g., a vehicle). Each device determines its capabilities for input and output (IO). For each device in the pairing link, the IO capabilities determine their ability to create an encrypted shared secret key. Public key cryptography may be used.

[0087] In step 505, a user activates discovery mode on responder device 504. To be found by other Bluetooth devices, the device should be set to discoverable mode so that an advertisement signal is transmitted. The advertisement signal allows other devices in the vicinity to detect its presence and attempt to establish a connection. For example, a user can activate a button on responder device 504.

[0088] In step 510, the responder device 504 emits an advertising signal in response to user activation. The initiator device 502 can detect the advertising signal. For example, the initiator device 502 can periodically scan for advertising signals. The user can enable the initiator device 502 to perform such scans and set the scan rate, or the scan rate can be set by default. The advertising signal can include identifiers such as the type of device (e.g., phone, headset, etc.), the device name (e.g., assigned by the user or manufacturer), etc.

[0089] In step 515, the user initiates the pairing process by providing user input to a user interface of the responder device 504. For example, the user may navigate to a settings page, determine that the responder device 504 has been detected via an advertising signal, and select an option to pair with the responder device 504.

[0090] In step 520, a pairing request message is sent from the initiator device 502 to the responder device 504. By way of example, the pairing request message may include the initiator device's 502 IO capabilities, authentication data availability, authentication requirements, key size requirements, and other data.

[0091] In step 525, a pairing response message is sent from the responder device 504 and includes much of the same information as the pairing request message. Steps 520 and 525 may occur as part of Phase 1. The devices may perform authentication using the information in the message, for example, to select authentication options and perform authentication.

[0092] In step 530, authentication is performed, for example, via one of the four modes described above. Authentication can establish that a device is communicating with another device that corresponds to the encryption key being used. Authentication can be confirmed by one device or both devices. Authentication can be performed as Phase 2.

[0093] In step 535, keys are exchanged, e.g., as part of Phase 3. The key exchange can accommodate the bonding process, such that pairing (e.g., Phases 1 and 2) does not need to be performed each time devices connect (link) with one another. Thus, the keys can be used to encrypt future communications. For example, an advertisement signal can identify the responder device, and the initiator device can determine that the two devices are already paired. The initiator device can then proceed using one or more keys to send messages to the responder device, and the responder device can decrypt or otherwise read the messages using its stored keys.

[0094] Later, in step 540, a communication link is automatically established between the devices. As just described, this link can use the exchanged keys. And because the devices are already paired, once the advertising signal is detected, messages can be sent immediately over the link. However, this automatic connection requires that the pairing process has already been performed. A device can determine that another device is already paired by comparing the data in the advertising signal with a list of devices that are already paired. IV. Ranging Service - First Protocol

[0095] In various embodiments, the ranging service may be instantiated as a primary service or a secondary service. In some examples provided, the ranging service defines messages that can be exchanged over a BT connection-oriented channel. Both the mobile device and the vehicle can support a database and can use defined procedures to interact with the database independently of the ranging service. The vehicle can act as a central device and open the channel. Aspects of the protocol for establishing the ranging service using the first wireless protocol (e.g., for performing security handshake 307, data exchange 308, and ranging setup handshake 309) are described below, followed by some exemplary message sequences. A. Protocol

[0096] An exemplary format for a ranging service message format may provide a code (e.g., 1 octet long) indicating the type of message. A length field (e.g., 2 octets long) may indicate the size in octets of the data field of the message, which may not include the code and length fields. The data field may be variable in length. Thus, the code field may determine the format of the data field, and the length field may indicate the length of the data field. The following sections provide exemplary details of a ranging service message for negotiating, initiating, and completing UWB ranging between a mobile device and a vehicle. 1. Ranging Capability Request / Response

[0097] A ranging setup (capability) handshake can be initiated at the start of every connection to exchange the status of the mobile device and the UWB device on the vehicle. The ranging capability request message can have a specific ID code (e.g., 1). Some example parameters of this message include a supported feature mask, a required feature mask, a software version, a link identifier, the number of UWB radio devices, and a UWB device descriptor.

[0098] The software version parameter may indicate the current ranging software version running on the initiator device. The link identifier may be a random number that allows the responder to match the received UWB packet to a BT connection with the initiator. Therefore, the link identifier may be included in the UWB message.

[0099] Both the mobile device and the vehicle can maintain two feature masks: a supported feature mask and a required feature mask. The supported feature mask can indicate the supported features. The feature mask parameter can be a bit mask of all features. For each feature, a single bit can be specified, e.g., set to 1 if the feature is supported and 0 otherwise. Exemplary features are secure ranging, one-to-one ranging (e.g., one device-to-one device), and one-to-many ranging (e.g., one mobile device-to-multiple vehicles, or multiple vehicles-to-multiple mobile devices). The required feature mask can indicate the required features. For example, support for secure ranging and one-to-one ranging can be mandatory.

[0100] The UWB device descriptor may have one entry for each available UWB antenna device (e.g., an antenna, or a node with two or more antennas). The feature request message may have one UWB device descriptor entry for each UWB device on the initiator device. Each of the UWB antenna devices may be characterized by a UWB device descriptor with the following parameters: Firmware Version—the current UWB firmware version; Hardware Version—the current UWB hardware version; Manufacturer Name—the name of the UWB manufacturer.

[0101] The number of available UWB devices can be specified for a particular ranging session. Link identifiers can map BT links to UWB packets. Calibration data can be exchanged on pairing or on every connection.

[0102] The ranging capability response message may be similar to the ranging capability request message. A responder may be designated to send this message. If the responder does not support any of the features listed in the requested features of the ranging capability request message, the responder may respond with an additional ranging command complete message with an unsupported feature error code. The ranging capability response message may include parameters, such as supported features, software version, number of UWB devices, and UWB device descriptor. 2. Ranging Security Key Request / Response

[0103] The request and response can be used in a handshake to exchange keys and derive a shared secret during pairing. Periodic key refresh can also be used. In some implementations, a handshake can be performed on every connection to implement a challenge / response. 3.Distance measurement start / stop request

[0104] A ranging session can be initiated by sending a ranging start request command containing a set of parameters. The receiving device can decide to propose different parameters by responding with its own ranging start request or accept the request. If the receiving device decides to accept the request, it can send a ranging start notification event. If secure ranging is required and the security handshake has not been completed, the request can be rejected with an additional ranging command complete message with an insufficient authentication error code.

[0105] An example of a ranging initiation request may include a minimum ranging interval (e.g., 30 ms), a maximum ranging interval (e.g., 2,550 ms), a ranging offset (e.g., 30 ms to 2,550 ms), and a ranging timeout (e.g., 300 ms to 25.5 s). The ranging interval may define the amount of time between successive ranging attempts. The minimum and maximum ranging intervals may specify the minimum and maximum allowable ranging durations, for example, in milliseconds. Either the mobile device or the vehicle may request to initiate ranging.

[0106] Ranging mode can be exited by either the mobile device or the vehicle by sending a ranging stop request. The requested device can respond with a ranging command completed with a success status code. 4. Distance measurement event notification

[0107] Event notifications can be used to encapsulate events generated by central and peripheral devices. The subevent code can be the first one (e.g., the first octet) of the event parameters, with the following subevent parameters: Examples of ranging subevent types are: ranging command complete subevent (parameter: state), ranging capability update subevent (parameters: number of UWB devices and UWB device descriptor), ranging start subevent (parameters: ranging interval and ranging offset), ranging session state change subevent (parameter: session state), and ranging device state change subevent (parameter: device state).

[0108] The ranging command completed sub-event may be sent by the responder to indicate that the command sent by the initiator has completed. The status parameter may indicate whether the command was successful.

[0109] The Ranging Capability Update sub-event may indicate any change in the availability of UWB sensors for ranging. This event is optional and may be ignored by the receiving device. This event can be used to indicate that the initiator device has a subset of UWB sensors that are unavailable or suitable for initial ranging. The parameter for this event may be the number of UWB devices.

[0110] The Ranging Start subevent can be sent in response to a ranging start request from the initiator. The responder can send this event with the accepted ranging interval and ranging offset. The ranging offset parameter can provide a rough estimate of the starting UWB session for this event. This event can be used to trigger a one-shot immediate ranging session by setting the ranging interval and offset to 0. Previous ranging start request messages are not required for an immediate ranging session. The responder may ignore them with an immediate request. The ranging interval parameter can be between 30 ms and 2,550 ms and can be set to 0 to request immediate ranging. The ranging offset parameter can be between 30 ms and 2,550 ms and can be set to 0 to request immediate ranging.

[0111] A set of ranging session state change sub-events can be generated to indicate the initiation, progress, and completion of UWB-related actions. These sub-events can be generated by both the mobile device and the vehicle. A security key refresh event may be initiated by the vehicle or the mobile device to request a new set of security keys. Lock and unlock events can be generated by the vehicle after a successful ranging session. Examples of this set of sub-events include: That is, a ranging session key refresh sub-event (e.g., when the initiator needs to refresh all security keys), a ranging session lock start sub-event (e.g., when the initiator is performing a lock operation), a ranging session lock completion sub-event (e.g., when the initiator has completed a lock operation), a ranging session unlock start sub-event (e.g., when the initiator is performing an unlock operation), a ranging session unlock completion sub-event (e.g., when the initiator has completed an unlock operation), a ranging session ignition start sub-event (e.g., when the initiator is performing an immobilizer operation), a ranging session ignition completion sub-event (e.g., when the initiator has completed an immobilizer operation), and a ranging session timeout sub-event (e.g., when the initiator has stopped ranging due to a timeout).

[0112] A set of ranging device state change sub-events may be generated in response to a change in the state of the vehicle or mobile device. The device state parameter indicates the new state of the initiator. Example sub-events include: a ranging device disable sub-event (e.g., when the initiator does not recognize the receiver as a valid key), a ranging device authentication sub-event (e.g., when the initiator completes local authentication of the device), and a ranging device enable sub-event (e.g., when the initiator recognizes the receiver as a valid device).

[0113] The ranging device disabled sub-event can be used by a vehicle to indicate that the mobile device has been disabled and can no longer perform any actions until the mobile device completes user authentication. If the initiator or responder decides to stop any existing ranging sessions in response to this event, the initiator or responder can send a ranging stop request message.

[0114] The ranging device authentication complete sub-event may indicate that the initiator device has performed local authentication of the user. The responder may accept this event and allow the initiator device to perform actions on the responder.

[0115] The ranging device enabled sub-event can be used by the initiator to indicate that the receiver has been re-enabled as a valid device for performing any operations on the initiator. In response to this event, a ranging session can be started by either the initiator or the receiver.

[0116] The ranging device may use an error code that closely matches the error condition. Example error codes include: success, insufficient authentication, ranging timeout, maximum ranging client limit exceeded, and unsupported feature. B. Message Sequence

[0117] This section illustrates an example interaction between a vehicle and a mobile device using ranging service messages. It is assumed that a communication channel has already been established.

[0118] FIG. 6 illustrates ranging interval negotiation, according to an embodiment of the present invention. A first ranging initiation request can be sent by the initiator 600 to the responder 650. The responder 650 can respond by sending its own second ranging initiation request 610, but with a different set of ranging parameters. The ranging exchange messages 615-625 can be sent, for example, as part of a negotiation of ranging capabilities, as defined by the parameters. If the ranging parameters from the remote side are acceptable, the responder 650 can send a ranging initiation sub-event with the parameters for the ranging session.

[0119] 7 illustrates a key refresh negotiation according to an embodiment of the present invention. A security key refresh request 715 can be initiated by the initiator 700 (mobile device or vehicle) after a refresh sub-event 705 and a stop message 710 have been sent, after which the UWB ranging session can be paused. The initiator 700 can provide security parameters for the subsequent ranging session to the responder 750, which can provide a security key response 720. Once the security keys have been successfully refreshed, the initiator 700 can start a new UWB ranging session using a ranging start request message 725 followed by a start sub-event 730.

[0120] The ranging key refresh handshake may be required to complete within a specified time. If the timer expires before the handshake is complete, the ranging session may be restarted with the current security parameters. The UWB radio may need to resynchronize to compensate for any drift caused by the timeout. V. Ranging Service - Second Protocol

[0121] A description of exemplary messages used for ranging services over a second wireless protocol (e.g., UWB) is provided below, along with exemplary message sequences. Further details of UWB messaging can be found in IEEE Standard 802.15.4® (2016), "IEEE Standard for Low-Rate wireless networks," which is incorporated by reference. A. Protocol

[0122] The UWB ranging start request is an optional message that may indicate the start of a UWB ranging session and allow for precise coordination between the initiator and responder.

[0123] The UWB ranging stop request is an optional message that can indicate the end of a ranging session. The session can be ended because keys need to be updated, for example, because ranging between devices no longer needs to be performed, or because one or more devices want to end ranging.

[0124] The UWB ranging start event message can be sent in response to a UWB ranging start request message. The UWB ranging stop event message can be sent in response to a UWB ranging stop request message.

[0125] The UWB ranging exchange message may have the dual purpose of providing an optionally encrypted preamble for secure ranging and transferring the necessary round-trip time timestamps between the initiator and responder. Exemplary parameters of this message may include validity time, transmit and receive timestamps, timestamp uncertainty, timestamp validity, RSSI, and status. This event can be triggered as part of a single two-way ranging exchange or a more than three-way ranging exchange for either one-to-one or one-to-many ranging.

[0126] Further description of example parameters of the UWB ranging exchange message follows: Validity timestamp may be absolute time based. Number of ranging nodes may correspond to the number of valid ranging timestamps in the message. Index (node_x_index) may be an index into the responder node list. Ranging timestamp node_x may correspond to the timestamp of the most recently received or transmitted UWB packet from a particular node. For example, ranging timestamp uncertainty node_x 1 may have a value range of 1.5 cm to 3.6 m with various degrees of confidence. RSSI_node_x 1 may be the RSSI in dBm of the received packet. Ranging status node_x may provide the status of node x. Node x_antenna may define which antenna for node_x receives or transmits the packet.

[0127] Examples of UWB ranging states can be: success (successful reception and transmission of packet), timestamp overflow (timestamp counter overflow), transaction expired (transaction was too long and expired), frame too long, key unavailable (key unavailable for secure ranging), security not supported (secure ranging mode not supported), and ranging not supported (ranging mode not supported). B. Message Sequence

[0128] In some embodiments of one-to-one ranging, each responder (e.g., a UWB radio) can perform a UWB ranging exchange with the initiator as soon as the responder sees the first UWB ranging exchange packet. Figure 6 shows two-sided, two-way ranging with a three-packet exchange. One optional exchange not shown is the time of receipt at responder 650 of the last packet being sent to initiator 600. This can be performed if the initiator wants to calculate a more accurate range from all the timestamps.

[0129] 8 illustrates one-to-many ranging according to an embodiment of the present invention, where one-to-many ranging can be performed by having the initiator and each responder perform UWB ranging exchanges in a predetermined sequential order after the first UWB ranging exchange packet from the initiator.

[0130] FIG. 8 illustrates two-sided, two-way ranging involving three packet exchanges between an initiator 800 and each of three responders 852-856. A ranging start request 802 (e.g., using a first wireless protocol) can be received by the responders 852-856, which can respond with a ranging start event message 804. Responders 1, 2, and 3 each receive an initial ranging packet 810 from the initiator 800, but respond at different times. They can also all receive a final ranging packet 840 from the initiator 800, which may correspond to message 430 in FIG. 4. One optional exchange is the time of receipt of message 840 at each responder 852-856 sent back to the initiator 800. This can be performed if the initiator 800 desires to calculate a more accurate range from all the timestamps.

[0131] To support point-to-multipoint ranging, where a vehicle may contain more than one UWB transceiver, special provisions for addressing can be defined. The four least significant bits (LSBs) of the source and destination addresses can be used to define the intended transceiver, with possible transceiver IDs, e.g., 0x0 to 0xE. For point-to-multipoint ranging, the destination address can be set to a specific value (e.g., 0xF) to indicate that the packet is intended for all transceivers. VI. Method

[0132] 9 is a flowchart of a method 900 for performing communication between a mobile device and an access control system (e.g., associated with a vehicle or building) according to an embodiment of the present invention. Method 900 may be performed by a mobile device (or other computing device) that may include one or more processors and memory that stores program code executed by the one or more processors. Aspects of method 900 may be performed in a manner similar to method 100.

[0133] At block 910, a first wireless protocol is used (e.g., via a first antenna) to authenticate the access control system. The first wireless protocol may be BT. The authentication may use information exchanged during a previously performed pairing process between the mobile device and the access control system (e.g., a vehicle), as described herein. The authentication may involve a challenge-response procedure between the mobile device and the access control system. An identifier from the access control system may be used to determine an expected response to a given challenge, for example, to obtain a key expected to be used by the access control system to generate a response, and to authenticate the response using the key (e.g., by decrypting or regenerating the response). The access control system may also authenticate the mobile device.

[0134] The authentication may be of a control unit of the access control system. For example, a challenge (e.g., a random number) may be sent to the access control system. The control unit of the access control system (e.g., the ECU in FIG. 3) may operate on the challenge using an encryption key to provide a response. The encryption key may be derived from or be a shared secret established during pairing of the mobile device with the access control system. The response may be received from the access control system and compared to an expected result, thereby authenticating the control unit of the access control system. As an example, the response may be decrypted and compared to the original challenge, or the mobile device may encrypt the challenge (e.g., using the same encryption key) and compare the result to the received response. As another example of authentication, a digital signature of the control unit of the access control system may be received using the first wireless protocol. The digital signature may be verified using the control unit's public key, thereby authenticating the control unit of the access control system.

[0135] After authentication, a secure channel is created between the mobile device and the access control system (e.g., a vehicle control unit) in block 920 using the shared secret. The secure channel may use a first wireless protocol. The shared secret may be established during a pairing process between the mobile device and the access control system. The shared secret may be used for authentication in block 910. Creation of the secure channel may be performed by using an identifier obtained from the access control system to access a database (e.g., a table) of paired devices to determine one or more encryption keys, for example, to derive or retrieve an Elliptic-curve Diffie-Hellman (ECDH) key pair.

[0136] At block 930, ranging capabilities are communicated with the access control system using a secure channel for ranging performed using the second wireless protocol. As an example, the ranging capabilities may specify a format for ranging messages between the mobile device and the access control system, e.g., as described herein. Other examples of ranging capabilities include the number of antennas, the locations of those antennas (e.g., relative distances between antennas and / or origins within the access control system, such as ECUs), the number of antennas used, encryption protocols, packet formats, operating modes, and supported frequency ranges.

[0137] At block 940, the first set of pulses in a ranging request message may be transmitted to the access control system using a second wireless protocol. The second wireless protocol may use a pulse width that is smaller than the pulse width used by the first wireless protocol. In some embodiments, the first wireless protocol is Bluetooth (e.g., BTLE) and the second wireless protocol is UWB.

[0138] At block 950, a second set of pulses in one or more ranging response messages is received from the access control system (e.g., using a second antenna). The one or more ranging response messages may be multiple ranging response messages (e.g., as shown in FIGS. 4 and 8). Each ranging response message may be from a different antenna unit (e.g., different node) of the access control system and may include identification information unique to the particular antenna unit, where such identification information may be encrypted. In some implementations, the ranging request message may be broadcast in multiple ranging response messages, for example, as shown in ranging request 410 of FIG. 4 or FIG. 8. In other implementations, separate ranging request messages may be sent to different antenna units.

[0139] At block 960, distance information corresponding to the transmission time(s) of the first set of pulses and the reception time(s) of the second set of pulses is determined. The distance information may include, for example, timestamps corresponding to the first set of pulses in the ranging request message and the second set of pulses in one or more ranging response messages, as shown in FIG. 4. The timestamps may be configurable for use by a control unit of the access control system to determine the distance of the mobile device from the access control system, for example, as described herein.

[0140] In some embodiments, the mobile device can determine the distance. For example, the mobile device can determine the distance using the transmit time(s) of the first set of pulses and the receive time(s) of the second set of pulses. Thus, the distance information can include the distance.

[0141] At block 970, the distance information is transmitted to the access control system, thereby enabling the access control system to perform an action. The distance information can be transmitted using either a first wireless protocol (e.g., using a secure channel) or a second wireless protocol. In various embodiments, the action can be unlocking a door in the access control system (e.g., all doors, or specific doors based on user access privileges, or the nearest door), turning on the heater or air conditioning, or enabling the start button on a vehicle. Any such action can be triggered based on the distance or rate of change of distance (e.g., speed toward the vehicle) exceeding a threshold. Multiple such thresholds can be used for different actions, for example, as described herein. VII. Exemplary Devices

[0142] 10 is a block diagram of an exemplary device 1000, which may be a mobile device. Device 1000 generally includes computer-readable media 1002, a processing system 1004, an input / output (I / O) subsystem 1006, radio circuitry 1008, and audio circuitry 1010, including a speaker 1050 and a microphone 1052. These components may be coupled by one or more communication buses or signal lines 1003. Device 1000 may be any portable electronic device, including a handheld computer, a tablet computer, a mobile phone, a laptop computer, a tablet device, a media player, a personal digital assistant (PDA), a key fob, a car key, an access card, a multifunction device, a mobile phone, a portable gaming device, an automobile display unit, or the like (including combinations of two or more of these items).

[0143] It will be apparent that the architecture shown in Figure 10 is only one example architecture for device 1000, and that device 1000 may have more, fewer, or differently configured components than those shown. The various components shown in Figure 10 may be implemented as hardware, software, or a combination of both hardware and software, including one or more signal processing circuits and / or application specific integrated circuits.

[0144] The radio circuitry 1008 is used to transmit and receive information over a wireless link or network with conventional circuitry of one or more other devices, such as an antenna system, an RF transceiver, one or more amplifiers, a tuner, one or more oscillators, a digital signal processor, a codec chipset, memory, etc. The radio circuitry 1008 can use various protocols, such as those described herein. For example, the radio circuitry 1008 can have one component for one wireless protocol (e.g., Bluetooth) and a separate component for another wireless protocol (e.g., UWB). Different antennas can be used for the different protocols.

[0145] The radio circuit 1008 is coupled to the processing system 1004 via a peripheral interface 1016. The interface 1016 may include conventional components for establishing and maintaining communications between peripherals and the processing system 1004. Voice and data information received by the radio circuit 1008 (e.g., in a speech recognition application or a voice command application) is transmitted via the peripheral interface 1016 to one or more processors 1018. The one or more processors 1018 may be configured to process various data formats for one or more application programs 1034 stored on the medium 1002.

[0146] A peripheral interface 1016 couples input / output peripherals of the device to the processor 1018 and the computer-readable medium 1002. The one or more processors 1018 communicate with the computer-readable medium 1002 via a controller 1020. The computer-readable medium 1002 may be any device or medium capable of storing code and / or data for use by the one or more processors 1018. The medium 1002 may include a memory hierarchy including a cache, a main memory, and a secondary memory.

[0147] Device 1000 also includes a power system 1042 that provides power to the various hardware components. Power system 1042 can include a power management system, one or more power sources (e.g., batteries, alternating current (AC)), a recharging system, power failure detection circuitry, power converters or inverters, power status indicators (e.g., light emitting diodes (LEDs)), and any other components typically associated with the generation, management, and distribution of power within a mobile device.

[0148] In some embodiments, device 1000 includes a camera 1044. In some embodiments, device 1000 includes sensors 1046. Sensors 1046 may include an accelerometer, a compass, a gyrometer, a pressure sensor, an audio sensor, a light sensor, a barometer, etc. Sensors 1046 may be used to sense aspects of a location, such as an auditory or optical signature of the location.

[0149] In some embodiments, device 1000 may include a GPS receiver, sometimes referred to as a GPS unit 1048. Mobile devices may use satellite navigation systems, such as the Global Positioning System (GPS), to obtain location information, timing information, altitude, or other navigation information. During operation, the GPS unit may receive signals from GPS satellites orbiting the Earth. The GPS unit analyzes the signals to generate travel time and distance estimates. The GPS unit may determine the mobile device's current location. Based on these estimates, the mobile device may determine a location fix, altitude, and / or current speed. The location fix may be geographic coordinates, such as latitude and longitude information.

[0150] The one or more processors 1018 execute various software components stored on the medium 1002 to perform various functions for the device 1000. In some embodiments, the software components include an operating system 1022, a communications module (or instruction set) 1024, a location module (or instruction set) 1026, a ranging module 1028 used as part of the ranging operations described herein, and other applications (or instruction sets) 1034.

[0151] Operating system 1022 may be any suitable operating system, including embedded operating systems such as iOS, MacOS, Darwin, RTXC, LINUX, UNIX, OSX, WINDOWS, or VxWorks. An operating system may include procedures, sets of instructions, software components, and / or drivers for controlling and managing general system tasks (e.g., memory management, storage device control, power management, etc.) and facilitating communication between various hardware and software components.

[0152] Communications module 1024 facilitates communication with other devices via one or more external ports 1036 or via wireless circuitry 1008 and includes various software components for handling data received from wireless circuitry 1008 and / or external port 1036. External port 1036 (e.g., USB, FireWire, Lightning connector, 60-pin connector, etc.) is adapted to couple directly to other devices or indirectly via a network (e.g., the Internet, wireless LAN, etc.).

[0153] The location / motion module 1026 can assist in determining the current location (e.g., coordinates or other geographic location identifier) ​​and movement of the device 1000. Modern location determination systems include satellite-based location determination systems such as the Global Positioning System (GPS), cellular network location based on "cell ID," and Wi-Fi location technology based on Wi-Fi networks. GPS also determines a location estimate based on the visibility of multiple satellites. Satellites may not be visible (or have weak signals) indoors or in "city canyons." In some embodiments, the location / motion module 1026 receives data from the GPS unit 1048 and analyzes the signals to determine the current location of the mobile device. In some embodiments, the location / motion module 1026 can determine the current location using Wi-Fi or cellular positioning technology. For example, the location of the mobile device can be estimated using knowledge of nearby cell sites and / or Wi-Fi access points and their locations. Information identifying the Wi-Fi or cellular transmitter is received by the radio circuit 1008 and communicated to the location / motion module 1026. In some embodiments, the location determination module receives one or more transmitter IDs. In some embodiments, a set of transmitter IDs can be compared to a reference database (e.g., a cell ID database, a Wi-Fi reference database). The reference database maps or correlates the transmitter IDs to location coordinates of the corresponding transmitters and calculates estimated location coordinates for the device 1000 based on the location coordinates of the corresponding transmitters. Regardless of the particular location determination technology used, the location determination / motion module 1026 receives information from which a location fix can be derived, interprets that information, and returns location information such as geographic coordinates, latitude / longitude, or other location fix data.

[0154] The ranging module 1028 can transmit / receive ranging messages, for example, to / from an antenna connected to the radio circuitry 1008. The messages can be used for various purposes, such as to identify the vehicle's transmitting antenna, to determine a timestamp of the message (e.g., for transmission to the vehicle), and potentially to determine the distance from the vehicle to the mobile device 1000.

[0155] The one or more application programs 1034 on the mobile device may include any application installed on the device 1000, including, without limitation, a browser, an address book, a contact list, email, instant messaging, word processing, keyboard emulation, widgets, JAVA-enabled applications, encryption, digital rights management, voice recognition, voice duplication, a music player (which plays recorded music stored in one or more files, such as MP3 or AAC files), and the like.

[0156] There may be other modules or instruction sets (not shown), such as a graphics module, a time module, etc. For example, the graphics module may include various conventional software components for rendering, animating, and displaying graphical objects (including, without limitation, text, web pages, icons, digital images, animations, etc.) on a display surface. In another example, the timer module may be a software timer. The timer module may also be implemented in hardware. The time module may maintain various timers for any number of events.

[0157] The I / O subsystem 1006 can be coupled to a display system (not shown), which can be a touch-sensitive display. The display system displays visual output to the user in a GUI. This visual output can include text, graphics, video, and any combination thereof. Some or all of the visual output can correspond to user interface objects. The display can use LED (light emitting diode), LCD (liquid crystal display) technology, or LPD (light emitting polymer display) technology, although other display technologies can be used in other embodiments.

[0158] In some embodiments, I / O subsystem 1006 can include a display and user input devices such as a keyboard, a mouse, and / or a trackpad. In some embodiments, I / O subsystem 1006 can include a touch-sensitive display. The touch-sensitive display can also accept input from a user based on tactile and / or haptic contact. In some embodiments, the touch-sensitive display forms a touch-sensitive surface that accepts user input. The touch-sensitive display / surface (together with any associated modules and / or instruction sets in medium 1002) detects contact (and any movement or release of contact) on the touch-sensitive display and translates the detected contact into an interaction with a user interface object (e.g., one or more soft keys) that is displayed on the touchscreen when the contact occurs. In some embodiments, the point of contact between the touch-sensitive display and the user corresponds to one or more of the user's fingers. The user can contact the touch-sensitive display using any suitable object or accessory, such as a stylus, pen, finger, etc. The touch-sensitive display surface can detect the contact and any movement or release thereof using any suitable touch sensitivity technology. Touch sensitivity technologies include capacitive, resistive, infrared, and surface acoustic wave technologies, as well as other proximity sensor arrays or other elements that determine one or more points of contact with a touch-sensitive display.

[0159] Additionally, the I / O subsystem may be coupled to one or more other physical control devices (not shown), such as push buttons, keys, switches, rocker buttons, dials, slider switches, sticks, LEDs, etc., to control or perform various functions, such as power control, speaker volume control, ring volume, keyboard input, scrolling, hold, menu, screen lock, clearing and ending communications, etc. In some embodiments, in addition to a touch screen, device 1000 may include a touch pad (not shown) for activating or deactivating certain functions. In some embodiments, a touch pad is a touch-sensitive area of ​​a device that, unlike a touch screen, does not display visual output. A touch pad may be a touch-sensitive surface separate from a touch-sensitive display or an extension of the touch-sensitive surface formed by a touch-sensitive display.

[0160] In some embodiments, some or all of the operations described herein may be performed using an application running on a user's device. Circuits, logic modules, processors, and / or other components may be configured to perform the various operations described herein. Those skilled in the art will appreciate that such configuration may be achieved through the design, setup, interconnection, and / or programming of specific components, depending on the implementation, and that configured components may or may not be reconfigurable for different operations, depending on the implementation. For example, a programmable processor may be configured by providing suitable executable code, and dedicated logic circuits may be configured by suitable connections of logic gates and other circuit elements.

[0161] Any of the software components or functions described in this application may be implemented as software code to be executed by a processor, using any suitable computer language, such as, for example, Java, C, C++, C#, Objective-C, Swift, or a scripting language such as Perl or Python, using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions or commands on a computer-readable medium for storage and / or transmission. Suitable non-transitory computer-readable media may include random access memory (RAM), read-only memory (ROM), magnetic media such as a hard drive or floppy disk, optical media such as a compact disk (CD) or digital versatile disk (DVD), flash memory, etc. The computer-readable medium may also be any combination of such storage or transmission devices.

[0162] A computer program incorporating various features of the present disclosure may be encoded on a variety of computer-readable storage media, with suitable media including magnetic disks or tapes, optical storage media such as compact disks (CDs) or digital versatile disks (DVDs), flash memory, and the like. A computer-readable storage medium encoded with program code may be packaged with a compatible device or provided separately from other devices. Additionally, the program code may be encoded and transmitted over wired and / or wireless networks conforming to various protocols, including the Internet, thereby enabling distribution, for example, via Internet download. Any such computer-readable medium may be on or within a single computer product (e.g., a solid-state drive, hard drive, CD, or an entire computer system), or may be present on or within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display that provides a user with any of the results described herein.

[0163] Although the present disclosure has been described with reference to specific embodiments, it will be understood that the present disclosure is intended to cover all modifications and equivalents that fall within the scope of the following claims.

[0164] The terms "a," "an," or "the" are intended to mean "one or more" unless specifically stated to the contrary. The use of "or" is intended to mean "inclusive or" rather than "exclusive or" unless specifically stated to the contrary. Reference to a "first" element does not necessarily require that a second element be present. Furthermore, reference to a "first" or "second" element does not limit the referenced components to a particular location unless specifically stated.

[0165] All patents, patent applications, publications, and descriptions referred to herein are incorporated by reference in their entirety for all purposes. None is admitted to be prior art.

Claims

1. 1. A method for performing communication between a mobile device and an access control system, the method comprising: authenticating the access control system using a first wireless protocol; creating a secure channel between the mobile device and the access control system using a shared secret after authentication, the secure channel using the first wireless protocol; communicating, using the secure channel, one or more ranging capabilities with the access control system for ranging performed using a second wireless protocol; transmitting a first set of pulses in a ranging request message to the access control system using the second wireless protocol, the second wireless protocol using a pulse width that is smaller than a pulse width used by the first wireless protocol; receiving a second set of pulses in one or more ranging response messages from the access control system using the second wireless protocol; determining distance information corresponding to a transmission time(s) of the first set of pulses and a reception time(s) of the second set of pulses; transmitting the distance information to the access control system to enable the access control system to perform an action; A method comprising:

2. 2. The method of claim 1, wherein the one or more ranging response messages are a plurality of ranging response messages, each ranging response message being from a different antenna unit of the access control system and including identification information unique to a particular antenna unit.

3. The method of claim 2 , wherein the ranging request message is broadcast to the plurality of ranging response messages.

4. authenticating the access control system sending a challenge to the access control system, the challenge being operated by a control unit of the access control system using an encryption key to provide a response; receiving the response from the access control system; and comparing the response with an expected result to authenticate the control unit of the access control system.

5. 10. The method of claim 1, further comprising: determining a distance of the mobile device from the access control system using the transmit time(s) of the first set of pulses and the receive time(s) of the second set of pulses, wherein the distance information comprises the distance.

6. 2. The method of claim 1, wherein the distance information includes timestamps corresponding to the first set of pulses in the ranging request message and the second set of pulses in the one or more ranging response messages, the timestamps being configurable to be used by a control unit of the access control system to determine a distance of the mobile device from the access control system.

7. The method of claim 1 , wherein the action is unlocking a door of the access control system.

8. The method of claim 1 , wherein the one or more ranging capabilities specify a format for ranging messages between the mobile device and the access control system using the second wireless protocol.

9. 10. The method of claim 1, wherein the first wireless protocol is Bluetooth®, the second wireless protocol is Ultra Wideband (UWB), the first wireless protocol uses a first antenna, the second wireless protocol uses a second antenna, and the mobile device is a mobile phone.

10. The method of claim 1 , wherein the access control system is a vehicle.

11. A computer product comprising a computer readable medium storing a plurality of instructions that, when executed, control a computing device to perform the method of any one of claims 1 to 10.

12. A mobile device comprising one or more processors configured to perform the method of any one of claims 1 to 10.

Images