Web request and response transmission method, system and device based on bluetooth low energy link and electronic equipment

Abstract

This application discloses a web request and response transmission method based on a Bluetooth Low Energy (BLE) link. A BLE client decomposes a web request into request frames and sends them to a data relay device. The data relay device converts the request frames into Hypertext Transfer Protocol (HTTP / HTTPS) requests. A web server processes the HTTP / HTTPS requests and returns an HTTP / HTTPS response to the data relay device. The data relay device then decomposes the HTTP / HTTPS response into response frames and sends them to the BLE client, enabling the BLE client to obtain the HTTP / HTTPS response based on the response frames. This allows the BLE client to efficiently and reliably access internet resources without requiring a TCP / IP protocol stack, overcoming the application limitations of traditional BLE devices in web access and bidirectional data interaction.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, system, device and electronic device for transmitting web requests and responses based on a Bluetooth Low Energy link. Background Technology

[0002] With the rapid development of IoT technology, a large number of embedded devices, sensors, wearable devices, and other limited devices are widely used in smart homes, healthcare, industrial monitoring, and other scenarios. These devices typically have limited hardware resources, lack a complete TCP (Transmission Control Protocol) / IP (Internet Protocol) stack, and are not configured with network communication modules such as Wi-Fi, but they still need to access Internet web resources in practical applications.

[0003] Bluetooth Low Energy (BLE) technology has become the mainstream communication method for interaction between restricted devices and terminals or gateways due to its advantages such as low power consumption, low cost, convenient connection, and wide hardware support. However, BLE communication has inherent technical limitations such as a small maximum transmission unit, limited data throughput, and strict connection interval constraints, and cannot directly carry standard HTTP / HTTPS web protocol messages.

[0004] In related technologies, BLE communication solutions are mostly geared towards customized data interaction, providing only basic GATT (Generic Attribute Profile) data read and write capabilities, and have not formed a standardized and robust Web message transmission mechanism.

[0005] Therefore, how to provide efficient and reliable web access capabilities for limited devices without a complete IP protocol stack under the inherent constraints of BLE has become a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0006] The purpose of this application is to propose a web request and response transmission method based on Bluetooth Low Energy links, which aims to solve the problem of providing efficient and reliable web access capabilities for limited devices without a complete IP protocol stack.

[0007] This application provides a method for transmitting web requests and responses based on a Bluetooth Low Energy link, the method including: The web request is broken down into request frame messages by the Bluetooth Low Energy client, and the request frame messages are sent to the data relay device through the Bluetooth Low Energy data transmission channel; The request frame message is converted into a standard HTTP / HTTPS request through a data relay device, and then the HTTP / HTTPS request is sent to the web server. The web server processes HTTP / HTTPS requests and returns HTTP / HTTPS responses to the data relay device. The HTTP / HTTPS response is decomposed into response frame messages by a data relay device and sent to the Bluetooth Low Energy client so that the Bluetooth Low Energy client can obtain the HTTP / HTTPS response based on the response frame messages; In the process of sending the response frame message to the Bluetooth Low Energy client, a power-aware scheduling mechanism is used to schedule and control the transmission timing of the response frame message, so that the data transmission time is aligned and matched with the sleep cycle and link connection interval of the Bluetooth Low Energy client.

[0008] Accordingly, this application also provides a web request and response transmission system based on a Bluetooth Low Energy link, including a Bluetooth Low Energy client, a data relay device, and a web server: Bluetooth Low Energy client, used to break down web requests into request frame messages and send the request frame messages to a data relay device via Bluetooth Low Energy data transmission channel; Data relay equipment is used to convert request frame messages into standard HTTP / HTTPS requests and send the HTTP / HTTPS requests to the web server; A web server is used to receive and process HTTP / HTTPS requests, and to return HTTP / HTTPS responses to data relay devices; The data relay device is also used to decompose HTTP / HTTPS responses into response frame messages and send the response frame messages to Bluetooth Low Energy clients; The Bluetooth Low Energy client is also used to receive response frame messages and obtain HTTP / HTTPS responses based on the response frame messages.

[0009] Accordingly, this application also provides a web request and response transmission device based on a Bluetooth Low Energy link, comprising: The decomposition unit is used to decompose a web request into request frame messages via a Bluetooth Low Energy client and send the request frame messages to a data relay device via a Bluetooth Low Energy data transmission channel. The conversion unit is used to convert request frame messages into standard HTTP / HTTPS requests through a data relay device, and send the HTTP / HTTPS requests to the web server; The response receiving and processing unit is used to process HTTP / HTTPS requests through the web server and return HTTP / HTTPS responses to the data relay device; The sending unit is used to decompose the HTTP / HTTPS response into response frame messages through a data relay device and send the response frame messages to the Bluetooth Low Energy client so that the Bluetooth Low Energy client can obtain the HTTP / HTTPS response based on the response frame messages; The control unit is used to schedule and control the transmission timing of the response frame message using a power-aware scheduling mechanism during the process of sending the response frame message to the Bluetooth Low Energy client, so that the data transmission time is aligned and matched with the sleep cycle and link connection interval of the Bluetooth Low Energy client.

[0010] Accordingly, this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the program to implement the above-described web request and response transmission method based on a Bluetooth Low Energy link.

[0011] This application utilizes a Bluetooth Low Energy (BLE) client to decompose a web request into request frame messages and send these frames to a data relay device via a BLE data transmission channel. The data relay device then converts these frame messages into standard HTTP / HTTPS requests and sends them to a web server. The web server processes the HTTP / HTTPS requests and returns an HTTP / HTTPS response to the data relay device. Finally, the data relay device decomposes the HTTP / HTTPS response into response frame messages and sends these frames to the BLE client, enabling the BLE client to obtain the HTTP / HTTPS response based on the response frame messages. This allows a restricted BLE client to efficiently and reliably access internet web resources without needing a complete TCP / IP protocol stack, overcoming the application limitations of traditional BLE devices in web access and bidirectional data interaction. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] in: Figure 1This is a schematic diagram of a web request and response transmission system based on a Bluetooth Low Energy link, provided as an embodiment of this application.

[0014] Figure 2 This is a flowchart illustrating a web request and response transmission method based on a Bluetooth Low Energy link, as provided in an embodiment of this application.

[0015] Figure 3 This is a structural block diagram of a web request and response transmission device based on a Bluetooth Low Energy link, provided in an embodiment of this application.

[0016] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0018] This application provides a method, system, apparatus, and electronic device for transmitting web requests and responses based on a Bluetooth Low Energy link. Specifically, the web request and response transmission method based on a Bluetooth Low Energy link in this application can be executed by an electronic device, which can be a terminal or a server. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, and big data and artificial intelligence platforms.

[0019] To address the aforementioned issues, this application provides a method, system, device, and electronic device for transmitting web requests and responses based on a Bluetooth Low Energy link. This enables restricted Bluetooth Low Energy clients to efficiently and reliably access internet web resources without needing to carry a complete TCP / IP protocol stack, overcoming the application limitations of traditional Bluetooth Low Energy devices in web access and bidirectional data interaction.

[0020] The following sections provide detailed descriptions of each example. It should be noted that the order in which the embodiments are described is not intended to limit the preferred order of the embodiments.

[0021] This application provides a web request and response transmission system based on a Bluetooth Low Energy link, including a Bluetooth Low Energy client, a data relay device, and a web server, wherein: Bluetooth Low Energy client, used to break down web requests into request frame messages and send the request frame messages to a data relay device via Bluetooth Low Energy data transmission channel; Data relay equipment is used to convert request frame messages into standard HTTP / HTTPS requests and send the HTTP / HTTPS requests to the web server; A web server is used to receive and process HTTP / HTTPS requests, and to return HTTP / HTTPS responses to data relay devices; The data relay device is also used to decompose HTTP / HTTPS responses into response frame messages and send the response frame messages to Bluetooth Low Energy clients; The Bluetooth Low Energy client is also used to receive response frame messages and obtain HTTP / HTTPS responses based on the response frame messages.

[0022] For example, please see Figure 1 , Figure 1 This illustration shows a web request and response transmission system based on a Bluetooth Low Energy (BLE) link, provided as an embodiment of this application. This embodiment is a web-based interactive system implemented on a device without a TCP / IP protocol stack, based on Bluetooth Low Energy (BLE). The overall architecture consists of three parts: the device side (QCC, Bluetooth system-on-a-chip), the BLE link layer, and the mobile terminal side (Android App). It enables web resource delivery, user interaction processing, and interface rendering via the BLE link without relying on a TCP / IP protocol stack. The specific implementation is as follows: Device side (QCC side): Web page interaction implementation without TCP / IP protocol stack The device uses QCC series chips as its core, requiring no TCP / IP protocol stack. It provides complete web-based interactive capabilities through a BLE link. The core modules and execution logic are as follows: Web page resource storage module: This module embeds the HTML, CSS, and JavaScript resource files required for web page interaction into the device firmware, enabling local storage of page resources without relying on external networks or servers to obtain resources.

[0023] Page Fragmentation Service Module: In response to page resource requests from mobile terminals, the module splits the complete HTML page data into fragmented data blocks (HTML chunks) adapted to BLE MTU (Bluetooth Low Energy Maximum Transmission Unit) according to the offset in the request, and sends them to the mobile terminal in sequence through the BLE link.

