Vehicle positioning device, vehicle positioning system, and vehicle positioning method

Abstract

To provide a system and method for vehicle passive entry / passive start (PEPS).SOLUTION: The communication gateway establishes a Bluetooth low energy communication connection with the mobile device. The localization module determines the location of the mobile device based on two way ranging using impulse radio ultra-wideband. The PEPS system performs a vehicle function, such as unlocking a door or trunk, allowing the vehicle to start, or activating wireless charging, based on the location of the portable device. Another system includes at least one low frequency (LF) antenna configured to transmit a wireless charging ping signal within a predetermined range to a portable device configured for wireless charging. The communication gateway authenticates the portable device based on a response to the ping signal by the portable device. The PEPS performs a vehicle function, such as unlocking a door or trunk or allowing the vehicle to be started, in response to authenticating the portable device.SELECTED DRAWING: Figure 22

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Application No. 15 / 730,265, filed October 11, 2017, and also claims the benefit of U.S. Provisional Application No. 62 / 407,190, filed October 12, 2016. This application also claims the benefit of U.S. Provisional Application No. 62 / 450,235, filed January 25, 2017. The entire disclosure of each of the above applications is incorporated herein by reference. [Technical Field]

[0002] The present disclosure relates to a vehicle passive entry / passive start (PEPS) system and method with connectivity, and more particularly to a PEPS system and method that uses a Bluetooth Low Energy (BLE) communication device, an ultra-wide band (UWB) communication device, and / or a wireless charging device. [Background technology]

[0003] This section provides background information related to the present disclosure that is not necessarily publicly known.

[0004] Traditionally, PEPS systems allow the owner of a key fob, previously paired with the vehicle's PEPS central electronic control unit (ECU), to access the vehicle by simply grasping the door handle and start the vehicle by pushing a button. In response to the button push, the PEPS central ECU authenticates the key fob by determining whether it is authorized to access the vehicle and uses signal strength exhibited by multiple vehicle antennas to estimate the key fob's location. If the key fob is authenticated and located within an authorized zone, vehicle functionality is made available to the user (i.e., doors are unlocked or the vehicle is started).

[0005] Previous PEPS systems use proprietary radio protocols that use low frequency (LF) signals at approximately 125 kHz. Previous PEPS systems are also constrained by the physical nature of LF systems. LF was chosen in early PEPS systems because radio wave propagation allows for relatively accurate estimation of range and location by using signal strength within a typical target activation range of 2 meters. However, due to the very long wavelength of LF signals compared to the size of practical vehicle antennas and key fob receivers, it is difficult to reliably communicate with key fobs beyond a few meters using LF within reasonable power consumption and safe transmit power levels. Summary of the Invention

[0006] This section provides a summary of the disclosure but is not an exhaustive disclosure of its entire scope or all of its features.

[0007] The present disclosure provides a sensor for a vehicle having a passive entry / passive start (PEPS) system. The sensor is configured to communicate with a mobile device via Bluetooth® Low Energy (BLE). The sensor is further configured to perform impulse radio (IR) ultra-wideband (UWB) ranging of the mobile device via IR UWB communication with the mobile device based on the result of the BLE communication.

[0008] In other features, the sensor measures at least one of received signal strength, time of arrival, time difference of arrival, and angle of arrival via BLE communication. In other features, the signal information based on the IR UWB ranging includes at least one of received signal strength, time of arrival, time difference of arrival, and angle of arrival in IR UWB communication with the mobile device, and a location of the mobile device is determined based on the signal information.

[0009] In other features, the signal information includes at least one of a time of arrival and a time difference of arrival. In other features, the sensor measures at least one of a time of arrival and a time difference of arrival based on IR UWB ranging, and a location of the mobile device is determined based on the at least one of the time of arrival and the time difference of arrival. In other features, the sensor is configured to perform IR UWB communication in a time slot designated by the BLE communication.

[0010] In another aspect, the IR UWB ranging is two-way ranging. In other features, the sensor is a plurality of sensors.

[0011] In another feature, the vehicle is provided with a plurality of sensors, and the plurality of sensors are provided on either the front side of the vehicle, the rear side, one side in the left-right direction of the vehicle, or the opposite side to the one side.

[0012] The present disclosure also provides a plurality of sensors provided in a vehicle having a passive entry / passive start (PEPS) system. At least one sensor of the plurality of sensors is configured to perform Bluetooth® Low Energy (hereinafter, referred to as BLE) communication with a mobile device and, based on a result of the BLE communication, to perform IR UWB ranging of the mobile device via impulse radio (IR) ultra-wideband (UWB) communication with the mobile device. At least one sensor of the plurality of sensors is configured to perform only BLE communication among the BLE communication and the IR UWB communication. At least one sensor of the plurality of sensors is configured to perform only IR UWB communication among the BLE communication and the IR UWB communication.

[0013] The present disclosure also relates to a method for communicating with a mobile device using a sensor provided in a vehicle having a passive entry / passive start (PEPS) system via Bluetooth (registered trademark) Low Energy (hereinafter, referred to as BLE); Using the sensor, performing impulse radio (IR) ultra-wideband (UWB) ranging of the mobile device via IR UWB communication with the mobile device based on results of the BLE communication.

[0014] (delete)

[0015] (delete)

[0016] The present disclosure also provides another system including at least one low frequency (LF) antenna on a vehicle configured to transmit a wireless charging ping signal within a predetermined range of the at least one LF antenna to a portable device configured for wireless charging. The system also includes a communications gateway in the vehicle configured to establish a wireless communication connection with the portable device, receive a response to the wireless charging ping signal from the portable device via the wireless communication connection, and authenticate the portable device based on the response to the wireless charging ping signal. The system also includes a passive entry / passive start (PEPS) system configured to communicate with the communications gateway and, in response to the communications gateway authenticating the portable device, perform a vehicle function including at least one of unlocking a vehicle door, unlocking a vehicle trunk, and allowing the vehicle to be started.

[0017] In other features, the communications gateway is configured to control timing at which the at least one LF antenna transmits a wireless charging ping signal to the portable device.

[0018] In other features, the communications gateway is configured to control the at least one LF antenna to transmit a wireless charging ping signal to the portable device in response to at least one of a door button operation, a push button operation, signal characteristics of a communication signal between the communications gateway and the portable device, a GPS location of the portable device, a GPS location of the vehicle, and data received from an additional vehicle sensor.

[0019] In other features, the response to the wireless charging ping signal from the portable device is at least one of encrypted, replay safe, and signed.

[0020] In other features, the at least one LF antenna is configured to communicate with the key fob using LF communications.

[0021] In other features, the at least one LF antenna comprises a plurality of LF antennas.

[0022] In other features, the wireless communication connection is one of a Bluetooth Low Energy (BLE) communication connection and an Impulse Radio (IR) Ultra Wideband (UWB) communication connection.

[0023] Further areas of applicability will become apparent from the description provided herein.The description and specific examples in this summary are intended for purposes of illustration only and are not intended to limit the scope of the present disclosure. [Brief explanation of the drawings]

[0024] The drawings described below are for purposes of illustrating selected embodiments only and do not represent all possible implementations, nor are they intended to limit the scope of the present disclosure.

[0025] [Figure 1] 1 illustrates an ego-vehicle equipped with a PEPS system according to the present disclosure.

[0026] [Figure 2] FIG. 1 shows a block diagram of a PEPS system according to the present disclosure.

[0027] [Figure 3] FIG. 1 shows a block diagram of a sensor of a PEPS system according to the present disclosure.

[0028] [Figure 4] 1 illustrates a communication gateway for a PEPS system according to the present disclosure.

[0029] [Figure 5] 1 shows a timing diagram of a sensor receiving data from an authorized device and data from an attacker.

[0030] [Figure 6]1 shows a timing diagram of the data received by the two sensors.

[0031] [Figure 7] FIG. 1 shows a block diagram of a PEPS system according to the present disclosure.

[0032] [Figure 8] 1 shows information used by sensors to find and track secure communication links.

[0033] [Figure 9] 1 illustrates the operation of a PEPS system according to the present disclosure.

[0034] [Figure 10] 1 illustrates an exemplary channel hopping map according to the present disclosure.

[0035] [Figure 11] 1 illustrates a process for synchronizing timing of a sensor with a communication gateway according to the present disclosure.

[0036] [Figure 12] 1 illustrates the process of the PEPS module for configuring and controlling a sensor network and initiating and / or terminating subsequent connections according to the present disclosure.

[0037] [Figure 13] 1 illustrates an authentication method according to the present disclosure.

[0038] [Figure 14] 1 shows a timing diagram of communication between a slave, a master, a communication gateway, and a sensor.

[0039] [Figure 15] 1 shows a prior art PEPS system.

[0040] [Figure 16] 1 illustrates a PEPS system according to the present disclosure.

[0041] [Figure 17] 1 illustrates a PEPS system according to the present disclosure.

[0042] [Figure 18] 10 shows a screenshot of an alert to a mobile device according to the present disclosure.

[0043] [Figure 19] 1 illustrates an ego-vehicle having a PEPS system according to the present disclosure.

[0044] [Figure 20] 1 illustrates an ego-vehicle having a PEPS system according to the present disclosure.

[0045] [Figure 21] 1 illustrates an ego-vehicle having a PEPS system according to the present disclosure.

[0046] [Figure 22] 1 shows a sequence diagram of a PEPS system according to the present disclosure.

[0047] [Figure 23] 1 illustrates an ego-vehicle having a PEPS system according to the present disclosure.

[0048] [Figure 24] FIG. 1 shows a block diagram of a PEPS system according to the present disclosure.

[0049] [Figure 25] 1 shows a sequence diagram of a PEPS system according to the present disclosure.

[0050] Corresponding reference numbers indicate corresponding parts throughout the several views. DETAILED DESCRIPTION OF THE INVENTION

[0051] Exemplary embodiments will now be described in more detail with reference to the accompanying drawings.

[0052] The present disclosure relates to systems, methods, and architectures for implementing a PEPS system using a consumer-grade wireless protocol based on standardized specifications from the Bluetooth Consortium. Specifically, the present disclosure relates to a PEPS system that uses the Bluetooth Low Energy (BLE) communication protocol for communication between a vehicle and a BLE-enabled user device, such as a smartphone or wearable device. Furthermore, the present disclosure applies to vehicle systems equipped with keyless entry and keyless go systems, commonly referred to as PEPS systems or keyless entry and keyless go systems. Generally, a PEPS system is a type of location system. The present disclosure relates to systems, methods, and architectures for securely implementing a location system targeted at PEPS applications that uses a sensor network configured to locate an existing connection between a BLE device and a vehicle and measure the timing and signal characteristics of the communication. Thus, the present disclosure provides a PEPS system that provides authorized vehicle users with secure access to vehicle functions by locating a wireless device relative to the vehicle and comparing the wireless device's location to criteria. As described in detail below, the PEPS system of the present disclosure includes a central module that collects received signal strengths from wireless devices from multiple sensors located in and around the vehicle. The central module contains, for example, encryption keys and challenge-response algorithms for authentication of wireless devices. Thus, as described in detail below, this disclosure describes a power-saving, private method for implementing a PEPS system that uses the BLE communication protocol.

[0053] It is desirable to allow users to use other devices, such as smart devices like smartphones or wearable devices, as their vehicle keys. As described in more detail below, this enables digital key sharing applications. Furthermore, long-range features are becoming important for convenience features such as passive welcome lighting and distance range for remote parking applications. Such systems and benefits are not achievable with conventional PEPS systems because each vehicle manufacturer and PEPS system supplier traditionally implements proprietary, closed systems that use radio frequencies not used by ubiquitous devices like smartphones.

[0054] The systems, methods, and architectures of the present disclosure include a PEPS system having a central decision-making module and multiple sensor modules that serve as direct replacements for the multiple LF antennas used in previous PEPS systems. The systems, methods, and architectures of the present disclosure differ from previous LF PEPS systems both in when data is collected and how the data flows and is processed by the system.

[0055] 1 and 2, a PEPS system 1, also referred to as a position location system, is provided within a vehicle 30 and includes a communication gateway 29 and multiple sensors 31A-31F, collectively referred to as 31. The PEPS system 1 includes one or more vehicle modules 20 distributed throughout the vehicle 30 and capable of communicating with each other, for example, via a vehicle interface 45. Additionally, some of the modules may be integrated into a single ECU and capable of communicating with each other using the vehicle interface 45. The vehicle interface 45 may include, for example, a controller area network (CAN) bus for communication between the main modules and / or a lower data rate communication such as a local interconnect network (LIN) for communication between multiple sensors 31A-31F. The vehicle interface 45 may also include a clock extension peripheral interface (CXPI) bus. Additionally or alternatively, the vehicle interface 45 may include a combination of CAN bus, LIN, and CXPI bus communication interfaces. The structure of the sensor 31 is discussed in further detail below with reference to FIG. 3.

[0056] The vehicle module 20 may include a communication gateway 29 including, for example, a BLE chipset 21 connected to the antenna 19. As shown in FIG. 2 , the antenna 19 may be located within the vehicle 30. Alternatively, the antenna 19 may be contained within and located within the vehicle module 20. Alternatively, the antenna 19 may be located outside the vehicle 30. The vehicle module 20 may also include a link authentication module 22 that authenticates the mobile device 10 for communication over the secure communication link 680. The vehicle module 20 may also include a data management layer 23 for push data. The vehicle module 20 may also include a connection information distribution module 24. The vehicle module 20 may also include a timing control module 25. The vehicle module 20 may also include a telematics module 26, such as a global positioning system (GPS) module and / or other navigation or location module. The vehicle module 20 may also include a PEPS module 27. The vehicle module 20 may also include a body control module. The vehicle module 20 may also include a sensor processing and location module 32. The vehicle module 20 may also include a security filtering module 33 .

[0057] As shown in FIGS. 1 and 2 , the mobile device 10 can communicate with the communication gateway 29 of the vehicle 30 via a secure communication link 680. The mobile device 10 may be any Bluetooth-enabled communication device, such as a smartphone, smartwatch, wearable electronic device, key fob, tablet device, or other device associated with a user of the vehicle 30, such as the owner, driver, passenger, and / or mechanic of the vehicle 30. The mobile device 10 may include a BLE chipset 11 connected to an antenna 13. The mobile device 10 may also include application software 12 stored on a computer-readable storage module or device. The mobile device 10 may also optionally include a GPS module 14 or other device location service.

[0058] The mobile device 10 and the communication gateway 29 can establish a secure communication link 680 as a Bluetooth communication link as defined in the Bluetooth specification. For example, the secure communication link 680 between the mobile device 10 and the communication gateway 29 can be a BLE communication link. The PEPS system 1 can be configured to additionally authenticate the secure communication link 680 with the mobile device. For example, the communication gateway 29 can communicate with the link authentication module 22 to authenticate the mobile device 10 and establish the secure communication link 680. For example, the link authentication module 22 can be configured to implement challenge-response authentication. In such a case, timing information regarding communication between the communication gateway 29 and the mobile device 10 is transmitted to the timing control module 25, which communicates with the sensors 31A-31F via the vehicle interface 45, as described below. The communication gateway 29 can also communicate information regarding communication channels and channel switching parameters to the connection information distribution module 24. The connection information distribution module 24 is configured to communicate with each of the sensors 31A-31F using the vehicle interface 45 and, once the sensors 31A-31F are synchronized with the communication gateway 29, to provide the sensors 31A-31F with the communication information necessary for the sensors 31A-31F to locate and track or intercept the secure communication link 680. While FIGS. 1 and 2 show the PEPS system 1 with six sensors 31A-31F, any number of sensors can be used. For example, a PEPS system can include seven, eight, nine, ten, eleven, twelve, or more sensors. Thus, although this disclosure provides an example utilizing six sensors, additional or fewer sensors can be used in accordance with this disclosure.

[0059] Referring to FIG. 3 , each of the sensors 31 includes a BLE chipset 41 connected to an antenna 43. As shown in FIG. 3 , the antenna 43 may be located internal to the sensor 31. Alternatively, the antenna 43 may be located external to the sensor 31. The sensor 31 receives BLE signals using the antenna 43, specifically, receives BLE physical layer messages using a BLE physical layer (PHY) controller 600. The sensor 31 observes the BLE physical layer messages and can use the channel map generated by the channel map reconstruction module 42 to make measurements of physical characteristics of the associated signals, including, for example, received signal strength (RSSI). Additionally or alternatively, the sensor 31 can determine other measurements of the physical characteristics of the associated signals, including, for example, data related to angle of arrival. Additionally or alternatively, the sensors 31 can communicate with each other and / or with the communication gateway 29 via the vehicle interface, for example, to determine time difference of arrival, time of arrival, or angle of arrival data for signals received by multiple sensors. The sensor 31 receives timing information and channel map information from the communication gateway 29 via the vehicle interface 45. The timing synchronization module 44 is configured to precisely measure the reception time of messages on the vehicle interface 45 and pass the timing information to the BLE chipset 41. The BLE chipset 41 is configured to obtain the channel map information and timing signals, tune the PHY controller 600 to a specific channel at a specific time, and observe all physical layer messages and data that conform to the Bluetooth physical layer specification, including normal data rates proposed or adopted in, for example, Bluetooth Specification Version 5.0. The data, timestamps, and measured signal strength are reported by the BLE chipset 41 via the vehicle interface 45 to the communication gateway 29 or other vehicle modules 20 of the vehicle 30.

