EP4278856A1

EP4278856A1 - Architecture framework for service recording physical layer features

Info

Publication number: EP4278856A1
Application number: EP21920329.6A
Authority: EP
Inventors: Girish Shivalingappa REVADIGAR; Zhuo WEI; Zhen Li; Sanjay Jha
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2021-01-22
Filing date: 2021-01-22
Publication date: 2023-11-22
Also published as: WO2022155931A1; EP4278856A4; CN115119539A; CN115119539B; CN117014933A

Abstract

Provided are a signal processing method and related products. In the method, 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.

Description

ARCHITECTURE FRAMEWORK FOR SERVICE RECORDING PHYSICAL LAYER FEATURES

TECHNICAL FIELD

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.

BACKGROUND

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” .
This background information is provided to reveal information believed by the applicant to be of possible relevance to the present application. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art against the present application.
SUMMARY
In view of the above, in order to solve the above problem, 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.
The foregoing and other objects are achieved by the subject matter of the independent claims. Further implementation forms are apparent from the dependent claims, the description and the figures.
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:
receiving, at a connection interval change, a signal from a second device, where the second device is a BLE device;
measuring at least one physical feature of the received signal;
extracting at least one piece of raw data for the at least one physical feature of the received signal; and
converting the at least one piece of raw data into at least one attribute in a preset format, where the at least one attribute corresponds to the at least one physical feature respectively.
By exploiting the above mechanism, the present application proposes utilizing the default packet transmission that is already present in BLE connections to realize the recording of the channel features. According to an embodiment of the present application, 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.
In an optional implementation of the first aspect, the converting the at least one piece of raw data into at least one attribute in a preset format includes:
converting 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.
The converting of the attribute based on the L2CAP enables efficient recording of the BLE channel features.
In an optional implementation of the first aspect, where an application programming interface API is provided for the first device based on an attribute protocol ATT; the method further includes:
updating the converted attribute through the API.
With the API provided by the embodiments of the present application, 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; and
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.
BRIEF DESCRIPTION OF DRAWINGS
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.
DESCRIPTION OF EMBODIMENTS
In the following description, reference is made to the accompanying figures, which form part of the present application, and which show, by way of illustration, specific aspects of embodiments of the present application or specific aspects in which embodiments of the present application may be used. It is understood that embodiments of the present application may be used in other aspects and comprise structural or logical changes not depicted in the figures. The following detailed description, therefore, is not to be taken in a limiting sense, and the scope of the present application is defined by the appended claims.
For instance, it is understood that 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. For example, if one or a plurality of specific method steps are described, 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. On the other hand, for example, if a specific apparatus is described based on one or a plurality of units, e.g. functional units, 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.
Recent studies/advancements have shown that wireless physical layer features, e.g., Received Signal strength (RSS) based secure proximity verification and authentication mechanisms are suitable for BLE devices and related applications. These are easy to implement, no additional hardware required, software-based solutions and all platforms irrespective of vendor/hardware support these mechanisms.
Currently, there are no proper standard secure mechanisms for recording the physical layer features of BLE channel. Existing platforms/operating system (OS) implementations of BLE do not expose proper application programming interface (API) or methods or functionalities to read/record the channel features.
Hence, it is proposed herein an architecture framework for the secure service recording BLE channel’s physical layer features that can be ported to any OS/platform.
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. In addition, the proposed architecture is lightweight and has small footprint, which can be easily ported to any BLE platforms.
In the following part, the basics of BLE device scanning and connection procedure is introduced in the first place. 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.
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. After each connection interval 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:
1) Considering the versions of BLE protocols. The common channel features available in BLE of all versions is Received Signal Strength (RSS) . Other features new to BLE 5 and above are Angle of arrival, Angle of Departure, Time of flight;
2) Considering channels of BLE devices and frequencies applied. 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;
3) Considering the characteristic of a wireless channel. Due to the properties of wireless channel, the packets exchanged on the SAME channel between a transmitter and receiver experience similar multi-path fading and scattering, and thus will have very high correlation. Obtaining highly correlated channel features on both the legitimate devices connected over BLE is essential for successful mutual authentication;
4) Considering the 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.
Based on the above analysis, by exploiting the above mechanism, the present application proposes utilizing the default packet transmission that is already present in BLE connections to realize the recording of the channel features. To be specific, 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. In the following, it would become clear that recording highly correlated BLE channel features (on same channels) 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) . It should be noted that in the present application, in addition to functions specified in the present application, these components are also capable of achieving traditional functions in prior art, which will not be elaborated herein. Besides, some of these components may be combined to one based on the platform implementing this framework.
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.
As explained above, the connection interval change refers to the change between two connection intervals shown in FIG. 2. After the connection establishment, the two BLE devices may communicate according to the mechanism described with reference to the BLE protocols. Hence, at every connection interval change, the second device transmits default packets, which may be generally used for synchronization, to the first device. It should be noted that here the present application takes advantage of the default packet for the measurement of the physical features. 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.
Upon receiving the 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.
In an optional implementation, 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.
At each connection interval change, 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.
Regarding the number of the physical features, 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. For example, the common channel features available in BLE of all versions is received signal strength (RSS) . Other features new to BLE version 5 and above are, for example, angle of arrival, angle of departure and time of flight.
S504: 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. Upon obtaining the physical feature, the first device may extract raw data from the extracted physical feature. The step S504 may correspond to the Feature extraction in FIG. 4.
In an optional implementation, 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) .
Regarding 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.
Regarding the number of pieces of raw data, it corresponds to the number of physical features. As described in step S503, 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.
S505: 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.
After obtaining the at least one piece of raw data, since the data is not readable by a user, therefore, the extracted raw data is converted into an attribute in the preset format, the preset format may be a predefined format which is readable for a user.
In an optional implementation, 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) . 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.
According to the embodiments of the present application, 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.
In an optional implementation, an application programming interface (API) 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.
In an optional implementation, 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.
In an optional implementation, for the case where there are a plurality of physical features, 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. 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.
The method may be implemented with the framework proposed in FIG. 4, with details added in FIG. 6. 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:
1) Signal reception: it occupies the physical layer part where the analog signal reaches to the receiver device (i.e., the first device) . Typically 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.
2) Feature Extraction: 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.
3) Feature Recording: the component corresponding to L2CAP converts the raw signal value to a human readable value of an attribute. For example, the raw value 655432 is converted into a negative integer -65dB. It should be noted that the attribute at said component can be a single value or a structure (entity) with multiple values/fields. Hence, it should be implemented as a UNION data type (in C) to allow future extension. Here the data type would change depending on the specific implementation language.
4) Attribute Update: the component based on ATT provides an API/method to read/access the attribute generated at the component based on L2CAP.
5) Attribute Access: the component based on GATT provides interface between the application level component and the component based on ATT.
6) 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.
It should be noted that 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. In some cases, a manufacturer may change the original BLE stack to produce a custom BLE stack. In such cases, depending on the level of details exposed by the manufacturer, 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. Moreover, 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; and
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.
In an optional implementation, the measuring module 802 is specifically configured to:
measure the at least one physical feature of the received signal at a physical layer PHY.
In an optional implementation, the extracting module 803 is specifically configured to:
extract the at least one piece of raw data for the at least one physical feature of the received signal at a link layer LL.
In an optional implementation, the converting module 804 is specifically configured to:
convert 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.
In an optional implementation, 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.
In an optional implementation, 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.
In an optional implementation, 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.
In an optional implementation, the extracting module 803 is specifically configured to:
extract a plurality pieces of raw data for a plurality of physical features of the received signal at a link layer LL;
the converting module 804 is specifically configured to: convert the plurality pieces of raw data into a plurality of attributes in the preset format.
In an optional implementation, the first device 800 further comprises an accessing module, configured to access the plurality of attributes at an application layer APP by an application.
It should be understood that the first device 800 according to an embodiment of the present application 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.
As shown in FIG. 9, 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.
Optionally, as shown in FIG. 9, the first device 900 may further include a memory 920. Where 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.
Optionally, as shown in FIG. 9, 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.
Where 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.
Optionally, 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. For the sake of brevity, details will not be described herein again.
In a specific embodiment, 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.
In an optional implementation, 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.
In an optional implementation, 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.
In an optional implementation, 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.
Terms such as “first” , “second” and the like in the specification and claims of the present application as well as in the above drawings are intended to distinguish different objects, but not intended to define a particular order.
The term such as “and/or” in the embodiments of the present application is merely used to describe an association between associated objects, which indicates that there may be three relationships, for example, A and/or B may indicate presence of A only, of both A and B, and of B only.
In the embodiments of the present application, expressions such as “exemplary” or “for example” are used to indicate illustration of an example or an instance. In the embodiments of the present application, any embodiment or design scheme described as “exemplary” or “for example” should not be interpreted as preferred or advantageous over other embodiments or design schemes. In particular, the use of “exemplary” or “for example” is aimed at presenting related concepts in a specific manner.
Persons of ordinary skill in the art may realize that, the units and algorithm steps described in the embodiments disclosed herein may be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are executed in a manner of hardware or software depends on the particular application and design constraints of the technical solution. Professionals may use different methods for each particular application to implement the described functions, but such implementations should not be considered to be beyond the scope of the present application.
A person skilled in the pertinent art may clearly understand that, for the convenience and simplicity of description, the specific working processes of the systems, apparatuses and units described above may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.
In the several embodiments provided in the present application, it should be understood that, the disclosed systems, apparatuses and methods may be implemented in other manners. For example, the apparatus embodiments described above are merely schematic. For example, the division of the units is merely a logical function division, and there may be another division manner in an actual implementation. For example, a plurality of units or components may be combined or integrated in another system, or some features may be ignored or not performed. In another point, 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.
In addition, 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.
If 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. Based on this understanding, 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.
The above are merely specific embodiments of the present application, but the protection scope of the present application is not limited thereto. Any variation or replacement readily conceivable by a person skilled in the art within the technical scope disclosed in the present application should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be defined by the protection scope of the claims.