[0024] CGI (Common Gateway Interface) service modules are used to process GET / POST interaction requests sent by mobile terminals, execute corresponding business logic such as status query, parameter configuration, and command issuance, and generate response data to send back to the mobile terminal.

[0025] The GAIA Vendor Command distribution module is used to map mobile terminal requests into three types of commands—page download, GET request, and POST request—through the GAIA (Generic Application Interface Architecture) protocol, thereby completing the distribution and routing of requests and realizing the correspondence between BLE link data and web page interaction requests.

[0026] BLE Link Layer: GATT+GAIA Protocol Transmission and Fragmentation Constraints The BLE link layer is the communication channel between the device and the mobile terminal, and its core consists of two parts: BLE GATT Service: Used as a basic communication carrier, it provides underlying service support for BLE connection establishment and data transmission and reception, enabling basic data interaction between devices and mobile terminals.

[0027] MTU / Fragmentation Constraint Module: Based on the MTU negotiation results of the BLE link, it performs fragmentation and reassembly constraints on the transmitted data to ensure that all web resource fragments and interactive request data comply with the transmission limits of the BLE link, thereby achieving reliable data transmission.

[0028] Mobile terminal side (Android App): Bluetooth Low Energy client + page reorganization + WebView rendering On the mobile terminal side, an Android App is used as the carrier. It establishes a connection with the device via BLE to complete data reception, page reconstruction, and interface rendering. The core modules and execution logic are as follows: BLE Scanning and Connection Module: Used to discover QCC devices on the device side through BLE scanning, establish BLE connections and maintain link status, providing link support for subsequent data transmission.

[0029] GAIA Client Module: Used to implement short packet sending and receiving and notification processing of the GAIA protocol, complete the reception of page fragment data and interactive response data sent by the device side, as well as the encapsulation and sending of user interaction requests.

[0030] Page Reassembler Module: Based on the HTML fragment data sent from the device, the module splices and reassembles the fragment data according to the offset to restore the complete HTML page data.

[0031] WebView renderer module: Used to load the reconstructed HTML page data into WebView, render and display a lightweight web page UI, and realize visual interaction with the user.

[0032] JavaScript overlay module: Used to replace the original HTTP request entry point, redirecting GET / POST requests triggered by the user in WebView to the AndroidGaia Bridge module to complete the capture and forwarding of requests.

[0033] The AndroidGaia Bridge module is used to bridge the gap between WebView and the BLE link. It encapsulates user interaction requests into GAIA commands and sends them to the device side via the sendGet / sendPost interfaces, and receives response data from the device side and sends it back to WebView.

[0034] User Results Presentation Module: This module responds to user interactions such as button presses and inputs through the WebView interface, displays the interaction results returned from the device side on the interface, and completes the closed loop of user interaction.

[0035] A web-based interactive implementation without a TCP / IP protocol stack is achieved by abstracting page resource distribution and user interaction requests into a unified BLE application protocol, enabling web-based interactive capabilities for restricted devices.

[0036] For further details, please refer to Figure 2 , Figure 2 This is a flowchart illustrating a web request and response transmission method based on a Bluetooth Low Energy link, provided in an embodiment of this application. The specific flow of this Bluetooth Low Energy link-based web request and response transmission method can be as follows: 101. The web request is decomposed into request frame messages by the Bluetooth Low Energy client, and the request frame messages are sent to the data relay device through the Bluetooth Low Energy data transmission channel.

[0037] Bluetooth Low Energy Client refers to a limited low-power device equipped with a Bluetooth Low Energy (BLE) communication module that does not have or rely on a complete TCP / IP protocol stack.

[0038] For example, Bluetooth Low Energy clients can include health monitoring wearable devices (such as smart bracelets, sports watches, etc.), low-power smart home devices (temperature and humidity sensors, smart door locks, wireless switches, etc.), and low-power IoT terminals (such as Bluetooth headsets, wireless remote controls, etc.).

[0039] The data relay device is an intermediate gateway device positioned between the Bluetooth Low Energy restricted client device and the web service side, responsible for protocol bridging, data forwarding, and BLE link management. One end of the data relay device establishes a connection with the restricted Bluetooth Low Energy client via Bluetooth Low Energy, while the other end can interact with the web service, forward requests, and send back responses, completing protocol translation and bidirectional relay between BLE proprietary protocol / GAIA / GATT data and web interaction requests and responses. The data relay device can simultaneously possess BLE peripheral device functionality and gateway / proxy functionality, used to receive BLE framed messages, reassemble them, and convert them into HTTP / HTTPS requests for forwarding.

[0040] For example, data relay devices may include: smartphones, tablets, smart home control devices, IoT edge gateways with built-in Bluetooth Low Energy modules, vehicle-mounted smart terminals, and other terminal or gateway devices with Bluetooth Low Energy access and application processing capabilities.

[0041] In this embodiment of the application, a framed transmission method is used to carry web data on BLE. Framed transmission is to divide a complete large data block (such as the body of an HTTP POST request) into multiple small frames, that is, request framed messages. Each request framed message is sent independently and then reassembled at the receiving end.

[0042] Each frame consists of a frame header and a payload. The frame header may contain the following fields: sequence identifier, fragment index, total number of fragments, payload length, and flags. The functions of each field are as follows: Sequence identifier: Used to distinguish different large data blocks. BLE devices may transmit multiple independent "web payloads" simultaneously (such as sending historical temperature data and requesting firmware upgrades at the same time), and the receiving end needs to know which frames belong to the same original message.

[0043] Fragment Index: Used to indicate which fragment the current frame is in the entire message. It is usually numbered starting from 0 or 1. This helps the receiving end to reassemble the data in the correct order.

[0044] Total number of fragments: This tells the receiver how many frames the original message was divided into. The receiver can pre-allocate a buffer and determine whether all fragments have been received.

[0045] Payload length: Indicates how many valid bytes are in the payload portion of the current frame. The last fragment may not be full (e.g., if the total is 1032 bytes, divided into 10 frames, the last frame may only have 32 bytes). The receiver uses this information to determine how many bytes to read from the frame as actual data, avoiding the processing of invalid padding.

[0046] Flags: Used to carry binary flags to indicate special states. Common flag examples include: START (whether it is the first fragment); END (whether it is the last fragment); ACK_REQUEST (whether receiver acknowledgment is required); ERROR (this frame contains error information).

[0047] In some embodiments, the step "decompose the web request into request frame messages via Bluetooth Low Energy client" may include the following operations: The Bluetooth Low Energy client establishes a Bluetooth Low Energy connection with the data relay device and negotiates to determine the maximum transmission unit size.

[0048] The Bluetooth Low Energy client divides the web request into multiple request frame messages that meet the length limit according to the negotiated maximum transmission unit, and adds frame header information containing sequence identifier, fragment index, total number of fragments, payload length and flags to each request frame message.

[0049] Among them, the Bluetooth Low Energy data transmission channel refers to a dedicated logical transmission path established between Bluetooth Low Energy devices based on the BLE link and relying on GATT services and features, used to carry command signaling, fragmented service data, interactive requests and response messages; this channel does not rely on the traditional TCP / IP network protocol stack, and can realize bidirectional data transmission and reception between the two devices through Bluetooth Low Energy wireless connection alone.

[0050] In some embodiments, the Bluetooth Low Energy data transmission channel can be: a bidirectional Bluetooth Low Energy data transmission channel; The step "decompose the web request into request frame messages via the Bluetooth Low Energy client and send the request frame messages to the data relay device via the Bluetooth Low Energy data transmission channel" can include the following operations: The web request is treated as a whole and processed into frames to obtain the request frame message. The request frame messages are sent sequentially to the data relay device via a two-way Bluetooth Low Energy data transmission channel.

[0051] Among them, the bidirectional Bluetooth Low Energy data transmission channel, also known as the bidirectional GATT feature, is a communication data channel in BLE that can be used for both sending and receiving; the client can write, and the server can actively push, and the same feature can be used to send requests and receive responses without having to use two separate channels.

[0052] The process of treating a Web request as a whole and processing it into frames to obtain request frame messages may include: after the Bluetooth Low Energy client and the data relay device establish a Bluetooth Low Energy connection and negotiate to determine the maximum transmission unit, the Bluetooth Low Energy client, based on the negotiated maximum transmission unit, divides the Web request into multiple request frame messages that meet the length limit, treating the URI (Uniform Resource Identifier) ​​+ header + body as a whole data segment. The payload of each request frame message is a segment of the whole message.

[0053] The URI is used to uniquely identify a resource, entity, or endpoint; the header refers to the metadata about this data, which describes the characteristics of the subject; the subject is the actual data content, which carries the real data required for business logic.

[0054] Furthermore, sending request framing messages sequentially to the data relay device via a bidirectional Bluetooth Low Energy (BLE) data transmission channel can include: the BLE client adding a frame header containing a sequence identifier, fragment index, total number of fragments, payload length, and flags to each request framing message; the BLE client sending the request framing messages sequentially to the data relay device via the bidirectional BLE data transmission channel, using either write-with-response or write-without-response methods; and the BLE client receiving and processing the acknowledgment or denial information returned by the data relay device to complete the reliable transmission of the request framing messages.