[0060] Referring to FIG. 4 , the communication gateway 29 includes a BLE chipset 41 connected to the antenna 19 to receive BLE signals. The BLE chipset 41 implements a Bluetooth protocol stack 46 conforming to the BLE specification, including, for example, version 5 of the BLE specification. The BLE chipset 41 also includes an application 47 implemented by application code stored on a computer-readable medium, such as a storage module. The application 47 may include modifications outside the Bluetooth specification to enable the BLE chipset 41 to verify time-stamped data transmitted and received by the BLE chipset 41, regardless of the validity of the data. For example, the application 47 enables the BLE chipset 41 to compare the transmitted and received data with expected values. The communication gateway 29 is configured to transmit the actual transmitted and received data to a vehicle system of the vehicle 30 via the vehicle interface 45. Alternatively, the communication gateway 29 may be configured to receive data from each of the sensors 31 via the vehicle interface 45. The application 47 may be further configured to enable the BLE chipset 41 to verify that each of the sensors 31 received the correct data at the correct time, as described in more detail below.

[0061] Continuing with FIG. 4 , communication gateway 29 is further configured to provide information regarding ongoing connections and timing signals necessary, for example, for each of sensors 31 to discover and subsequently track connections with mobile device 10 maintained by communication gateway 29. Bluetooth protocol stack 46 is configured to provide a channel map, access identifier, next channel, and time to next channel to application 47. Bluetooth protocol stack 46 is configured to output timing signals for timestamps of transmit and receive events to application 47 and / or to a digital PIN output of BLE chipset 41. Communication gateway 29 also includes a timing synchronization module 44. Timing synchronization module 44 is configured to accept timing signals and operates in conjunction with vehicle interface 45 to generate accurate timestamps for connection information messages and other communications.

[0062] Previous BLE PEPS systems use BLE advertising data, as described in U.S. Patent Application Publication No. 2014 / 0188348, which is incorporated herein by reference. In such systems, a secure link is established between an authorized mobile device and a PEPS module. When authorized access to a vehicle function, such as unlocking the doors, is required, the mobile device must send an advertising signal to the PEPS module. The PEPS module receives the advertising signals from each of the sensors, processes the information, and determines the location of the mobile device. U.S. Patent Application Publication No. 2014 / 0188348 also describes a system in which the mobile device must connect individually to each of the sensors in the PEPS system. This type of system has several drawbacks. For example, the mobile device may not be able to connect to each of the sensors. Due to the fact that most BLE chipsets support a total of eight connections, and one connection is usually a secure connection to a communication gateway, the number of connections is typically limited to seven sensors. Furthermore, there is a time delay between connection events with each sensor. Therefore, each sensor will not measure the same signal. For example, because BLE uses frequency hop spread spectrum (FHSS), each sensor will typically measure the signal from the mobile device on a different channel at a different time. This can result in a loss of mission-critical accuracy.

[0063] The BLE specification prescribes the use of 40 communication channels, three of which are known as advertising channels. These advertising channels are used by devices to discover each other and report some basic information about the type of device they are. For example, advertising data typically includes the address of the device broadcasting the advertising packet, the device's name, along with the services the device offers. Automotive systems can detect and measure advertising channel packets to determine where a phone is located relative to the vehicle. However, as explained in more detail below, such systems are sensitive to the injection of advertising data and are subject to the additional communication load required by the advertiser to continue advertising. Therefore, it may be more advantageous to use the other 37 "connected channels" to determine a device's location.

[0064] Once two devices are connected, the broadcasting device no longer needs to broadcast to fulfill communication requirements. However, if the device needs to be located by the system using the advertising channel, it must continue broadcasting on the advertising channel, which creates significant power consumption issues for battery-powered devices. Therefore, a system that uses connection data can provide not only security benefits but also device power savings. Such a system also allows the system to monitor the location of devices that are not considered part of the system, such as tracking a smartwatch that is not directly connected to the vehicle system.

[0065] Previous BLE PEPS systems that use advertising data are susceptible to attacks. For example, an attacker can use a packet sniffer to collect advertising data from all nearby devices, including authorized mobile devices. The authorized mobile devices are outside the authorized zone of any PEPS system. The attacker can set the radio transmit power to a similar transmit power as the mobile device, usually a smartphone, which can be easily characterized by the attacker. After setting the transmit power, the attacker moves to an authorized zone outside the PEPS system, usually an exterior door. The attacker can then clone the advertising data and inject it into the PEPS system. Depending on the sophistication of the protection built into the PEPS system, the attacker can also use active interference modes to prevent the PEPS system from correctly receiving the original advertising packets.

[0066] Previous BLE chipset and software stack implementations are not configured to detect this type of advertising data injection, and no part of the BLE specification guarantees a deterministic arrival time for advertising data. Without timing synchronization between each of the sensors, there is no way to guarantee that each sensor is measuring the same signal, leaving the system dangerously open to cloning, jamming, and injection attacks.

[0067] In contrast, the present disclosure provides a PEPS system 1 that enables sensors 31 to follow connected data between authorized mobile devices 10 and communication gateways 29 to make measurements on communication signals and verify that the measured data is not being injected by an attacker. Many injection prevention techniques are applicable to advertising data. However, the present disclosure provides a more secure and energy-efficient PEPS system 1 by eliminating the need for mobile devices 10 to advertise. This allows each sensor to measure signals with known expected values ​​at arrival times and frequency channels, enabling sensors 31 to find and track existing connection data, thereby ensuring that all sensors 31 are measuring the same signals. In this way, the PEPS system 1 of the present disclosure shares information with each sensor 31 about the existing connection between the mobile device 10 and the communication gateway 29. In this way, each sensor 31 can find the existing communication connection between the mobile device 10 and the communication gateway 29, begin tracking the communication connection, and maintain accurate timing using the communication connection. The PEPS system 1 of the present disclosure also allows each of the sensors 31 to verify that an attacker is not attempting to inject data into the system. The same anti-injection techniques are applicable to advertising systems, such as those described in U.S. Patent Application Publication No. 2014 / 0188348. Furthermore, while many of the anti-injection techniques of the present disclosure apply to advertising data, timing-related anti-injection techniques require deterministic timing that only connection data can provide.

[0068] In a traditional BLE PEPS system, an attacker could clone advertising packets from authorized mobile devices and inject them into the PEPS system. Each BLE packet has a header consisting of a preamble and an access address, a data section consisting of a data header and data payload, and a CRC. An attacker can observe all of this information and clone all of the data. Immediately after receiving all the data from a packet, the attacker replays an exact copy of the data on the same frequency channel into the PEPS system by modulating the physical location or transmit power, causing the sensor to read the injected measurement. To protect against this, the PEPS system must detect the presence of two copies of the same or similar data within an expected time window to determine that it is under attack. Either the sensor itself or the extended PEPS system can inspect any part of the packet, or a mathematical derivation, for a duplicate that matches the attack pattern. The most useful information is the channel number on which the data was received, the synchronization timestamp for the entire PEPS system, and the access address of the connected data.

[0069] The attacker does not need to know which of the potentially multiple nearby advertising devices is an authorized mobile device. Rather, the attacker can clone all copies of the advertising data from all nearby devices. A slightly more sophisticated hacker might be able to perform cloning on all three advertising channels simultaneously. This technique might ensure that if an authorized mobile device is found, the data is successfully cloned and injected.

[0070] Furthermore, a more sophisticated hacker could force a legacy PEPS system to reject the original packet by ensuring that the injected packet is the only valid packet observed. BLE chipsets and stacks reject all messages that do not have a valid CRC. An attacker could clone all data in the packet to the end of the data section. The attacker could then use prior knowledge of the packet length or decode the packet length using information in the data header to calculate the time when the last data byte is received. All usable data up to the CRC could then be received by the attacker. The attacker could then use onboard processing to calculate the correct CRC for the message and send a signal to the physical channel that causes the checksum to be corrupted. The legacy PEPS system could then receive the message in a corrupted form. Immediately after the CRC is transmitted by an authorized mobile device and corrupted by the attacker, the attacker can reconstruct the packet using the cloned data by calculating the checksum and inserting it into the packet. The reconstructed packet can then be injected into a legacy PEPS system.

[0071] Typically, the BLE protocol stack discards messages with invalid CRC fields and does not report this information to upper-level applications. For a BLE PEPS system to protect itself from the above type of attack, the BLE protocol stack must be modified to report messages even if the CRC is invalid. In other words, messages that are normally discarded by the BLE protocol stack must be made available to the PEPS system for processing. In particular, the application must detect the presence of two messages with the same payload within a certain time window, even though the CRC of the first packet is invalid. The PEPS system can then determine that the system has been attacked by the attempted injection.

[0072] Furthermore, even if a BLE PEPS system includes sensors with a modified BLE protocol stack to detect corrupted messages and can protect itself by processing injected data as described above, the BLE PEPS system may still be susceptible to a radio frequency (RF) isolation attack. In an RF isolation attack, an attacker RF isolates sensors located outside the vehicle. For example, a simple RF-isolated box with an outer antenna for cloning advertisements and an inner antenna for injecting advertising signals into the sensors can be used to disable the modified BLE protocol stack and enable data injection into the sensors and the PEPS system.

[0073] Two techniques are required for a PEPS system to protect itself from RF isolation attacks. The first technique utilizes highly accurate timing expectations regarding signal arrival times, so that the PEPS system has a timing synchronization method to ensure that the PEPS system has a way to verify the arrival time of the incoming signal from each sensor and compare the actual arrival time of the incoming signal with the expected arrival time. A global timing discrepancy across all sensors indicates that data has been cloned or injected. If sensors are grouped into two or more different sets based on arrival time, a discrepancy indicates that an attacker has isolated the sensors to prevent them from receiving the true signal and then injected cloned copies.

[0074] This disclosure provides methods for detecting and mitigating the risk of injection attacks. For example, FIG. 5 illustrates how a sensor might observe when subjected to various types of physical layer attacks. In FIG. 5, the horizontal axis represents time, and tick marks 510A-510F represent expected protocol intervals for data from authorized mobile devices. Protocol timing 510A-510F for BLE communications is either the expected advertising interval of an authorized mobile device or the connection interval and slave latency parameters for connections between mobile devices and communication gateways in a PEPS system. In FIG. 5, the vertical axis represents the signal strength received by the sensor from an attacker and the signal strength received from authorized mobile devices.

[0075] For illustrative purposes, a stronger RSSI value received by the sensor authorizes the PEPS system to perform vehicle functions. For an attacker to successfully launch an attack against the PEPS system, the attacker must inject an RSSI value that is stronger than some configurable decision threshold 551. The attacker launches the attack by observing communications 530 and cloning the data. The attacker then replays data to the PEPS system with the appropriate signal strength 520 that meets or exceeds the decision criterion 551.

[0076] Continuing with FIG. 5, time interval 510A corresponds to a high-precision measurement from an approved mobile device. The key feature is that only one sampled measurement 530A occurs within the expected tolerance of scale 510A. The PEPS system determines measurement point 530A as a valid measurement for further processing because no suspicious data was observed on the BLE physical layer.

[0077] During time interval 510B, an attacker attempts to clone and inject data contained in packet 530B at 520B. The sensor and subsequent security filtering module 33, described in detail below with reference to FIGS. 6 and 7, can detect the data injection using one or more techniques described below. First, the security filtering module can count the number of packets deemed to have originated from an authorized mobile device and compare this number to the maximum number of packets permitted by the protocol from a mobile device. In this technique, two measurement points 520B and 530B are deemed to have originated from an authorized mobile device during time interval 510B, even though the protocol permits only one, until the next expected arrival time at tick mark 510C. Second, the security filtering module can measure the variance, or its mathematical equivalent, over any given time window and compare it to a configurable threshold to ensure that the variance is within a bounded range expected from an authorized mobile device. During time interval 510B, the calculated variance 552 can be determined to be too high. It should be noted that the distribution and packet counting techniques described herein are equally suitable for applications over multiple time intervals.

[0078] Continuing with FIG. 5 , an attacker in time interval 510C attempts to inject cloned packet 520C into the PEPS system by cloning 530C up to the CRC and then disrupting the sensor's ability to correctly receive the CRC. The sensor may implement special BLE protocol stack software processing for received packets 530C with invalid checksums so that the sensor and security filtering module 33 can count corrupted data 530C in its counting algorithm, as previously described. Thus, in time interval 510C, two deemed packets 520C and 530C are detected, while the protocol allows only one packet originating from an authorized mobile device during the same interval, allowing the PEPS system to determine that some data has been injected. Furthermore, the special BLE protocol stack processing for corrupted packets is equally applicable to other processing techniques, such as inclusion in distributed measurements or timing analysis.

[0079] An attacker in time interval 510D attempts to inject clone packet 520D into the sensor by placing an RF isolator around the sensor, preventing the sensor from receiving packet 530D. This attack circumvents the two previously mentioned techniques of counting the number of packets in a time window, comparing it to the maximum number allowed by the protocol, and checking the variance, which would be out of range if only authorized mobile devices were generating the signal. The sensor receives only one packet 520D during time interval 510D. The sensor and security filtering module 33 can detect this data injection by measuring the time the data was received and comparing it to the protocol timing. The difference between the expected arrival time, indicated by tick mark 510D, and the actual arrival time of packet 520D is shown as 550. Sensors in a PEPS system require a synchronization method to accurately measure time interval 550. Synchronization methods are described in more detail below.

[0080] Note also that time interval 550 represents a negative quantity if the injected data arrives before the expected protocol timing 510D. This is shown in time interval 510E. In situations where an attacker can predict the value contained in 530E and inject it early as 520E, or in situations where the attacker performs a man-in-the-middle (MITM) attack by adding a time delay by moving tick mark 510E after recognizing data from an authorized mobile device, the attacker can inject 520E into the PEPS system before relaying data 530E to the system. To detect this type of attack, sensors can be configured to scan packets preceding the expected arrival time 510E for data that may have originated from an authorized mobile device that will ultimately be injected early into the system. In general, the workload of pre-scanning all 37 available connection channels provided by BLE makes it difficult for BLE devices to detect the presence of a relaying MITM attacker gating messages while maintaining a communication link. However, in a PEPS system with multiple sensors, each sensor can be configured to search a different channel for data from the mobile device to the attacker. Furthermore, it's worth noting that an attacker acting as a MITM won't generate packet 520E that's exactly equivalent to a packet originating from a mobile device like 530E. In particular, the FHSS channel number will be different, and the access address for that connection may also be different. What needs to be searched is the address in each packet that corresponds to the mobile device and / or the PEPS system itself.

[0081] While the above discussion describes the types of measurements a single sensor can make to detect data injection attacks, FIG. 6 illustrates how the security filtering module 33, described in detail below, operates to examine data from multiple sensors looking for more sophisticated types of injections where an attacker successfully compromises a sensor or collection of sensors. Referring to FIG. 6, the horizontal axis of the chart represents time, and the vertical axis represents measured signal values. In the example of FIG. 6, the vertical axis represents RSSI. Each tick mark 510A-510F represents the expected arrival time of each data sample in the PEPS system. The chart includes data 520A-520D received from a sensor referred to as Sensor A and data 530A-530D received from a sensor referred to as Sensor B. It is assumed that values ​​520A-520F all satisfy a condition (not shown) that an authorized mobile device is considered to be located within an area where location-based functionality should be enabled. The security filtering module 33 can use data generated by other sensors, such as sensor B, to verify whether the sensors have values ​​within the valid range represented by lines 580, 581. If any of the alternate sensors, such as sensor B, samples measurements 530A-530F that are inconsistent with the expected measurements 520A-520F, the security filtering module 33 can report to the PEPS system that the current measurements indicate that the portable device should not be granted access to vehicle functions.

[0082] Continuing with reference to FIG. 6 , time interval 510A corresponds to an example of valid data. Data point 530A falls between boundaries 580 and 581. In time interval 510B, an attacker injected a sample into sensor A but with a time delay relative to sensor B. Security filtering module 33 compares the arrival times of 520B and 530B, and a difference 585 between the receipt times is calculated and compared to a configurable threshold. If difference 585 is not within certain system performance and measurement error limits, security filtering module 33 can detect that data has been injected into the system. In time interval 510C, an attacker injected data into sensor B prior to reference sensor A. The same time boundary principles applied to time interval 510B can be applied to time interval 510C. If points 530C and 520C do not match beyond the system's measurement capabilities and difference 586 is not within system performance and measurement error limits, security filtering module 33 can detect that data has been injected into the system.

[0083] Continuing with reference to FIG. 6 , assuming an attacker can inject data 520D into sensor A during time interval 510D without affecting the timing, security filtering module 33 can use measurement data 530D from sensor B to verify whether 520D is likely injected data. In the example of FIG. 6 , data point 530D is considered too weak because it is weaker than threshold 581. Security filtering module 33 determines that either point 520D or point 530D is injected because the two points do not correlate to valid data points. In one embodiment, valid reference 520D is received and the conditional probability of observing 530D is checked given measurement 520D. If the conditional probability is compared to a configurable confidence level, such as a mapping to RSSI lines 580 / 581, security filtering module 33 can determine that points 530D and 520D do not corroborate each other and that either 520D or 530D is invalid injected data.