Claims

A signal processing method applied in a first device, wherein the first device is a bluetooth low energy BLE device, and the method comprises:

receiving, at a connection interval change, a signal from a second device, wherein the second device is a BLE device;

measuring at least one physical feature of the received signal;

extracting at least one piece of raw data for the at least one physical feature of the received signal; and

converting 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 method as claimed in claim 1, wherein the measuring at least one physical feature of the received signal comprises:

measuring the at least one physical feature of the received signal at a physical layer PHY.
The method as claimed in claim 1 or 2, wherein the extracting at least one piece of raw data for the at least one physical feature of the received signal comprises:

extracting the at least one piece of raw data for the at least one physical feature of the received signal at a link layer LL.
The method as claimed in any one of claims 1-3, wherein the converting the at least one piece of raw data into at least one attribute in a preset format comprises:

converting 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.
The method as claimed in any one of claims 1-4, wherein an application programming interface API is provided for the first device based on an attribute protocol ATT;

the method further comprises:

updating the converted attribute through the API.
The method as claimed in any one of claims 1-5, wherein an attribute access interface is provided for the first device based on a generic attribute protocol GATT;

the method further comprises:

accessing the converted attribute through the attribute access interface.
The method as claimed in any one of claims 1-6, wherein the extracting at least one piece of raw data for at least one physical feature of the received signal comprises:

extracting a plurality pieces of raw data for a plurality of physical features of the received signal at a link layer LL;

the converting the at least one piece of raw data into at least one piece of attribute in a preset format comprises:

converting the plurality pieces of raw data into a plurality of attributes in the preset format.
The method as claimed in claim 7, the method further comprises:

accessing the plurality of attributes at an application layer APP by an application.
The method as claimed in any one of claims 1-8, wherein 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.
A first device, wherein the first device is a bluetooth low energy BLE device, and comprises:

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; and

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.
The first device as claimed in claim 10, wherein the measuring module is specifically configured to:

measure the at least one physical feature of the received signal at a physical layer PHY.
The first device as claimed in claim 10 or 11, wherein the extracting module is specifically configured to:

extract the at least one piece of raw data for the at least one physical feature of the received signal at a link layer LL.
The first device as claimed in any one of claims 10-12, wherein the converting module is specifically configured to:

convert 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.
The first device as claimed in any one of claims 10-13, wherein an application programming interface API is provided for the first device based on an attribute protocol ATT;

the first device further comprises an updating module, configured to update the converted attribute through the API.
The first device as claimed in any one of claims 10-14, wherein an attribute access interface is provided for the first device based on a generic attribute protocol GATT;

the first device further comprises an accessing module, configured to access the converted attribute through the attribute access interface.
The first device as claimed in any one of claims 10-14, wherein the extracting module is specifically configured to:

extract a plurality pieces of raw data for a plurality of physical features of the received signal at a link layer LL;

the converting module is specifically configured to: convert the plurality pieces of raw data into a plurality of attributes in the preset format.
The first device as claimed in claim 16, wherein the first device further comprises an accessing module, configured to access the plurality of attributes at an application layer APP by an application.
The first device as claimed in any one of claims 10-17, wherein 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.
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 any one of claims 1 to 9.
A computer-readable storage medium, configured to store a computer program that enables a computer to execute the method according to any one of claims 1 to 9.
A computer program product, comprising computer program instructions that cause a computer to execute the method according to any one of claims 1 to 9.
A computer program, wherein the computer program causes a computer to execute the method according to any one of claims 1 to 9.