[0055] Transmitting request frames using bidirectional GATT feature values ​​eliminates the need for additional multi-channel configuration, saving Bluetooth Low Energy link resources and reducing device power consumption. The frame division and retransmission mechanism ensures the integrity and reliability of Web request transmission, adapts to low-resource Bluetooth Low Energy clients, simplifies the implementation process, improves compatibility, and reduces the cost of technology implementation and device upgrades.

[0056] In some embodiments, the Bluetooth Low Energy data transmission channel can be: multiple independent Bluetooth Low Energy data transmission channels; The step "decompose the web request into request frame messages via the Bluetooth Low Energy client and send the request frame messages to the data relay device via the Bluetooth Low Energy data transmission channel" can include the following operations: Web requests are split into at least one type of semantic data according to a preset semantic type. Each type of semantic data is then processed into frames independently to obtain request frame messages. The request frame message is sent in parallel to the data relay device through multiple independent Bluetooth Low Energy data transmission channels.

[0057] Among them, multiple independent Bluetooth Low Energy data transmission channels, also known as multi-feature value GATT, break down a single communication channel into multiple dedicated small channels, each transmitting different content, each performing its own function and transmitting in parallel.

[0058] In some embodiments, the preset semantic types may include: URI, header, body, and control channel. The control channel is a dedicated channel used to issue commands, change states, or provide confirmations. The control channel does not transmit service data (URI / header / body), but rather sends control commands. Examples include: start, stop, reset, acknowledge receipt, request retransmission, switch rates, and enter low-power mode.

[0059] Specifically, the web request is split according to a preset semantic type to obtain at least one type of semantic data. Each type of semantic data is then independently processed into frames to obtain a request frame message. This process may include: establishing a Bluetooth Low Energy (BLE) communication link between the Bluetooth Low Energy client and the data relay device; after the link is established, both parties automatically negotiate the maximum transmission unit (MTU) parameter that the communication can carry, which serves as the length constraint for subsequent data frame segmentation; secondly, the Bluetooth Low Energy client no longer treats the web request to be transmitted as a single, uniform data frame, but instead performs semantic hierarchical segmentation of the web request according to the preset semantic type. Different categories of semantic data are formed, typically categorized as URI data, header data, data body data, and control channel data. Furthermore, for each category of semantic data obtained from the splitting, the client independently performs frame segmentation and trimming based on the negotiated maximum transmission unit, ensuring that the payload length of each frame message does not exceed the link transmission limit. Simultaneously, a unified frame header field is configured for each frame message. The frame header carries at least the sequence identifier, fragment index, total number of fragments, payload length, and flags to identify fragment ownership, arrangement order, and the total number of fragments in the complete message, providing a basis for the receiving end to reassemble and restore the data.

[0060] Furthermore, sending the request framing message to the data relay device in parallel through multiple independent Bluetooth Low Energy (BLE) data transmission channels can include: pre-configuring multiple independent BLE data transmission channels, with each channel mapped to a specific type of semantic data after splitting; the BLE client utilizing the parallel transmission capability of multiple independent transmission channels to simultaneously send the framing messages corresponding to different semantic data to the data relay device via their respective independent transmission channels, achieving semantic separation and multi-stream parallel transmission; subsequently, the data relay device receives the corresponding type of framing message on each independent transmission channel, reads the frame header information of the framing message, and sequentially performs fragment integrity verification, duplicate fragment removal, and message order correction to ensure that fragments of the same type of semantic data are received in order.

[0061] Finally, the Bluetooth Low Energy client continuously receives link confirmation information from the data relay device, stops sending correctly received frame messages, and automatically triggers a retransmission process for frame messages that have timed out and not been acknowledged or have failed verification. The retransmission and acknowledgment mechanism is executed in a loop until all frame messages of all types of semantic data are reliably received by the data relay device, thus completing the entire process of Web request frame transmission based on the multi-feature value architecture.

[0062] This method uses GATT with multiple feature values ​​to transmit request frame messages. Through semantic segmentation, independent framing, and multi-channel parallel transmission, web request data with different functions are isolated and transmitted in independent channels without interference. It not only adapts to the length limit of the maximum transmission unit of Bluetooth Low Energy links, but also improves transmission throughput efficiency and reduces the probability of single-channel congestion. At the same time, it facilitates the receiver to process the data according to semantic categories, improving the efficiency and stability of protocol conversion and message reassembly.

[0063] In this embodiment, the specific transmission method of the framed messages can be selected according to the capabilities of the Bluetooth Low Energy (BLE) client. For example, for BLE clients with very limited resources (minimal RAM / Flash), which only need to handle single, simple request-response interactions (e.g., a sensor that only reports temperature and occasionally receives threshold settings), and for which simple and rapid prototyping is prioritized over performance optimization, a bidirectional Bluetooth Low Energy data transmission channel can be selected for transmission. For BLE clients with sufficient processing power and memory, which need to process multiple types of data simultaneously (e.g., video streams, audio, files, control commands), require concurrency and low latency, and desire a clear, modular code structure for easy maintenance, multiple independent Bluetooth Low Energy data transmission channels can be selected for transmission.

[0064] In some embodiments, the method may further include the following steps: The Bluetooth Low Energy client determines the priority information corresponding to the web request based on the content of the web request and adds the priority information to the request frame message. After receiving the request frame segmentation message through the data relay device, the priority information in the request frame segmentation message is obtained, and the request frame segmentation message is added to the target priority queue corresponding to the priority information. The request frame messages are processed by the data relay device based on the target priority queue.

[0065] Different web requests may have different levels of importance for their data content. For example, with smart bracelets, routine data such as daily steps, sleep quality, or hourly body temperature records are generally considered moderately important. Web requests based on this type of data are of moderate importance, can tolerate some transmission delays, and are suitable for batch uploading to save battery power. On the other hand, data on emergency physiological events such as abnormal heart rate, sudden drop in blood sugar, or fall alarms are generally considered very important. Web requests based on this type of data are of higher importance, and this data must be uploaded to the cloud server immediately and with priority to trigger alarms or medical interventions in a timely manner.

[0066] Existing framing mechanisms and gateway translation logic lack a clear, application-level mechanism to identify and process data of different priorities. This prevents gateways from intelligently scheduling and allocating resources based on the actual urgency of the data. Consequently, a high-priority health alert might be queued after a large amount of low-priority routine data, or its transmission might be unnecessarily delayed due to strict power optimization strategies. This lack of dynamic prioritization capabilities based on data semantics can lead to delayed responses to critical health events, impacting user safety and system real-time performance.

[0067] Therefore, when encapsulating a Web request and generating a request frame message, the Bluetooth Low Energy client of this application extends the original frame header (which includes sequence identifier, fragment index, total number of fragments, payload length, and flags) by adding a priority level (PL) field.

[0068] For example, this priority field can be set using 2-3 bits to indicate the urgency of the data. It can correspond to four priorities, as follows: 00: Indicates background / low priority (such as daily steps, historical data synchronization); 01: Indicates routine priority (such as periodic health reports, non-urgent vital signs data); 10: Indicates importance and priority (such as early warning of abnormal trends, measurement data at a specific time point); 11: Indicates emergency / critical priority (such as data on emergency physiological events such as abnormal heart rate, critical blood sugar levels, and fall alarms).

[0069] In this embodiment, the firmware of the Bluetooth Low Energy client has a built-in priority mapping rule. When generating a Web request and encapsulating the request frame message, the firmware will automatically identify the API endpoint, data type and data value corresponding to the Web request. According to the preset priority mapping rule, it will determine the priority type corresponding to the request, and then match the corresponding priority level bit field. The bit field value will be filled into the newly added priority level (PL) field in the frame header. After the complete encapsulation of the frame message is completed, it will be sent to the Bluetooth Low Energy pending transmission queue.

[0070] For example, if the Bluetooth Low Energy client detects "abnormal heart rate alarm" data, it will set the PL field of all relevant frame messages to "urgent / critical priority"; if it is only uploading "daily step count statistics", it will set the PL field of the relevant frame messages to "background / low priority".

[0071] Subsequently, after receiving the request frame fragmentation message sent by the Bluetooth Low Energy client via the Bluetooth Low Energy link, the data relay device (such as a gateway) first performs a complete parsing of the frame header of the frame fragmentation message, focusing on extracting the newly added priority level (PL) field bit value in the frame header. Based on this bit value, it identifies the priority type corresponding to the current frame fragmentation message, and then performs subsequent protocol conversion and data forwarding operations based on this priority type. Before the PL field parsing is completed, the subsequent frame reassembly and protocol conversion process is not started.

[0072] In this application embodiment, a priority transmission queue is introduced on the data relay device side. All web requests (or web responses to be sent back to the client) received and reassembled from the Bluetooth Low Energy client will no longer be simply queued in the order of receipt, but will enter different priority queues according to the PL value in their frame header, or be sorted in a unified priority queue.

[0073] For example, a semantically aware adaptive scheduler can be added to the data relay device. This scheduler first reads the priority level field of the framed messages, and then classifies the framed messages and adds them to the corresponding priority queues (background / low priority queue, regular priority queue, important priority queue, urgent / critical priority queue). Then, the data relay device reads the framed messages in each queue in the order of "urgent / critical priority > important priority > regular priority > background / low priority", performs protocol conversion, and forwards them to the corresponding terminals or servers, prioritizing the processing of high-priority data.

