Passive entry / passive start systems and methods for vehicles

Abstract

To provide systems and methods for vehicle passive entry / passive start (PEPS).SOLUTION: A communication gateway establishes a Bluetooth low energy communication connection with a portable device. A localization module determines a portable device location based on two-way ranging using impulse radio ultra-side band. The PEPS system performs vehicle functions, such as unlocking a door or trunk, allowing the vehicle to be started, or activating wireless charging, based on the portable device location. 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. A PEPS performs vehicle functions, 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 disclosures of each of the above applications are incorporated herein by reference. [Technical field]

[0002] The present disclosure relates to vehicle passive entry / passive start (PEPS) systems and methods with connectivity, and more particularly, to PEPS systems and methods that use Bluetooth Low Energy (BLE) communication devices, ultra-wide band (UWB) communication devices, and / or wireless charging devices. [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 to start the vehicle by pushing a button. In response to the button push, the PEPS central ECU authenticates the key fob by determining if it is authorized to access the vehicle and uses the signal strength exhibited by multiple vehicle antennas to estimate the location of the key fob. If the key fob is authenticated and located within an authorized zone, vehicle functionality is made available to the user (i.e., the doors are unlocked or the vehicle is started).

[0005] Previous PEPS systems use proprietary grade radio protocols that use low frequency (LF) signals at approximately 125 kHz. Previous PEPS systems are also constrained by the physical nature of the LF system. 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 the LF signal 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 transmission 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 provided in a vehicle having a passive entry / passive start (PEPS) system. The sensor performs IR UWB ranging of a mobile device through impulse radio (IR) ultra-wideband (UWB) communication with the mobile device. The sensor receives communication information related to communication with the mobile device from a communication gateway mounted in the vehicle and connected to the mobile device via Bluetooth (registered trademark) Low Energy (hereinafter, referred to as BLE) communication, and performs IR UWB ranging based on the communication information.

[0008] In other features, the communication information includes timing information regarding communication with the mobile device. In other features, the communication information includes information regarding a communication channel or channel switching parameters. In other features, the sensor is configured to perform IR UWB communication in designated time slots. In other features, the sensor is configured to perform IR UWB communication in a designated time slot, the designated time slot being between a connection event and a subsequent connection event of the BLE communication connection. 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.

[0010] In another feature, the IR UWB ranging is two-way ranging.

[0011] In another feature, the vehicle is provided with a plurality of sensors, the plurality of sensors being 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 method for performing IR UWB ranging of a mobile device using a sensor provided in a vehicle having a passive entry / passive start (PEPS) system, the method comprising: performing IR UWB ranging of the mobile device using the sensor provided in the vehicle through impulse radio (IR) ultra-wideband (UWB) communication with the mobile device, and receiving communication information related to communication with the mobile device from a communication gateway mounted in the vehicle and connected to the mobile device via Bluetooth Low Energy (hereinafter, BLE) communication, the IR UWB ranging being performed based on the communication information.

[0013] In other features, the communication information includes timing information regarding communication with the mobile device. In other features, the sensor is configured to perform IR UWB communication in designated time slots. In other features, the sensor is configured to perform IR UWB communication in a designated time slot, the designated time slot being between a connection event and a subsequent connection event of the BLE communication connection. 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.

[0014] In other features, the signal information includes at least one of a time of arrival and a time difference of arrival.

[0015] In another feature, the IR UWB ranging is two-way ranging.

[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 door of the vehicle, unlocking a trunk of the vehicle, and allowing the vehicle to be started.

[0017] In other features, the communications gateway is configured to control a 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 includes 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 description of the drawings]

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

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

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

[0027] [Diagram 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 of a PEPS system according to the present disclosure.

[0029] [Diagram 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 example 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 stopping 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] 13 illustrates a screenshot of an alert on 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] FIG. 1 shows a sequence diagram of a PEPS system according to the present disclosure.

[0047] [Diagram 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] [Diagram 25]FIG. 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 PREFERRED EMBODIMENTS

[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 of the Bluetooth Consortium. In particular, the present disclosure relates to a PEPS system using a Bluetooth Low Energy (BLE) communication protocol for communication between a vehicle and a BLE-enabled user device, such as a smartphone or a wearable device. Furthermore, the present disclosure applies to vehicle systems with keyless systems, commonly referred to as PEPS systems or keyless entry and keyless go systems. In general, 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 using a sensor network configured to find 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 location of the wireless device to a criterion. As described in more detail below, the PEPS system of the present disclosure includes a central module that collects received signal strengths received from a wireless device from a number of 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 more detail below, this disclosure describes a power-saving, private method for implementing a PEPS system that uses a 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. Additionally, the long range feature is important for convenience features such as passive welcome lighting, distance range for remote parking applications, etc. Such systems and benefits are not achievable with traditional PEPS systems because each vehicle manufacturer and PEPS system supplier traditionally implements proprietary closed systems that use radio frequencies not used by ubiquitous devices such as 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 a direct replacement for the multiple LF antennas used in prior PEPS systems. The systems, methods, and architectures of the present disclosure differ from prior 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 in a vehicle 30 and includes a communication gateway 29 and a number of sensors 31A-31F, collectively referred to as 31. The PEPS system 1 includes one or more vehicle modules 20 that are distributed throughout the vehicle 30 and can communicate with each other, for example, via a vehicle interface 45. Furthermore, some of the modules may be integrated into a single ECU and can communicate 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 the 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 more 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 included 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 delivery 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 Figures 1 and 2, the portable device 10 can communicate with a communication gateway 29 of the vehicle 30 via a secure communication link 680. Without limitation, the portable device 10 may be any Bluetooth-enabled communication device, such as a smartphone, a smart watch, a wearable electronic device, a key fob, a tablet device, or other device associated with a user of the vehicle 30, such as an owner, driver, passenger, and / or mechanic of the vehicle 30. The portable device 10 may include a BLE chipset 11 connected to an antenna 13. The portable device 10 may also include application software 12 stored on a computer-readable storage module or device. The portable device 10 may also optionally include a GPS module 14 or other device location services.

[0058] The mobile device 10 and the communication gateway 29 can establish the secure communication link 680 as a Bluetooth communication link as specified and 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 the communication between the communication gateway 29 and the mobile device 10 is sent 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 the communication channel and channel switching parameters to the connection information distribution module 24. The connection information delivery module 24 is configured to communicate with each of the sensors 31A-31F using the vehicle interface 45 and 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 once the sensors 31A-31F are synchronized with the communication gateway 29. Although 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 the present disclosure provides an example utilizing six sensors, additional or fewer sensors can be used in accordance with the present disclosure.

[0059] 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 inside the sensor 31. Alternatively, the antenna 43 may be located outside the sensor 31. The sensor 31 receives BLE signals using the antenna 43, and in particular, receives BLE physical layer messages using a BLE physical layer (PHY) controller 600. The sensor 31 can observe the BLE physical layer messages and use a channel map generated by the channel map reconstruction module 42 to make measurements of physical properties of the associated signals, including, for example, received signal strength (RSSI). Additionally or alternatively, the sensor 31 can determine other measurements of physical properties 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 of signals received by multiple sensors. The sensor 31 receives timing 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 receipt 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 and tune the PHY controller 600 to a particular channel at a particular time to observe all physical layer messages and data that conform to the Bluetooth physical layer specification, including, for example, normal data rates proposed or adopted in the 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 realized 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 check the 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 to 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] 4, the communication gateway 29 is further configured to provide information regarding ongoing connections and timing signals necessary, for example, for each of the sensors 31 to discover and subsequently track connections with the mobile device 10 maintained by the communication gateway 29. The Bluetooth protocol stack 46 is configured to provide a channel map, an access identifier, a next channel, and a time to the next channel to the application 47. The Bluetooth protocol stack 46 is configured to output timing signals for timestamps of transmit and receive events to the application 47 and / or to a digital PIN output of the BLE chipset 41. The communication gateway 29 also includes a timing synchronization module 44. The timing synchronization module 44 is configured to accept timing signals and works in conjunction with the vehicle interface 45 to generate accurate timestamps of 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 between an authorized mobile device and a PEPS module is established. When authorized access to a vehicle function is required, such as unlocking the door, the mobile device must send an advertising signal to the PEPS module. The PEPS module receives the advertising signal at each of the sensors, processes the information, and makes a decision about 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 of 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. A general limitation is the number of connections is limited to seven sensors due to the fact that most BLE chipsets support a total of eight connections, with one connection usually being a secure connection to a communication gateway. 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, with three channels known as advertising channels. These advertising channels are used by devices to discover each other and report some basic information about what kind of device they are. For example, advertising data typically includes the address of the device broadcasting the advertising packet, as well as the name of the device along with the services the device provides. Automotive systems can detect and measure advertising channel packets with the goal of determining where the 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 subject to the additional communication load required by the advertiser to continue advertising. It may therefore be more advantageous to use the other 37 "connected channels" to determine the location of the device.

[0064] Once two devices are connected, the broadcasting device no longer needs to broadcast to fulfill the communication requirements. However, if the device needs to be located by the system using the advertising channel, it must continue to broadcast on the advertising channel, which creates significant power consumption issues for battery-powered devices. Thus, a system that uses connection data can provide security benefits as well as device power saving benefits. 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, that 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 the authorized zone outside the PEPS system, usually the 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 implementations of BLE chipsets and software stacks 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 allows sensors 31 to follow connected data between authorized mobile devices 10 and communication gateways 29 to make measurements on communication signals and to verify that the measured data is not 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 ​​in arrival times and frequency channels, allowing sensors 31 to find and track existing connection data, thereby ensuring that all sensors 31 are measuring the same signal. In this way, the PEPS system 1 of the present disclosure shares information about the existing connection between mobile devices 10 and communication gateways 29 with each of the sensors 31. In this way, each of the sensors 31 can find the existing communication connection between mobile devices 10 and communication gateways 29, start 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 also applicable to advertising systems such as those described in U.S. Patent Application Publication No. 2014 / 0188348. Additionally, 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 the previous BLE PEPS system, an attacker can 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 the data. Immediately after receiving all the data from the packet, the attacker plays an exact copy of the data on the same frequency channel into the PEPS system by physical location or by modulating the transmission power so that the sensor reads the injected measurement. To protect against this, the PEPS system must detect the presence of two copies of the same or similar data within the expected time window to determine that it is under attack. Either in the sensor itself or in the extended PEPS system, any part of the packet, or a mathematical derivation, can be inspected for a copy 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 multiple possible nearby advertising devices are authorized mobile devices. 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 the cloning simultaneously on all three advertising channels. This technique might ensure that if there is an authorized mobile device, the data is successfully cloned and injected.

[0070] Additionally, a more sophisticated hacker can make a legacy PEPS system reject the original packet by making the injected packet the only valid packet observed. The BLE chipset and stack reject all messages that do not have a valid CRC. The attacker can clone all the data in the packet until the end of the data section. The attacker can 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 of the usable data up to the CRC can then be received by the attacker. The attacker can then use on-board 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 can then receive the message in a corrupted form. Immediately after the CRC is sent by the authorized mobile device and corrupted by the attacker, the attacker can reconstruct the packet using the data cloned from the packet by calculating the checksum and inserting it into the packet. The reconstructed packet can then be injected into the legacy PEPS system.

[0071] Typically, the BLE protocol stack discards messages with invalid CRC fields and does not report this information to upper applications. For a BLE PEPS system to protect itself against the above type of attack, the BLE protocol stack needs to be modified to report messages even if the CRC is invalid. That is, messages that are normally discarded by the BLE protocol stack need to be made available to the PEPS system for processing. In particular, the application needs to 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 will then be able to 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 radio frequency (RF) isolation attacks. 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 very accurate timing expectations on the arrival times of signals, so that the PEPS system has a method of timing synchronization 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 to the expected arrival time. A global timing discrepancy across all sensors indicates that data has been cloned or injected. A discrepancy when sensors are grouped into two or more different sets based on arrival time indicates that an attacker has isolated the sensors so that they do not receive the true signal and injected cloned copies.

[0074] The present disclosure provides methods to detect and mitigate the risk of injection attacks. For example, FIG. 5 shows how a sensor observes when under 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 timings 510A-510F for BLE communications are either the expected advertising intervals of authorized mobile devices, or connection intervals 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 the vehicle function. 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 attacks by observing communications 530 and cloning the data. The attacker then replays data to the PEPS system that has the appropriate signal strength 520 to meet or exceed the decision criterion 551.

[0076] 5, time interval 510A corresponds to a highly accurate measurement from an approved mobile device. The important 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] In time interval 510B, the 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 Figures 6 and 7, can detect that data has been injected by 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 possible packets from a mobile device that the protocol allows. In this technique, two measurement points 520B and 530B are deemed to have originated from an authorized mobile device in time interval 510B until the next expected arrival time at tick 510C, even though the protocol allows only one. 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. In time interval 510B, it can be determined that the calculated variance 552 is too high. It should be noted that the distribution and packet counting techniques described herein are equally suitable for applications across multiple time intervals.