[0084] Continuing to refer to FIG. 6, assume that an attacker is able to inject data 520E into sensor A during time interval 510E without affecting the timing, and that sensor B measures value 530E that corroborates 520E. Sensors A and B are configured to report data contained in packets 521 and 531. If data 521 and 531 are not exactly the same, security filtering module 33 can determine that some data has been injected into the system. Additionally or alternatively, to reduce the amount of data transferred between each sensor and security filtering module 33, for example, hashes 522 and 532 of the data contained in the packets, e.g., hashes using the SHA-256 cryptographic hashing algorithm, can be transferred from each sensor to security filtering module 33. If hashes 522 and 532 do not exactly match, security filtering module 33 is configured to determine that data has been injected into the system.

[0085] 7 illustrates a PEPS system 1 employing a PHY controller 600 capable of receiving BLE signals at an antenna 601 of a sensor 31 and passing measurement information about the packets to a security filtering module 33. The security filtering module 33, described above in connection with FIGS. 5 and 6, searches for violations of the physical layer and protocol, as described above, and filters and communicates the data accordingly to the sensor processing and location module 32. The security filtering module 33 is configured to flag the injected data so that the sensor processing and location module 32 can discard the data and alert the PEPS system. The data from the sensor processing and location module 32 is communicated to the PEPS module 27, which is configured to read vehicle state information from multiple sensors to detect a user's intent to access a function and compare the location of the mobile device 10 to a set of locations that authorize certain vehicle functions, such as unlocking the vehicle doors or trunk and / or starting the vehicle.

[0086] 7 , a prerequisite for the PHY controller 600 to collect data and measure RSSI from the mobile device 10 is a secure communication link 680, such as a secure BLE communication link, between the mobile device 10 and the communication gateway 29. The communication gateway 29 is configured to share information about the secure communication link 680 between the communication gateway 29 and the mobile device 10 with the connection information distribution module 24. The connection information distribution module 24 is configured to distribute information about the secure communication link 680 so that it can be tracked by multiple physical layer controllers 600. The physical layer controller 600 is a component of the BLE chipset 41 in the sensor 31. The connection information distribution module 24 can be, for example, any wiring in a vehicle communication network, such as a local interconnect network (LIN) or a controller area network (CAN). However, other communication connections or buses can also be used.

[0087] 7 , the communications gateway 29 is configured to share with the timing control module 25 information regarding current timing information for the secure communications link 680 between the communications gateway 29 and the mobile device 10. The timing control module 25 is configured to broadcast the current timing information to multiple sensors 31. Additionally or alternatively, in embodiments in which advertising data from the mobile device 10 is collected by the sensors 31, the communications gateway 29 is configured to share timing pulses with each sensor 31. In such cases, the sensors 31 are configured to accept timing information from the communications gateway 29 and record incoming data packets relative to the timing pulses. The sensors 31 report time-stamped data to the security filtering module 33, which can be established within the accuracy limits of the timing system if packets between the sensors are received simultaneously as described in detail above.

[0088] Continuing with reference to Figure 7, the timing control module 25 is configured to exchange data as described below with reference to Figure 8. The information described with reference to Figure 8 is sufficient for the sensor 31 to find and track existing secure communication links 680, provided the sensor 31 is synchronized with the communication gateway 29.

[0089] Referring to FIG. 8 , the communication gateway 29 can forward information shown as 1200 to 1290 to all sensors 31. The communication gateway includes a channel map 1200, a channel hop interval 1210, a slave latency 1220, a next channel 1230, a next channel time 1240, a clock precision 1250, filtering data 1260, channel pre-scan parameters 1270, channel post-scan parameters 1280, and connection monitoring parameters 1290. The channel map 1200 informs the sensors 31 which of the 37 connection channels and the 3 advertising channels should be observed. The channel map 1200 conveys parameters that specify how the next channel is calculated. For example, in BLE, this is a simple incrementer. The channel hop interval 1210 corresponds to the connection interval defined in the BLE specification. The channel hop interval 1210 tells each of the sensors 31 how long to wait before beginning the observation process for the next channel, and is used to inform the security filtering module 33 and the sensors 31 of the expected arrival time of the next packet. The slave wait time 1220 tells the sensors how many time intervals, as defined by the channel hop interval 1210, the device being observed is allowed to skip communications. Typically, this value is zero while locating the mobile device 10. The next channel 1230 tells the sensors 31 the channel in the channel map 1200 on which the next observation should be made. The next channel time 1240 tells the sensors 31 at what time in the future they should make an observation on the next channel 1230. The clock accuracy 1250 of the devices in the system, including the mobile device 10, is used by the sensors 31 to calculate the time to start observation, correcting for uncertainties in the system's measurement capabilities and the timing of each device's transmission. Once the sensor 31 receives the information 1200, 1210, 1220, 1230, 1240, and 1250, the sensor can use the information to find the secure communication link 680 and begin tracking the connection.The filtering data 1260 informs each of the sensors 31 how to filter data received in packets. The filtering data may include an expected access identifier for the connection. The filtering data may also include information indicating the minimum length of the packet or whether the packet contains encrypted data. The filtering data also instructs the sensors which aspects of the packet to measure, such as RSSI, timestamps, time difference from the nominal expected arrival time, channel number, whether the CRC is correct, data within the frame, and a hash of any portion of the message that can be filtered and reported to the security filtering module 610, among others. The channel pre-scan parameters 1270 inform the sensors 31 how to observe the channel for MITM attacker data and injection data prior to the next observation and prior to a request for observation over the secure communication link 680. A simple example of a pre-scan parameter may be information indicating that the sensor 31 can make early observations on the expected channel looking for pre-injection data. Another example is information indicating that the sensor 40 can observe randomly selected channels whenever it is not required to make observations on the secure communication link 680 looking for packets matching a MITM attack. The channel post-scan parameters 1280 inform the sensor how to observe channels looking for MITM attacker data and injected data after completing observations and prior to making observations on the secure communication link 680. The connection monitoring parameters 1290 include, for example, a link monitoring timeout defined by the Bluetooth specification. The connection monitoring parameters 1290 enable the sensor 31 to determine that a connection should no longer be tracked because it has failed.

[0090] The operation of the PEPS system 1 will be described with reference to FIG. 9. In the example of FIG. 9, the mobile device 10 is configured as a BLE peripheral. However, the system would function similarly if the mobile device were instead configured as a BLE central. During process 1010, the mobile device 10 continues advertising 1020, as defined by the BLE specification, until a connection is established with the communication gateway 29 in accordance with the Bluetooth specification. During process 1011, the communication gateway 29 performs a scan for the mobile device 10, as defined by the Bluetooth specification. Once the communication gateway 29 discovers the mobile device 10, it sends a link request 1021 to the mobile device 10 in accordance with the method defined by the Bluetooth specification. Once a connection between the communication gateway 29 and the mobile device 10 is established, the advertising 1010 and scanning 1011 processes can be completed in accordance with the Bluetooth specification.

[0091] After the communication link is established, the communication gateway 29 initiates process 1013, and the mobile device 10 initiates process 1012, to maintain the link in accordance with the Bluetooth specification. After the communication link is established, the communication gateway 29 recognizes all connection parameters of the communication link and exchanges connection parameter information with the connection information distribution module 24 using message 1040. The vehicle interface 45 receives the connection parameter information and passes the information to the BLE chipset 41 of the sensor 31. The communication gateway 29 communicates a timing information message 1041 to the timing control module 25. The sensor 31 receives the timing information message 1041 via the vehicle interface 45. The timing synchronization module 44 in the sensor 31 receives the timing information message 1041. The timing control module 25 is configured to transmit a message with signal 1041 containing the time to the next event, measured relative to the message itself. The timing synchronization module 44 can accurately timestamp incoming messages to the vehicle interface 45 and control the BLE chipset 41 to observe the required channels according to the connection parameters.

[0092] Continuing to refer to FIG. 9, the sensor 31 executes a process 1014 to receive incoming connection information 1040 and timing signals 1041. The sensor 31 uses the channel map reconstruction module 42 to regenerate a connection information schedule table. An example of the connection information schedule table is shown in FIG. 10, which is described in detail below. The sensor 31 sets a time reference to the timing signals 1041 and learns the time and channel of the next connection event to observe in the connection information message 1040. Thus, the sensor 31 can calculate the time 1060 until the next connection event. The calculation of the time window 1060 is corrected for the accuracy of synchronization through the timing control module 25 and the clock error of each device. The sensor 31 waits for the calculated time 1060 before starting observation 1015A of the central-to-peripheral communication 1050 and the peripheral-to-master communication 1050B. The sensor 31 is configured to measure the received energy strength of each of the transmissions 1050A and 1050B. Other parameters the sensor 31 may be configured to measure include: (1) the data in each transmission 1050A and 1050B; (2) a mathematical derivation of the data, such as a hash function, e.g., SHA256; (3) the arrival time of 1050A and 1050B; (4) the arrival time difference between 1050A and 1050B; and (5) the arrival phase angle and phase angle of each 1050A and 1050B. The scan width of 1015A is defined by the timing uncertainty involved, as well as the behavior of pre-scan and post-scan. Pre-scan and post-scan are important to ensure that an attacker is not present within the system's uncertainty window. Information collected during observation 1015A is passed to the sensor processing and location module 32 via the security filtering module 33. The sensor 31 then waits a connection interval time 1061A until the next connection event. The connection interval time 1060A-B is calculated to account for clock accuracy, synchronization error, and pre-scan and post-scan parameters, which affect the next activation time. After the connection interval time 1061A has elapsed, the sensor 31 begins observing 1015B the next channel in the playback channel map.The process repeats indefinitely until the connection is lost or a command from the timing control module 25 instructs the sensor 31 to stop tracking the communication link.

[0093] Referring to FIG. 11, the process by which the sensor 31 synchronizes timing with the communication gateway 29 is shown. The figure shows two connection events 1050A1 / 1050B1 and 1050A2 / 1050B2. The communication gateway 29 is configured to output timing signals 1075A1 / 1075A2 at each connection event. FIG. 11 shows timing signals 1075A1 / 1075A2 coincident with communication 1050A1 / 1050A2 from the BLE central to the BLE peripheral. Additionally or alternatively, the communication gateway 29 can be configured to output timing pulses during communication from the BLE peripheral to the BLE central, i.e., timing signals 1050B1 / 1050B2. The timing control module 25 is responsible for receiving the timing signals 1075A1 / 1075A2. For example, the communication gateway 29 can output the timing signal 1075A1 / 1075A2 as an output pulse on one of the digital pins of the BLE chipset 41, and the timing control module 25 can receive the pulse as an edge interrupt using a high-speed clock and timer to generate a timestamp. At a later point in time, the timing control module 25 can communicate to the sensor 31 via message 1076. The time 1081 elapsed from the timing signal 1075A1 to the transmission of the message 1076 is packed into the message 1076. The sensor 31 receives the message 1076 on the vehicle interface 45. The sensor 31 also has a high-speed clock and a running timer, and records the time the message 1076 was received. The sensor 31 extracts the elapsed time 1081 from the message 1076 and subtracts this value from the connection interval 1080 to calculate the time until the next connection event 1082. As described above with reference to FIG. 9 , the connection interval 1080 was previously communicated to the sensor via message 1040. After calculating the time to the next connection event 1082, the sensor 31 also calculates the measurement uncertainty by combining the measurement uncertainty of the timing control module 25, the uncertainty of the arrival time of the BLE message based on the sleep clock accuracy of all devices, and the connection interval 1080.The sensor 31 adds the pre-scan parameter time to calculate a value 1083. The sensor 31 then calculates the future time to start observation by taking the time until the next connection event 1082 and subtracting 1083 from this value to determine the future time to start observation 1084. The sensor 31 uses a timer to start the observation process 1085 after the time 1084 has passed.

[0094] 12, the process by which the PEPS module 27 configures and controls the sensor network and commands multiple sensors 31 to start and / or stop following connections is shown. The PEPS module 27 detects 800 that a link should be followed and sends a message 801 to the communications gateway 29 indicating that the link should be followed. The communications gateway 29 then retrieves and sends the link information to the connectivity information distribution module 24. The connectivity information distribution module 24 uses the vehicle interface 45 to send the message to the sensors 31 of interest.

[0095] Referring again to FIGS. 1, 2, 3, and 9, the sensor 31 may include a channel map reconstruction module 42 configured to regenerate connection timing for the secure communication link 680 using the connection information signal 1040 and the timing signal 1041. FIG. 10 illustrates an example of a channel hopping map. In FIG. 10, for example, columns 1360-1363 from left to right represent time-incremental connection events. The time elapsed between each column is a connection interval, described as the channel hop interval 1210 described above with reference to FIG. 8. In this example, the channel hop interval 1210 is equal to the time elapsed between any two adjacent columns, such as columns 1360 and 1361. Note that the channel hop interval 1210 should be considered any deterministic process for determining future channel times and should not be limited by the static connection interval utilized by BLE. For example, the channel hop interval 1210 could include the deterministic pseudo-random channel hopping of classic Bluetooth. Each row 1300-1336 represents a channel number. Each channel 1300-1336 is one of the BLE channels defined by the Bluetooth specification and is 2 MHz wide. The example of FIG. 10 shows 37 channels, one for each of the connection channels. However, it should be understood that the system of the present disclosure can have the sensor 31 track any channel, which may be described with reference to the data contained in FIG. 8. The channel to be used is learned by the sensor 31 based on the channel map 1200 received by the sensor 40 in message 1040, described above with reference to FIG. 9. In the example shown in FIG. 10, the channel represented by row 1335 is not used. Furthermore, the black boxes denoted by 1351-1353 represent associations for the PHY controller 600 of the BLE chipset 41 in the sensor 31 to observe the channels associated by rows 1300-1336 at the times associated by the columns. It is not necessary for the message 1040 to include all channels and times for the channel map reconstruction module 42.The channel map reconstruction module 42 accepts inputs required by the BLE peripheral to generate a connection event schedule map according to the Bluetooth specification, as well as the next channel 1230 to communicate on, exemplified as channel 1303, to synchronize the sensor's current time reference with that of the connection. This channel is set to index 0 1360 in the map. The channel map 1200 includes a deterministic channel hopping scheme. In BLE, the channel hopping scheme is a simple incrementer defined by the BLE specification as a "hop increment." As illustrated in FIG. 10, the hop increment is 5, which represents the amount by which the current channel is incremented in each connection interval. For example, in FIG. 10, when the time is incremented by one connection interval from 1360 to 1361, the channel is advanced by 5 from 1352 to 1353. The BLE channel hopping scheme defined by the Bluetooth specification includes a modulus operation that allows the channel index to cycle from the bottom of the table, as shown in time interval 1362. The channel hopping scheme also allows for empty channel 1335 to be skipped. For example, as shown in FIG. 10, channel 1335 is skipped at point 1350, and channel 1336 is sampled instead at point 1351. The channel with index 35 1335 is unused. The BLE specification provides methods for remapping, for example, as described in Section 4.5.8.2. Channel Selection of the Low Energy Link Layer Specification Version 4.2.

[0096] 8, 9, and 10, channel pre-scan parameters 1270 and channel post-scan parameters 1280 describe the behavior of the PHY controller 600 during the time intervals between the time windows represented by the columns in FIG. 10. To accommodate the uncertainty in both the measurement and transmission times of each device in the system, clock precision 1250 allows the BLE chipset 41 to spread out the time intervals for each of the black boxes 1351-1353. Initially, the sensor 31 is not synchronized to the secure communication link 680. Upon receiving the timing signal 1041, next channel 1230, and next channel time 1240, the sensor 31 synchronizes its time reference with the connection and has sufficient information to determine the future time of the communication measured by the sensor 31 at next channel time 1240 relative to the timing of the secure communication link 680.

[0097] With reference to FIG. 13, an authentication method is described. The authentication method is triggered by a user action detected by the vehicle 30 described in FIGS. 1 and 2. For example, the PEPS module 27 detects a user action, such as grabbing a door handle or pressing a button, as commonly found in modern vehicles. In the example of FIG. 1, the PEPS module 27 includes the link authentication module 22. Alternatively, the PEPS module 27 and the link authentication module 22 can be implemented as separate modules, as shown in FIG. 2. Additionally or alternatively, all of the described signals can be routed to the communications gateway 29, allowing for alternative configurations. The PEPS module 27 must make a decision regarding secure access to functionality based on the location of the mobile device 10 and security information the mobile device 10 can provide. For example, a challenge / response procedure can be used, similar to current PEPS systems implemented using LF and RF systems.