[0074] In some embodiments, in order to ensure that important data is processed quickly, the data transfer device allocates corresponding processing resources to each priority queue, and allocates more CPU processing time and network bandwidth to the emergency / critical priority queue to ensure that high-priority data is transmitted without delay and low-priority data is transmitted in an orderly manner according to the link status, so as to avoid high-priority data being blocked by low-priority data.

[0075] Correspondingly, after receiving the response frame message forwarded by the data relay device, the Bluetooth Low Energy client can also prioritize parsing and processing high-priority frame data according to the priority level field in the frame header of the response frame message, ensuring rapid response to urgent data and normal decoding and reassembly of regular and low-priority data.

[0076] In some embodiments, the method may further include the following steps: If a target request frame message that meets the preset priority processing conditions exists, the Bluetooth Low Energy link connection interval is temporarily shortened through the data relay device, and the fastest supported physical transport layer transmission rate is enabled to complete the transmission of the target request frame message. After the transmission is completed, the default link connection parameters and power consumption optimization settings are automatically restored.

[0077] Among them, meeting the preset priority processing conditions can include: the priority level belongs to the urgent / critical priority.

[0078] Specifically, when the semantic-aware adaptive scheduler of the data relay device detects a framed message in the emergency / critical priority queue, it immediately triggers the Bluetooth Low Energy link connection parameter adjustment mechanism to temporarily adjust the Bluetooth Low Energy link connection parameters. This includes shortening the link connection interval and enabling the fastest PHY layer transmission rate supported by the device hardware to improve the transmission speed of the emergency framed message. After all the emergency / critical priority framed messages have been transmitted, the semantic-aware adaptive scheduler automatically triggers the connection parameter recovery mechanism to restore the Bluetooth Low Energy link connection parameters to the default power optimization settings, ensuring that the device power consumption returns to normal levels.

[0079] This application's embodiments introduce a "priority level" field into the frame header information, enabling Bluetooth Low Energy clients to directly convey the semantic importance of data content to the data relay device. The semantically aware adaptive scheduler of the data relay device utilizes this information to overcome the limitations of traditional power-aware scheduling that treats all data equally. It ensures that critical data is transmitted first, and emergency health alert data, due to its high priority, is processed and sent by the scheduler first, significantly shortening the delay from when the device detects an event to when the alert is received in the cloud, thereby protecting user safety.

[0080] For low-priority data, the scheduler still strictly follows the power optimization strategy, transmitting data in batches at the optimal time to maximize the battery life of Bluetooth Low Energy clients. For high-priority data, connection parameters can be temporarily adjusted within a controlled range, sacrificing a small amount of power consumption for critical timeliness, thus achieving an intelligent balance between power consumption and response speed.

[0081] Through priority queuing and adaptive scheduling, BLE's limited bandwidth and connection time are more effectively allocated to the data that needs to be transmitted immediately, avoiding the situation where high-priority data is blocked by low-priority data.

[0082] 102. The request frame message is converted into a standard HTTP / HTTPS request through a data relay device, and the HTTP / HTTPS request is sent to the web server.

[0083] In some embodiments, the step "converting the request framed message into a standard HTTP / HTTPS request via a data relay device and sending the HTTP / HTTPS request to the web server" may include the following operations: A fragmentation and reassembly algorithm is used to reassemble the request frame messages and restore the complete Web request. Convert the protocol format of the complete web request to generate an HTTP / HTTPS request; Based on the TCP / IP protocol stack, HTTP / HTTPS requests are forwarded to the web server.

[0084] Among them, the fragmentation and reassembly algorithm can use a fragmentation and reassembly algorithm optimized for BLE MTU (Bluetooth Low Power Maximum Transmission Unit) negotiation and dynamic MTU changes.

[0085] Specifically, the method for reassembling request frame messages using fragmentation and reassembly algorithms optimized by BLE MTU negotiation and dynamic MTU change can be as follows: The data relay device monitors the MTU update events reported by the BLE underlying protocol stack in real time and continuously detects whether the MTU value of the current link has changed dynamically (such as changes in link signal quality, PHY layer rate adjustment, or MTU changes caused by connection parameter optimization). If a change in the MTU value is detected, the algorithm's dynamic adaptation mechanism is immediately triggered to update the baseline MTU threshold for internal fragment reassembly without restarting the BLE connection or re-initializing the session, ensuring that the algorithm remains synchronized with the current link MTU state.

[0086] The data relay device's fragmentation and reassembly module reads all request frame messages from the buffer and performs timing correction and ordered sorting of the frames based on the fragmentation index, offset, and sequence identifier of each frame header. For new and old specification frames (old MTU fragments and new MTU fragments) received during dynamic MTU changes, the algorithm automatically handles compatibility and sorts them uniformly according to the fragmentation index and offset to avoid frame disorder caused by MTU changes and ensure that all frames are neatly arranged in the original Web request order.

[0087] Following the normalized frame order, the data relay device's reassembly module extracts the payload data piece by piece based on the currently effective MTU value, and splices them together sequentially according to the offset to gradually restore the complete Web request data. During the splicing process, the integrity verification module performs a verification operation simultaneously, checking the total number of frame pieces, the length of each piece, and the continuity of the offset, confirming that all frames have been received without any missing or disordered parts. If a missing piece or discontinuous offset is detected, a missing piece retransmission request is immediately sent to the Bluetooth Low Energy client until all frames are received.

[0088] Once all frames are assembled and verified, the reassembly algorithm outputs the restored complete Web request. This Web request is then sent to the protocol conversion module of the data transfer device to perform subsequent GAIA instruction parsing, Web request forwarding, and other operations. Simultaneously, all frame data corresponding to the current Web request in the fragment receiving buffer is cleared, releasing buffer resources and preparing to receive the next set of request frame messages, thus completing a complete fragment reassembly process.

[0089] This application's embodiments achieve adaptive adjustment of fragmentation granularity according to link capabilities by adapting to initial MTU negotiation and being compatible with dynamic MTU changes during runtime. This maximizes the utilization of link transmission bandwidth, reduces the number of fragments and transmission interaction overhead, and avoids problems such as frame overflow, reassembly failure, and data packet loss and disorder when fixed fragments change MTU, thereby improving transmission reliability and communication efficiency in BLE Web interaction, sensor reporting, and command control scenarios.

[0090] In some embodiments, the step "converting the protocol format of the complete web request to generate an HTTP / HTTPS request" may include the following operations: The data relay equipment integrates protocol conversion functionality, enabling it to recognize the format and content of complete web requests and, in accordance with HTTP / HTTPS standards, complete the format conversion, field mapping, and content adaptation of web requests and HTTP / HTTPS requests.

[0091] The conversion process is compatible with different formats of web requests, ensuring that the converted HTTP / HTTPS requests can be recognized and responded to normally by existing web servers without any modifications to the web servers.

[0092] In some embodiments, the method may further include the following steps: During protocol conversion and request forwarding, error recovery and flow control operations are performed based on the sequence identifier in the request frame message, the acknowledgment information and / or denial information returned by the web server.

[0093] The serial number is a sequence identifier configured by the Bluetooth Low Energy client in the frame header of each request frame message. It is used to identify the order of each request frame message in the complete Web request and the message ownership relationship. It can be used by data relay devices to complete frame sorting, out-of-order correction and duplicate fragment identification based on the serial number. At the same time, it can uniquely mark each Web request after forwarding, providing a basis for error judgment and traffic statistics.

[0094] A confirmation message is a positive response message sent by the receiving end to the sending end after the receiving end has fully received and verified the request frame message or web request with the corresponding sequence number. It is used to inform the sending end that the current data reception is normal and there is no need to resend it.

[0095] A denial message is a reverse response message sent by the receiving end to the sending end for the corresponding sequence number when data reception is abnormal, verification fails, data is lost, or format is incorrect. It is used to accurately indicate that the request frame message or web request for the corresponding sequence number needs to be retransmitted.

[0096] Error recovery operations may include identifying forwarded HTTP / HTTPS requests by sequence number, receiving confirmation or denial information returned by the web server, and performing a new round of screening and identification based on the proposed retransmission conditions. For example, retransmitting requests that are not confirmed or have abnormal confirmation, or retransmitting through a newly created temporary retransmission window, to ensure that the request can be reliably received by the web server.

[0097] During retransmission, flow control operations can include recording the order and number of request forwardings based on sequence numbers, dynamically adjusting the request forwarding rate according to the response rate of the web server and the transmission status of the Transmission Control Protocol / Internet Protocol network, so as to avoid network congestion or data loss caused by excessive request concurrency.

[0098] Specifically, during protocol conversion and request forwarding, the data relay device uses the sequence number as a unique identifier and engages in bidirectional interaction with acknowledgment and denial messages. For data with the corresponding sequence number that has received a denial message or has not received an acknowledgment message within a timeout period, it performs targeted retransmission to recover from transmission link errors and anomalies. At the same time, based on the sequence number, it statistically analyzes the number of data sent and received and the timing of data transmission and reception, and dynamically adjusts the request forwarding rate in conjunction with the response status of the peer end to achieve transmission flow control. This effectively avoids link congestion, data out-of-order delivery, and packet loss, thereby improving overall transmission reliability and operational stability.