[0078] Continuing to refer to FIG. 5, an attacker in time interval 510C attempts to inject cloned packets 520C into the PEPS system by cloning 530C up to the CRC and then disrupting the sensor's ability to receive the CRC correctly. 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 the 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, so that the PEPS system can 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 including in distributed measurements or timing analysis.

[0079] An attacker in time interval 510D attempts to inject a 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 injection of data 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 indicated as 550. The sensors of the PEPS system require a synchronization method to accurately measure time interval 550, which is described in more detail below.

[0080] It should also be noted that time interval 550 represents a negative amount 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 where the attacker adds a time delay by moving tick marks 510E after recognizing the 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, the sensor 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 eventually be injected early into the system. In general, due to the workload of pre-scanning all of the 37 available connection channels that BLE provides, it is difficult for a BLE device 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 probe a different channel for data from the mobile device to the attacker. Furthermore, it is worth noting that an attacker acting as a MITM will not generate packet 520E that is exactly equal to a packet originating from a mobile device such as 530E. In particular, the FHSS channel number will be different, and the access address for that connection may also be different. What should be searched for is the address of 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 a data injection attack, 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. With reference to FIG. 6, the horizontal axis of the chart represents time and the vertical axis represents the measured signal value. 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 the values ​​520A-520F all meet 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 ranges represented by lines 580, 581. If any of the alternate sensors, such as sensor B, sample 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 allowed access to vehicle functions.

[0082] Continuing to refer to FIG. 6, time interval 510A corresponds to an example of valid data. Data point 530A is between boundaries 580 and 581. In time interval 510B, an attacker has injected a sample into sensor A, but with a time delay with respect to sensor B. The 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 the difference 585 is not within certain system performance and measurement error limits, the security filtering module 33 can detect that data has been injected into the system. In time interval 510C, an attacker has injected data into sensor B ahead of reference sensor A. The same time boundary principles applied for time interval 510B are applicable to time interval 510C. If points 530C, 520C do not match beyond the measurement capabilities of the system, and the difference 586 is not within the system performance and measurement error limits, the security filtering module 33 can detect that data has been injected into the system.

[0083] Continuing with reference to FIG. 6, assuming an attacker is able to 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 may be 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, a 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, such as a mapping to RSSI lines 580 / 581, security filtering module 33 can determine that points 530D and 520D are not corroborated by each other and 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 a 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, for example, hashes using the SHA-256 cryptographic hash algorithm, can be transferred from each sensor to security filtering module 33. If hashes 522 and 532 do not match exactly, security filtering module 33 is configured to determine that data has been injected into the system.

[0085] FIG. 7 illustrates a PEPS system 1 using 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 passes 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 passed to a 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] Continuing to refer to FIG. 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 any wiring in a vehicle communication network, such as, for example, a local interconnect network (LIN) or a controller area network (CAN). However, other communication connections or buses can also be used.

[0087] 7, the communication gateway 29 is configured to share with the timing control module 25 information regarding the current timing information of the secure communication link 680 between the communication gateway 29 and the mobile device 10. The timing control module 25 is configured to transmit the current timing information to a number of sensors 31. Additionally or alternatively, in an embodiment in which advertising data from the mobile device 10 is collected by the sensors 31, the communication gateway 29 is configured to share a timing pulse with each sensor 31. In such a case, the sensor 31 is configured to accept timing information from the communication gateway 29 and record incoming data packets relative to the timing pulse. The sensor 31 reports back to the security filtering module 33 timestamped data that 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] With continued 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 the 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, a channel pre-scan parameter 1270, a channel post-scan parameter 1280, and a connection monitoring parameter 1290. The channel map 1200 tells the sensor 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, it is a simple incrementer. The channel hop interval 1210 corresponds to the connection interval defined in the BLE specification. The channel hop interval 1210 is used to tell each of the sensors 31 how long to wait before starting the process of observing the next channel, as well as to inform the security filtering module 33 and the sensor 31 of the expected arrival time of the next packet. The slave wait time 1220 tells the sensor how many time intervals, as defined by the channel hop interval 1210, the observed device is allowed to skip communication. Typically, this value is zero while locating the mobile device 10. The next channel 1230 tells the sensor 31 the channel in the channel map 1200 on which the next observation should be made. The next channel time 1240 tells the sensor 31 at what time in the future the sensor 31 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 sensor 31 to calculate the time to start observing, compensating for the measurement capabilities of the system and the uncertainty of when each device transmits. Once the sensor 31 receives the information 1200, 1210, 1220, 1230, 1240, and 1250, it 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 a packet. The filtering data may include an expected access identifier for a connection. The filtering data may also include information indicating a minimum length of a 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, timestamp, time difference from a nominal expected arrival time, channel number, whether the CRC is correct, data in the frame, and a hash of any part 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 looking for MITM attacker data and injection data prior to the next observation and prior to a request for observation on 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 an 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 allow 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 according to the Bluetooth specification. During process 1011, the communication gateway 29 performs a scan for the mobile device 10, as defined by the Bluetooth specification. When the communication gateway 29 discovers the mobile device 10, it sends a link request 1021 to the mobile device 10 according to the method defined by the Bluetooth specification. Once a connection between the communication gateway 29 and the mobile device 10 is established, the processes of advertising 1010 and scanning 1011 can be completed according to the Bluetooth specification.