[0098] Continuing with FIG. 13 , the PEPS module 27 detects an intent to access vehicle functions via a sensor. The PEPS module 27 then maps the request to a zone ID and sends a request 1700 to the processing and location module 32 to determine whether any mobile devices 10 are within the vehicle 30's zone ID. The processing and location module 32 responds to the PEPS module 27 with a response 1701 indicating a list of mobile devices located in the area corresponding to the zone ID and potentially accessing vehicle functions. In 1702, the PEPS module 27 checks the list of mobile devices to determine whether the mobile device is paired with the system. For each valid mobile device, a set of encryption information for that mobile device is retrieved. This is referred to as an encryption key, such as a commonly used Advanced Encryption Standard (AES) encryption key. Additionally or alternatively, a counter value can be implemented using an asymmetric public / private key. In 1703, the PEPS module 27 obtains the current vehicle location (coordinates) in latitude / longitude from the telematics module 26. The location may include an error range based on the vehicle system's current measurement accuracy. PEPS module 27 then embeds the vehicle's 30's latitude and longitude into the message and encrypts the challenge message at 1704 using the security information retrieved at 1702. The challenge data generated at 1704 is forwarded to communications gateway 29 at 1705. Communications gateway 29 then transmits it to mobile device 10 at 1706 using BLE. An application running on mobile device 10 decrypts the challenge message at 1707. The application running on mobile device 10 obtains the mobile device's 10's latitude and longitude location coordinates, along with optional location accuracy information, at 1708. The application running on mobile device 10 then performs a mathematical operation at 1709 on the mobile device's coordinates received at 1708 and the vehicle's 30 coordinates received from communications gateway 29 (and sent at 1703). The mathematical operation at 1709 is known as the challenge response.An example of the mathematical operation at 1709 may be calculating the distance between two coordinates. Another example of the mathematical operation at 1709 is calculating the exclusive OR (XOR) of the two sets of coordinates shown at 1703 and 1708. Yet another example of the mathematical operation at 1709 is calculating the direction from the vehicle's coordinates from 1703 to the mobile device's coordinates from 1708. Once the value from the mathematical operation at 1709 is obtained, the application running on the mobile device 10 then packs the mobile device's 10 coordinate information from 1708 and the value of the mathematical operation at 1709 into a message and encrypts the packet at 1710 using a key necessary for communication with the communication gateway 29. The mobile device 10 then transmits the encrypted message from 1710 to the communication gateway 29 using BLE at 1711. The communication gateway 29 receives the encrypted message from 1710 at 1711. At 1712, communications gateway 29 forwards the encrypted message from 1710 to PEPS module 27. At 1713, PEPS module 27 decrypts the encrypted message from 1710 using a key that matches the communication from mobile device 10. PEPS module 27 then extracts the coordinates of mobile device 10 from 1708 and the mobile device's calculated challenge response from 1709, and calculates the same mathematical operation on the coordinates from 1703 and 1708. The result of that operation is then compared to what is included in the encrypted message, referred to as the challenge response, at step 1714. PEPS module 27 then compares the challenge response to a pass criterion at 1715. For example, the pass criterion could indicate that the value must be less than a certain threshold or within a certain acceptable range.

[0099] The vulnerability of advertising-based systems is primarily caused by two factors. First, BLE's advertising channel is designed to be easily predictable and easily discoverable, allowing any BLE device to discover nearby advertisers and copy and imitate data without special software. Second, the advertising channel implements inherent jitter to avoid message collisions, making it difficult to build a system that can verify the authenticity of advertising packets by reception time without special modifications to the system, which is not covered by the BLE specification. Advertising packets may contain special application-specific security information, but the loose tolerance for the expected arrival time of advertising data depends only on the required cryptographic techniques.

[0100] The present disclosure provides a method for accurately conveying timing information from the communications gateway 29 to the sensors 31, and provides a security filtering module 33 that determines the cross-correlation of signal timing and sensor values ​​to verify whether an injection scenario is likely occurring. While the present disclosure uses the example of connection data, the security filtering module 33 of the present disclosure is equally applicable for use in verifying the timing of advertising data.

[0101] The aforementioned U.S. Patent Application Publication No. 2014 / 0188348 describes a method using connection data in which a mobile device connects to each sensor individually. This design has several inherent drawbacks. For example, there are significant requirements placed on the mobile device to form and maintain connections with multiple sensors. For example, there may be an excess of sensors in the network for the mobile device to connect to each, requiring additional communication and processing time.

[0102] Referring again to Figure 1, the PEPS system 1 of the present disclosure includes a vehicle 30 and a mobile device 10. The mobile device is a Bluetooth-enabled device capable of supporting the BLE protocol. Bluetooth technical specifications are developed and published by the Bluetooth Special Interest Group (SIG).

[0103] The mobile device 10 may be any Bluetooth-enabled communication device, such as, but not limited to, a smartphone, smartwatch, wearable electronic device, key fob, tablet, etc. The mobile device 10 may incorporate other wireless technologies, such as WiFi or impulse radio, that can be used to communicate with the vehicle 30. While this disclosure provides an example using Bluetooth communication, the disclosed system, method, and architecture may be implemented using other applicable communication protocols, other authentication systems or methods, or other fine-grained localization. Thus, the disclosed system, method, and architecture is not limited to the BLE communication protocol. Furthermore, the disclosed system, method, and architecture is applicable to any communication protocol using frequency-hopping spread spectrum (FHSS), where the communication gateway 29 can share with the sensor 31 the information necessary to reconstruct the channel map and timing information.

[0104] The vehicle 30 includes a set of modules 20, either as a single controller or distributed throughout the vehicle 30, and multiple sensors 31 that can communicate with the control module 20 wirelessly via Bluetooth or via traditional vehicle wired connections, such as a Local Interconnect Network (LIN) or Controller Area Network (CAN). The vehicle 30 can learn its current location and position error via a telematics module 26 that implements either GPS, an inertial navigation system, GSM signal location, or the like. Vehicle information is collected by the data management layer 23 and can be shared with the mobile device 10. Data can include the current latitude / longitude of the vehicle 30, as well as a measure of the current location uncertainty for each link session.

[0105] The communication gateway 29 includes a BLE chipset 21 and a link authentication module 22. The link authentication module 22 can authenticate that the mobile device 10 is the same device that was previously paired with the communication gateway 29. The pairing process and authentication method are specified by the Bluetooth Special Interest Group (SIG).

[0106] The BLE chipset 21 can use the antenna 19 to generate and receive signals that comply with the Bluetooth specification.

[0107] Each sensor 31 includes a BLE chipset 41 capable of generating and receiving signals compliant with the Bluetooth specification using an antenna 43. The BLE chipset 41 includes a channel map reconstruction module 42 that can reconstruct the channel map of an existing connection between the mobile device 10 and the communication gateway 29 using FHSS information received from the vehicle module 20 over the vehicle interface 45. All BLE chipsets 41 implement the precise timing required to track BLE connections and tune to the correct frequency, but cannot tune to connections that are unsynchronized or have lost synchronization. The sensor 31 includes a timing synchronization module 44 that can receive timing signals from the timing control module 25. The timing control module 25 keeps the sensors synchronized with the connection interval of the communication between the communication gateway 29 and the mobile device 10.

[0108] The communication gateway 29 and the mobile device 10 establish a connection governed by the Bluetooth Core specification, with one device advertising and the other scanning. After communication is established, both the communication gateway 29 and the mobile device 10 must adhere to the channel map and channel hopping scheme agreed upon by the devices at the time the communication link is established. FIG. 10 shows an example channel hopping map for illustrative purposes. The channel hopping map contains all the information necessary for the communication gateway 29 and the mobile device 10 to communicate with each other on the correct frequency channel at the correct time in the future. While it is possible for an observer to estimate the channel hopping map, in most practical applications, the channel hopping map is considered private and specific to that particular communication. Using the example BLE channel map, under the Bluetooth specification, a unique number known as an access identifier is assigned to identify the link. The disclosed system, method, and architecture are intended to broadcast the channel hopping map to sensors 31 in a network so that each sensor 31 can comply with FHSS communication. In this manner, the systems, methods and architectures of the present disclosure can be generalized to any FHSS protocol.

[0109] After a link between the mobile device 10 and the communication gateway 29 is established, the link authentication module 22 can establish the authenticity of the link. The Bluetooth SIG defines how the link is secured by checking previously stored security information exchanged between the vehicle 30 and the mobile device 10. The link authentication module 22 may require additional information other than that defined by the Bluetooth SIG to authenticate the link. In embodiments, only the link authentication method specified by the Bluetooth SIG may be used, or additional security mechanisms may be used. This disclosure is not limited to the particular method by which the link is authenticated. After link authentication is established, the data management layer 23 collects the current location of the vehicle 30 from the telematics module 26 and shares that location with the mobile device 10. The mobile device 10 optionally includes a GPS module 14, such as those provided by the Apple iOS and Google Android operating systems. Application software 12 running on the mobile device 10 can compare the estimated relative location of the mobile device 10 with the vehicle 30. Based on the estimated location of the mobile device 10 relative to the vehicle 30, the mobile device 10 can send a signal to the communications gateway 29 requesting the vehicle to perform a predetermined action.

[0110] As mentioned above, previous systems use open advertising channels for RSSI measurements. However, these systems may be insecure because advertising data is communicated over public and easily detectable channels. Thus, injection attacks can be carried out using freely downloadable phone applications. Previous systems have not addressed obvious security vulnerabilities when using advertising data. Furthermore, using advertising data is very energy inefficient. In such systems, the key fob must securely communicate with a central node and exchange advertising data with multiple sensors. This results in many unnecessary transmissions and receptions, ultimately reducing the system's power performance. In some systems, multiple connections may be formed with each sensor. This situation also significantly increases the amount of transmission and reception required to initiate and maintain links with each sensor. While this primarily addresses advertising privacy and injection concerns, it is still highly inefficient and introduces new security risks because it does not disclose a method to prevent attacks by unauthorized connections to sensors to inject stronger signals.

[0111] This disclosure relates to providing passive eavesdropping capabilities to multiple vehicle sensors. The eavesdropping nature of sensors within a network offers many advantages for implementing a BLE PEPS system. For example, smartphones / key fobs only need to consume the energy necessary to securely communicate with a central communication gateway. There is no additional energy consumption required to communicate with each sensor separately. Furthermore, using a single communication channel significantly enhances security due to tight, well-understood timing constraints, protocol checksums, and so on. An attacker cannot inject tampered data into an existing link without interfering with the link. For example, it is very difficult for an attacker to know in advance what data will be exchanged until the data is observed. An attacker only knows the channel and timing. Injecting a signal into that channel would likely interfere with the BLE protocol and lead to errors, most likely CRC / checksum errors, which would result in packets being discarded and no measurements being taken. Furthermore, the use of advertising data can be considered a privacy concern. For example, if smartphones were constantly advertising, someone with a large sensor network could easily track where the smartphone goes. Advantageously, smartphones are not required to advertise in order to use the PEPS system.

[0112] As described above, the systems, methods, and architectures of the present disclosure include a communication gateway 29, such as a BLE gateway. The communication gateway 29 may include any device capable of securely communicating with the mobile device 10, such as, for example, a smartphone, a tablet device, a key fob, a wearable device such as a smartwatch, or another BLE communication device. The communication gateway 29 may be integrated into, for example, a dedicated short-range communication (DSRC) module. Alternatively, the communication gateway 29 may be integrated into an LTE communication module. Communication data between the communication gateway 29 and the mobile device 10 is encrypted, known to be private, and signed, allowing the authenticity of the data to be determined (not forged). Communication data is securely replayed, for example, by using counter-based encryption, real-time token exchange, and / or timestamp information.

[0113] The mobile device 10 and communication gateway 29 establish a trust relationship through a pairing process. The pairing process can include Bluetooth pairing as described in the Bluetooth specification, pairing in which additional security information is exchanged between the vehicle system and the phone using the phone and vehicle interfaces, pairing in which device addresses, device ID resolution keys, reservation IDs, and encryption keys are exchanged via cloud infrastructure, and / or pairing in which a certificate for use with the vehicle is presented to the vehicle, the certificate being signed by the vehicle owner's device and / or a trusted security signing authority, such as the vehicle manufacturer or a trusted third party. In the case of a certificate, the certificate can include use case restrictions (e.g., geofencing, valet mode restrictions), validity period, whether reporting of driving performance / behavior to the owner is required, etc.

[0114] As described above, the systems, methods, and architectures of the present disclosure include one or more BLE sensors 31. Each sensor 31 can measure some physical phenomenon characteristic of a received BLE signal. For example, the sensor 31 can measure the RSSI, angle of arrival, time difference of arrival, or other characteristics of the received signal.

[0115] The sensor 31 may be located in or on the vehicle at a location where certain physical phenomena allow meaningful determinations to be made about the location of the mobile device 10 relative to the vehicle. For example, the physical phenomena may include free space signal loss, scattering, multipath fading, propagation time and propagation time differences, and differences in angle of arrival due to propagation.

[0116] Referring again to FIGS. 1 and 2 , each sensor 31 can communicate with the communication gateway 29. The mobile device 10 can communicate with the communication gateway 29 over an advertising channel or a connected channel, for example, as part of a BLE communication link. Each sensor 31 can passively eavesdrop on communications between two connected devices, such as the communication gateway 29 and the mobile device 10. Additionally or alternatively, in the case of a wearable device, eavesdropping can be between the mobile device 10 and a wearable device, such as a smartwatch, associated with the mobile device 10. Each sensor 31 can selectively disable eavesdropping, i.e., the procedure for tracking connections, to conserve power, and then re-enable it. The communication gateway can control which sensors 31 are eavesdropping.

[0117] Additionally, the communication gateway 29 can provide each sensor 31 with the necessary information to resume interception. The necessary information for interception can include, for example, an access identifier for the BLE communication link, which uniquely identifies communication between the communication gateway 29 and the mobile device 10. Each communication packet includes access identifier data as a preamble. Thus, the information can include information on how to decode the preamble. This information can also include a currently used channel map so that the sensor 31 knows the set of channels to use when intercepting. This information can also include information on a channel hopping scheme so that the sensor 31 knows how to jump from one channel to the next. Many wireless communication standards implement channel hopping that is deterministic when several basic parameters are known. In BLE, the sensor 31 needs to know the current channel, the channel map, and the channel hop number to determine the next channel to hop to. This information can also include information necessary to find a future connection event, such as the next communication channel and / or a future communication channel with an approximate time for the communication event.

[0118] Each sensor 31 can listen to the connection channel immediately before the connection event to collect the physical phenomena described above, i.e., RSSI, timestamp, angle of arrival, etc., as well as all the data contained in the communication packets of both the master and slave.

[0119] One consideration for connections in accordance with the disclosed systems, methods, and architectures is synchronization of schedule tables. Because all communication information required by two devices in the connection process is broadcast in a publicly observable format, any BLE communication node that happens to witness or overhear a connection being formed can obtain the schedule table and therefore scan for communications in a passive eavesdropping mode. However, having sensors constantly tracking all connections can result in significant power consumption. Thus, synchronization issues can arise if each sensor loses its ability to scan on the correct channel at the correct time, but it would be beneficial to have a system that can selectively enable or disable connection tracking. For these reasons, the disclosed systems, methods, and architectures utilize a synchronization algorithm to coordinate communications and overhearing communications by sensors 31.

[0120] For example, a message is sent from the communications gateway 29 to each of the sensors 31 that must begin tracking the communications connection. This message contains information needed by the sensors 31 to decode the communications packets, which in its simplest form may include sending an access identifier that identifies the link ID, which is a fairly robust unique ID for any given region. At some point prior to the request by the communications gateway 29, information about the link has been communicated or forwarded to the sensors 31. As noted above, this may include the channel map, channel hop count, connection interval, slave latency, as well as sleep clock precision settings for all devices.

[0121] Referring to Figure 14, the master and slave devices are shown communicating with a communication interval such as 100 ms. The devices use all channels and channel hop by 5 channels. The current, or starting, channel is channel 3. In the example of Figure 14, the slave latency is zero, so the slave always communicates.

[0122] At 1400, the communications gateway 29 issues a command to one or more sensors 31 to begin eavesdropping. The begin eavesdrop command contains all the information needed for the sensor 31 to begin scanning on the correct channel and follow the correct channel hopping scheme. Initially, the sensor 31 must start listening to the channel slightly early so that it can detect communications between devices, as shown at 1402. For subsequent connection events, such as at 1404 and 1406, the scan interval can be reduced to a shorter period based on the clock accuracy of all devices. The sensor 31 can share measured data about signals and connection events with the communications gateway 29, as shown at 1408, 1410, and 1412.

[0123] U.S. Patent No. 9,123,244, entitled "Vehicle Tracking of Personal Devices with Response System," issued September 1, 2015, describes a method for tracking an object via a system mounted on a motor vehicle. The method includes detecting a wireless device, determining a location of the wireless device, recognizing the location of the wireless device relative to the vehicle, analyzing the location of the wireless device with respect to predefined conditional statements, and issuing an alert pursuant to the predefined conditional statements being met. U.S. Patent No. 9,123,244 is incorporated herein by reference in its entirety.

[0124] No. 9,123,244 describes a system that can track devices in proximity to a phone and in proximity to a vehicle. The present disclosure extends the exemplary use cases described in U.S. Pat. No. 9,123,244 with the use of connections in accordance with the above-described systems, methods, and architectures.

[0125] The disclosure of U.S. Patent No. 9,123,244 describes the transfer of a digital key from a user's smartphone or key fob to a wearable device such as an activity monitor or smartwatch, i.e., a FitBit or Apple Watch. For example, in an example use of the system and method described in U.S. Patent No. 9,123,244, a driver arrives at a park in their car and wants to go jogging. The driver does not want to take their car keys or smartphone with them on the jog, but only their smartwatch. However, because the vehicle keys and smartphone are enabled as car keys, it is not safe to leave them in the vehicle. For example, if a burglar breaks into the vehicle, they could steal the entire vehicle.