[0099] In some embodiments, the step "forwarding HTTP / HTTPS requests to a web server based on the TCP / IP protocol stack" may include: the data relay device establishing a network connection with the web server through its own built-in TCP / IP protocol stack, and forwarding the adapted HTTP / HTTPS request message completely to the web server. During the forwarding process, the request identifier, forwarding time, and corresponding Bluetooth Low Energy client identifier are recorded to ensure that the request is traceable.

[0100] 103. Process HTTP / HTTPS requests through a web server and return HTTP / HTTPS responses to the data relay device.

[0101] Specifically, after receiving an HTTP / HTTPS request message forwarded by a data relay device, the web server initiates a request parsing process: First, it validates the request message to ensure the request header and body are complete and error-free. Once validation is successful, it parses the core information in the request. After parsing, the web server matches the corresponding business processing logic based on the request content and prepares to execute subsequent request processing operations.

[0102] The web server executes corresponding business processing based on the parsed HTTP / HTTPS request content: If it is a GET request, the web server queries the resources corresponding to the request (such as device configuration parameters, historical data reports, static web page resources, etc.); if it is a POST request, the web server receives the data in the request body (such as sensor data, alarm information, configuration instructions, etc. uploaded by Bluetooth Low Energy clients), and performs operations such as data storage, business logic calculation, and instruction preprocessing.

[0103] In some embodiments, during processing, the web server synchronously associates semantic priority information in the request. If it is an urgent / critical priority request, processing resources are allocated first to shorten processing time and ensure a rapid response to urgent requests.

[0104] After the web server completes the request processing, it generates the corresponding HTTP / HTTPS response message based on the processing result. Then, the web server sends the complete response message to the data relay device through the established TCP / IP network connection.

[0105] 104. The HTTP / HTTPS response is decomposed into response frame messages through a data relay device, and the response frame messages are sent to the Bluetooth Low Energy client so that the Bluetooth Low Energy client can obtain the HTTP / HTTPS response based on the response frame messages.

[0106] In this embodiment, the data relay device receives the HTTP / HTTPS response message through its own TCP / IP protocol stack. It first performs an integrity check to verify whether the response identifier is consistent with the HTTP / HTTPS request identifier previously forwarded to the web server, whether the response status code is valid, and whether the response header and response body are complete. After the check passes, the HTTP / HTTPS response message is sent to the buffer module of the data relay device for temporary storage. At the same time, the Bluetooth Low Energy client identifier associated with the response is recorded to ensure that the response frame message can be accurately sent to the corresponding Bluetooth Low Energy client.

[0107] Specifically, decomposing the HTTP / HTTPS response into response frame messages via a data relay device can include the following operations: The data relay device reads the effective MTU parameter of the BLE link between the current device and the Bluetooth Low Energy client (this parameter is the initial MTU value negotiated when the BLE link is established; if the MTU changes dynamically, the latest updated MTU value is read). At the same time, it calls the fragmentation and reassembly algorithm to use this MTU value as the baseline threshold for HTTP / HTTPS response framing, and determines the maximum payload length of a single frame response message (the single frame payload length does not exceed the effective carrying bytes of the current MTU, reserving the bytes required for the frame header).

[0108] Then, the data relay device reads the verified HTTP / HTTPS response messages from the buffer module, first parses the core information of the response messages, and then splits the HTTP / HTTPS response messages into frames according to the currently effective MTU baseline threshold, generating several response frame messages. The frame header of each response frame message follows the expanded frame structure described above, including a sequence identifier, fragment index, total number of fragments, payload length, flags, and a newly added priority level field.

[0109] After all response frame messages are generated, the semantic-aware adaptive scheduler of the data relay device classifies the response frame messages and adds them to the corresponding priority queues according to the PL field in the frame header of each frame message, sorting them in the order of "urgent / critical priority > important priority > normal priority > background / low priority". At the same time, the sorted response frame messages are sent to the response frame buffer area of ​​the buffer module for temporary storage and awaiting transmission. During the caching process, the BLE link status is monitored in real time to ensure that the transmission timing is adapted to link stability.

[0110] Then, under the control of the semantically aware adaptive scheduler, the data relay device reads the response frame messages sequentially from the priority queue and sends the response frame messages to the Bluetooth Low Energy client through the BLE data transmission channel.

[0111] Finally, the Bluetooth Low Energy client parses and restores the HTTP / HTTPS response message, extracts the response header, response body, and response status code, and executes the corresponding business logic based on the response content: if the response indicates successful request processing, it reads the processing result (such as configuration parameters, query data, etc.) from the response body, updates the local device status, or executes the corresponding operation; if the response indicates an error, it records the error information and waits for a subsequent re-initiation of the request; at the same time, based on the PL field of the response frame, it prioritizes processing high-priority response data to ensure that emergency responses take effect quickly.

[0112] In some embodiments, the method may further include the following steps: During the process of sending response frame messages to the Bluetooth Low Energy client, a power-aware scheduling mechanism is used to schedule and control the transmission timing of the response frame messages, so that the data transmission time is aligned and matched with the sleep cycle and link connection interval of the Bluetooth Low Energy device.

[0113] The Bluetooth Low Energy (BLE) client's sleep cycle is preset by its own firmware, representing the duration of the BLE client's sleep in an inactive state (i.e., the time interval during which it does not receive data and operates at low power). The link connection interval is determined by both parties during BLE link establishment, representing the time interval (in milliseconds) during which the BLE client wakes up from sleep and establishes temporary communication with the data relay device.

[0114] The data relay device includes a power consumption-aware scheduling module. This module performs timing scheduling on the response frame messages in the buffer according to the following logic to achieve alignment and matching with the Bluetooth Low Energy client's sleep cycle and link connection interval: Timing prediction: Real-time tracking of the timing of BLE link connection intervals, predicting the start time and duration of the next wake-up synchronization window, and combining the priority of response frame messages to determine the scheduling order of frames to be sent; Transmission during non-sleep periods: The response frame message sending operation is triggered only within the wake-up synchronization window of the Bluetooth Low Energy client, avoiding data transmission during the Bluetooth Low Energy client's sleep cycle. If the current time is during the Bluetooth Low Energy client's sleep period, the power consumption awareness scheduling module will temporarily store the frame message to be sent in the buffer and wait for the next wake-up synchronization window to start before sending it. Multi-frame timing adaptation: If multiple response frame messages need to be sent (such as multiple frames after splitting a long HTTP / HTTPS response), the frame sending timing is evenly distributed to consecutive wake-up synchronization windows. The number of frames sent in each wake-up synchronization window is determined according to the window duration and single frame transmission duration to avoid timeout caused by transmitting too many frames in a single wake-up window, and at the same time to avoid frequent wake-up of Bluetooth Low Energy clients. After all response frame messages are sent, the power consumption awareness scheduling module of the data relay device sends a transmission completion notification to the Bluetooth Low Energy client, informing the Bluetooth Low Energy client that it can resume normal sleep cycles. At the same time, the power consumption awareness scheduling module suspends response frame transmission scheduling and enters a low-power listening state, only restarting the scheduling process when it receives a new response frame message or a Bluetooth Low Energy client parameter update notification.

[0115] After receiving the transmission completion notification, the Bluetooth Low Energy client confirms that all response frame messages have been received completely, immediately exits the wake-up state, resumes the preset sleep cycle, minimizes its own power consumption, and achieves a low-power operation mode of "wake-up during data transmission and sleep after transmission is completed".

[0116] In some embodiments, the method may further include the following steps: The response frame message is compressed and encrypted to obtain the processed response frame message; In this embodiment, after the data relay device frames the response message, it can optionally perform lossless compression on the framed payload data and can encrypt and encapsulate the compressed framed data based on a pre-negotiated session key. Simultaneously, it marks the frame header with compression and encryption identifiers so that the Bluetooth Low Energy client can perform decryption and decompression accordingly. The compression / encryption identifiers inform the receiving end whether the current payload has been compressed or encrypted, and which algorithm (e.g., zlib compression, AES encryption) was used.

[0117] Compression reduces the number of bytes transmitted in the Bluetooth Low Energy link, decreases the number of packets sent, shortens transmission time, further saves power consumption and improves transmission throughput efficiency; encryption protects the confidentiality of response message data during Bluetooth Low Energy wireless transmission, preventing data from being eavesdropped on or tampered with, and improving the security level of wireless communication.

[0118] The step "Send response frame message to Bluetooth Low Energy client" can include the following operations: The processed response frame message is sent to the Bluetooth Low Energy client.

[0119] In some embodiments, the method may further include the following steps: When the data relay device receives a request for framing, it temporarily stores the request for framing in a preset buffer space. When the data relay device receives an HTTP / HTTPS response, it temporarily stores the HTTP / HTTPS response in a preset buffer space. Based on the real-time data transmission status between the Bluetooth Low Energy link and the Internet Protocol network, the data relay device reads temporary data from a preset buffer space and executes subsequent protocol conversion or data transmission operations in a preset order.