[0091] After the communication link is established, the communication gateway 29 starts the process 1013 and the mobile device 10 starts the process 1012 to maintain the link according to the Bluetooth specification. After the communication link is established, the communication gateway 29 knows all the connection parameters of the communication link and exchanges the 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 a signal 1041 that includes the time to the next event, measured relative to the message itself. The timing synchronization module 44 can precisely timestamp the incoming message to the vehicle interface 45 and control the BLE chipset 41 to observe the required channel according to the connection parameters.

[0092] Continuing to refer to FIG. 9, the sensor 31 executes a process 1014 for receiving 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 will be described in detail below. The sensor 31 sets a time reference to the timing signal 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 the 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 that 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 times of 1050A and 1050B, (4) the arrival time difference between 1050A and 1050B, and (5) the arrival phase and phase angle of each 1050A and 1050B. The scan width of 1015A is defined by the timing uncertainties involved, as well as the behavior of pre-scan and post-scan. Pre-scan and post-scan are important to ensure that no attacker is present within the system's uncertainty window. The information collected during the 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 such that clock accuracy, synchronization error, and pre-scan and post-scan parameters affect the next wake-up 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 either 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 of the sensor 31 synchronizing timing with the communication gateway 29 is shown. In the figure, there are 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 at the same time as the BLE central to BLE peripheral communication 1050A1 / 1050A2. Additionally or alternatively, the communication gateway 29 can also be configured to output timing pulses during the BLE peripheral to BLE central communication, 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 receives 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 a message 1076. The time 1081 that has 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 timer running, and records the time that 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 1082 until the next connection event. As described above with reference to FIG. 9, the connection interval 1080 was previously communicated to the sensor via the 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 arrival time uncertainty 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 a future time 1084 to start observation. The sensor 31 uses a timer to start the observation process 1085 after the time 1084 has passed.

[0094] 12, there is shown a 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. 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 sends the message using the vehicle interface 45 to the sensors 31 of interest.

[0095] Referring again to Figures 1, 2, 3 and 9, the sensor 31 may include a channel map reconstruction module 42 configured to use the connection information signal 1040 and the timing signal 1041 to regenerate connection timing for the secure communication link 680. Figure 10 shows an example of a channel hopping map. In Figure 10, for example, columns 1360-1363 from left to right represent time-incremental connection events. The time that elapses between each column is a connection interval described as the channel hop interval 1210 described above with reference to Figure 8. In this example, the channel hop interval 1210 is equal to the time that elapses between any two adjacent columns, such as 1360 and 1361. It should be noted that the channel hop interval 1210 should be considered as 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 may 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 respect to the data included 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 the message 1040, described above with reference to FIG. 9. In the example described in FIG. 10, the channel represented by row 1335 is not used. Furthermore, the black boxes indicated 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, and 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 of 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 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 the 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 not used. 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, the channel pre-scan parameters 1270 and the channel post-scan parameters 1280 describe the behavior of the PHY controller 600 during the time interval between the time windows represented by the columns of FIG. 10. The clock precision 1250 allows the BLE chipset 41 to spread out the time intervals of each of the black boxes 1351-1353 to accommodate the uncertainty of both the measurement time and the transmission time of each device in the system. Initially, the sensor 31 is not synchronized to the secure communication link 680. Upon receiving the timing signal 1041, the next channel 1230, the next channel time 1240, the sensor 31 has enough information to synchronize its time reference with the connection and determine the future time of the communication measured by the sensor 31 to the next channel time 1240 relative to the timing of the secure communication link 680.