[0126] The disclosure provides a way to temporarily disable the key so that it is safe to leave it in the vehicle until after the user returns from a jog, allowing the user to safely access the vehicle and re-enable the smartphone and key fob.

[0127] In the present disclosure, the systems, methods, and architectures of U.S. Patent No. 9,123,244 can be extended to allow key fobs (whether using BLE, LF, RF, etc.) to also be located near the phone. As such, the systems, methods, and architectures described in U.S. Patent No. 9,123,244 can be extended to include detecting when the phone is linked to a device such as a smartwatch or athletic equipment such as a FitBit, and making this information available to the vehicle's decision-making system.

[0128] For example, when the smartwatch returns after a jog, the phone can detect that the secure link with the smartwatch has been re-established. Reporting this information to the vehicle system is important for determining whether to allow the user into the vehicle after returning from a jog. Such information should include an indication of whether the link is secure / attached and whether the security data associated with the link can be verified.

[0129] The present disclosure provides additional features to the system described in U.S. Pat. No. 9,123,244, for example, to ensure that the tracking device is a trusted, non-attacker device. For example, the security information can include a personal identification number (PIN) that the user must enter into the watch when returning from a jog, entering the vehicle, and disabling the system. As a further example, the security information can also include secure pairing information between the smartphone and the watch, i.e., the watch and phone encrypt their link so that the phone can trust the watch to be an authorized watch. For example, existing smartwatches include systems for encrypting the communication link with the phone for sensitive data exchanged between the watch and phone. Once a security layer is achieved between the smartphone's operating system (OS) and the smartwatch, this is reported to the vehicle for use in trusting that the tracked device is a trusted device. The security information can also include a token that the smartphone shares with an application running on the smartwatch. When the smartwatch reconnects, the smartphone can ask the watch application to generate a token, thereby verifying that the smartwatch is the same device that originally authorized delegation mode. Security information can also include the GPS location of the smartwatch, which is both in the vicinity of the vehicle and in the vicinity of the smartphone. This reduces the possibility of relay attacks, where the smartwatch is far from the vehicle but the security information can be gated without being known to the attacker. The GPS range can broadly include, for example, the latitude / longitude coordinates of the device. The smartphone and smartwatch can also estimate their respective locations due to the presence of WiFi networks and via cellular data. Therefore, the locations of the smartphone and smartwatch need to be compared with their relative accuracy in mind.If GPS accuracy is not available with sufficient precision to eliminate relay station attacks, the system may require manual input from the user, such as an alert, when it is not accurate enough to automatically disable but needs the user to acknowledge that it has detected them near the vehicle. For example, the alert could reuse the security model of a smartwatch, where it is safe to avoid entering a PIN if the watch is continuously worn by the user. If the smartwatch may be removed, the user would need to manually activate an interface on the wearable. System and method rules may include disabling certain functionality until a certain condition is met, i.e., disabling PEPS on a specific device such as a smartphone or key fob until the watch is returned.

[0130] Using either the smartphone, smartwatch / activity monitor, or one of the vehicle display interfaces, a user can set a rule that causes the PEPS system to ignore devices, such as a key fob or smartphone, in the vehicle while the user goes out for a jog. For example, both the smartphone and smartwatch interfaces can be used to enter "handover mode," which causes any key fob / smartphone currently located near the vehicle to be disabled for purposes of operating the PEPS system when handover mode is entered. The interface allows the user to select a list of enabled devices, but by default, all nearby devices may be disabled. The user can use the smartwatch to lock the vehicle doors, leaving the smartphone and key fob safely inside the vehicle, preferably out of sight in the glove compartment to reduce the possibility of a break-in. The user can then go for a jog, and the system can detect that the watch has left the vicinity of the vehicle. This satisfies the first part of the rule, that the user is expected to go for a jog. At this time, the system can track phones left in the vicinity of the vehicle, and if a security key, such as a key fob and / or smartphone, is left in the vehicle, the system can trigger an alert to the user that delegation mode is available in case the key is accidentally left in the vehicle, or that they should return to the car to retrieve the device that is enabled as a key.

[0131] When a user goes for a jog, for example, a wearable device, such as a smartwatch, leaves communication range with the smartphone remaining in the car. The smartphone can report the loss of communication link, as described in U.S. Patent No. 9,123,244 regarding secure link loss processing rules. The wearable device can typically begin broadcasting on an advertising channel to reestablish a link to the smartphone. Additionally or alternatively, the roles could potentially be reversed, whereby the smartphone broadcasts on the advertising channel. Because the smartwatch and smartphone are out of range of each other, interesting activity related to activating vehicle functions is unlikely to be detected by the vehicle system. However, the vehicle may be able to detect advertising communications from the wearable due to better antenna design and placement compared to the smartphone.

[0132] Continuing with this example, the user continues jogging and returns within communication range of the vehicle system and the smartphone located within the vehicle with which the wearable is associated. At this time, the wearable can broadcast, for example, on an advertising channel and the smartphone can scan for those advertisements.

[0133] When a smartphone and a wearable discover each other on the advertising channel, a connection is established between them. In this disclosure, the vehicle system described in U.S. Patent No. 9,123,244 is extended to notice connection events between a smartphone and a wearable, such as a smartwatch, and record the connection interval, first communication time, channel map, access identifier, slave latency, Bluetooth addresses (IEEE MAC) of both devices, and the address type (public, resolvable, etc.). This information can be used to track BLE connections, as described above, although this disclosure is not limited to BLE communications. All low-power wireless networks use some type of discovery and scheduling / time slotting where connections are observed and passively tracked. Each type of network or communication differs by its medium access control (MAC) layer. In this way, the vehicle system of this disclosure can observe established connections and use the published MAC layer specifications to eavesdrop on communication connections as described above. By recording the above information, the vehicle system can passively eavesdrop on connections between a smartphone and a wearable, such as a smartwatch. Additionally, the wearable will likely stop using advertising channels at this point to reduce power consumption.

[0134] The data between the smartphone and the wearable, i.e., smartwatch, may be encrypted so that it cannot be used by the vehicle system, i.e., the PEPS system, but the smartphone can use the security data mentioned above to report to the vehicle system that the link is considered secure, the device is a trusted device, and the device / communication is not subject to a relay attack.

[0135] Using the link parameters and trust state reported by the smartphone, the system can track connections and collect information about the location of wearables in the vicinity of the vehicle using the architecture described by this disclosure.

[0136] BLE sensors typically cannot pinpoint the location of mobile devices such as smartphones, wearable devices, or key fobs with the same accuracy as traditional PEPS systems built to use low-frequency (LF) signals at 125 kHz.

[0137] 15, a conventional vehicle PEPS system 150 is shown along with the requirements achieved by current production PEPS systems that use LF as the underlying technology for locating key fobs. For example, conventional LF PEPS systems have a low enough error rate to avoid a tendency toward inaccurate decisions while still allowing correct operation in virtually all practical scenarios, avoiding user frustration.

[0138] For example, when the key fob is located within area 152, which includes a radius of, for example, two meters, from the door handle of vehicle 150, a door unlock operation is enabled. While an example using two meters is provided, the distance threshold may vary by manufacturer and / or region. As a further example, when the key fob is located within area 154 of vehicle 150, which includes the interior of vehicle 150, but with some leakage to the exterior of vehicle 150, a vehicle start operation is enabled. For example, area 154 of vehicle 150 may be allowed to extend up to approximately 5 cm outside the side windows and up to approximately 15 cm outside the front and rear windshields. As a further example, when the key fob is located within area 156 of vehicle 150, a trunk open operation is enabled.

[0139] Compared to conventional PEPS systems built using 125 kHz LF signals, implementing a PEPS system using BLE communications, which utilizes the industrial, scientific, and medical (ISM) radio band with 2.4 GHz signals, can involve many challenges. For example, a PEPS system using BLE communications and the ISM radio band with 2.4 GHz signals must consider issues of multipath, shadowing, and fading, which can make a PEPS system using low-cost BLE sensors to measure RSSI less accurate than, for example, conventional systems implementing LF. However, the present disclosure provides systems, methods, and architectures that take these issues into account.

[0140] One issue to address is that with sensors located inside a vehicle, the measured RSSI of a signal is strong when the mobile device 10 is inside the vehicle, but also strong when the mobile device is outside the vehicle and in the vehicle window. A further issue to address is the significant shadow created by the human body, for example, when the mobile device 10 is placed in the back pants pocket of someone attempting to unlock the vehicle door. The human body is primarily water and absorbs 2.4 GHz signals very efficiently. Therefore, it can be difficult to make a reliable determination of the range of the mobile device 10 from the vehicle door handle based on the measured RSSI of the signal from the mobile device 10. With an RSSI threshold optimized to ensure that the mobile device 10 is within two meters of the door, assuming near-free-space propagation, the PEPS system will be unable to detect the mobile device 10 as close enough to the door to allow unlocking when the signal from the mobile device 10 is attenuated by the human body or subjected to a severely disruptive multipath fading environment. Furthermore, an RSSI threshold set to tolerate weaker RSSI when the vehicle sensor 31 is in the shadow of a human body will almost certainly allow the mobile device 10 to be more than two meters away from the door handle with a clear line of sight and no destructive (or constructive) multipath interference to the vehicle sensor 31. For the reasons stated above, such a PEPS system may not always meet user expectations, including the tendency of the PEPS system to make incorrect decisions.

[0141] 16 and 17 , a vehicle 30 is shown equipped with a PEPS system utilizing BLE sensors that use BLE communication in the ISM radio band with a 2.4 GHz signal. As described above, due to uncertainty in the location of the mobile device 10, the PEPS system includes a number of different zones, including an uncertainty zone. For example, referring to FIG. 16 , the PEPS system may permit vehicle start operations when the mobile device 10 is located within an area designated 164A, while areas within area 164B but outside area 164A may be designated as uncertainty zones. In other words, when the mobile device 10 is located in area 164A, the PEPS system may permit vehicle start operations. As described in more detail below, when the mobile device 10 is measured to be outside area 164A but within area 164B, the mobile device 10 is designated as being within the uncertainty zone. As described above, the location of the mobile device 10 may be measured based on, for example, the RSSI of a signal received from the mobile device 10.

[0142] Referring to FIG. 17 , the PEPS system may permit a door unlock operation when the portable device 10 is located within an area designated as 162A, while the area within area 162B but outside area 162A may be designated as an uncertainty zone. In other words, the PEPS system may permit a door unlock operation when the portable device 10 is located within area 162A. As described in more detail below, when the portable device 10 is measured to be outside area 162A but within area 162B, the portable device 10 is designated as being within an uncertainty zone. Furthermore, the PEPS system may permit a trunk unlock operation when the portable device 10 is located within an area designated as 166A, while the area within area 166B but outside area 166A may be designated as an uncertainty zone. In other words, the PEPS system may permit a trunk unlock operation when the portable device 10 is located within area 166A. As will be explained in more detail below, when the mobile device 10 is measured to be outside area 166A but inside area 166B, the mobile device 10 is designated as being within a zone of uncertainty.

[0143] The PEPS system may detect that the mobile device is in one of the zones of uncertainty shown in Figures 16 and 17. In such cases, the mobile device 10 is known to be possibly within an authorized zone, but there is not enough certainty to make a correct determination with adequate confidence to minimize false positives. In such cases, the PEPS system may be configured to alert the user when an activation switch associated with a particular zone is activated.

[0144] For these reasons, a PEPS system using BLE communications may require more educated and informed users, acceptance of certain restrictions, and predetermined actions to be taken by the PEPS system when a mobile device is determined to be located in one of the uncertainty zones. For example, users can be classified into two different categories. For purposes of this example, two categories are used, although additional categories can be used with the systems, methods, and architectures of this disclosure.

[0145] For example, the first category of users includes users who are very concerned about security. For users in this category, the PEPS system must not make any false positive errors. For example, the PEPS system should not allow an unlock operation when the mobile device 10 is more than two meters away from the door handle of the vehicle 30, regardless of the shadowing or multipath environment of the mobile device 10. Users in this category must accept the limitation that the PEPS system may not be able to detect the mobile device 10 when it is located in an uncertainty zone due to attenuation of the communication signal caused by shadowing or fading. In other words, these situations ultimately result in a false negative result in which the vehicle start operation, door unlock, or trunk unlock operation is not allowed when the mobile device is located in the uncertainty zone.

[0146] For example, a second category of users includes users who are more concerned with convenience. For users in this category, it is acceptable for the PEPS system to make some false positive errors, but the PEPS system must minimize false negative results to avoid user inconvenience. For example, in a constructive multipath environment, the mobile device 10 may be detected as being strong enough to unlock the door. As a result, in some cases, the door unlock function may be permitted despite the fact that the mobile device 10 is more than a predetermined distance, such as two meters, from the door handle of the vehicle 30.

[0147] Both categories of users face some limitations or inconveniences. However, unlike traditional PEPS systems, in which key fobs effectively cannot communicate with system users, BLE PEPS systems target the use of smart devices such as smartphones, tablets, and wearable devices such as smartwatches as replacements for traditional key fobs. These devices include advanced interface systems, including haptics, vibration, audio, and screens. Furthermore, these devices can interface with other devices. For example, smartphones and tablets can interface with smartwatches or other wearable devices using the same type of interface and quickly access them by users. These devices can also use in-device motion sensors to accept user input, both on the screen and in the air, such as button presses on the interface, voice commands, and measured gestures. Furthermore, these devices can easily detect their own movement relative to a stationary state and can report not only the screen lockout state but also their orientation. They can also use cameras and / or optical sensors designed to measure the lighting of the surrounding background and lock out the screen when someone is speaking.

[0148] Using the above-described set of enhanced compatibility, a BLE PEPS system according to the disclosed system, method, and architecture can perform a number of different operations. For example, a BLE PEPS system according to the disclosed system, method, and architecture can alert a user when a PEPS system operation is performed on a vehicle, but the PEPS system does not have sufficient evidence to reduce the false positive rate to an acceptably low number. For example, when the driver's door unlock button is pressed and there is sufficient evidence to determine that an approved device is near the door, but not enough evidence has been collected to reduce the false positive rate to an appropriately low rate, an alert can be triggered to the user to confirm whether the door needs to be unlocked. Furthermore, when the ignition switch button is pressed and there is sufficient evidence to determine that an approved device may be inside the vehicle, but not enough evidence to reduce the false positive rate to an appropriately low rate, an alert can be triggered to the user to confirm whether the vehicle needs to be started. In addition, other alerts can be enabled by the system described in U.S. Patent No. 9,123,244, which is incorporated herein by reference. As a further example, an alert may be generated if an object is left inside the vehicle, the smartphone is no longer inside the vehicle, etc.

[0149] As described above, the PEPS system can generate a number of different types of alerts to the user, including, for example, alerts delivered to the user via the mobile device 10. For example, the alerts can include one or more combinations of haptic vibrations, audible sounds, phone notifications in phone operating systems such as those used in iOS and Android, and pop-up alerts on either the smartphone and / or a worn wearable, such as a smartwatch. Additionally, the alerts can request confirmation of behaviors that would be initiated if higher levels of evidence were available. Alerts can incorporate vehicle conditions such as door lock status or ignition and brake pedal status.

[0150] Alerts can target all devices reasonably located near the activation switch. For example, if there is one smartphone near the driver's door and two smartphones by the passenger door, and the passenger door switch is pressed, the PEPS system can trigger an alert on both passenger smartphones without the driver's smartphone receiving the alert. Alternatively, the PEPS system can be configured to allow all devices to receive alerts. Alternatively, the mobile device 10 can be configured via application settings to receive all alerts regardless of the mobile device's location. Alternatively, if a device that should receive an alert via application settings is not within communication range, the PEPS system can queue the alert so that it can alert when communication with the device resumes. Alerts can also be triggered when a vehicle unlock button is pressed or a gesture switch (such as a trunk unlock gesture switch) is activated, even when no authorized device is nearby. Alerts can also be triggered when a device imitates some of the data from an authorized device but fails to meet all security data, such as an attempted hack by an impersonator.

[0151] In response to the alert, the user can take some action, measure, or intervention. For example, an alert button on a graphical user interface (GUI) can confirm the intended action, such as unlocking the doors, unlocking the trunk, or starting the vehicle. For example, when a user presses the unlock button on a door handle, an alert can be sent to the smartphone asking the user if they want to unlock the doors. The above command includes a door lock status, since if the doors are already unlocked, the question on the GUI will ask the user to confirm if they want to lock the doors. The alert can be mapped to a specific meaning, such as a unique haptic sensation for each specific action, such as locking the vehicle, unlocking the vehicle, or starting the vehicle. Additionally or alternatively, a unique tone can be played by the mobile device 10 for a specific action. Additionally or alternatively, a user can dictate via the smartphone's text-to-speech function, asking, "Do you want to unlock the doors?" Other text can be read aloud by the mobile device 10 to confirm the intended action.

[0152] In response to such an alert, the user can, for example, press a button on the GUI of the mobile device 10 to accept the action or ignore the alert. Additionally or alternatively, a voice command can be used to accept the intended action by speaking "yes," "no," "cancel," "ignore," etc. Existing security systems in the smartphone system can be used to determine whether the smartwatch has been worn continuously since the PIN was entered, whether the smartphone is in an unlocked state, whether the smartphone can authenticate the voice, etc. Additionally or alternatively, the user can use a programmed gesture, such as looping the smartwatch three times, in response to receiving the alert.

