Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W8/00—Network data management
  • H04W8/005—Discovery of network devices, e.g. terminals
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
  • H04L69/06—Notations for structuring of protocol data, e.g. abstract syntax notation one [ASN.1]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W24/00—Supervisory, monitoring or testing arrangements
  • H04W24/08—Testing, supervising or monitoring using real traffic
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W24/00—Supervisory, monitoring or testing arrangements
  • H04W24/10—Scheduling measurement reports ; Arrangements for measurement reports
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
  • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W84/00—Network topologies
  • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
  • H04W84/10—Small scale networks; Flat hierarchical networks
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
  • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
  • H04W12/06—Authentication
  • H04W12/065—Continuous authentication
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W84/00—Network topologies
  • H04W84/18—Self-organising networks, e.g. ad-hoc networks or sensor networks

Definitions

• the present application relates to the technical field of Internet of Things (IoT) technologies and, in particular, to an architecture framework for the service recording Bluetooth low energy (BLE) physical layer features.
• IoT Internet of Things
• BLE Bluetooth low energy
• BLE is increasingly becoming popular for IoT applications that require short range communication and low energy consumption. It has wide variety of applications such as millions of personal devices, sensor networks, smart home devices, medical equipment, industrial applications etc. Some of the recent applications to vehicular industry include “Digital Key solutions for Vehicles” .
• the present application provides a signal processing recording method and related products, so as to implement an architecture framework for the service recording BLE physical layer features.
• a first aspect the present application relates to a signal processing method applied in a first device, where the first device is a bluetooth low energy BLE device, and the method includes:
• the present application proposes utilizing the default packet transmission that is already present in BLE connections to realize the recording of the channel features.
• the first device receives, at a connection interval change, a signal from a second device, measures at least one physical feature of the received signal, extracts at least one piece of raw data for the at least one physical feature of the received signal; and converts the at least one piece of raw data into at least one attribute in a preset format, in this way, the recording of physical features for the BLE device is realized.
• the physical feature herein refers to the BLE channel feature.
• the proposed framework for the secure service recording BLE channel’s physical layer features can be incorporated into any platform/OS environment having the BLE stack, thus achieving efficient secure automatic recording of BLE channel features.
• the converting the at least one piece of raw data into at least one attribute in a preset format includes:
• the converting of the attribute based on the L2CAP enables efficient recording of the BLE channel features.
• an application programming interface API is provided for the first device based on an attribute protocol ATT; the method further includes:
• the accessing and updating of the attribute corresponding to the physical feature is achieved.
• a first aspect the present application relates to a first device, wherein the first device is a bluetooth low energy BLE device, and includes:
• a receiving module configured to receive, at a connection interval change, a signal from a second device, wherein the second device is a BLE device;
• a measuring module configured to measure at least one physical feature of the received signal
• an extracting module configured to extract at least one piece of raw data for the at least one physical feature of the received signal
• a converting module configured to convert the at least one piece of raw data into at least one attribute in a preset format, wherein the at least one attribute corresponds to the at least one physical feature respectively.
• a third aspect relates to a bluetooth low energy BLE device, comprising: a processor and a memory, the memory is configured to store a computer program, the processor is configured to call and run the computer program stored in the memory, and execute the method according to the first aspect or any possible implementations thereof.
• a fourth aspect relates to a computer-readable storage medium, configured to store a computer program that enables a computer to execute the method according to the first aspect or any possible implementations thereof.
• a fifth aspect relates to a computer program product, comprising computer program instructions that cause a computer to execute the method according to the first aspect or any possible implementations thereof.
• a sixth aspect relates to a computer program, wherein the computer program causes a computer to execute the method according to the first aspect or any possible implementations thereof.
• FIG. 1 shows a BLE device connection establishment procedure.
• FIG. 2 shows a BLE device data exchange after connection establishment.
• FIG. 3 shows BLE Stack architecture
• FIG. 4 shows a BLE stack architecture with a proposed framework.
• FIG. 5 shows a schematic flowchart of a signal processing method according to an embodiment of the present application.
• FIG. 6 shows an example of implementation of the proposed framework provided by an embodiment of the present application.
• FIG. 7 shows an example data structure implementation in C language.
• FIG. 8 shows a schematic structural diagram of a first device provided by an embodiment of the present application.
• FIG. 9 shows another schematic structural diagram of a first device provided by an embodiment of the present application.
• a disclosure in connection with a described method may also hold true for a corresponding device or system configured to perform the method and vice versa.
• a corresponding device may include one or a plurality of units, e.g. functional units, to perform the described one or plurality of method steps (e.g. one unit performing the one or plurality of steps, or a plurality of units each performing one or more of the plurality of steps) , even if such one or more units are not explicitly described or illustrated in the figures.
• a specific apparatus is described based on one or a plurality of units, e.g.
• a corresponding method may include one step to perform the functionality of the one or plurality of units (e.g. one step performing the functionality of the one or plurality of units, or a plurality of steps each performing the functionality of one or more of the plurality of units) , even if such one or plurality of steps are not explicitly described or illustrated in the figures. Further, it is understood that the features of the various exemplary embodiments and/or aspects described herein may be combined with each other, unless specifically noted otherwise.
• Continuous Mutual Authentication is essential to secure bluetooth low energy (BLE) devices from attacks. It is also essential to verify periodically that each BLE device is connected to an intended device. Additionally, Secure Proximity Verification is necessary. However, resource constrained devices cannot employ strong cryptographic mechanisms that depend on special hardware. A lightweight Secure Mutual Authentication Mechanism with proximity verification is very much essential to secure BLE devices against security threats.
• RSS Received Signal strength
• Physical layer features of a wireless channel are important to design secure solutions for BLE applications like proximity verification, mutual authentication etc.
• the present application presents an architecture framework for the secure service recording BLE channel’s physical layer features automatically in a synchronized manner, which can be incorporated into any platform/OS environment having BLE stack.
• the proposed architecture is lightweight and has small footprint, which can be easily ported to any BLE platforms.
• FIG. 1 is a BLE device connection establishment procedure. Once the CONNECT_REQ packet is sent or received, the devices are connected and data packets can be exchanged. The Initiator becomes the Link Layer Master, while the Advertiser becomes the Link Layer Slave.
• connection events As shown in FIG. 2, once connected, the Master/Slave exchange data packets at regular intervals, called "connection events" .
• the connection interval is in a range of 7.5ms to 4s (step size: 1.25ms) and 0-byte data packets are exchanged if there is no other data to exchange.
• the devices hop to another channel using adaptive Frequency Hopping.
• the solutions of the present application are proposed based on basic analysis of characteristics of the channel features of the BLE device, which may include:
• BLE has a total of 40 channels (0-39) -3 channels 37, 38 and 39 are used for advertisement beacon transmission, and remaining channels are used for data transmission after connection. All channels of BLE experience different multipath fading since they are separated by 2MHz frequency;
• connection interval of the BLE connection and packets exchanged between BLE devices therein. It is noted that the devices exchange valid data packets at each connection interval if there is data available, otherwise they exchange a dummy ‘0’ byte packet. Besides, large data packets are fragmented and sent in small-multiple packets, which is actually handled by the BLE stack.
• the present application proposes utilizing the default packet transmission that is already present in BLE connections to realize the recording of the channel features.
• the channel features may be recorded at each “Connection Interval change” (shown as change between two connection intervals in FIG. 2) and log them via a service to shared memory, so that applications can use this information for security purposes.
• Connection Interval change shown as change between two connection intervals in FIG. 2
• recording highly correlated BLE channel features could be automated on two connected devices without sending the explicit PROBE and RESPONSE packets, which are utilized in existing methods for application-level signal measurements.
• the present application thus proposes a framework implemented on the basis of a traditional BLE Stack architecture, and the embodiments of the present application may be applied to the BLE stack architecture with the proposed framework.
• FIG. 3 shows default architecture of BLE stack and how different layers will be implemented on a given platform.
• FIG. 4 shows BLE architecture with a proposed secure service framework.
• FIG. 4 illustrates how the proposed service will be incorporated with the BLE stack architecture shown in FIG. 3.
• the proposed service consists of six components as shown in the architecture diagram, including a physical layer (PHY) , a link layer (LL) , a logical link control and adaptation protocol (L2CAP) , an attribute protocol (ATT) , a generic attribute protocol (GATT) and an application layer (APP) .
• PHY physical layer
• L2CAP logical link control and adaptation protocol
• ATT attribute protocol
• GATT generic attribute protocol
• APP application layer
• FIG. 5 shows a schematic flowchart of a signal processing method according to an embodiment of the present application.
• the steps of the signal processing method may be explained in the following with respect to the architecture shown in FIG. 4.
• the method may be applied in a first device and a second device, where both of the first device and the second device are BLE devices, and the method includes following steps:
• S501 the second device transmits, at a connection interval change, a signal to a first device.
• the second device may be a device which has already been connected to the first device, for example, the connection between the first device and the second device may have been established with reference to the process described in FIG. 1.
• connection interval change refers to the change between two connection intervals shown in FIG. 2.
• the two BLE devices may communicate according to the mechanism described with reference to the BLE protocols.
• the second device transmits default packets, which may be generally used for synchronization, to the first device.
• the default packet may be sent by the second device in the signal (which may be a radio signal) , and the signal is then received by the first device for later measurement and extraction.
• S502 the first device receives the signal at the connection interval change from the second device.
• S503 the first device measures at least one physical feature of the received signal.
• the first device may measure the physical feature of the received signal. Techniques in related art may be adopted herein for implementing the measurement.
• the step S502 and S503 may correspond to the signal reception shown in FIG. 4.
• the physical feature herein refers to the BLE channel feature.
• the signal may be received by the first device at a physical layer, PHY, and the first device may measure the at least one physical feature of the received signal at the PHY.
• default packets (generally used for synchronization) are exchanged and the physical features such as the RSSI of these synchronization packets may be measured and stored in a memory pool so that any application can make use of this data later.
• the first device may extract one physical feature or a plurality of physical features, depending on actual situations and the version of the BLE protocol applied by the first device.
• the common channel features available in BLE of all versions is received signal strength (RSS) .
• RSS received signal strength
• Other features new to BLE version 5 and above are, for example, angle of arrival, angle of departure and time of flight.
• the first device extracts at least one piece of raw data for the at least one physical feature of the received signal.
• the raw data here refers to data in a raw format, i.e., a raw number without having any metric.
• the first device may extract raw data from the extracted physical feature.
• the step S504 may correspond to the Feature extraction in FIG. 4.
• the first device extracts the at least one piece of raw data for the at least one physical feature of the received signal at a link layer (LL) .
• LL link layer
• the frequency of the extraction it is not hard requirement to measure RSSI after every interval change, however, the frequency of the extraction or the measurement may be decided according to actual situations. Generally, at least 10 times RSSI collection in a second is good. However, more data collection is always good for fine grained variation analysis etc. Once the RSSI data is logged in memory, upper layers can access them at any time either in sync with RSSI collection time or based on application requirement.
• the first device may measure one physical feature or a plurality of physical features, correspondingly, when measuring one physical feature, the first device may extract one piece of raw data; or, when measuring a plurality of physical feature, the first device may extract a plurality of pieces of raw data.
• the first device converts the at least one piece of raw data into at least one attribute in a preset format, wherein the at least one attribute corresponds to the at least one physical feature respectively.
• the preset format may be a predefined format which is readable for a user.
• the first device converts the at least one piece of raw data into the at least one attribute in the preset format based on a logical link control and adaptation protocol (L2CAP) .
• L2CAP logical link control and adaptation protocol
• the step S505 may correspond to the Feature recording in FIG. 4.
• the number of the attributes also corresponds to the number of physical features. That is, after the extraction, one piece of raw data is obtained for each physical feature, and then said piece of raw data is converted into one attribute in a preset format. Hence, when there are a plurality of physical features, a plurality of pieces of raw data would be extracted, which are then converted to a plurality of attributes.
• the first device receives, at a connection interval change, a signal from a second device, measures at least one physical feature of the received signal, extracts at least one piece of raw data for the at least one physical feature of the received signal; and converts the at least one piece of raw data into at least one attribute in a preset format, in this way, the recording of physical features for the BLE device is realized.
• the proposed framework for the secure service recording BLE channel’s physical layer features can be incorporated into any platform/OS environment having the BLE stack, thus achieving efficient secure automatic recording of BLE channel features.
• an application programming interface is provided for the first device based on an attribute protocol ATT, the first device may then update the converted attribute through the API. This may correspond to the Attribute update in FIG. 4.
• an attribute access interface is provided for the first device based on a generic attribute protocol (GATT) , the first device may then access the converted attribute through the attribute access interface. This may correspond to the Attribute access in FIG. 4.
• GATT generic attribute protocol
• step S503 may be implemented as: extracting a plurality pieces of raw data for a plurality of physical features of the received signal; correspondingly, step S504 may be implemented as converting the plurality pieces of raw data into a plurality of attributes in the preset format.
• the first device may then access the plurality of attributes at an application layer (APP) by an application.
• APP application layer
• the plurality of attributes may also be referred to as an attribute pool (as shown in FIG. 4) and different applications may then access the attribute pool depending on actual needs.
• FIG. 6 shows an example of implementation of the proposed framework provided by an embodiment of the present application, it illustrates an example implementation of the proposed framework with the BLE stack. As shown in FIG. 6:
• Signal reception it occupies the physical layer part where the analog signal reaches to the receiver device (i.e., the first device) .
• this interface will be the antenna receiving signals.
• the analog signal is detected and frame capturing starts, which can be part of chip or separate function as part of BLE stack.
• the component implemented at the LL extracts the physical layer feature from the analog signal in a raw format (without having any metric, simply a raw number, such as the raw value 65432 shown in FIG. 6) and stores it into internal registers or data structure.
• the component corresponding to L2CAP converts the raw signal value to a human readable value of an attribute.
• the raw value 655432 is converted into a negative integer -65dB.
• the attribute at said component can be a single value or a structure (entity) with multiple values/fields.
• it should be implemented as a UNION data type (in C) to allow future extension.
• the data type would change depending on the specific implementation language.
• Attribute Update the component based on ATT provides an API/method to read/access the attribute generated at the component based on L2CAP.
• Attribute Access the component based on GATT provides interface between the application level component and the component based on ATT.
• Attribute pool the component implemented at the application layer provides a pool of attributes that can be accessed by different applications. This part will be application/platform OS specific implementation (e.g., Android, iOS, Linux, Windows etc., ) and can be optional to the base BLE stack.
• the illustration of implementation in FIG. 6 is an example to describe how the proposed architecture framework can be integrated into a product or device by the manufacturer.
• a manufacturer may change the original BLE stack to produce a custom BLE stack.
• the proposed framework can be integrated post-manufacturing process also. It means, the proposed framework can also be integrated into existing BLE products depending on the availability of open API/access permissions etc., about received BLE signals/packets from original manufacturer.
• FIG. 7 shows an example of implementation of the (data) structure in C for capturing and storing the BLE physical layer features. Equivalent implementation can be achieved in other programming languages.
• the entities in the structure are minimum requirements for the fields, however, more details and fields can be added depending on implementation requirements and also keeping some buffer space future extension/updates of design.
• the proposed architecture framework provides an easy and efficient way of recording the unique physical layer features of BLE channel on any BLE enabled device, in addition, the proposed framework has lightweight structures and consume very little amount of memory, that can be incorporated with existing BLE stack on any platform, even on the resource constrained platforms –Platform independent.
• the service designed will run in the background and help applications to extract BLE channel features without doing any extra work, which means that application developers need not worry about the basics and internal functionality about extracting physical layer features, this saves a lot time during application development.
• the service records BLE features without using any explicit probe/response packets that are energy consuming, rather uses the default sync messages used by BLE. Thus, do not add any energy overheads to the BLE devices.
• the physical layer feature recording facility can greatly improve the security of BILLIONS of BLE device in future if this is included in the BLE stack architecture. Compared to other products in the market, the ‘service recording physical layer features’ can be beneficial for providing robust security.
• the proposed patent has very high commercial value, as it can be implemented in a variety of BLE products.
• the proposed framework for service can be implemented as either a thread, a service, a background program, a daemon, or as a lightweight client server architecture.
• FIG. 8 shows a schematic structural diagram of a first device 800 provided by an embodiment of the present application.
• the first device 800 is a bluetooth low energy BLE device and includes:
• a receiving module 801 configured to receive, at a connection interval change, a signal from a second device, wherein the second device is a BLE device;
• a measuring module 802 configured to measure at least one physical feature of the received signal
• an extracting module 803, configured to extract at least one piece of raw data for the at least one physical feature of the received signal
• a converting module 804 configured to convert the at least one piece of raw data into at least one attribute in a preset format, wherein the at least one attribute corresponds to the at least one physical feature respectively.
• the measuring module 802 is specifically configured to:
• the extracting module 803 is specifically configured to:
• the converting module 804 is specifically configured to:
• the physical feature is any one of the following features: received signal strength RSS, angle-of-arrival AOA, angle of departure AOD and time of flight.
• an application programming interface API is provided for the first device based on an attribute protocol ATT;
• the first device further 800 comprises an updating module, configured to update the converted attribute through the API.
• an attribute access interface is provided for the first device based on a generic attribute protocol GATT;
• the first device 800 further comprises an accessing module, configured to access the converted attribute through the attribute access interface.
• the extracting module 803 is specifically configured to:
• the converting module 804 is specifically configured to: convert the plurality pieces of raw data into a plurality of attributes in the preset format.
• the first device 800 further comprises an accessing module, configured to access the plurality of attributes at an application layer APP by an application.
• first device 800 may correspond to the first device in the method embodiment of the present application, and the foregoing and other operations and/or functions of each unit in the first device 800 are for implementing the corresponding process of the first device in the method of FIG. 5. For the sake of brevity, it will not be repeated here.
• an embodiment of the present application also provides a first device 900.
• the first device 900 may be the first device 800 in FIG. 8, which can be configured to execute the content of the first device corresponding to the method 500 in FIG. 5.
• the first device 900 shown in FIG. 9 includes a processor 910, and the processor 910 can call and run a computer program from a memory to implement the method in the embodiments of the present application.
• the first device 900 may further include a memory 920.
• the processor 910 may call and run a computer program from the memory 920 to implement the method in the embodiments of the present application.
• the memory 920 may be a separate device independent of the processor 910, or may be integrated in the processor 910.
• the first device 900 may further include a transceiver 930, and the processor 910 may control the transceiver 930 to communicate with other devices. Specifically, it may transmit information or data to other devices, or receive information or data sent by other devices.
• the transceiver 930 may include a transmitter and a receiver.
• the transceiver 930 may further include an antenna, and the number of the antennas may be one or more.
• the first device 900 may be a first device provided in the embodiment of the present application, and the first device 900 may implement the corresponding process implemented by the terminal device in each method of the embodiments of the present application.
• the first device 900 may implement the corresponding process implemented by the terminal device in each method of the embodiments of the present application.
• details will not be described herein again.
• the measuring module, the extracting module and the converting module in the first device 800 may be implemented by the processor 910 in FIG. 9.
• the receiving module in the first device 800 may be implemented by the transceiver 930 in FIG. 9.
• An embodiment of the present application further provides a computer readable storage medium for storing a computer program.
• the computer readable storage medium may be applied to a first device in the embodiments of the present application, and the computer program may cause a computer to execute corresponding processes implemented by the first device in various methods in the embodiments of the present application. It is not described herein for simplicity.
• An embodiment of the present application further provides a computer program product which includes computer program instructions.
• the computer program product may be applied to a first device in the embodiments of the present application, and the computer program instructions may cause a computer to execute corresponding processes implemented by the first device in various methods in the embodiments of the present application. It is not described herein for simplicity.
• An embodiment of the present application further provides a computer program.
• the computer program may be applied to a first device in the embodiments of the present application, when the computer program is run on a computer, the computer may be caused to execute corresponding processes implemented by the first device in various methods in the embodiments of the present application. It is not described herein for simplicity.
• the disclosed systems, apparatuses and methods may be implemented in other manners.
• the apparatus embodiments described above are merely schematic.
• the division of the units is merely a logical function division, and there may be another division manner in an actual implementation.
• a plurality of units or components may be combined or integrated in another system, or some features may be ignored or not performed.
• the displayed or discussed coupling to each other or direct coupling or a communication connection may be through some interfaces. Indirect coupling or a communication connection of the devices or the units may be electrical, mechanical or in other forms.
• the units described as separate components may or may not be physically separate, and the components displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed to a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of the present embodiment.
• each functional unit in each embodiment of the present application may be integrated in one processing unit, or each unit may be physically present separately, or two or more units may be integrated in one unit.
• the functions are implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer readable storage medium.
• the technical solution of the present application essentially or the part that contributes to the existing technology or a part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including several instructions used to cause a computing device (which may be a personal computer, a server, or a network device, etc. ) to execute all or part of the steps of the method described in each embodiment of the present application.
• the foregoing storage medium include: a U disk, a mobile hard disk, a read-only memory (Read-Only Memory, ROM) , a random access memory (Random Access Memory, RAM) , a magnetic disk or an optical disk and other mediums that can store program codes.
• ROM Read-Only Memory
• RAM Random Access Memory

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Databases & Information Systems (AREA)
• Computer Security & Cryptography (AREA)
• Mobile Radio Communication Systems (AREA)
• Signal Processing For Digital Recording And Reproducing (AREA)

Applications Claiming Priority (1)

Publications (2)

Family

ID=82548421

Family Applications (1)

Country Status (3)

Family Cites Families (12)

• 2021
  • 2021-01-22 CN CN202180000262.6A patent/CN115119539B/zh active Active
  • 2021-01-22 CN CN202310610061.9A patent/CN117014933A/zh active Pending
  • 2021-01-22 EP EP21920329.6A patent/EP4278856A4/de active Pending
  • 2021-01-22 WO PCT/CN2021/073424 patent/WO2022155931A1/en unknown

Also Published As

Similar Documents

Legal Events