[0097] With respect to FIG. 13, an authentication method is described. The authentication method is triggered by a user action detected by the vehicle 30 described in FIG. 1 and FIG. 2. For example, the PEPS module 27 detects a user action such as grabbing a door handle or pressing a button, as is 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 communication gateway 29, allowing for alternative configurations. The PEPS module 27 must make a decision regarding secure access to the functionality based on the location of the mobile device 10 and security information that 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 to refer to FIG. 13, the PEPS module 27 detects an intent to access a vehicle function 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 if any mobile device 10 is within the zone ID of the vehicle 30. 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 that may access the vehicle function. At 1702, the PEPS module 27 checks the list of mobile devices to determine if 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 the commonly used advanced encryption standard (AES) encryption key. Additionally or alternatively, the counter value can be implemented by an asymmetric public / private key. At 1703, the PEPS module 27 gets 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. The PEPS module 27 then embeds the latitude and longitude of the vehicle 30 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 at 1705 to the communications gateway 29. The communications gateway 29 then transmits at 1706 to the mobile device 10 using BLE. At 1707, an application running on the mobile device 10 decrypts the challenge message. The application running on the mobile device 10 obtains at 1708 the location coordinates of the mobile device 10 in latitude and longitude, along with optional location accuracy information. The application running on the mobile device 10 then performs a mathematical operation at 1709 on the mobile device coordinates received at 1708 and the vehicle 30 coordinates received from the communications gateway 29 (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 coordinates from 1703 to the mobile device coordinates from 1708. Once a value is obtained from the mathematical operation at 1709, the application running on the mobile device 10 then packs the mobile device 10's coordinate information from 1708 as well as the value of the mathematical operation at 1709 into a message and encrypts the packet at 1710 using a key required for communication with the communication gateway 29. The mobile device 10 then transmits the encrypted message from 1710 to the communication gateway 29 at 1711 using BLE. The communication gateway 29 receives the encrypted message from 1710 at 1711. At 1712, the communication gateway 29 forwards the encrypted message from 1710 to the PEPS module 27. At 1713, the PEPS module 27 decrypts the encrypted message from 1710 using a key that matches the communication from the mobile device 10. The PEPS module 27 then extracts the coordinates of the 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 in step 1714 to what is contained in the encrypted message, called the challenge response. The 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 mainly caused by two factors. First, BLE advertising channels are designed to be easily predictable and easily discoverable, allowing any BLE device to discover nearby advertisers without special software and to copy and mimic data. Second, advertising channels implement inherent jitter to avoid message collisions, making it difficult to build a system that allows advertising packets to be verified as authentic by their 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 tolerances on the expected arrival time of advertising data depend only on the required cryptography.

[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 timing of the signals and cross-correlation of the sensor values ​​to verify whether an injection scenario is likely occurring. Although 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 US Patent Application Publication No. 2014 / 0188348 describes a method using connection data where the mobile device connects to each sensor individually. This design has some 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 one, requiring additional communication and processing time.

[0102] 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] Without limitation, the mobile device 10 may be any Bluetooth-enabled communication device, such as a smartphone, a smartwatch, a wearable electronic device, a key fob, a tablet, etc. The mobile device 10 may incorporate other wireless technologies, such as WiFi, impulse radio, etc., that may be used to communicate with the vehicle 30. Although the present disclosure provides an example using Bluetooth communication, the system, method, and architecture of the present disclosure may be implemented using other applicable communication protocols, other authentication systems or methods, or other fine-grained localization. Thus, the system, method, and architecture of the present disclosure is not limited to BLE communication protocols. Furthermore, the system, method, and architecture of the present disclosure 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 know its current location and position error via a telematics module 26 that implements either GPS, an inertial navigation system, GSM signal location, etc. Vehicle information can be collected by the data management layer 23 and shared with the mobile device 10. The 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 is capable of generating and receiving signals compliant with the Bluetooth specification using the antenna 19.

[0107] Each sensor 31 includes a BLE chipset 41 capable of generating and receiving signals conforming to the Bluetooth specification using an antenna 43. The BLE chipset 41 includes a channel map reconstruction module 42 capable of regenerating a 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 not synchronized or have lost synchronization. The sensor 31 includes a timing synchronization module 44 capable of receiving a timing signal from the timing control module 25. The timing control module 25 keeps the multiple 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 follow the channel map and channel hopping scheme that the devices agree upon at the time the communication link is established. FIG. 10 shows an example of a 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. Although it is not impossible for an observer to estimate the channel hopping map, in most practical applications the channel hopping map is considered private and unique for 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 system, method, and architecture of the present disclosure are for disseminating the channel hopping map to sensors 31 in a network so that each sensor 31 can follow the FHSS communication. Thus, the systems, methods and architectures of the present disclosure can be generalized to any FHSS protocol.

[0109] After the 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 an embodiment, 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 the link authentication is established, the data management layer 23 collects the current location of the vehicle 30 from the telematics module 26 and shares the 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 OS. Application software 12 running on the mobile device 10 can compare the estimated relative location of the mobile device 10 to 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 certain action.

[0110] As mentioned above, previous systems use open advertising channels for RSSI measurements. However, these systems may not be secure because advertising data is communicated in public and easily detectable channels. Thus, injection attacks may be performed using freely downloadable phone applications. Previous systems do not address how to handle the 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 power performance of the system. In some systems, multiple connections may be formed with each of the sensors. This situation also significantly increases the amount of transmissions and receptions required to initiate and maintain links with each sensor. Although this primarily addresses the privacy and injection concerns of advertising, it is still very inefficient and introduces new security risks, as no method is disclosed 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 in a network provides many advantages to the implementation of a BLE PEPS system. For example, the smartphone / key fob only needs to consume the energy required to communicate securely with a central communication gateway. There is no additional energy consumption required to communicate with each sensor separately. Furthermore, the use of only one communication channel allows for a significant increase in security due to tight timing constraints, protocol checksums, etc., which are very well understood. 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. The attacker can only know the channel and timing. Injecting a signal into that channel will most likely interfere with the BLE protocol and lead to errors, most likely CRC / checksum errors that will result in packets being dropped and no measurements being made. Furthermore, the use of advertising data may be considered a privacy concern. For example, if a smartphone is advertising all the time, it is easy for someone with a large sensor network to track where that smartphone goes. Advantageously, smart phones 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 smart watch, or other BLE communication devices. The communication gateway 29 may be integrated, for example, into a dedicated short-range communication (DSRC) module. Alternatively, the communication gateway 29 may be integrated into an LTE communication module. The communication data between the communication gateway 29 and the mobile device 10 is encrypted, known to be private and signed, and the authenticity of the data can be determined (not forged). The communication data is securely regenerated, for example, by using counter-based encryption, real-time token exchange, and / or timestamp information.

[0113] The mobile device 10 and the communication gateway 29 establish a trust relationship through a pairing process. The pairing process may include Bluetooth pairing as described in the Bluetooth specification, pairing where additional security information is exchanged between the vehicle system and the phone using the phone and vehicle interfaces, pairing where device addresses, device ID resolution keys, reservation IDs, and encryption keys are exchanged via a cloud infrastructure, and / or pairing where a certificate for use of 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 may include use case restrictions (i.e., 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 of the received BLE signal characteristics. 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 times and propagation time differences, and differences in angle of arrival due to propagation.

[0116] Referring again to Figures 1 and 2, each sensor 31 can communicate with the communication gateway 29. The mobile device 10 can communicate with the communication gateway 29, for example, on an advertising channel or a connected channel, as part of a BLE communication link. Each sensor 31 can passively eavesdrop on the communication 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, the eavesdropping may be between the mobile device 10 and a wearable device, such as a smart watch, associated with the mobile device 10. Each sensor 31 can selectively disable the eavesdropping, i.e. the procedure of tracking the connection, to save power, and then re-enable it. The communication gateway can control which sensors 31 are eavesdropping.

[0117] Further, the communication gateway can provide each sensor 31 with the necessary information for eavesdropping to be resumed. The necessary information for eavesdropping can include, for example, an access identifier of the BLE communication link, which uniquely identifies the communication between the communication gateway 29 and the mobile device 10. Each communication packet includes the access identifier data as a preamble. Thus, the information can include information on how to decode the preamble. This information can also include the currently used channel map so that the sensor 31 knows the set of channels to use when eavesdropping. This information can also include information on the 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 some 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 required 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 prior to 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 according to the disclosed systems, methods, and architectures is the synchronization of schedule tables. Because all communication information required by two devices in the connection process is broadcast in a freely observable format, any BLE communication node that happens to witness or eavesdrop on the connection being formed can obtain the schedule table and therefore scan the communication in a passive eavesdropping mode. However, having sensors that track all connections all the time would be a significant power drain. Thus, if each sensor loses the ability to scan on the correct channel at the correct time, synchronization issues may arise, but it would be beneficial to have a system that can selectively enable or disable tracking of connections. For these reasons, the disclosed systems, methods, and architectures utilize synchronization algorithms to coordinate the communication and eavesdropping of the communication by the sensors 31.

[0120] For example, a message is sent from the communication gateway 29 to each of the sensors 31 that must begin tracking the communication connection. This message contains the information needed by the sensor 31 to decode the communication 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 communication gateway 29, information about the link has been communicated or forwarded to the sensor 31. As mentioned 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 as communicating with a communication interval such as 100 ms. The devices use all channels and channel hop by 5 channels. The current channel, 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 communication gateway 29 issues a command to one or more sensors 31 to start eavesdropping. The start eavesdropping command contains all the information needed for the sensor 31 to start 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 communication between the devices, as shown at 1402. For subsequent connection events, such as 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 communication 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 Sep. 1, 2015, describes a method for tracking objects via a system mounted on a 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 according 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 example 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 US 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 US 9,123,244, a driver arrives at a park in his car and wants to go jogging. The driver does not want to take his car keys or smartphone with him on the jog, but only his smartwatch. However, the vehicle key and smartphone are enabled as car keys, so it is not safe to leave them in the vehicle. For example, if a burglar breaks into the vehicle, he could steal the whole vehicle.

[0126] The disclosure provides a method for temporarily disabling 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. Thus, 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, etc., with devices such as smart watches or athletic equipment such as 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 the decision of 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 device being tracked 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 have encrypted their link, and the phone can trust that the watch is an authorized watch. For example, existing smart watches include a system for encrypting the communication link with the phone for sensitive data exchanged between the watch and the phone. Once a security layer is obtained between the smartphone's operating system (OS) and the smart watch, this is reported to the vehicle for use in trust 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 smart watch. When the smart watch reconnects, the smartphone can ask the watch application to generate a token, thereby verifying that the smart watch is the same device that originally authorized the delegation mode. The security information can also include the GPS location of the smartwatch, which is in the vicinity of the vehicle and in the vicinity of the smartphone. This can reduce the possibility of relay attacks, where the smartwatch is very far from the vehicle, but the above security information can be gated, but not 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. Thus, the locations of the smartphone and smartwatch need to be compared, keeping in mind their relative accuracy.If GPS accuracy is not available with sufficient precision to eliminate relay station attacks, the system can require manual input from the user, such as an alert, when the system is not accurate enough to automatically disable but the user needs to be aware of their detection in the vicinity of the vehicle. For example, the alert can 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 needs to manually activate some interface on the wearable. Rules of the system and method can include disabling certain functions until certain conditions are met, i.e., disabling PEPS on a particular device such as a smartphone or key fob until the watch is returned.

[0130] Using an interface on either the smartphone, the smartwatch / activity monitor, or one of the vehicle displays, the user can set a rule that causes the PEPS system to ignore devices in the vehicle, such as the key fob or smartphone, while the user is out for a jog. For example, both the smartphone and smartwatch interfaces can be used to enter a "handover mode," whereby any key fob / smartphone currently located near the vehicle is 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 lock the vehicle doors using the smartwatch, leaving the smartphone and key fob safely inside the car, preferably out of sight in the glove box to reduce the chance 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. The first part of the rule, that the user is expected to go for a jog, is now satisfied. At this time, the system can track the phone being 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 out for a jog, for example, a wearable device such as a smartwatch leaves communication connection range with the smartphone that remains in the car. The smartphone can report the loss of communication link as described in U.S. Pat. No. 9,123,244 regarding processing rules for loss of secure link. The wearable device can typically start broadcasting on an advertising channel to re-establish a link to the smartphone. Additionally or alternatively, the roles could potentially be reversed, whereby the smartphone broadcasts on the advertising channel. Since the smartwatch and smartphone are out of range of each other, interesting activities related to activating vehicle functions are 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 the example, the user continues jogging and comes back within range of the vehicle system with which the wearable is associated and the smartphone located within the vehicle, at which point the wearable can broadcast, for example, on an advertising channel and the smartphone can scan for those advertisements.

[0133] When the smartphone and wearable discover each other on the advertising channel, a connection is established between the smartphone and the wearable. In the present disclosure, the vehicle system described in U.S. Pat. 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 type of address, i.e., public, resolvable, etc. This information can be used to track BLE connections as described above, although the present disclosure is not limited to BLE communications. All low power wireless networks use some sort of discovery and scheduling / time slots 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 the present disclosure can observe the established connection and can eavesdrop on the communication connection as described above using the published MAC layer specification. By recording the above information, the vehicle system can passively eavesdrop on the connection between the smartphone and the 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. the 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 the wearable in the vicinity of the vehicle using the architecture described by this disclosure.

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

[0137] 15, a conventional vehicle PEPS system 150 is shown along with the requirements that are met 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 the tendency for inaccurate decisions while still allowing correct operation in virtually all practical scenarios so as to avoid user frustration.

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

[0139] Compared to conventional PEPS systems built using 125 kHz LF signals, implementing a PEPS system using BLE communications utilizing 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 multipath, shadowing, and fading issues that can make a PEPS system using low-cost BLE sensors that 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 problem to be addressed is that for sensors located inside the vehicle, the measured RSSI of a signal is strong when the mobile device 10 is inside the vehicle, but is also measured strong when the mobile device is outside the vehicle and in the vehicle window. A further problem to be addressed is that a significant shadow is created by the human body, for example when the mobile device 10 is placed in the back trouser pocket of a person attempting to unlock the vehicle door. The human body is primarily water and absorbs 2.4 GHz signals very efficiently. Thus, 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 2 meters of the door, assuming almost certain free space propagation, the PEPS system will not be able to detect the mobile device 10 as being close enough to the door to allow unlocking when the signal from the mobile device 10 is attenuated by the human body or is exposed 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 would almost certainly tolerate a mobile device 10 more than 2 meters away from the door handle with a clear line of sight to the vehicle sensor 31 and no destructive (or constructive) multipath interference. For the reasons discussed above, such a PEPS system may not always meet user expectations, including the tendency of the PEPS system to make erroneous decisions.

[0141] 16 and 17, a vehicle 30 is shown with a PEPS system utilizing a BLE sensor using BLE communication in the ISM radio band with a 2.4 GHz signal. As mentioned above, due to the uncertainty of 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 allow a start operation of the vehicle when the mobile device 10 is located within an area designated as 164A, while an area within area 164B but outside of area 164A may be designated as an uncertainty zone. In other words, when the mobile device 10 is located in area 164A, the PEPS system may allow a start operation of the vehicle. As will be explained in more detail below, when the mobile device 10 is measured to be outside area 164A but inside area 164B, the mobile device 10 is designated to be within a zone of uncertainty. As mentioned 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] 17, the PEPS system may permit a door unlock operation when the portable device 10 is located within an area designated as 162A, while areas within area 162B but outside area 162A may be designated as zones of uncertainty. In other words, the PEPS system may permit a door unlock operation when the portable device 10 is located within area 162A. As will be explained in more detail below, the portable device 10 is designated to be within a zone of uncertainty when it is measured to be outside area 162A but within area 162B. Furthermore, the PEPS system may permit a trunk unlock operation when the portable device 10 is located within an area designated as 166A, while areas within area 166B but outside area 166A may be designated as zones of uncertainty. 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 portable device is in one of the zones of uncertainty shown in Figures 16 and 17. In such cases, it is known that the portable device 10 may be 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 a more educated and informed user, acceptance of certain restrictions, and predefined 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 the present disclosure.

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

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

[0147] There are some types of limitations or inconveniences for both categories of users. However, unlike traditional PEPS systems where the key fob is virtually unable to communicate with the system user, the BLE PEPS system targets the use of smart devices such as smartphones, tablets, wearable devices such as smart watches, etc., as a replacement for traditional key fobs. These devices contain 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 smart watches or other wearable devices using the same type of interface and quickly accessible by the user. These devices can also use in-device motion sensors to accept user inputs, such as button presses on the interface, voice commands, measuring gestures, both on the screen and in the air. Furthermore, these devices can easily detect their own motion relative to a stationary state and can report their orientation as well as the screen lockout state. They can also use cameras and / or optical sensors designed to measure the lighting of the surrounding background to lock out the screen when someone is talking.

[0148] Using the above set of extended compatibility, the BLE PEPS system according to the system, method, and architecture of the present disclosure can perform a number of different actions. For example, the BLE PEPS system according to the system, method, and architecture of the present disclosure can enable an alert to a user when a PEPS system action is performed on a vehicle, but the PEPS system does not have enough 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 enough 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 acceptable 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 enough evidence to determine that an approved device may be inside the vehicle, but not enough evidence to reduce the false positive rate to an acceptable low rate, an alert can be triggered to the user to confirm that 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 on the phone's operating system, 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 ask for confirmation of behaviors that would be initiated if higher levels of evidence were available. The alerts can incorporate vehicle conditions, such as door lock status or ignition status and brake pedal status.

[0150] The alert can be targeted to all devices that can be 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 and prevent the driver's smartphone from receiving the alert. Alternatively, the PEPS system can be configured to allow all devices to receive the alert. Alternatively, the mobile device 10 can be configured via application settings to receive all alerts regardless of the location of the mobile device 10. Alternatively, if a device that should receive the 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. An alert can also be triggered when the vehicle's unlock button is pressed or a gesture switch (such as a gesture switch to unlock the trunk) is activated, but no authorized device is nearby. An alert can also be triggered when a device mimics 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 an 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 the 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 for each specific action, such as locking the vehicle, unlocking the vehicle, starting the vehicle, etc. Additionally or alternatively, a unique tone can be played on the mobile device 10 for a specific action. Additionally or alternatively, a dictation via the smartphone's text-to-speech function can ask, "Do you want to unlock the doors?" Other text can be read 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 proposed action by speaking "yes," "no," "cancel," "ignore," etc. The existing security system of the smartphone system can be used to determine if the smartwatch has been worn continuously since the PIN was entered, if the smartphone is in an unlocked state, if 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 and therefore it may be more appropriate to alert on the smartphone even if a smartwatch is present.

[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 to be activated, such as a gesture switch to unlock the trunk. When an action is performed, such as pressing a button on a 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 communication gateway 29 and the sensor 31. Based on the determined location of the mobile device 10, the level of evidence of that location, and the user settings regarding the user's tolerance for security and convenience as described above, the PEPS system determines whether to perform an operation of a vehicle function, such as unlocking the doors or trunk of the vehicle 30 or starting the vehicle 30. The PEPS system can read the change in state of an activation switch, such as a door handle. When a change in state of a switch occurs that requires some action to be taken by the PEPS system, the PEPS system checks which mobile devices should receive an alert based on which devices are near the activation zone and which devices have chosen to receive alerts regardless of location. The PEPS system can route messages from the PEPS system through a communications gateway 29 or through a cellular data connection such as an LTE / cloud module to a mobile device 10 such as a smartphone. The PEPS system can be configured to use BLE communications when available, and cellular data such as an LTE data connection when necessary when BLE communications is not available. Messages need to be encrypted and signed to avoid 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 discussed above, the PEPS system can utilize multiple levels of evidence in determining the location of the portable 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 portable device 10 is located near the driver's door of the vehicle 30. The PEPS system can be configured to utilize a higher standard of evidence to make a decision that allows a decision to take action when the activation switch is pressed for more aggressive users who are willing to tolerate some false positives. The PEPS system can be further configured to utilize an even higher standard of evidence to make a decision that allows a decision 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) preferences for acceptable levels of evidence for each action criterion

[0157] For example, each user can configure how they want the devices they own to work with the system: in a vehicle that is 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, may 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 level used by the PEPS system. For example, the user interface may show the user that there is a risk involved in making the system less secure by allowing more false positives. For example, the user interface may visually show where the false positives may be and what they may 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. With reference to FIG. 18, this risk may 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 may still have issues with system performance. However, the alert system of the PEPS system can learn frequently occurring behaviors and bring an alert to the user asking if the user would like to program an override to the PEPS system. For example, a businessman may wear a suit coat and leave a portable 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 such that the portable device 10 is always in an uncertain zone to start the vehicle. When the ignition switch is pressed, the PEPS system can recognize that ignition should be allowed, but the PEPS system may be uncertain as to whether the user's smartphone is really inside the vehicle. As described above, an alert can be triggered to the smartphone and the user can recognize that the vehicle should be started in such a situation. But more importantly, the decision boundary can be arbitrarily modified to approve / accept future ignition commands if, as in this example, evidence collected about the smartphone's location appears to indicate so when the smartphone is in the breast pocket of the suit coat. In a simple form, it may be a multi-dimensional space of future inputs and some surface that, for example, 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 so that the decision boundary can learn the correct action based on user input over time.

[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 go into 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 and alert the user without allowing any passive functions at that time. By way of further example, conflicting evidence occurs when the mobile device 10 is measured near the window line of a vehicle, and a sensor designed to unlock the vehicle is generating evidence that the mobile device 10 is outside the vehicle and near the door, and a sensor inside the vehicle is generating 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 Unlocked state has a significant margin of greater probability when compared to the Ignition state, although 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 when accepting a higher false positive rate for the sake of user convenience is the risk that the mobile device 10 is more than two meters away from the vehicle, but someone can still unlock the door. An alert may be used to warn the user when there is an attacker who may be breaking into the vehicle by alerting the user that an unreliable decision has been made. Additionally or alternatively, this situation may be prevented from happening 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 may be received by the vehicle as they exit and walk away from the vehicle. An attacker may sneak up behind the user and break into the vehicle. Because in this scenario, the user is walking away from the vehicle, and the smartphone can easily detect the walking movement. The PEPS system may incorporate algorithms to detect if the user's smartphone is moving. For example, the phone may report to the PEPS system when movement is starting and stopping. The vehicle lock / unlock function may be disabled for the device when the device is deemed to be in motion or when observed or detected smartphone motion is greater than a predefined motion threshold, effectively reducing the above-mentioned risks. This setting may be made available to the smartphone user in the application settings. For example, the user may be encouraged to enable this setting if the user has configured the system to tolerate false positives in this area.

[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 to securely report measurements to the central controller. The communication gateway or central controller can be in secure BLE communication with the mobile device or nomadic device, and is configured to provide connection information to the passive eavesdropping sensors regarding communication connections with the mobile device or nomadic device, and to collect data from the eavesdropping sensors. The communication gateway or central controller can share with each of the passive eavesdropping sensors communication information required for the passive eavesdropping sensors to passively track communications between the communication gateway or central controller and the mobile device or nomadic device. Each of the eavesdropping sensors is configured, upon receiving the connection information from the communications gateway or central controller, to synchronize its internal timing and communication channel map to find the next scheduled communication between the communications gateway or central controller and the portable or nomadic device, and to observe and measure all subsequent communications between the communications gateway or central controller and the portable or nomadic device. The communications gateway or central controller can be configured to communicate the latitude, longitude, and position measurement error of the vehicle position to the portable or nomadic device. The portable or nomadic device can use a location based service available on the portable 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 communication 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 to known communication characteristics. The security filtering module can compare whether there is more communication data sampled from the mobile or nomadic device in 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 in a given time window exceeds that 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 at different locations or a single device forcing the system to make 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 filtering module.The sensors can receive timing information from the system that allows each sensor to report a timestamp of each received packet. The security filtering module can search for received packets that are too early or too late according to configurable thresholds. The security filtering module can compare the similarity of timing of packets received by multiple sensors to determine if any sensor received data configurably earlier than a nominal value by a configurable value or later than a nominal value by a configurable value, thereby determining if 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 allow 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 that are attributed to authorized sensor measurements.

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

[0166] The communication gateway can be configured to share data transmitted between the portable or nomadic device and the communication gateway with the security filtering module, either in raw format or a cryptographic hash of one or more packets. The security filtering module can be configured to inspect and compare the data or cryptographic hash data from the multiple sensors with the reported data or cryptographic hash of the data received from the communication gateway, such that the security filtering module can verify that each sensor received the same data and that the data is consistent with the data received by the communication gateway. The security filtering module is configured to report the cleaned data to the decision module. If any security rules are not met, the security filtering module can report to the decision module that the system is determined to be under attack. The decision module is configured to optionally send an alert message to an authorized portable or nomadic device via an authenticated BLE communication link. Application software on the portable or nomadic device is optionally 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 the 40 BLE channels at a configurable future time or for a configurable period of time.

[0168] The present disclosure also includes a sensor network, where each sensor is configured to search different BLE channels at different times 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 the communication 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 looks 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 within the recorded packets and compares it to 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 to take a time series of received messages emitted from a portable or nomadic device and reconstruct 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 in a vehicle 230. Similar to the PEPS system 1 described above, the PEPS system 200 includes a communication gateway 229 and a number of sensors 231A-231F, collectively referred to as 231. Similar to the PEPS system 1 described above, in the PEPS system 200 of FIG. 19, the mobile device 210 can communicate with the communication gateway 229 of the vehicle 230 via a secure communication link 280, such as a Bluetooth communication link, as described above with reference to the secure communication link 680. The PEPS system 200 of FIG. 19 is similar to the PEPS system 1 described above, except that the PEPS system 200 of FIG. 19, in addition to utilizing BLE communication, also utilizes impulse radio (IR) ultra-wideband (UWB) communication. More specifically, one or more sensors 231 may be configured to communicate using IR UWB communication in addition to BLE communication. Additionally, the communication gateway 229 is also configured and provided with a communication gateway 229 in addition to BLE communication. For example, the mobile device 210 may communicate with the communication gateway 229 utilizing IR UWB communication. 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 communication. For example, the vehicle 202 may be configured to have one or more sensors 231 configured to communicate using both IR UWB and BLE communication, one or more sensors 231 configured to communicate using only IR UWB, and / or one or more sensors configured to communicate using only BLE communication. In the example of FIG. 19 described herein, the vehicle 202 is referred to as including at least one sensor 231 configured to communicate using IR UWB and one or more sensors configured to communicate using at least BLE communication. Alternatively, the vehicle 202 may include only a sensor 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, the mobile device 210 is similar to the mobile device 10 described above, except that the mobile device 210 is configured to communicate using IR UWB communication in addition to BLE communication. Without limitation, the mobile device 10 may be any device configured for IR UWB and BLE communication, such as a smartphone, a smart watch, a wearable electronic device, a key fob, a tablet device, or other device associated with a user of the vehicle 230, such as an owner, driver, passenger, and / or mechanic of the vehicle 230. The mobile device 210 may include a BLE chipset 11 connected to an antenna 13, as described above. The mobile device 210 may also include application software 12 stored on a computer readable storage module or device, as described above. The mobile device 210 may also optionally include a GPS module 214 or other device location services, as described above.

[0174] 19, the mobile device 210 may be configured with an internal IR UWB communication module or may be provided 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 an exterior surface 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 more 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 communications gateway 229 and the one or more sensors 231 are configured to communicate using IR UWB communications in accordance with 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 allows for more accurate location tracking of the mobile device 210 by using a communication technology such as IR UWB in addition to communication using BLE communication. The additional communication technology such as IR UWB communication may be triggered in response to a predefined key event, such as a time frame immediately following a BLE connection event. In such a case, the PEPS system 200 may wake up 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 may be assigned a time slot for performing two-way ranging based on the sensor's unique identification code. However, not every connection event may trigger two-way ranging, since in many cases ranging may not be necessary and would incur power consumption costs. Thus, the PEPS system 200 may be configured such that a trigger transmitted via BLE communication is transmitted to indicate that ranging should be performed at some future connection, i.e., immediately after 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 a device being tracked and can send 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 consumption savings can be achieved by limiting the use of IR UWB or other ranging technologies by using synchronization with the primary data channel provided by BLE or other low energy protocols, where 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 communications.

[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 using 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 group 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, transmission power and signal strength. The transmit power can be set low, for example, so that tag 250 can only communicate when it is attached to mobile device 210, whereby a certain threshold level of RSSI must be maintained in order 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, since the tag 250 is physically attached to the mobile device 210, the relative orientation of the tag 250 and mobile device 210 can be learned when they are paired with each other. In other words, a simple transformation of x, y, z accelerometer data from each device can be used to move 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 since 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 determination 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 allowed based on, for example, hardware tolerances. A discrepancy in the orientation of the two devices beyond a set tolerance can be used to invalidate the determination of the mobile device's location. Because the tag 250 may slowly slide and shift position relative to the portable device 210 over time, the mapping function can be adjusted based on the orientation indicated at each decision point where the tag 250 and portable device 210 are within tolerance.An averaging / filtering function can be applied to a certain number of recent relative orientations to compensate for small, slow drifts in the precision of the electronics or the physical orientation of the devices relative to each other. For example, the averaging filter can use the most recent relative coordinates that meet a required tolerance.

[0181] As mentioned above, in one configuration, the vehicle 230 may only include the sensor 231 that communicates using IR UWB ranging communications. In this case, the mobile device 210 may communicate with the communications gateway 229 utilizing BLE communications and may communicate with the sensor 231 using IR UWB ranging communications. In this configuration, the PEPS system 200 includes a communications gateway 299 that may communicate with the mobile device 210 using a secure BLE communications connection and may optionally include an IR UWB communications module for communicating with the mobile device 210 using IR UWB communications. In this configuration, the PEPS system 200 also includes an IR UWB sensor 231 that may communicate with the communications gateway 229 via a dedicated bus, such as a CAN bus or LIN bus, or via IR UWB communications if the communications gateway 229 includes an IR UWB communications module. Additionally or alternatively, the IR UWB sensor may communicate information to the mobile device 210 using IR UWB communications, and the mobile device 210 may relay information from the sensor 231 to the communications gateway 229 using BLE communications. In such a configuration, the mobile device 210 is configured to communicate with 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 a verification method for verifying that it is attached to the mobile device 210, as described above.

[0182] Referring to FIG. 20, another configuration of the PEPS system 201 is shown having a vehicle 230 including a sensor 231 that communicates using BLE communication as well as IR UWB ranging communication. For example, in the configuration of the PEPS system 201 shown in FIG. 20, the sensor 231A is a sensor capable of both IR UWB and BLE communication, while the sensor 231C is only capable of IR UWB communication. As shown in FIG. 20, the 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 can 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 needing an attached IR UWB tag 250. As shown in FIG. 20, the mobile device 210 communicates with the communication gateway 229 over a secure communication link 280 using BLE communication. Mobile device 210 communicates with sensor 231C using IR UWB communications over communication link 281. Mobile device 210 communicates with sensor 231A using BLE communications over communication link 282 and IR UWB communications over communication link 283. Referring to FIG. 20, a PEPS system 201 is shown communicating with a mobile device 211 that can communicate using BLE communications but not using IR UWB. Mobile device 210 communicates with communication gateway 229 over secure communication link 280 using BLE communications. Mobile device 210 also communicates with sensor 231A using BLE communications over 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 smartphone, tablet device, and wearable device manufacturers are likely to adopt and utilize precise time-of-flight (TOF) based two-way ranging systems such as IR UWB. Thus, 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 Figures 20 and 21 may be used, allowing users to provide IR UWB on their mobile devices for precise location tracking. A user may not want to install UWB tags and may be willing to accept the limitations and security risks imposed by using a low-cost BLE-only solution. A hybrid configuration may also include the wearable handover mode described above, since the BLE communication portion of the system may be able to roughly locate the wearable device when it returns to the vicinity of the vehicle 230, for example. In this manner, a hybrid configuration system provides a low-cost system for the user and also provides compatibility with BLE devices that are not capable of IR UWB communication.

[0184] As mentioned above, the hybrid configuration system can include a communication gateway 229 configured to communicate with the mobile devices 210, 211 using BLE communication. 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 communication. The combination sensor can measure BLE signal characteristics of advertising and subsequent connection channels, and can 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 using only BLE communication. For example, a BLE-only sensor can be used to deploy a "known location" starting system, whereby the 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. For such BLE-only sensors, the proximity characteristic typically dominates 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 UWB ranging capable as described above and are placed in areas where geometric ranging characteristics are critical to the location of the tracked device, but very little BLE signal information is important. As described above, the hybrid configuration PEPS system 201 is compatible for 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 configuration PEPS system 201 is also compatible for communication with mobile devices 210 that can communicate using both BLE and IR UWB communications. These types of mobile devices 210 may be tracked via UWB ranging, with BLE communications being used as a control channel to enable IR UWB communications only as long as necessary 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 portable devices 210, 211, the PEPS system 201 can also track wearable devices associated with the portable devices 210, 211. The wearable devices can include the delegation functionality described above and can use status messages from the portable devices to indicate whether the associated wearable device is 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 is shown illustrating the operation of the system using two different methods. 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 allocating 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 with IR UWB sensor 1 231 is performed at 2206 and 2208 in ranging slot 1. Furthermore, two-way ranging with IR UWB sensor N is performed 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 with IR UWB sensor 1 231 is performed again at 2216 and 2218 in ranging slot 1. In practice, two-way ranging may not be performed following every connection event, as it would be too costly in terms of energy. Thus, 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, the data packets between the mobile device 210 and the communication gateway 29 can include a trigger. For example, the trigger information can provide instructions to activate 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 to activate ranging when a connection event arrives on a particular BLE channel, e.g., every time the system communicates on channel 5, or when on channels 5, 15, 25, and 32, for example. Additionally or alternatively, the trigger information can provide instructions to activate ranging on every Nth connection event starting after the next Y connection events. For example, starting within 3 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 about which channel is the current channel. Therefore, the communication node must implement a mode of initial discovery. For example, if the system should be operated when communication is 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 subsequent communication link is observed. Then, a schedule table can be established to follow the BLE communication link. 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 of IR UWB ranging requests. Thus, the receiver can scan for IR UWB two-way ranging requests from the correct device (such as preamble). When an IR UWB request is received, the receiver can set the next scan time to N times the connection interval. In this way, synchronization can be achieved.

[0189] The ranging system described in the sequence diagram of Figure 22 uses two-way ranging. However, there are other modes available in which the 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, may result in higher energy consumption and is therefore initiated based on BLE commands between the nodes.

[0190] IR UWB communication systems can be attacked at the physical layer by attacks such as "preamble injection" attacks and "cicada attacks". Ways to reduce the chances of an attacker succeeding are to use the shortest possible symbols (higher bit rates) and to use unpredictable preambles. However, by reducing the symbol length, the effective communication range is reduced. The system requires adaptive settings because some functions, such as welcoming long distances, have low accuracy and minimal security concerns at long distances, while other functions, such as door unlocking, require high security at short distances. The system can vary the symbol rate from a long symbol rate that provides a longer communication range but less robust IR UWB ranging, to a short symbol rate that provides a shorter communication range but more robust IR UWB ranging. Negotiation of which symbol rate is used and when is controlled can be done via communication between the portable device 210 and the vehicle system through the communication gateway 29 by BLE communication messages.

[0191] Also, 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. Thus, the system can implement a method in which the temporary preamble is selected, either partially or entirely, by either the mobile device 210 or the vehicle system. An example of a partial preamble includes selecting some number of bits smaller than the preamble size. This data may be a subset of the preamble or may be used by all nodes to determine a larger preamble as a seed for a deterministic generation algorithm. The temporary preamble is then deployed throughout the system using the BLE communication network immediately prior to use. The sequence diagram shown in FIG. 22 explains 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 transferred with the preamble used during the ranging command.

[0192] Numerous triggers can be used to activate the IR UWB ranging system. These triggers also trigger the system to change the bit rate / symbol rate of the IR UWB to change from long range to short range or vice versa. The triggers can include using the RSSI of the BLE control channel to determine that the IR UWB system is close enough to the vehicle system to activate the welcome / approach function. Additionally, the IR UWB communication can be disabled immediately after activation of the welcome function to reduce power consumption. The triggers can also include using the coarse location capabilities of the BLE sensor network to determine that the mobile device 210 is relatively close to a critical activation zone, such as, for example, near the driver's door for an unlock function, near the lift gate, or near the passenger door, or the mobile device 210 is believed to be inside the vehicle and the start button may be pressed soon. The triggers can also include using a vehicle occupant detection system incorporating weight sensors and / or visual recognition of the occupants. To reduce power consumption, the IR UWB system can disable the "ignition on" scenario until someone is found to be in the driver's seat or the brake pedal is pressed, 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 approach 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 the current direction and movement of travel. The speed of approach relative to the vehicle can then be derived from this data.In this way, the ranging and authentication system can be selectively activated or triggered early when the mobile device 210 will soon reach the decision zone. For example, a user may be running to a vehicle and in a hurry, perhaps because it is raining or being chased by a burglar. The ranging system can remain activated to predict the exact time the person will arrive at the safe 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 safe decision zone, only the position of the mobile device relative to the vehicle is pending. This allows functions such as unlocking the doors or automatically opening the lift gate based on the very quick approach of the user. The trigger can also include enabling the ranging system longer, closer to the long-range welcome feature, to calculate the "speed of approach" to determine that the system should remain on and enable the above use cases 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 in either case, if it is simply energy efficient to use this method. 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 article 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 be automatically opened. 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 in the vicinity of a decision zone, e.g., in the vicinity of 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 IR UWB system of the second tag so that the vehicle system can accurately locate the tag.

[0193] Referring to FIG. 23, another PEPS system 300 is provided in a vehicle 202. Similar to the PEPS systems 1, 200 described above, the PEPS system 300 includes a communication gateway 329 configured to communicate with a mobile device 311, such as a smartphone, a smart watch, a wearable electronic device, a key fob, a 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 that can communicate with a conventional PEPS key fob, such as those currently used in conventional LF PEPS systems. For example, the PEPS system 300 can 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 can 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 communications 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 a wireless charging capability, i.e., wireless power transfer capability. The wireless charging capability 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 with the Qi charging device may observe a wireless charger ping request from the LF antenna at approximately 4 meters, for example, based on the receiving gain of the Qi receiver of the portable device 311. Communications, such as a Qi wireless charger ping request, to / from the LF antenna 331 to the portable device 311 are shown at 381. Although the communications 381 are shown with a single LF antenna 331, it is understood that communications are occurring between the portable device 311 and each of the LF antennas 331.

[0195] The amount of power provided to the LF antenna 331 may be changed such that the LF driver reduces the transmit gain to achieve a smaller communication range when a range less than 4 meters is targeted. Additionally, 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 may be learned by the vehicle through a calibration that is set based on the type of mobile device. The results of the calibration may then be transmitted to the vehicle PEPS system when the mobile device 311 is first paired with the vehicle PEPS system 300. Alternatively, the receiver gain may 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 may transmit several packets at various power levels to the mobile device 311, and the mobile device 311 may respond to each communication packet received. The LF driver or transmitter may then measure a 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 path loss, 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 portable device 311. The LF driver or transmitter can also communicate with conventional 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 conventional PEPS systems. Conventional key fobs can also be modified to implement the Qi specification. Thus, the LF antenna 331 does not need to change its communications protocol to accommodate both.

[0197] The portable device 311 utilizes a secure encrypted communication link 380 to the communication gateway 329 of the vehicle 330, such as a secure BLE communication link 380. Additionally or alternatively, the communication link 380 may be an IR UWB communication link, or other standardized or proprietary protocol. The portable device 311 includes a Qi charging device that can communicate with application software operating on the portable device 311. When the portable 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 portable device 311. The application software creates a cryptographic response based on the data in the packet using a key or set of keys exchanged between the vehicle system and the portable device 311 when the portable device 311 was paired with the vehicle system. The response is then transmitted by the portable device 311 to the communication gateway module over the secure BLE communication link 380. The data transmitted over the secure BLE communication link 380 is encrypted. Optionally, the data can be configured to be replay-safe, i.e., by using a counter-based encryption such as AES-CCM. Optionally, the data can be signed, i.e. by using AES-CCM or by using signatures over 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 attacks by measuring the arrival time or arrival time difference of the responses.

[0198] The PEPS system 300 includes one or more communication gateways 329 that can securely communicate with the mobile device 311, such as by using BLE communications, as described above. The communication gateway 329 can generate 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 ensure that they have the keys exchanged when the mobile device 311 is paired with the vehicle system to understand the encrypted data exchanged between the devices. In this manner, the communication gateway 329 and the mobile device 311 can freely pass data back and forth to 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 the LF antenna to 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 of each ping so that each ping is unique. LF pings may be transmitted periodically. LF pings may also be transmitted upon operation of the vehicle, such as a door button being actuated or a start push button being actuated. 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 the RSSI between the communications gateway and the mobile device. The signal characteristics may be used to estimate the distance from the mobile device 311 to the communications gateway 329, such that an LF ping may 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, where data from several other sensors in the vehicle may 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 communication gateway 329 can receive the challenge response from the mobile device 311, decode it, and optionally check the replay 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 communication gateway 329, the communication gateway 329 can communicate with the vehicle access subsystem and the vehicle start subsystem in the vehicle 330 to lock / unlock the doors or change the vehicle ignition state based on well-established rules, for example, the location established by the “Thatcham” requirements. Authentication can also be used to restrict the wireless charging function at 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 function.

[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. The 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 the communications gateway 329, the LF antenna 331, and the portable device 311. The sequence diagram assumes that cryptographic information required by the portable device 311 to compute a secure challenge response to a challenge code was distributed between the communications gateway 329 and the portable device 3111 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 an appropriate power level along with data including the challenge. The mobile device 311 can then receive the challenge, calculate the challenge response, and measure RSSI and timestamp data. At 386, the mobile device 311 sends a response via BLE communication to the communications gateway. The communications gateway then determines, for the mobile device that responded, 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 a charging station inside and / or outside the vehicle.

[0203] The description of the above-mentioned embodiments is 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 may 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 as departures 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 the 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 described 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 technologies 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 the 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 replaced with 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 the medium and may therefore be considered tangible and non-transient. Non-limiting examples of non-transient, tangible computer-readable media include non-volatile memory, volatile memory, magnetic storage, and optical storage.

[0206] The apparatus and methods described in this application may be implemented in part or in full 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, flow chart components, and other elements described above serve as software specifications and 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 depends on stored data. Computer programs include 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, and the like.

[0208] A computer program may include (i) a 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 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®, VisualBasic®, Lua, and Python®.

[0209] None of the elements recited in the claims are intended to be a means-plus-function element 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, the phrase "operation of," or "step of."

[0210] The terms used herein are merely for the purpose of describing certain exemplary embodiments and are 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 indicates otherwise. The terms "comprises", "comprising", "including" and "having" are inclusive and thus specify the presence of a stated feature, integer, step, operation, element, and / or component, but do not preclude 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 the methods described herein should not be construed as necessarily requiring their execution in the particular order described or illustrated, unless specifically identified as an order of execution. 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, connected, 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, there may be no intervening elements or layers present. Other words 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, third, etc. may be used herein to describe various elements, components, regions, layers, and / or sections, but 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, as used herein, do not imply any sequence or order unless the context clearly dictates otherwise. Thus, a described first element, component, region, layer, or section may 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," and the like, may be used herein for ease of description to describe the relationship of one element or feature to another element or feature as depicted. Spatially relative terms may be intended to encompass different orientations of the device in use or operation in addition to the orientation depicted. For example, if the device in the figures were inverted, elements described as "below" or "below" other elements or features would 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 oriented in other ways (rotated 90 degrees or at other orientations) and the spatially relative descriptors used herein would be interpreted accordingly.

Claims

1. A sensor provided in a vehicle having a passive entry / passive start (PEPS) system, comprising: the sensor performs impulse radio (IR) ultra-wideband (UWB) ranging of the mobile device via IR UWB communication with the mobile device; The sensor is mounted on the vehicle, receives communication information regarding communication with the mobile device from a communication gateway that is connected to the mobile device via Bluetooth (registered trademark) Low Energy (hereinafter, referred to as "BLE") communication, and performs the IR UWB ranging based on the communication information.

2. The sensor of claim 1 , wherein the communication information includes timing information regarding communication with the portable device.

3. The sensor of claim 1 , wherein the sensor is configured for IR UWB communications in designated time slots.

4. the sensor is configured to perform IR UWB communication in a designated time slot; The sensor of claim 1 , wherein the designated time slot is set between a connection event of the BLE communication connection and a connection event following the connection event.

5. The IR UWB ranging based signal information 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 , wherein a location of the mobile device is determined based on the signal information.

6. The sensor of claim 1 or 5, wherein the IR UWB ranging based signal information includes at least one of time of arrival and time difference of arrival.

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

8. 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 a left-right direction of the vehicle, and an opposite side to the one side of the vehicle.

9. The vehicle is provided with a plurality of the sensors, The sensor of claim 1 , wherein a plurality of the sensors are configured to receive the communication information relating to the BLE communication connection from the communication gateway.

10. performing impulse radio (IR) ultra-wideband (UWB) ranging of a portable device via IR UWB communication with the portable device using a sensor provided in a vehicle having a passive entry / passive start (PEPS) system; and receiving communication information regarding communication with the mobile device from a communication gateway that is mounted on the vehicle and is connected to the mobile device via Bluetooth (registered trademark) Low Energy (hereinafter, BLE) communication; The method, wherein the IR UWB ranging is performed based on the communication information.

11. The method of claim 10 , wherein the communication information includes timing information regarding communications with the mobile device.

12. The method of claim 10 , wherein the sensors are configured to perform IR UWB communications in designated time slots.

13. the sensor is configured to perform IR UWB communication in a designated time slot; The method of claim 10 , wherein the designated time slot is set between a connection event of the BLE communication connection and a connection event following the connection event.

14. The IR UWB ranging based signal information 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 method of claim 10 , wherein a location of the mobile device is determined based on the signal information.

15. The method of claim 10 or 14, wherein the IR UWB ranging based signal information includes at least one of time of arrival and time difference of arrival.

16. The method according to any of claims 10 to 15, wherein the IR UWB ranging is two-way ranging.

17. The vehicle is provided with a plurality of the sensors, 17. The method of claim 10, wherein a plurality of the sensors receive the communication information relating to the BLE communication connection from the communication gateway.

18. A sensor provided in a vehicle having a passive entry / passive start (PEPS) system, comprising: the sensor performs impulse radio (IR) ultra-wideband (UWB) ranging of the mobile device via IR UWB communication with the mobile device; The sensor is mounted on the vehicle, receives information about a communication channel from a communication gateway that is connected to the mobile device via Bluetooth (registered trademark) Low Energy (hereinafter, referred to as BLE) communication, and performs the IR UWB ranging based on the information about the communication channel.

19. performing impulse radio (IR) ultra-wideband (UWB) ranging of a portable device via IR UWB communication with the portable device using a sensor provided in a vehicle having a passive entry / passive start (PEPS) system; and receiving information about a communication channel from a communication gateway that is mounted in the vehicle and is connected to the mobile device via Bluetooth (registered trademark) Low Energy (hereinafter, BLE) communication; 4. A method according to claim 1, wherein said IR UWB ranging is performed based on information about said communication channel.

Images