[0120] In this embodiment, the data relay device is pre-configured with an independent buffer space, which is used to temporarily store various types of data to be processed. For example, it may include frame data from Bluetooth Low Energy clients and HTTP / HTTPS response data from web servers. At the same time, the read and write rules, storage priority and data retention duration of the buffer space are configured to complete the initial configuration of the buffer mechanism.

[0121] When the data relay device receives a request frame message from a Bluetooth Low Energy client, it initiates a buffer storage operation, storing each received request frame message in the preset buffer space according to the receiving time sequence. During the storage process, the receiving time, sequence identifier, and data type of the request frame message are recorded to ensure that the frame data is stored in an orderly manner in the buffer space without being disordered or lost.

[0122] The data relay device reads the temporarily stored Bluetooth Low Energy frame data sequentially from the buffer space according to the preset reading rules. During the reading process, the frame data is initially verified. After confirming that the data format is correct, it is sent to the protocol conversion module to perform the conversion operation from Bluetooth Low Energy frame message to standard HTTP / HTTPS request. If the temporarily stored frame data in the buffer space has not reached the preset reading threshold or the protocol conversion module is busy, the frame data will continue to be stored until the reading conditions are met before the reading operation is performed.

[0123] During the Web response processing, when the data relay device receives HTTP / HTTPS response data returned from the Web server, it also initiates a buffering operation to store the response data completely in a preset buffer space. During storage, the Bluetooth Low Energy client identifier and request sequence number corresponding to the response data are marked to ensure that the response data is accurately associated with the corresponding Web request.

[0124] The data relay device reads the temporarily stored Hypertext Transfer Protocol (HTTP) response data from the buffer space based on the real-time transmission status of the Bluetooth Low Energy (BLE) link, including connection interval, transmission rate, and device sleep cycle. After reading, the data is sent to the framing processing module to perform framing, optional compression, and encryption processing of the response message. If the BLE link is busy or there is a momentary congestion, the data relay device will continue to store the response data in the buffer space. After the link status is restored, the data will be read in sequence and sent to the BLE client.

[0125] During data storage, the buffer space monitors the storage capacity in real time. When the stored data reaches the preset capacity threshold, it can delete the earliest stored data that has been processed according to the "first-in, first-out" rule to release the buffer space. If there is unprocessed data, it will be retained first to ensure that the buffer operation does not affect the normal protocol conversion and data transmission process of the data transfer device.

[0126] In some embodiments, the method may further include the following steps: After the Bluetooth Low Energy client starts, it enables request-response listening mode to receive requests from the web server. The Bluetooth Low Energy client monitors the data transmission status of the Bluetooth Low Energy link in real time. When it receives a request forwarded by the Web server through a data relay device, it parses the request content and performs the corresponding operation to complete the two-way data interaction with the Web server.

[0127] In this embodiment, the Bluetooth Low Energy (BLE) client has bidirectional interaction capabilities. The specific implementation process is as follows: After the BLE client starts up, it automatically enables request-response listening mode and low-power sleep mechanism, completes the BLE link connection with the data relay device, and negotiates and determines the MTU parameters and sleep cycle. The client can actively initiate Web requests and send them to the data relay device through the GATT link, or passively respond to requests initiated by the Web server or the data relay device (such as status query, parameter configuration), perform the corresponding operation, and feed back the results through the BLE link. All data transmission follows the MTU limit, is transmitted in frames, and interacts in an orderly manner. At the same time, with the help of power-aware scheduling, data transmission and reception are only completed during the client wake-up period to ensure reliable interaction and meet low-power requirements.

[0128] Compared to traditional Bluetooth Low Energy (BLE) clients that typically operate in a "client-pull" mode, meaning they only initiate requests, the BLE client in this application possesses the ability to respond to server-initiated requests, significantly expanding the application scope and interactive flexibility of restricted devices. This enables the web server to proactively push information, send control commands, update configurations, or trigger specific operations to restricted devices, thereby achieving "server-push" or bidirectional communication. This capability is crucial for remote device management, real-time notifications, over-the-air (OTA) firmware upgrades, and more complex IoT application scenarios, enhancing the system's real-time performance and interactivity.

[0129] This application discloses a web request and response transmission method based on a Bluetooth Low Energy (BLE) link. The method includes: decomposing a web request into request frame messages using a Bluetooth Low Energy (BLE) client, and sending the request frame messages to a data relay device via a BLE data transmission channel; converting the request frame messages into standard HTTP / HTTPS requests using the data relay device, and sending the HTTP / HTTPS requests to a web server; processing the HTTP / HTTPS requests using the web server, and returning an HTTP / HTTPS response to the data relay device; and decomposing the HTTP / HTTPS response into response frame messages using the data relay device, and sending the response frame messages to the BLE client, so that the BLE client obtains an HTTP / HTTPS response based on the response frame messages. This allows a restricted BLE client to efficiently and reliably access internet web resources without needing to carry a complete TCP / IP protocol stack, overcoming the application limitations of traditional BLE devices in web access and bidirectional data interaction.

[0130] Based on the above description, the following example will further illustrate the web request and response transmission method based on Bluetooth Low Energy (BLE) of this application. Taking the application of this BLE-based web request and response transmission method to a smart bracelet as an example, the specific process can be as follows: Step 1: The Bluetooth Low Energy client initiates a web request: Suppose a Bluetooth Low Energy (BLE) client is a smart bracelet (acting as a BLE client) that needs to upload its user's step count data to a cloud-based health management platform's web server (e.g., a RESTful API endpoint). Since smart bracelets typically lack a complete IP stack or Wi-Fi module, they cannot directly send HTTP requests.

[0131] The smart bracelet first encapsulates the step count data to be sent into an HTTP POST request. Then, using a framing mechanism, this HTTP request is broken down into multiple BLE (Browser-Leaf) frame messages. Each frame message has a compact header containing information such as a sequence number and fragment index to ensure the order and integrity of data transmission.