[0153] Actions and alerts may be routed appropriately by the mobile device 10. For example, if there is no wearable device present or no wearable device linked to the smartphone, the smartphone itself should handle the alert. On the other hand, if the user is wearing a smartwatch, it may be more appropriate to alert the user via the watch, and the alert may be routed to the smartwatch. If the smartphone is unlocked, the user is currently using the smartphone, so even if a smartwatch is present, it may be more appropriate to alert the smartphone.

[0154] The PEPS system operates by waiting or by action. For example, the PEPS system can wait for an activation switch on a door handle to be activated or for a gesture switch, such as a gesture switch to unlock the trunk, to be activated. When an action is performed, such as pressing a button on the door handle or making a gesture to activate a gesture switch, a set of evidence about the location of the mobile device 10 is collected by the communications gateway 29 and the sensor 31. Based on the determined location of the mobile device 10, the level of evidence indicating that location, and the user's preferences for security and convenience, as described above, the PEPS system determines whether to perform a vehicle function operation, such as unlocking the doors or trunk of the vehicle 30 or starting the vehicle 30. The PEPS system can read changes in the state of activation switches, such as door handles. When a change in the state of a switch occurs that requires the PEPS system to perform some action, the PEPS system checks which mobile devices should receive an alert based on which devices are near the activation zone and which devices have opted to receive alerts regardless of location. The PEPS system can route messages from the PEPS system to a mobile device 10, such as a smartphone, through a communications gateway 29 or through a cellular data connection, such as an LTE / cloud module. The PEPS system can be configured to use BLE communications when available, and, if necessary, cellular data, such as an LTE data connection, when BLE communications is unavailable. Messages must be encrypted and signed to prevent interception, injection, or replay. Authorized mobile devices can review the messages and determine the best way to alert the user and whether any action or intervention is required.

[0155] As described above, the PEPS system can utilize multiple levels of evidence in determining the location of the mobile device 10. For example, the PEPS system can be configured to require a predetermined level of evidence to activate an alert, such as when there is sufficient evidence that the mobile device 10 is located near the driver's door of the vehicle 30. For more aggressive users who tolerate some false positives, the PEPS system can be configured to utilize a higher standard of evidence to make a decision that allows the mobile device 10 to take action when the activation switch is pressed. The PEPS system can further be configured to utilize an even higher standard of evidence to make a decision that allows the mobile device 10 to take action when the activation switch is pressed for more conservative users who reduce false positives.

[0156] An interface to set per-device (per-user) settings for acceptable levels of evidence for each action criterion

[0157] For example, each user can configure how they want their devices to work with the system. In a vehicle owned and operated by two drivers, one driver may want a safer system and the other a more convenient system.

[0158] A mobile device 10, such as a smartphone or tablet device, can include a user interface, such as a user interface of an application running on the smartphone or tablet device, for a user to set and / or adjust the risk / tolerance / evidence levels used by the PEPS system. For example, the user interface can indicate to the user the risks involved in reducing the security of the system by allowing more false positives. For example, the user interface can visually indicate where false positives may be and what a false positive might actually cause. For example, by allowing a weak RSSI to unlock the driver's door, the user risks allowing an attacker to sneak up behind the user and gain access to the vehicle even if the user is standing more than 3 meters away from the passenger door. Referring to FIG. 18 , this risk can be displayed on the mobile device 10 using a graphical interface 180 that depicts, for example, a thief gaining access to the vehicle while the user's smartphone is further away from the vehicle than the thief.

[0159] The PEPS system can utilize programmed overrides. For example, a user may configure all application settings according to their preferences, but still experience system performance issues. However, the PEPS system's alert system can learn frequently occurring behaviors and provide an alert to the user asking if they would like to program an override into the PEPS system. For example, a businessman may wear a suit coat and leave a mobile device 10, such as a smartphone, in the breast pocket of the suit coat. The suit coat may then be hung on a coat hanger in the back seat so that the mobile device 10 is always in the uncertainty zone for starting the vehicle. When the ignition switch is pressed, the PEPS system can recognize that the ignition should be allowed, but the PEPS system may be uncertain as to whether the user's smartphone is actually inside the vehicle. As described above, an alert can be triggered to the smartphone, allowing the user to recognize that the vehicle should be started in this situation. But more importantly, if, as in this example, evidence gathered about the smartphone's location appears to indicate that it is in the breast pocket of a suit coat, the decision boundary can be arbitrarily modified to approve / accept future ignition commands. In its simplest form, it may be a multidimensional space of future inputs and some surface that separates location points that should be allowed to start the vehicle from location points that should not be allowed, and another surface that delineates location points that should be allowed to unlock the door. The shape of the surface can be modified over time so that the decision boundary can learn the correct action based on user input.

[0160] Because there are multiple levels of evidence used by the PEPS system, it is possible for the collected evidence regarding the location of the mobile device 10 to conflict. In such cases, the PEPS system can weight each piece of evidence to make a decision regarding the location of the mobile device. The PEPS system can also be configured to respond to conflicting evidence in a predetermined manner. For example, if the PEPS system has conflicting evidence, it can result in a no decision / no action / alert state. For example, when the PEPS system becomes confused because two or more operational states are possible based on the evidence, the PEPS system can default to the safe thing, not allow any passive functions at that time, and alert the user. By way of further example, conflicting evidence occurs when the mobile device 10 is measured near the window line of a vehicle, a sensor designed to unlock the vehicle generates evidence that the mobile device 10 is outside the vehicle and near the door, and a sensor inside the vehicle generates evidence that the phone is inside the vehicle. When there is conflicting evidence, the PEPS system can be configured to do the safe thing by default, not allow any passive functionality, and allow actions based on user alerts that the user must acknowledge / approve. Users can also disable this for their devices by configuring applications shared with the PEPS system so that either action is allowed.

[0161] Before deciding to enter the No Decision / No Action / Alert state, the PEPS system may optionally weigh the evidence between possible outcomes and selectively enter the No Decision / No Action / Alert state or choose the most likely possible outcome. For example, if the Unlock state has a significant margin of greater probability when compared to the Ignition state, even though both are possible, the PEPS system may decide not to enter the No Decision / No Action / Alert state and instead choose to allow the vehicle doors to unlock.

[0162] The PEPS system may be configured to disable certain vehicle functions or actions based on the movement of the mobile device 10. One of the major risks of accepting a higher false positive rate for user convenience is the risk that someone could unlock the vehicle door even if the mobile device 10 is more than two meters away. Alerts can be used to warn the user when an attacker is potentially breaking into the vehicle by alerting the user that an unreliable decision has been made. Additionally or alternatively, this situation can be prevented from occurring in the first place. For example, a user may have their smartphone in a back pocket, in their hand, or in their purse, where a strong signal can be received by the vehicle as they exit and walk away. An attacker could sneak up behind the user and break into the vehicle. Because in this scenario, the user is walking away from the vehicle, the smartphone can easily detect walking motion. The PEPS system can incorporate algorithms to detect whether the user's smartphone is moving. For example, the phone can report to the PEPS system when movement begins and stops. The vehicle lock / unlock function may be disabled for a device when the device is believed to be moving or when observed or detected smartphone movement is greater than a predetermined motion threshold, effectively reducing the risks described above. This setting may be made available to the smartphone user in the application settings. For example, if the user has configured the system to tolerate false positives in this area, the user may be encouraged to enable this setting.

[0163] The present disclosure includes a BLE location system that enables secure authorization of vehicle functions. The BLE location system includes a mobile device, also referred to as a nomadic device, and a vehicle. The BLE location system further includes a plurality of BLE passive eavesdropping sensors configured to securely receive frequency hopping spread spectrum connection information from a communication gateway, also referred to as a central controller, and securely report measurements to the central controller. The communication gateway or central controller is capable of secure BLE communication with the mobile or nomadic devices and is configured to provide connection information to the passive eavesdropping sensors regarding communication connections with the mobile or nomadic devices and collect data from the eavesdropping sensors. The communication gateway or central controller can share with each of the passive eavesdropping sensors communication information necessary for the passive eavesdropping sensors to passively track communications between the communication gateway or central controller and the mobile or nomadic devices. Upon receiving connection information from the communications gateway or central controller, each eavesdropping sensor is configured to synchronize its internal timing and communications channel map to find the next scheduled communication between the communications gateway or central controller and the mobile or nomadic device and to observe and measure all subsequent communications between the communications gateway or central controller and the mobile or nomadic device. The communications gateway or central controller can be configured to communicate the latitude, longitude, and position measurement error of the vehicle's location to the mobile or nomadic device. The mobile or nomadic device can use location based services available on the mobile or nomadic device, such as a smartphone, to estimate the distance or range to the vehicle or the vehicle's PEPS system and compare this to the location reported by the vehicle.

[0164] The present disclosure also includes a BLE location system that includes a mobile or nomadic device and a vehicle and enables secure authorization of vehicle functions. The BLE location system includes a plurality of sensors configured to measure signal characteristics of communications from the mobile or nomadic device and a communications gateway or central controller that can provide information regarding expected intervals and timing of communications from the mobile or nomadic device. The BLE location system also includes a security filtering module configured to process a time series of samples purportedly from the mobile or nomadic device. The security filtering module can compare the time series with known communication characteristics. The security filtering module can compare whether there is more communication data sampled from the mobile or nomadic device within a given time frame than could be generated by the mobile or nomadic device alone. In this manner, the security filtering module can determine whether a physical layer protocol has been compromised. The security filtering module can determine whether the variance of data purportedly sampled from the mobile or nomadic device within a given time window exceeds what is expected for all data originating from the mobile or nomadic device. The comparison is a bounded comparison where the variance may be too large, such as with multiple devices in different locations or a single device that forces the system to take measurements that are too consistent. The security filtering module can count the number of outliers that exceed a configurable threshold of absolute value within a given time window and compare the count to a configurable reference scale. The security filtering module can count the number of outliers that exceed a configurable threshold of standard deviation above the dataset mean within a given time window and compare the count to a configurable reference scale. The sensor can be configured to report incomplete receipt of corrupted data packets to the security filter module.The sensors can receive timing information from the system, allowing each sensor to report a timestamp for each received packet. The security filtering module can search for received packets that are too early or too late according to a configurable threshold. The security filtering module can compare the similarity of timing of packets received by multiple sensors to determine whether any sensor received data configurably earlier or later than a nominal value, thereby determining whether the sensors measured the same RF energy as expected. The security filtering module can compare reported signal strengths reported from multiple sensors when the sensor value from any particular sensor (an authorized sensor) allows the system to grant authorized access to a function. The reported values ​​from the remaining sensors can be used to verify that they are receiving values ​​consistent with devices in the area attributed to authorized sensor measurements.

[0165] Sensors can be configured to only report measurements of data that matches a specific format. For example, packets can be filtered so that only BLE attribute write requests with data longer than a certain number of bytes are measured. In such cases, packets related to simple link maintenance might be discarded, or measurements might not be made on unencrypted data. Sensors can be configured to report cryptographic hashes of the data contained in the packets, or an aggregation of the measured packets, to a security filtering module.

[0166] The communication gateway can be configured to share data transmitted between the mobile or nomadic device and the communication gateway, either in raw format or a cryptographic hash of one or more packets, with a security filtering module. The security filtering module can be configured to inspect data or cryptographic hash data from multiple sensors and compare it with reported data or cryptographic hash data received from the communication gateway, thereby enabling the security filtering module to verify that each sensor received the same data and that the data matches the data received by the communication gateway. The security filtering module can report the cleaned data to a decision module. If any security rules are not met, the security filtering module can report to the decision module that the system has been determined to be under attack. The decision module can optionally send an alert message to an authorized mobile or nomadic device via the authenticated BLE communication link. Application software on the mobile or nomadic device can optionally be configured to alert a user of the device via one of the device's alert mechanisms.

[0167] The present disclosure includes one or more sensors that can accept a command to receive a BLE physical layer packet, regardless of the absence of errors such as CRC errors, on any of 40 BLE channels at a configurable future time or for a configurable time period.

[0168] The present disclosure also includes a sensor network, where each sensor is configured to search a different BLE channel at a different time and report received data to a security module for later processing.

[0169] The present disclosure also includes a method for the security module to compare data received from a mobile device connected to a communications gateway, which is identified as an authorized mobile device, with a log of data read and generated by the sensor network.

[0170] The present disclosure includes a comparison method that searches for a device address in the recorded packets that is equal to the address of an authorized mobile device. The present disclosure also includes a comparison method that extracts data contained in the recorded packets and compares it with data being received or already received by the PEPS system. If there is a match, the security module can determine that a man-in-the-middle attack is occurring.

[0171] The present disclosure includes a method for taking a time series of received messages emitted from a mobile or nomadic device and reconstructing the connection interval, current channel, connection interval, slave latency and channel map required for a sensor in a sensor network to start following a connection.

[0172] Referring to FIG. 19, another PEPS system 200 is provided within a vehicle 230. Similar to PEPS system 1 described above, PEPS system 200 includes a communication gateway 229 and a plurality of sensors 231A-231F, collectively referred to as 231. Similar to PEPS system 1 described above, in PEPS system 200 of FIG. 19, mobile device 210 can communicate with communication gateway 229 of vehicle 230 via a secure communication link 280, such as a Bluetooth communication link, as described above with reference to secure communication link 680. PEPS system 200 of FIG. 19 is similar to PEPS system 1 described above, except that PEPS system 200 of FIG. 19 also utilizes impulse radio (IR) ultra-wideband (UWB) communication in addition to utilizing BLE communication. More specifically, one or more sensors 231 may be configured to communicate using IR UWB communication in addition to BLE communication. Additionally, communication gateway 229 is also configured and provided with a communication gateway 229 that is configured to communicate using IR UWB communication in addition to BLE communication. For example, the mobile device 210 can communicate with the communication gateway 229 using IR UWB communications. In some configurations, the vehicle 202 may include one or more sensors 231 configured to communicate using only IR UWB and one or more sensors 231 configured to communicate using only BLE communications. For example, the vehicle 202 may be configured to have one or more sensors 231 configured to communicate using both IR UWB and BLE communications, one or more sensors 231 configured to communicate using only IR UWB, and / or one or more sensors configured to communicate using only BLE communications. In the example of FIG. 19 described herein, the vehicle 202 is referred to as including one or more sensors 231 configured to communicate using at least IR UWB and one or more sensors configured to communicate using at least BLE communications. Alternatively, the vehicle 202 may include only sensors 231 configured to communicate using IR UWB.In such a case, the mobile device can communicate with the communication gateway 229 using BLE communication and can communicate with the sensor 231 using IR UWB communication.

[0173] 19 , mobile device 210 is similar to mobile device 10 described above, except that mobile device 210 is configured to communicate using IR UWB communication in addition to BLE communication. Mobile device 10 may be any device configured for IR UWB and BLE communication, such as, without limitation, a smartphone, a smartwatch, a wearable electronic device, a key fob, a tablet device, or other device associated with a user of vehicle 230, such as the owner, driver, passenger, and / or mechanic of vehicle 230. Mobile device 210 may include a BLE chipset 11 connected to antenna 13, as described above. Mobile device 210 may also include application software 12 stored on a computer-readable storage module or device, as described above. Mobile device 210 may also optionally include a GPS module 214 or other device location service, as described above.

[0174] 19 , the mobile device 210 may be configured with an internal IR UWB communication module or may be equipped with IR UWB communication capabilities. For example, the mobile device 210 may include an IR UWB communication chipset configured for IR UWB communication and connected to an antenna. Alternatively, the mobile device 210 may be modified for IR UWB communication by attaching an IR UWB tag 250 to the exterior of the mobile device 210. The IR UWB tag 250 may communicate using IR UWB communication with, for example, one or more sensors 231 and a communication gateway 229 configured for IR UWB communication. As described in further detail below, in a configuration in which the IR UWB tag 250 is attached to the mobile device 210, the mobile device 210 communicates with the tag 250 to verify that the tag 250 is attached to the mobile device 210.

[0175] As mentioned above, the communication gateway 229 and the one or more sensors 231 are configured to communicate using IR UWB communications according to the UWB IEEE 802.15.4IR UWB standard, and more specifically, the IEEE 802.15.4a standard.

[0176] As described in further detail below, the configuration shown in FIG. 19 enables more accurate location tracking of the mobile device 210 by using communication technologies such as IR UWB in addition to communication using BLE communication. The additional communication technologies, such as IR UWB communication, may be triggered in response to a predetermined key event, such as a time frame immediately following a BLE connection event. In such a case, the PEPS system 200 can activate the IR UWB communication system so that each of the sensors can perform two-way ranging with the tracked device in a deterministic manner by assigning a time slot synchronized with the BLE connection communication event. For example, after each BLE connection event, each BLE sensor can be assigned a time slot for performing two-way ranging based on the sensor's unique identification code. However, two-way ranging may not be triggered on every connection event because ranging may not be necessary in many cases and would incur power consumption costs. Therefore, the PEPS system 200 may be configured such that a trigger transmitted via BLE communication indicates that ranging should be performed on a future connection, i.e., immediately following the next connection event. The location module 32 described above can determine the location of the mobile device based on two-way ranging performed by the sensors.