[0132] The smart bracelet uses its GATT client functionality to write these framed messages to the GATT attribute exposed by its paired BLE server / peripheral device (e.g., the user's smartphone or a dedicated BLE gateway). In a "single-attribute implementation," all frames are written to the same bidirectional GATT attribute; in a "multi-attribute implementation," the URI, header, and data body may be written to different GATT attributes for more efficient parallel transmission.

[0133] When a smart bracelet transmits sensitive health data via an unencrypted BLE link, AES encryption with a pre-shared key can be used to encrypt the step count data before transmitting it in frames. Alternatively, when the smart bracelet transmits sensitive data, the request payload can be encrypted with AES using a pre-shared key, with an encryption flag filled in the frame header. The gateway can then decrypt the encrypted data before forwarding the HTTP request.

[0134] Step 2: Data transfer equipment processes requests: The data relay device can be called a "gateway / proxy" or "BLE server / peripheral device". The user's smartphone (acting as a BLE server / peripheral device and running gateway / proxy functions) receives BLE frame messages from the smart bracelet.

[0135] The gateway / proxy on the smartphone uses optimized fragmentation and reassembly algorithms to reassemble these fragmented messages into a complete HTTP POST request. The gateway / proxy then translates this HTTP request into a standard HTTP request over the TCP / IP protocol stack and forwards it to the web server of the cloud-based health management platform via the phone's cellular network or Wi-Fi connection.

[0136] During this process, the gateway / agent will also handle any errors that may be caused by BLE transmission instability (e.g., retransmission via serial number and ACK / NAK mechanism) and optimize transmission timing according to power-aware scheduling strategy to save power for smart bracelets and mobile phones.

[0137] Step 3: Web server response and gateway / proxy return: The cloud-based health management platform's web server processes step count data and returns an HTTP response (e.g., a JSON message indicating successful data upload).

[0138] After receiving this HTTP response, the gateway / proxy on the smartphone uses the framing mechanism again to break the HTTP response into multiple BLE frame messages, which are then sent back to the smart bracelet via BLE.

[0139] Step 4: Bluetooth Low Energy client receives response: After receiving these response frames, the smart bracelet reassembles them to obtain a complete HTTP response, thus confirming that the step count data has been successfully uploaded.

[0140] To facilitate better implementation of the Bluetooth Low Energy (BLE)-based Web request and response transmission method provided in this application, this application also provides a Bluetooth Low Energy (BLE)-based Web request and response transmission apparatus. The meanings of the terms used are the same as in the Bluetooth Low Energy (BLE)-based Web request and response transmission method described above, and specific implementation details can be found in the descriptions within the method embodiments.

[0141] Please see Figure 3 , Figure 3 A structural block diagram of a web request and response transmission device based on a Bluetooth Low Energy link, provided in an embodiment of this application, is shown. The device includes: The decomposition unit 301 is used to decompose a web request into request frame messages via a Bluetooth Low Energy client, and send the request frame messages to a data relay device via a Bluetooth Low Energy data transmission channel; The conversion unit 302 is used to convert the request frame message into a standard HTTP / HTTPS request through a data relay device, and send the HTTP / HTTPS request to the web server; The response receiving and processing unit 303 is used to process HTTP / HTTPS requests through a web server and return HTTP / HTTPS responses to the data relay device; The sending unit 304 is used to decompose the HTTP / HTTPS response into response frame messages through the data relay device and send the response frame messages to the Bluetooth Low Energy client so that the Bluetooth Low Energy client can obtain the HTTP / HTTPS response based on the response frame messages; The control unit 305 is used to schedule and control the transmission timing of the response frame message by employing a power-aware scheduling mechanism during the process of sending the response frame message to the Bluetooth Low Energy client, so that the data transmission time is aligned and matched with the sleep cycle and link connection interval of the Bluetooth Low Energy device.

[0142] In some embodiments, the Bluetooth Low Energy data transmission channel includes: a bidirectional Bluetooth Low Energy data transmission channel; Decomposition unit 301 may include: The frame processing subunit is used to process the Web request as a whole data into frames to obtain the request frame message. The corresponding transmitting subunit is used to sequentially send request framing messages to the data relay device via a bidirectional Bluetooth Low Energy data transmission channel.

[0143] In some embodiments, the Bluetooth Low Energy data transmission channel includes: multiple independent Bluetooth Low Energy data transmission channels; Decomposition unit 301 may include: The sub-unit is used to split the Web request according to a preset semantic type to obtain at least one type of semantic data, and to perform frame processing on each type of semantic data independently to obtain the request frame message. The parallel transmission subunit is used to send request framing messages to the data relay device in parallel through multiple independent Bluetooth Low Energy data transmission channels.

[0144] In some embodiments, the conversion unit 302 may include: The reassembly subunit is used to reassemble the request frame messages using a fragmentation and reassembly algorithm to restore the complete Web request. The conversion subunit is used to convert the protocol format of the complete web request and generate an HTTP / HTTPS request. The forwarding subunit is used to forward HTTP / HTTPS requests to the web server based on the TCP / IP protocol stack.

[0145] In some embodiments, the device may further include: The execution unit is used to perform error recovery and flow control operations during the protocol conversion and request forwarding process, based on the sequence identifier in the request frame message, the confirmation information and / or denial information returned by the web server.

[0146] In some embodiments, the device may further include: The encryption processing unit is used to compress and encrypt the response frame messages to obtain the processed response frame messages. The transmitting unit 304 may include: The transmitting subunit is used to send the processed response framed message to the Bluetooth Low Energy client.

[0147] In some embodiments, the device may further include: The message storage unit is used to temporarily store the request frame splitting message in a preset buffer space when the data relay device receives the request frame splitting message; The response storage unit is used to temporarily store the HTTP / HTTPS response to a preset buffer space when the data relay device receives the HTTP / HTTPS response; The operation unit is used to read temporary data from a preset buffer space based on the real-time data transmission status of the Bluetooth Low Energy link and the Internet Protocol network through a data relay device, and to execute subsequent protocol conversion or data transmission operations in a preset order.

[0148] In some embodiments, the device may further include: The enable unit is used to enable the request-response listening mode after the Bluetooth Low Energy client is started, so as to receive requests initiated from the web server. The receiving unit is used by the Bluetooth Low Energy client to monitor the data transmission status of the Bluetooth Low Energy link in real time. When it receives a request forwarded by the Web server through the data relay device, it parses the request content and performs the corresponding operation to complete the bidirectional data interaction with the Web server.

[0149] In some embodiments, the device may further include: The determining unit is used to determine the priority information corresponding to the Web request based on the content of the Web request through the Bluetooth Low Energy client, and add the priority information to the request frame message; The acquisition unit is used to receive the request framing message through the data relay device, acquire the priority information in the request framing message, and add the request framing message to the target priority queue corresponding to the priority information. The conversion processing unit is used to convert and process request frame messages based on the target priority queue through the data relay device; The interval processing unit is used to temporarily shorten the Bluetooth Low Energy link connection interval through a data relay device if there is a target request frame message that meets the preset priority processing conditions, and to enable the fastest supported physical transport layer transmission rate to complete the transmission of the target request frame message. After the transmission is completed, the default link connection parameters and power consumption optimization settings are automatically restored.

[0150] This application discloses a web request and response transmission device based on a Bluetooth Low Energy (BLE) link. A decomposition unit 301 decomposes a web request into request frame messages via a Bluetooth Low Energy client and sends these request frame messages to a data relay device via a Bluetooth Low Energy data transmission channel. A conversion unit 302 converts the request frame messages into standard HTTP / HTTPS requests via the data relay device and sends the HTTP / HTTPS requests to a web server. A response receiving and processing unit 303 processes the HTTP / HTTPS requests via the web server and returns an HTTP / HTTPS response to the data relay device. A sending unit 304 decomposes the HTTP / HTTPS response into response frame messages via the data relay device and sends these response frame messages to the Bluetooth Low Energy client, enabling the Bluetooth Low Energy client to obtain an HTTP / HTTPS response based on the response frame messages. During the process of sending response frame messages to the Bluetooth Low Energy client, a control unit 305 employs a power-aware scheduling mechanism to schedule and control the transmission timing of the response frame messages, ensuring that the data transmission time is aligned with the sleep cycle and link connection interval of the Bluetooth Low Energy device. This enables restricted Bluetooth Low Energy clients to efficiently and reliably access Internet Web resources without needing to carry a complete TCP / IP protocol stack, breaking through the application limitations of traditional Bluetooth Low Energy devices in Web access and two-way data interaction.

[0151] Accordingly, embodiments of this application also provide an electronic device. For example... Figure 4 As shown, Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device 400 includes a processor 401 with one or more processing cores, a memory 402 with one or more computer-readable storage media, and a computer program stored in the memory 402 and executable on the processor. The processor 401 and the memory 402 are electrically connected. Those skilled in the art will understand that... Figure 4 The electronic device structures shown herein do not constitute a limitation on electronic devices and may include, but are not limited to, those shown. Figure 4 It can show more or fewer parts, or combine certain parts, or arrange different parts.

[0152] The processor 401 is the control center of the electronic device 400. It connects various parts of the electronic device 400 through various interfaces and lines. By running or loading software programs and / or modules stored in the memory 402, and calling data stored in the memory 402, it performs various functions of the electronic device 400 and processes data, thereby monitoring the electronic device 400 as a whole.

[0153] In this embodiment, the processor 401 in the electronic device 400 loads the instructions corresponding to the processes of one or more applications into the memory 402 according to the following steps, and the processor 401 runs the applications stored in the memory 402 to realize various functions: The web request is broken down into request frame messages by the Bluetooth Low Energy client, and the request frame messages are sent to the data relay device through the Bluetooth Low Energy data transmission channel; The request frame message is converted into a standard HTTP / HTTPS request through a data relay device, and then the HTTP / HTTPS request is sent to the web server. The web server processes HTTP / HTTPS requests and returns HTTP / HTTPS responses to the data relay device. The HTTP / HTTPS response is broken down into response frame messages by a data relay device, and the response frame messages are sent to the Bluetooth Low Energy client so that the Bluetooth Low Energy client can obtain the HTTP / HTTPS response based on the response frame messages.

[0154] This embodiment of the application decomposes a web request into request frame messages by a Bluetooth Low Energy (BLE) client, and sends these request frame messages to a data relay device via a BLE data transmission channel. The data relay device converts the request frame messages into standard HTTP / HTTPS requests and sends them to a web server. The web server processes the HTTP / HTTPS requests and returns an HTTP / HTTPS response to the data relay device. The data relay device then decomposes the HTTP / HTTPS response into response frame messages and sends these response frame messages to the BLE client, enabling the BLE client to obtain the HTTP / HTTPS response based on the response frame messages. In this way, a restricted BLE client can efficiently and reliably access internet web resources without needing to carry a complete TCP / IP protocol stack, overcoming the application limitations of traditional BLE devices in web access and two-way data interaction.

[0155] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0156] Optional, such as Figure 4 As shown, the electronic device 400 may further include a display 403 and an input unit 404. The processor 401 is electrically connected to both the display 403 and the input unit 404. Those skilled in the art will understand that... Figure 4 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0157] Display 403 can be used to display a graphical user interface (GUI) and receive operation commands generated by the user interacting with the GUI. Display 403 may include a display panel and a touch panel. The display panel can be used to display information input by the user or information provided to the user, as well as various graphical user interfaces of the electronic device. These graphical user interfaces can be composed of graphics, guidance information, icons, video, and any combination thereof. Optionally, the display panel can be configured using a liquid crystal display (LCD), organic light-emitting diode (OLED), or other similar technologies. The touch panel can be used to collect touch operations performed by the user on or near it (such as operations performed by the user using a finger, stylus, or any suitable object or accessory on or near the touch panel), generate corresponding operation commands, and execute the corresponding program according to the operation commands. Optionally, the touch panel may include a touch detection device and a touch controller.

[0158] The touch detection device detects the user's touch location and the signal generated by the touch operation, transmitting the signal to the touch controller. The touch controller receives touch information from the touch detection device, converts it into touch point coordinates, and sends it to the processor 401. It can also receive and execute commands from the processor 401. The touch panel can cover the display panel. When the touch panel detects a touch operation on or near it, it transmits the information to the processor 401 to determine the type of touch event. Subsequently, the processor 401 provides corresponding visual output on the display panel based on the type of touch event. In this embodiment, the touch panel and display panel can be integrated into the display 403 to achieve input and output functions. However, in some embodiments, the touch panel and display panel can be implemented as two independent components to achieve input and output functions. That is, the display 403 can also be used as part of the input unit 404 to achieve input functions.