[0177] Optionally, all IR UWB radios can be time-synchronized, and two-way ranging may not be required if time difference of arrival is used. In such a case, the mobile device 210 can broadcast that it is the device being tracked and transmit ranging pulses synchronized to known connection events. All BLE sensors can wait for ranging pulses in time slots that follow this synchronization. In this way, significant power savings can be achieved by limiting the use of IR UWB or other ranging technologies to synchronization with the primary data channel provided by BLE or other low-energy protocols, whose communication timing is learned by each sensor in the network.

[0178] Each BLE sensor is configured and enabled to communicate with the communication gateway 229. In this manner, sensed data is communicated to the communication gateway 229 and can be distributed to other communication nodes in the network as needed. The communication connection between the sensor 231 and the communication gateway 229 can be directly wired, such as via a local interconnect network (LIN) interface with the communication gateway 229. The communication connection can also be wireless. For example, the BLE sensor can communicate with the communication gateway 229 using secure BLE communication.

[0179] As mentioned above, the mobile device 210 may be a smartphone that can communicate with the communication gateway 229 in a secure manner, for example, using an advertising channel or a connection channel. As further mentioned above, the mobile device 210 may include an attachment device, such as an attachment tag 250, that provides additional communication technology for more accurate ranging. For example, the tag 250 may incorporate IR UWB communication technology for more accurate ranging. The tag 250 may communicate independently with the communication gateway 229 and may be tracked by a sensor network, i.e., a sensor swarm 231, using either BLE or IR UWB communication. The tag 250 may also communicate with the mobile device 210 such that security data is exchanged between the mobile device 210 and the tag 250 to verify that the tag 250 is attached and remains attached to the mobile device 210. Such data may include, for example, transmit power and signal strength. The transmit power can be set low, for example, so that tag 250 can only communicate when attached to mobile device 210, whereby a certain threshold level of RSSI must be maintained for tag 250 to be considered attached to mobile device 210. The communicated data can also include the length of time the communication link is maintained.

[0180] The communicated data can also include accelerometer data. For example, an accelerometer built into the tag 250 can report accelerometer data that can be compared to accelerometer data generated by another accelerometer built into the mobile device 210. For example, because the tag 250 is physically attached to the mobile device 210, when the tag 250 and mobile device 210 are paired together, the relative orientation of both devices can be learned. In other words, a simple transformation of x, y, and z accelerometer data from each device can be used to translate the orientation of the mobile device 210 relative to the tag 250. In this way, if the tag 250 is removed and no longer attached to the mobile device 210, it is difficult to create a stable reference for the orientation of the mobile device, and the PEPS system 200 can avoid or override all location determinations based on the location of the tag 250 because it is assumed that the tag 250 is no longer co-located with the mobile device 210. The PEPS system 200 can be configured to process and analyze the current orientation of the mobile device 210 (e.g., x, y, z accelerometer data) along with the current orientation of the tag 250 attached to the mobile device (e.g., x, y, z accelerometer data). The PEPS system 200 can determine a mapping function from the orientation of the tag 250 to the orientation of the mobile device 210 via processing by the communications gateway 229 or the mobile device 210. The mapping function can be learned at the time the tag 250 is attached to the mobile device 210. After applying the conversion function, the relative drift or movement of the two devices relative to the learned initial positions can be monitored or tracked. The tolerance requirements can determine how much drift is acceptable based on, for example, hardware tolerances. A discrepancy in the orientation of the two devices that exceeds a set tolerance can be used to invalidate a determination regarding the mobile device's location. Because the tag 250 may slowly slide and shift position relative to the mobile device 210 over time, the mapping function can be adjusted based on the orientation indicated at each decision point at which the tag 250 and mobile device 210 are within an acceptable range.An averaging / filtering function can be applied to a predetermined number of recent relative orientations to compensate for small, slow drifts in electronics precision or the physical orientation of devices relative to each other. For example, the averaging filter can use the most recent relative coordinates that meet a required tolerance.

[0181] As described above, in one configuration, vehicle 230 may include only sensors 231 that communicate using IR UWB ranging communications. In this case, mobile device 210 may communicate with communications gateway 229 utilizing BLE communications and may communicate with sensors 231 using IR UWB ranging communications. In this configuration, PEPS system 200 includes communications gateway 299 that may communicate with mobile device 210 using a secure BLE communications connection and may optionally include an IR UWB communications module for communicating with mobile device 210 using IR UWB communications. In this configuration, PEPS system 200 also includes IR UWB sensors 231 that may communicate with communications gateway 229 via a dedicated bus, such as a CAN bus or LIN bus, or via IR UWB communications if communications gateway 229 includes an IR UWB communications module. Additionally or alternatively, IR UWB sensors may communicate information to mobile device 210 using IR UWB communications, and mobile device 210 may relay information from sensors 231 to communications gateway 229 using BLE communications. In such a configuration, the mobile device 210 is configured to communicate using both BLE and UWB communications. For example, the mobile device 210 may be a smartphone configured to communicate using BLE communications. Additionally or alternatively, the mobile device 210 may be configured to communicate using BLE communications and may include an attachment tag 250 that performs IR UWB communications, with the IR UWB tag 250 including verification methods for verifying that it is attached to the mobile device 210, as described above.

[0182] Referring to FIG. 20 , another configuration of a PEPS system 201 is shown having a vehicle 230 including a sensor 231 that communicates using BLE communication and IR UWB ranging communication. For example, in the configuration of the PEPS system 201 shown in FIG. 20 , sensor 231A is capable of both IR UWB and BLE communication, while sensor 231C is capable of only IR UWB communication. As shown in FIG. 20 , a mobile device 210 is capable of both BLE and IR UWB communication. For example, the mobile device 210 shown in FIG. 20 includes an attached IR UWB tag 250 for IR UWB communication. Alternatively, the mobile device 210 may include an IR UWB communication chipset connected to an antenna configured for IR UWB communication. In such a case, the mobile device 210 can communicate using IR UWB without requiring an attached IR UWB tag 250. As shown in FIG. 20 , the mobile device 210 communicates with a communication gateway 229 via a secure communication link 280 using BLE communication. Mobile device 210 communicates with sensor 231C using IR UWB communication via communication link 281. Mobile device 210 communicates with sensor 231A using BLE communication via communication link 282 and IR UWB communication via communication link 283. Referring to FIG. 20 , PEPS system 201 is shown communicating with mobile device 211, which can communicate using BLE communication but cannot communicate using IR UWB. Mobile device 210 communicates with communication gateway 229 over secure communication link 280 using BLE communication. Mobile device 210 also communicates with sensor 231A using BLE communication via communication link 282.

[0183] Initially, BLE may have been the only suitable technology for locating the mobile device 211 in proximity to the vehicle. As real-time location systems (RTLS) become more prevalent, manufacturers, such as those of smartphones, tablet devices, and wearable devices, are likely to adopt and utilize precise time-of-flight (TOF)-based two-way ranging systems, such as IR UWB. Therefore, to maintain compatibility with existing mobile devices, such as existing smartphones, tablet devices, and / or wearable devices, the hybrid configuration shown and described with reference to FIGS. 20 and 21 can be used where users do not want to install IR UWB tags on their mobile devices for precise location tracking and can tolerate the limitations and security risks imposed by using a low-cost BLE-only solution. The hybrid configuration can also include the wearable handover mode described above, since the BLE communication portion of the system can roughly locate the wearable device, for example, when it returns to the vicinity of the vehicle 230. In this way, the hybrid configuration system provides a low-cost system for users and also provides compatibility with BLE devices that do not support IR UWB communication.

[0184] As described above, the hybrid configuration system can include a communications gateway 229 configured to communicate with mobile devices 210, 211 using BLE communications. The system can also include one or more combination IR UWB and BLE sensors 231, i.e., sensors such as 231A that can communicate using both IR UWB and BLE communications. The combination sensor can measure BLE signal characteristics of advertising and subsequent connection channels and also perform IR UWB ranging using two-way ranging and / or time difference of arrival. The system can also include one or more sensors that communicate only using BLE communications. For example, a BLE-only sensor can be used to deploy a "known location" start system, whereby a mobile device must be placed in close proximity to the sensor to enable an action—i.e., the mobile device must be placed, for example, on the center console, to enable the vehicle to start. With such BLE-only sensors, proximity characteristics typically dominate in a system that allows for robust RSSI. The system also includes zero or more IR UWB-only sensors, such as sensor 231C. These sensors are capable of UWB ranging, as described above, and are placed in areas where geometric ranging characteristics are critical to determining the location of the tracked device, but where very little BLE signal information is important. As described above, the hybrid PEPS system 201 is compatible with communication with mobile devices 211 that communicate using BLE communications but not IR UWB. These types of mobile devices 211 may be tracked and roughly located via subsequent connection and / or advertising data, subject to accuracy limitations. The hybrid PEPS system 201 is also compatible with communication with mobile devices 210 that can communicate using both BLE and IR UWB communications. These types of mobile devices 210 can be tracked via UWB ranging, with BLE communications used as a control channel to enable IR UWB communications only as needed to reduce power consumption.The location module 32 described above can determine the location of the mobile device based on two-way ranging performed by the sensor 231 .

[0185] In addition to tracking the mobile devices 210, 211, the PEPS system 201 can also track wearable devices associated with the mobile devices 210, 211. The wearable devices can include the delegation functionality described above and can use status messages from the mobile devices to indicate whether the associated wearable devices are present and authenticated.

[0186] One consideration for this type of PEPS system 201 is when to enable the IR UWB communication system. As an example, the IR UWB communication system can be synchronized to follow a BLE connection event. For example, the system may be configured to calculate the distance from the mobile device 210 to all vehicle sensors 231. Referring to FIG. 22, a sequence diagram illustrating the operation of the system using two different methods is shown. As shown in FIG. 22, event timing information is sent from the communication gateway 29 to IR UWB sensor 1 231 at 2201 and to IR UWB sensor N 231 at 2202. At 2204, a connection event 2204 occurs between the mobile device 210 and the communication gateway. After the connection event, the time until the next connection event can be divided into N time slots. Each IR UWB sensor 231 can be assigned a time slot. The sensors 231 can calculate the time until the next connection event and the offset to their own time slot by communicating with the communication gateway 29 to minimize the time spent waiting for communication from the mobile device 210 using two-way ranging between each sensor 231.

[0187] In the sequence diagram of FIG. 22, two-way ranging can be activated by assigning a time slot to each of the sensors 231 following a connection event. As shown in FIG. 22, following a first connection event 2204, two-way ranging using IR UWB sensor 1 231 occurs at 2206 and 2208 in ranging slot 1. Furthermore, two-way ranging using IR UWB sensor N occurs at 2210 and 2212 in ranging slot N. Further, a second connection event is shown at 2214. Following the second connection event 2214, two-way ranging using IR UWB sensor 1 231 occurs again at 2216 and 2218 in ranging slot 1. In practice, two-way ranging may not occur following every connection event because it would be too costly in terms of energy. Therefore, during some connection events, data packets are forwarded from the communication gateway 29 to the mobile device 210 or vice versa. The data packets may indicate that the ranging system will be active during a future connection event.

[0188] In its simplest form, ranging can be initiated immediately after every connection event, as shown in the sequence diagram of FIG. 22. Additionally or alternatively, data packets between the mobile device 210 and the communication gateway 29 can include a trigger. For example, the trigger information can provide instructions for activating ranging on the next N connection events, ranging from 0 to N, where 0 is immediately after the connection event. Additionally or alternatively, the trigger information can provide instructions for activating ranging when a connection event arrives on a specific BLE channel, e.g., every time the system communicates on channel 5, or, e.g., channels 5, 15, 25, and 32. Additionally or alternatively, the trigger information can provide instructions for activating ranging on every Nth connection event starting after Yth connection event. For example, starting within three connection events (Y), the ranging system is activated on every 20th connection event (N). Some devices, such as certain smartphones, may not have accurate information about connection events or which channel is the current channel. Therefore, communication nodes must implement a discovery mode for initialization. For example, if the system is to operate when communication is performed on BLE channel 5, the sensor 231 can enter a mode in which channel 5 is continuously scanned until a packet matching the access identifier of the next communication link is observed. A schedule table for tracking the BLE communication link can then be established. As another example, the system can be configured such that every time the Nth connection event is used, the receiver does not know the value of the transmitter's current counter for IR UWB ranging requests. Thus, the receiver can scan for IR UWB two-way ranging requests from the correct device (e.g., preamble). When an IR UWB request is received, the receiver can set the next scan time to N times the connection interval. In this manner, synchronization can be achieved.

[0189] The ranging system described in the sequence diagram of Figure 22 uses two-way ranging. However, other modes are available in which nodes in an IR UWB network can maintain clocks with each other so that a common time base can be established. The clock synchronization process, however, can result in higher energy consumption and is therefore initiated based on BLE commands between nodes.

[0190] IR UWB communication systems can be attacked at the physical layer through attacks such as "preamble injection" and "cica" attacks. A way to reduce the chances of a successful attack is to use the shortest possible symbols (higher bit rates) and unpredictable preambles. However, shortening the symbol length reduces the effective communication range. Because some functions, such as long-range welcome, require less accuracy and minimal security concerns at long distances, while other functions, such as door unlocking, require high security at short distances, the system requires adaptive configuration. The system can change the symbol rate from a long symbol rate, which provides a longer communication range but less robust IR UWB ranging, to a short symbol rate, which provides a shorter communication range but more robust IR UWB ranging. Negotiation of which symbol rate is used and when is controlled can occur via BLE communication messages between the mobile device 210 and the vehicle system through the communication gateway 29.

[0191] Additionally, physical layer attacks in IR UWB communication systems can be partially mitigated by modifying the preamble. For example, the IEEE 802.15.4-2011a specification specifies the preamble to be used. However, it may be advantageous to modify the preamble, choosing to use a particular preamble only once. Therefore, the system can implement a method in which a temporary preamble is selected, either partially or entirely, by either the mobile device 210 or the vehicle system. An example of a partial preamble involves selecting a number of bits smaller than the preamble size. This data may be a subset of the preamble or may be used by all nodes as a seed for a deterministic generation algorithm to determine a larger preamble. The temporary preamble is then deployed throughout the system using the BLE communication network immediately prior to use. The sequence diagram shown in Figure 22 illustrates that IR UWB ranging can be synchronized with a connection event. During a connection event prior to IR UWB ranging communication, a BLE data packet can be transmitted with the preamble used during the ranging command.

[0192] Numerous triggers can be used to activate the IR UWB ranging system. These triggers can also trigger the system to change the IR UWB bit rate / symbol rate to change from long range to short range or vice versa. Triggers can include using the RSSI of the BLE control channel to determine when the IR UWB system is close enough to the vehicle system to activate the welcome / approach function. Additionally, IR UWB communications can be disabled immediately after activation of the welcome function to reduce power consumption. Triggers can also include using the coarse location capabilities of the BLE sensor network to determine when the mobile device 210 is relatively close to a critical activation zone, such as near the driver's door for an unlock function, near the lift gate, or near the passenger door, or when the mobile device 210 is believed to be inside the vehicle and the start button may be pressed soon. Triggers can also include using a vehicle occupant detection system incorporating weight sensors and / or visual recognition of the occupant. To reduce power consumption, the IR UWB system can disable the "ignition on" scenario until it determines someone is in the driver's seat or until the brake pedal is depressed, which activates the ignition on system. The trigger can also include the use of latitude / longitude, i.e., GPS data, to calculate the approximate distance and approaching side of the mobile device 210 relative to the vehicle 230, i.e., to compare the latitude / longitude of the vehicle 230 with the latitude / longitude of the mobile device 210 to calculate a vector from the vehicle 230 to the mobile device 210. The ranging system can be enabled once it is calculated that the mobile device 210 is likely within a zone where functionality is required. The trigger can also include the use of accelerometer / motion data available to the mobile device 210. To calculate a "speed of approach" value, the mobile device, such as a smart device, can provide the application with its current location in addition to its current direction and travel movement. The speed of approach relative to the vehicle can then be derived from this data.In this way, the ranging and authentication system can selectively activate or activate early when the mobile device 210 will soon reach a decision zone. For example, a user may be running to a vehicle and be in a hurry, perhaps because it is raining or because they are being chased by a burglar. The ranging system can remain activated to predict the exact time a person will arrive at a secure decision zone, such as unlocking the doors. In such a case, all authentication can be completed prior to arrival, and when the user arrives at the secure decision zone, only the location of the mobile device relative to the vehicle is pending. This allows functions such as unlocking doors or automatically opening a liftgate based on the user's very rapid approach. Triggers can also include enabling the ranging system longer, closer to the long-range welcome feature, to calculate a "speed of approach" to determine whether the system should remain on and enable the above use case without using motion detection on the mobile device 210, for example, if the mobile device 210 does not have motion detection capabilities, if the user opts for no motion data, or if using this method is simply energy-efficient in either case. Triggers can also include activation of a second tracked device by a first tracked device. For example, in a use case where a tag is placed on an item such as a golf bag and the golf bag and the owner's phone are both located in a lift gate unlock zone, the user may program the lift gate to open automatically. A first mobile device 210, e.g., a phone, can communicate with a second tracked device, e.g., a tag, in a low-power and highly efficient manner via BLE. When the first mobile device 210 is detected near a decision zone, e.g., near a lift gate, the first mobile device 210 can send a BLE communication message to the second tracked device, e.g., a golf bag tag, and / or the vehicle system to activate the second tag's IR UWB system so that the vehicle system can accurately locate the tag.