[0159] The input unit 404 can be used to receive input numbers, characters, or user characteristic information (such as fingerprints, iris, facial information, etc.), and to generate keyboard, mouse, joystick, optical, or trackball signal inputs related to user settings and function control.

[0160] In some embodiments, the electronic device may further include an audio circuit, which can provide an audio interface between the user and the device control device via a speaker and a microphone. The audio circuit can convert received audio data into electrical signals and transmit them to the speaker, where the speaker converts them into sound signals for output. Conversely, the microphone converts collected sound signals into electrical signals, which are then received by the audio circuit, converted back into audio data, and processed by the processor 401. The audio data is then transmitted via a radio frequency circuit to, for example, another device control device, or output to a memory 402 for further processing. The audio circuit may also include an earphone jack to provide communication between a peripheral headset and the device control device.

[0161] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0162] As can be seen from the above, the electronic device provided in this embodiment can decompose a web request into request frame messages through a Bluetooth Low Energy client, and send the request frame messages to a data relay device through a Bluetooth Low Energy data transmission channel; the data relay device converts the request frame messages into standard HTTP / HTTPS requests, and sends the HTTP / HTTPS requests to a web server; the web server processes the HTTP / HTTPS requests and returns an HTTP / HTTPS response to the data relay device; the data relay device decomposes the HTTP / HTTPS response into response frame messages, and sends the response frame messages to the Bluetooth Low Energy client, so that the Bluetooth Low Energy client can obtain an HTTP / HTTPS response based on the response frame messages.

[0163] Therefore, embodiments of this application provide a computer-readable storage medium storing a plurality of computer programs that can be loaded by a digital signal processor to execute the steps in any of the device control methods provided in embodiments of this application. For example, the computer program can execute the following steps: The web request is broken down into request frame messages by the Bluetooth Low Energy client, and the request frame messages are sent to the data relay device through the Bluetooth Low Energy data transmission channel; The request frame message is converted into a standard HTTP / HTTPS request through a data relay device, and then the HTTP / HTTPS request is sent to the web server. The web server processes HTTP / HTTPS requests and returns HTTP / HTTPS responses to the data relay device. The HTTP / HTTPS response is broken down into response frame messages by a data relay device, and the response frame messages are sent to the Bluetooth Low Energy client so that the Bluetooth Low Energy client can obtain the HTTP / HTTPS response based on the response frame messages.

[0164] This embodiment of the application decomposes a web request into request frame messages by a Bluetooth Low Energy (BLE) client, and sends these request frame messages to a data relay device via a BLE data transmission channel. The data relay device converts the request frame messages into standard HTTP / HTTPS requests and sends them to a web server. The web server processes the HTTP / HTTPS requests and returns an HTTP / HTTPS response to the data relay device. The data relay device then decomposes the HTTP / HTTPS response into response frame messages and sends these response frame messages to the BLE client, enabling the BLE client to obtain the HTTP / HTTPS response based on the response frame messages. In this way, a restricted BLE client can efficiently and reliably access internet web resources without needing to carry a complete TCP / IP protocol stack, overcoming the application limitations of traditional BLE devices in web access and two-way data interaction.

[0165] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0166] The computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0167] Since the computer program stored in the computer-readable storage medium can execute the steps of any of the device control methods provided in the embodiments of this application, the beneficial effects that any of the device control methods provided in the embodiments of this application can achieve can be realized, as detailed in the preceding embodiments, and will not be repeated here.

[0168] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A method for transmitting web requests and responses based on a Bluetooth Low Energy link, characterized in that, The method includes: The web request is decomposed into request frame messages by the Bluetooth Low Energy client, and the request frame messages are sent to the data relay device through the Bluetooth Low Energy data transmission channel; The data relay device converts the request frame message into a standard HTTP / HTTPS request and sends the HTTP / HTTPS request to the web server. The web server processes the HTTP / HTTPS request and returns an HTTP / HTTPS response to the data relay device; The data relay device decomposes the HTTP / HTTPS response into response frame messages and sends the response frame messages to the Bluetooth Low Energy client, so that the Bluetooth Low Energy client can obtain the HTTP / HTTPS response based on the response frame messages; In the process of sending the response frame message to the Bluetooth Low Energy client, a power-aware scheduling mechanism is used to schedule and control the transmission timing of the response frame message, so that the data transmission time is aligned and matched with the sleep cycle and link connection interval of the Bluetooth Low Energy client.

2. The method according to claim 1, characterized in that, The Bluetooth Low Energy data transmission channel includes: a bidirectional Bluetooth Low Energy data transmission channel; The step of decomposing a web request into request frame messages via a Bluetooth Low Energy client and sending the request frame messages to a data relay device via a Bluetooth Low Energy data transmission channel includes: The web request is treated as a whole and processed into frames to obtain the request frame message. The request frame message is sent sequentially to the data relay device through the bidirectional Bluetooth Low Energy data transmission channel.

3. The method according to claim 1, characterized in that, The Bluetooth Low Energy data transmission channel includes: multiple independent Bluetooth Low Energy data transmission channels; The step of decomposing a web request into request frame messages via a Bluetooth Low Energy client and sending the request frame messages to a data relay device via a Bluetooth Low Energy data transmission channel includes: The web request is split according to a preset semantic type to obtain at least one type of semantic data, and each type of semantic data is independently processed into frames to obtain the request frame message. The request frame message is sent in parallel to the data relay device through the multiple independent Bluetooth Low Energy data transmission channels.

4. The method according to claim 1, characterized in that, The step of converting the request framed message into a standard HTTP / HTTPS request through the data relay device and sending the HTTP / HTTPS request to the web server includes: A fragmentation and reassembly algorithm is used to reassemble the request frame messages to restore the complete Web request. The complete web request is converted to a different protocol format to generate the HTTP / HTTPS request; Based on the TCP / IP protocol stack, the HTTP / HTTPS request is forwarded to the web server.

5. The method according to claim 4, characterized in that, The method further includes: During the protocol conversion and request forwarding process, error recovery and flow control operations are performed based on the sequence identifier in the request frame message, the confirmation information and / or denial information returned by the Web server.

6. The method according to claim 1, characterized in that, The method further includes: The Bluetooth Low Energy client determines the priority information corresponding to the Web request based on the content of the Web request, and adds the priority information to the request frame message; After receiving the request frame message through the data relay device, the priority information in the request frame message is obtained, and the request frame message is added to the target priority queue corresponding to the priority information. The data relay device performs conversion processing on the request frame message based on the target priority queue; If a target request frame message that meets the preset priority processing conditions exists, the Bluetooth Low Energy link connection interval is temporarily shortened through the data relay device, and the fastest supported physical transport layer transmission rate is enabled to complete the transmission of the target request frame message. After the transmission is completed, the default link connection parameters and power consumption optimization settings are automatically restored.

7. The method according to claim 1, characterized in that, The method further includes: After the Bluetooth Low Energy client starts, it enables the request-response listening mode to receive requests from the web server. The Bluetooth Low Energy client monitors the data transmission status of the Bluetooth Low Energy link in real time. When it receives a request forwarded by the Web server through the data relay device, it parses the request content and performs the corresponding operation to complete the bidirectional data interaction with the Web server.

8. A web request and response transmission system based on a Bluetooth Low Energy link, comprising a Bluetooth Low Energy client, a data relay device, and a web server, characterized in that: The Bluetooth Low Energy client is used to decompose a Web request into request frame messages and send the request frame messages to the data relay device through a Bluetooth Low Energy data transmission channel; The data relay device is used to convert the request frame message into a standard HTTP / HTTPS request and send the HTTP / HTTPS request to the web server; The web server is used to receive and process the HTTP / HTTPS requests, and to return HTTP / HTTPS responses to the data relay device; The data relay device is also used to decompose the HTTP / HTTPS response into response frame messages and send the response frame messages to the Bluetooth Low Energy client; The Bluetooth Low Energy client is also used to receive the response frame message and obtain the HTTP / HTTPS response based on the response frame message.

9. A web request and response transmission device based on a Bluetooth Low Energy link, characterized in that, The device includes: The decomposition unit is used to decompose a web request into request frame messages via a Bluetooth Low Energy client, and send the request frame messages to a data relay device via a Bluetooth Low Energy data transmission channel; The conversion unit is used to convert the request frame message into a standard HTTP / HTTPS request through the data relay device, and send the HTTP / HTTPS request to the web server; A response receiving and processing unit is configured to process the HTTP / HTTPS request through the web server and return an HTTP / HTTPS response to the data relay device; The sending unit is configured to decompose the HTTP / HTTPS response into response frame messages through the data relay device, and send the response frame messages to the Bluetooth Low Energy client, so that the Bluetooth Low Energy client can obtain the HTTP / HTTPS response based on the response frame messages; The control unit is used to schedule and control the transmission timing of the response frame message using a power-aware scheduling mechanism during the process of sending the response frame message to the Bluetooth Low Energy client, so that the data transmission time is aligned and matched with the sleep cycle and link connection interval of the Bluetooth Low Energy client.

10. An electronic device, characterized in that, The electronic device includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the program to implement the web request and response transmission method based on a Bluetooth Low Energy link as described in any one of claims 1 to 7.

Images