[0193] Referring to FIG. 23 , another PEPS system 300 is provided within a vehicle 202. Similar to the PEPS systems 1 and 200 described above, the PEPS system 300 includes a communication gateway 329 configured to communicate with a mobile device 311, such as a smartphone, smartwatch, wearable electronic device, key fob, tablet device, or other device associated with a user of the vehicle, such as the owner. The PEPS system 300 includes a low frequency (LF) antenna 331 capable of communicating with a conventional PEPS key fob, such as those currently used in conventional LF PEPS systems. For example, the PEPS system 300 may include one or more LF antennas 331 disposed inside the vehicle 330 and one or more LF antennas 331 disposed outside the vehicle 330. The LF antennas 331 are configured to communicate within a frequency range, for example, between 80 kHz and 200 kHz. One or more separate LF drivers may be used to drive the LF antennas 331. In the configuration shown in FIG. 23 , the LF drivers are included in the communication gateway 329. Alternatively, a separate LF driver or transmitter module in communication with the communication gateway 329 may be used to drive the LF antenna 331 .

[0194] The portable device 311 shown in the PEPS system 300 of FIG. 23 includes wireless charging functionality, i.e., wireless power transfer functionality. The wireless charging functionality may include, for example, inductive charging and / or resonant charging. For example, the portable device 311 may include a Qi charging device for wireless charging of the portable device 311. The LF antenna 331 and an LF driver associated with the LF antenna 331 are configured to transmit a Qi wireless charger ping request up to a predetermined distance, such as 4 meters. In this manner, the portable device 311 equipped with a Qi charging device may observe a wireless charger ping request from the LF antenna at approximately 4 meters, for example, based on the receive gain of the Qi receiver of the portable device 311. Communication, such as a Qi wireless charger ping request, to / from the LF antenna 331 to the portable device 311 is shown at 381. While communication 381 is shown with a single LF antenna 331, it is understood that communication occurs between the portable device 311 and each of the LF antennas 331.

[0195] The amount of power provided to the LF antenna 331 can be changed so that the LF driver reduces the transmit gain to achieve a shorter communication range when a range of less than 4 meters is targeted. Furthermore, different types of mobile devices may have different Qi receiver gain settings. However, the gain sensitivity is known based on the type of mobile device, and different receiver gains can be learned by the vehicle through calibrations set based on the type of mobile device. The calibration results can then be transmitted to the vehicle PEPS system 300 when the mobile device 311 is first paired with the vehicle PEPS system. Alternatively, the receiver gain can be learned through a process in which the mobile device is placed in a known location near the LF antenna 331. The LF antenna 331 can transmit several packets at various power levels to the mobile device 311, and the mobile device 311 can respond to each received communication packet. The LF driver or transmitter can then measure the transmit power threshold below which the phone cannot detect a signal. For example, the receiver gain can be calculated using known locations chosen such that the propagation path, i.e., the signal loss due to propagation, is accurately understood based on a training scenario. Furthermore, the transmit power minus the received energy indicates the path loss. If the path loss is known and the received energy is equal to zero, then the path loss exactly matches the receiver gain.

[0196] The LF driver or transmitter can modify the packet payload to include a "challenge" code. The challenge code can be the same as the existing PEPS challenge code. The challenge code must be detected by the Qi receiver in the mobile device 311. The LF driver or transmitter can also communicate with legacy key fobs, typically at 125 kHz. A module controlling the LF antenna, such as the communications gateway 329 or a dedicated module, can be configured to change the mode of the LF antenna 331 to drive both Qi-specification packets and LF challenges currently used in legacy PEPS systems. Legacy key fobs can also be modified to implement the Qi specification. Thus, the LF antenna 331 does not need to change its communication protocol to accommodate both.

[0197] The mobile device 311 utilizes a secure encrypted communication link 380, such as a secure BLE communication link 380, to the communication gateway 329 of the vehicle 330. Additionally or alternatively, the communication link 380 may be an IR UWB communication link or other standardized or proprietary protocol. The mobile device 311 includes a Qi charging device that can communicate with application software running on the mobile device 311. When the mobile device 311 receives a Qi charging ping from the vehicle's LF antenna 331, the packet information is shared with the application software running on the mobile device 311. Based on the data in the packet, the application software creates a cryptographic response using a key or set of keys exchanged between the vehicle system and the mobile device 311 when the mobile device 311 paired with the vehicle system. The response is then transmitted by the mobile device 311 to the communication gateway module via the secure BLE communication link 380. The data transmitted via the secure BLE communication link 380 is encrypted. Optionally, the data can be configured to be replay-safe, i.e., by using counter-based encryption such as AES-CCM. Optionally, the data can be signed, i.e., by using AES-CCM or by using signatures via RSA or ECC. If IR UWB or other bidirectional communication protocols are used as a secure communication link, the link may be used to prevent relay station attacks by measuring the arrival time or arrival time difference of responses.

[0198] The PEPS system 300 includes one or more communication gateways 329 that can securely communicate with the mobile device 311, such as using BLE communications, as described above. The communication gateway 329 can create a secure communication link 380 with the mobile device 311 and verify the identity and authenticity of the mobile device 311. For example, the communication gateway 329 and the mobile device 311 are configured to reliably have the keys exchanged when the mobile device 311 paired with the vehicle system and understand encrypted data exchanged between them. In this manner, the communication gateway 329 and the mobile device 311 can freely exchange data with each other. For example, the mobile device can send a response code from an LF Qi ping to the communication gateway 329, so that the communication gateway 329 can verify operation. The communication gateway 329 can communicate with and activate each of the LF antennas to request that the LF antenna send an LF Qi ping request to the mobile device. The communication gateway 329 can control or learn the data sent in each ping and can control the data in each ping so that each ping is unique. LF pings may be transmitted periodically. LF pings may also be transmitted upon vehicle operation, such as when a door button is activated or a start pushbutton is activated. LF pings may also be transmitted based on signal characteristics between the communications gateway 329 and the mobile device 311, including, for example, based on RSSI between the communications gateway and the mobile device. The signal characteristics can be used to estimate the distance from the mobile device 311 to the communications gateway 329, such that an LF ping can be enabled whenever the mobile device 311 is likely to be within communication range of one of the vehicle's LF antennas 331. LF pings may also be transmitted based on a coarse location system, such as that described above with respect to the BLE PEPS system, in which data from several other sensors in the vehicle can locate a phone that is likely to be within communication range of an LF antenna.LF pings can also be sent based on a GPS comparison between the mobile device 311 and the vehicle 330, such as when the distance between them is close enough that the mobile device 311 is likely to be within communication range of one of the LF antennas.

[0199] The communications gateway 329 can receive the challenge response from the mobile device 311, decode it, and optionally check the playback and signature to verify the authenticity of the response. The response code can be compared to the challenge code and one or more keys shared with the mobile device 311 during pairing. A challenge / response code algorithm can be used to determine whether the response code is correct or incorrect. If a correct response code is received by the communications gateway 329, the communications gateway 329 can communicate with the vehicle access subsystem and vehicle start subsystem within the vehicle 330 to lock / unlock doors or change the vehicle ignition state based on well-established rules, for example, locations established by “Thatcham” requirements. Authentication can also be used to restrict wireless charging functionality to charging stations accessible from inside and / or outside the vehicle, i.e., LF antennas, to prevent passersby or other unauthorized persons from accessing the wireless charging functionality.

[0200] 24, a block diagram of a portion of a PEPS system 300 using LF communications and a Qi ping challenge is shown. A communications gateway 329 communicates a challenge code to an LF antenna at 360. An LF antenna 331 issues a Qi ping challenge to a mobile device 311 using LF communications at 362. The mobile device 311 responds to the Qi ping challenge by communicating an encrypted challenge response to the communications gateway 329 using BLE communications at 364.

[0201] 25, a sequence diagram illustrates communication between communications gateway 329, LF antenna 331, and portable device 311. The sequence diagram assumes that cryptographic information required by portable device 311 to calculate a secure challenge response to a challenge code was shared between communications gateway 329 and portable device 311 when the portable device was paired with the vehicle system.

[0202] The communications gateway 329 first determines that a Qi ping or challenge should be sent, as described in detail above. At 382, ​​the Qi challenge is sent to the LF antenna. The LF antenna is configured by the LF system to communicate using Qi. At 384, the LF antenna sends a Qi ping at the appropriate power level along with data including the challenge. The mobile device 311 then receives the challenge, can calculate the challenge response, and measure RSSI and timestamp data. At 386, the mobile device 311 sends a response to the communications gateway via BLE communication. The communications gateway then determines, for the responding mobile device, whether the response is correct. If the response is correct, the communications gateway can unlock the vehicle using applicable criteria or enable operation, such as activating wireless charging functionality at charging stations internal and / or external to the vehicle.

[0203] The description of the foregoing embodiments has been provided for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure. Individual elements and features of a particular embodiment are generally interchangeable and can be used in selected embodiments, where applicable, even if not specifically shown or described, without being limited to that particular embodiment. The same may also be modified in many ways. Such modifications should not be considered a departure from the present disclosure, and all such modifications are intended to be included within the scope of the present disclosure.

[0204] The exemplary embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the present disclosure to those skilled in the art. Numerous specific details, such as examples of specific components, devices, and methods, are set forth to provide a thorough understanding of the embodiments of the present disclosure. It will be apparent to those skilled in the art that specific details need not be used, and that the exemplary embodiments may be embodied in many different forms, none of which should be construed as limiting the scope of the present disclosure. In some exemplary embodiments, known processes, known device structures, and known techniques are not described in detail.

[0205] In this application, including the definitions below, the terms "module" and "system" may be referred to as part of or including a circuit or circuit configuration that may include processor hardware (shared, dedicated, or group) that executes code and memory hardware (shared, dedicated, or group) that stores code executed by the processor hardware. The code is configured to provide the functionality of the modules and systems described herein. Additionally, in this application, the terms "module" and "system" may be substituted for the term "circuitry." The term "memory hardware" may be a subset of the term computer-readable medium. The term computer-readable medium does not encompass transient electrical and electromagnetic signals that propagate through a medium and, therefore, may be considered tangible and non-transitory. Non-limiting examples of non-transitory, tangible computer-readable medium include non-volatile memory, volatile memory, magnetic storage, and optical storage.

[0206] The apparatus and methods described in this application may be implemented partially or completely by a special-purpose computer created by configuring a general-purpose computer to perform one or more specific functions embodied in a computer program. The functional blocks, flowchart components, and other elements described above serve as software specifications that can be translated into a computer program by the routine work of a skilled engineer or programmer.

[0207] A computer program includes processor-executable instructions stored on at least one non-transitory, tangible computer-readable medium. A computer program also includes or relies on stored data. Computer programs encompass a basic input / output system (BIOS) that interacts with the hardware of a special-purpose computer, device drivers that interact with specific devices of a special-purpose computer, one or more operating systems, user applications, background services, background applications, etc.

[0208] A computer program may include (i) parsed written text, such as JavaScript Object Notation (JSON), Hypertext Markup Language (HTML), or Extensible Markup Language (XML), (ii) assembly code, (iii) object code generated from source code by a compiler, (iv) source code for execution by an interpreter, (v) source code for compilation and execution by a just-in-time compiler, etc. By way of example only, source code may be written using the syntax of languages ​​including C, C++, C#, Objective C, Haskell, Go, SQL, R, Lisp, Java, Fortran, Perl, Pascal, Curl, OCaml, Javascript, HTML5, Ada, active server pages (ASP), PHP, Scala, Eiffel, Smalltalk, Erlang, Ruby, Flash®, Visual Basic®, Lua, and Python®.

[0209] None of the elements recited in the claims are intended to be means-plus-function elements within the meaning of 35 U.S.C. §112(f) unless the element is expressly recited using the phrase "means for," or, in the case of a method claim, using the phrase "operation of," or "step for."

[0210] The terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. As used herein, the singular forms "a," "an," and "the" may be intended to include the plural forms as well, unless the context clearly dictates otherwise. The terms "comprises," "comprising," "including," and "having" are inclusive and thus specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. The steps, processes, and operations of methods described herein should not be construed as necessarily requiring their performance in the particular order described or illustrated, unless specifically identified as an order of performance. It should also be understood that additional or alternative steps may be employed.

[0211] When an element or layer is referred to as being "on," "engaged to," "connected to," or "coupled to" another element or layer, it may be directly on, engaged to, connected to, or coupled to the other element or layer, or intervening elements or layers may be present. In contrast, when an element is referred to as being "directly on," "directly engaged to," "directly connected to," or "directly coupled to" another element or layer, intervening elements or layers may not be present. Other language used to describe relationships between elements should be construed in a similar manner (e.g., "directly between" for "between," "directly adjacent" for "adjacent," etc.). As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items.

[0212] Terms such as "first," "second," and "third" may be used herein to describe various elements, components, regions, layers, and / or sections; however, these elements, components, regions, layers, and / or sections should not be limited by these terms. These terms may be used merely to distinguish one element, component, region, layer, or section from another region, layer, or section. Terms such as "first," "second," and other numerical terms, when used herein, do not imply any arrangement or order unless the context clearly dictates otherwise. Thus, a described first element, component, region, layer, or section could be referred to as a second element, component, region, layer, or section without departing from the teachings of the exemplary embodiments.

[0213] Spatially relative terms, such as "inner," "outer," "beneath," "below," "lower," "above," "upper," etc., may be used herein for ease of description to describe the relationship of one element or feature to another element or feature, as illustrated. Spatially relative terms may be intended to encompass different orientations of the device in use or operation in addition to the orientation shown. For example, if the device in the figures were inverted, elements described as "below" or "below" other elements or features would then be oriented "above" the other elements or features. Thus, the exemplary term "below" can encompass both an orientation of above and below. The device may be otherwise oriented (rotated 90 degrees or at other orientations), and the spatially relative descriptors used herein would be interpreted accordingly.

Claims

1. 1. A sensor provided in a vehicle having a passive entry / passive start (PEPS) system, comprising: The sensor is configured to communicate with a mobile device via Bluetooth® Low Energy (BLE); and The sensor is configured to perform impulse radio (IR) ultra-wideband (UWB) ranging of the mobile device via IR UWB communication with the mobile device based on results of the BLE communication.

2. The sensor of claim 1 , wherein the sensor measures at least one of received signal strength, time of arrival, time difference of arrival, and angle of arrival via the BLE communication.

3. the signal information based on the IR UWB ranging includes at least one of received signal strength, time of arrival, time difference of arrival, and angle of arrival in IR UWB communication with the mobile device; The sensor of claim 1 or 2, wherein the location of the mobile device is determined based on the signal information.

4. The sensor of claim 3 , wherein the IR UWB ranging-based signal information includes at least one of time of arrival and time difference of arrival.

5. The sensor of claim 1 or 2, wherein the sensor measures at least one of a time of arrival and a time difference of arrival based on the IRUWB ranging, and the location of the mobile device is determined based on the at least one of the time of arrival and the time difference of arrival.

6. The sensor according to claim 1 , wherein the sensor is configured to perform IR UWB communication in a time slot assigned based on the BLE communication.

7. The sensor of claim 1 , wherein the IR UWB ranging is two-way ranging.

8. The sensor of claim 1 , wherein the sensor is a plurality of sensors.

9. The vehicle is provided with a plurality of the sensors, The sensor according to claim 1 , wherein the plurality of sensors are provided on any one of a front side, a rear side, one side in the left-right direction of the vehicle, and an opposite side to the one side.

10. A plurality of sensors provided in a vehicle having a passive entry / passive start (PEPS) system, comprising: At least one sensor of the plurality of sensors is configured to perform Bluetooth® Low Energy (hereinafter, referred to as BLE) communication with a mobile device, and to perform IRUWB ranging of the mobile device via impulse radio (IR) ultra-wideband (UWB) communication with the mobile device based on a result of the BLE communication; At least one sensor of the plurality of sensors is configured to perform only the BLE communication among the BLE communication and the IR UWB communication; At least one sensor of the plurality of sensors is configured to perform only the IR UWB communication among the BLE communication and the IR UWB communication.

11. The sensor of claim 1 or 10, wherein the sensor is configured to perform IRUWB ranging of the mobile device upon determining that the mobile device is in proximity to the vehicle based on reception strength obtained by the BLE communication with the mobile device.

12. Using a sensor installed in a vehicle having a passive entry / passive start (PEPS) system, a mobile device communicates with the vehicle using Bluetooth® Low Energy (hereinafter, referred to as BLE), and and using the sensor to perform impulse radio (IR) ultra-wideband (UWB) ranging of the mobile device via IR UWB communication with the mobile device based on results of the BLE communication.

13. 13. The method of claim 12, wherein IR UWB ranging of the mobile device is performed in response to determining, using the sensor, that the mobile device is in proximity to the vehicle based on reception strength obtained by the BLE communication with the mobile device.

Images