LoRa gateway configuration method and device, product and medium

The LoRa gateway configuration method, which combines Bluetooth pass-through and HTTP protocol, solves the problem of easy configuration of LoRa gateways in complex field environments, and realizes flexible adaptation and efficient development in multiple network environments.

CN122053366APending Publication Date: 2026-05-15SHENZHEN RUIKE HUILIAN TECH
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
SHENZHEN RUIKE HUILIAN TECH
Filing Date
2026-02-06
Publication Date
2026-05-15

AI Technical Summary

Technical Problem

Existing LoRa gateway configuration methods rely on wired or wireless networks, which cannot adapt to complex field environments, resulting in inconvenient deployment.

Method used

It adopts a combination of Bluetooth pass-through and HTTP protocol, and implements LoRa gateway configuration through GATT server and HTTP server, supporting multiple scenarios such as Bluetooth, wireless LAN, wired network and mobile network.

Benefits of technology

It enables flexible configuration of LoRa gateways in various network environments, avoiding redundant development and improving development efficiency and adaptability.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122053366A_ABST
    Figure CN122053366A_ABST
Patent Text Reader

Abstract

The invention relates to the field of communication, in particular to a LoRa gateway configuration method and device, a gateway, a product and a medium. According to the method, the configuration request received from the Bluetooth can be subjected to unvarnished transmission, and the unvarnished transmission configuration request is in the HTTP format, so that the LoRa gateway can be compatible with modes of the Bluetooth, a wireless local area network, a wired network and a mobile network at the same time, and can flexibly adapt to use requirements of various scenes.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of communications, and more particularly to a LoRa gateway configuration method, apparatus, product, and medium. Background Technology

[0002] With the widespread application of IoT technology, LoRa gateways, as the core hub connecting massive numbers of terminal devices and upper-layer networks, require ease of deployment and initial configuration. Common LoRa gateway configuration methods mainly include the following two: (1) Wired Ethernet configuration: The LoRa gateway must have a usable wired Ethernet interface at the installation point and be connected to the terminal via a network cable. The terminal can configure the LoRa gateway via the network cable.

[0003] (2) Wi-Fi connection configuration: There is an available Wi-Fi network in the environment where the LoRa gateway is located, and technicians need to connect the LoRa gateway to the Wi-Fi network on site first. The terminal completes the parameter configuration of the LoRa gateway through the wireless local area network.

[0004] The above solution only supports transmission via wired or wireless networks. However, the on-site environment is very complex. Some installation points support the network, while others do not. Summary of the Invention

[0005] This application provides a LoRa gateway configuration method, device, product, and medium that can flexibly adapt to the usage requirements of various scenarios.

[0006] Firstly, a method for configuring a LoRa gateway is provided. The LoRa gateway includes a GATT server, a gateway server, and a configuration storage module. The method includes: The GATT server receives a first configuration request sent by a mobile terminal via Bluetooth, wherein the first configuration request includes first configuration information, the first configuration information being used to configure the LoRa gateway, and the first configuration information including configuration data in JSON format. The GATT server will pass through the first configuration request, wherein the passing through includes: converting the JSON format configuration data into HTTP request format configuration data; The GATT server sends the first configuration request after passing through to the gateway server via HTTP. The first configuration request after passing through includes configuration data in the HTTP request format. The gateway server sends the first configuration request after pass-through to the configuration storage module for storage via an HTTP API interface.

[0007] In some possible designs, after the gateway server sends the first configuration request after transparent transmission to the configuration storage module for storage via an HTTP API interface, the method further includes: The gateway server sends a first configuration response to the GATT server, wherein the first configuration response includes response data in HTTP response format; The GATT server performs reverse pass-through on the first configuration response, wherein the reverse pass-through includes: converting the HTTP response data into JSON response data; The GATT server sends the first configuration response after reverse pass-through to the mobile terminal via Bluetooth, wherein the first configuration response after reverse pass-through includes the response data in JSON format.

[0008] In some possible designs, the LoRa gateway also includes an HTTP server. The HTTP server receives a second configuration request sent by the mobile terminal via a wireless local area network, a wired network, or a mobile network. The second configuration request includes second configuration information, which is used to configure the LoRa gateway. The HTTP server sends the second configuration request to the gateway server via HTTP; The gateway server sends the second configuration request to the configuration storage module for storage.

[0009] In some possible designs, after the gateway server sends the second configuration request to the configuration storage module for storage, the method further includes: The configuration storage module sends a second configuration response to the gateway server, wherein the second configuration response is used to indicate that the second configuration request has been processed. The gateway server sends the second configuration response to the HTTP server via HTTP; The HTTP server sends the second configuration response to the mobile terminal via a wireless LAN, a wired network, or a mobile network.

[0010] In some possible designs, the GATT server will pass through the first configuration request, including: The GATT server extracts JSON-formatted configuration data from the first configuration request. The JSON-formatted configuration data is used to configure the configuration object. The JSON-formatted configuration data includes an HTTP method, a path, headers, and a message body. The HTTP method is used to indicate the operation method of the configuration object. The path is used to indicate the location of the configuration object in the LoRa gateway. The message body is used to indicate the configuration parameters of the configuration object. The headers are used to indicate the format of the configuration parameters. The GATT server carries the HTTP method in the HTTP method field, the path in the request path field, the header in the request header field, and the message body in the message body field, thereby obtaining the configuration data of the HTTP request format and obtaining the first configuration request after pass-through.

[0011] In some possible designs, the GATT server performs reverse pass-through of the first configuration response, including: The GATT server extracts response data in the HTTP response format from the first configuration response, wherein the response data in the HTTP response format includes an HTTP status code; The GATT server carries the HTTP status code in a JSON format data body to obtain the JSON format response data; The GATT server obtains the first configuration response after the reverse pass-through based on the JSON format response data.

[0012] Secondly, a LoRa gateway configuration device is provided, comprising: A receiving module is configured to receive a first configuration request sent by a mobile terminal via Bluetooth, wherein the first configuration request includes first configuration information, the first configuration information is used to configure the LoRa gateway, and the first configuration information includes configuration data in JSON format. A pass-through module is used to pass through the first configuration request, wherein the pass-through includes: converting the JSON format configuration data into HTTP request format configuration data; The first sending module is used to send the first configuration request after passing through to the gateway server via HTTP. The first configuration request after passing through includes configuration data in HTTP request format. The second sending module is used to send the first configuration request after transparent transmission to the configuration storage module for storage via an HTTP API interface.

[0013] Thirdly, a LoRa gateway is provided, comprising: a processor and a memory, wherein the processor is connected to the memory, the memory is used to store instructions, and the processor is used to read the instructions from the memory to perform the method as described in any of the first aspects.

[0014] Fourthly, a program product containing instructions is provided that, when executed by an electronic device, causes the electronic device to perform the method as described in any of the first aspects.

[0015] Fifthly, a readable storage medium is provided, including program instructions that, when executed by an electronic device, perform the method as described in any of the first aspects.

[0016] In the above scheme, the GATT server can pass through configuration requests received from Bluetooth. The passed-through configuration requests are in HTTP format, so they can be sent directly to the gateway server for processing. The HTTP server can also receive configuration requests from Wi-Fi, wired networks, and mobile networks, and send the received configuration requests directly to the gateway server. Therefore, the LoRa gateway can be compatible with Bluetooth, Wi-Fi, wired networks, and mobile networks simultaneously, flexibly adapting to the usage requirements of various scenarios. Furthermore, only one gateway server is needed to provide services for various scenarios such as Bluetooth, Wi-Fi, wired networks, and mobile networks, eliminating the need to develop separate gateway servers for Bluetooth, Wi-Fi, wired networks, and mobile networks, thus avoiding redundant development work and improving development efficiency. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the structure of a LoRa gateway configuration system provided in this application; Figure 2 This is a schematic diagram of the hardware structure of a LoRa gateway provided in this application; Figure 3 This is a schematic diagram of the software architecture of a LoRa gateway provided in this application; Figure 4 This is a flowchart illustrating a LoRa gateway configuration method provided in this application; Figure 5 This is a schematic diagram of the structure of a first configuration request provided in this application; Figure 6 This is a schematic diagram of the structure of a first configuration request after transparent transmission provided in this application; Figure 7 This is a schematic diagram of the structure of a first configuration response provided in this application; Figure 8This is a flowchart illustrating another LoRa gateway configuration method provided in this application; Figure 9 This is a schematic diagram of the structure of a LoRa gateway provided in this application; Figure 10 This is a schematic diagram of the structure of an electronic device provided in this application. Detailed Implementation

[0018] See Figure 1 , Figure 1 This is a schematic diagram of the structure of a LoRa gateway configuration system provided in this application. Figure 1 As shown, the LoRa gateway configuration system of this application includes a mobile terminal 110 and a LoRa gateway 120.

[0019] Mobile terminal 110 may include smartphones, tablets, laptops, etc. Smartphones integrate computer-level computing, network connectivity, and multimedia processing capabilities. They run on a mobile operating system, support touch operation, can install various applications, and offer one or more functions such as communication, entertainment, office work, and payment. Tablets are portable touch-screen computing devices that fall between smartphones and laptops. They use a touchscreen as the core input method, run mobile or lightweight desktop operating systems, and typically have screen sizes between 7 and 13 inches. Their battery life is better than laptops, but their portability is less than smartphones. Laptops are foldable portable personal computers with a complete computer hardware architecture. They run desktop-level or mobile desktop operating systems, can be equipped with a physical keyboard and touchpad, and typically have screen sizes between 11 and 17 inches. They support high-performance computing, multitasking, and the operation of professional software. Terminal 110 has a Bluetooth communication module 1. The Bluetooth communication module 1 is a standardized hardware component integrating a Bluetooth radio frequency chip, baseband chip, storage unit, and peripheral circuits, enabling short-range wireless data transmission and communication between terminal 110 and LoRa gateway 120.

[0020] The LoRa Gateway 120 is the core hub of the LoRa system, used for protocol conversion and management of LoRa nodes. For example... Figure 2 As shown, the hardware of the LoRa gateway 120 may include one or more of the following: Bluetooth communication module 2121 and processor module 123.

[0021] Bluetooth communication module 2 121 is similar to Bluetooth communication module 1, and will not be described in detail here.

[0022] The processor module 123 can have various specific implementations. For example, it can be a microprocessor or a microcontroller unit (MCU). The processor module may include one or more combinations of a central processing unit (CPU), a microprocessor unit (MPU), a neural network processing unit (NPU), a tensor processing unit (TPU), or a data processing unit (DPU). This application does not impose specific limitations on these embodiments. The processor module can also be a single-core or multi-core processor. The processor module can be a combination of a CPU and hardware chips. The aforementioned hardware chips can be application-specific integrated circuits (ASICs), programmable logic devices (PLDs), or combinations thereof. The aforementioned PLDs can be complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), generic array logic (GALs), or any combination thereof. The processor module can also be implemented independently using logic devices with built-in processing logic, such as FPGAs or digital signal processors (DSPs).

[0023] like Figure 3 As shown, the software of the LoRa gateway may include a GATT server 122, an HTTP server 124, a gateway server 126, and a configuration storage module 128.

[0024] The GATT server 122 is the core data service component for Bluetooth Low Energy communication. It maintains an attribute table identified by UUID, stores information such as device status and sensor data, responds to read, write, and subscription requests from GATT clients, and completes data interaction and proactive push from the Bluetooth end through the ATT protocol. It is the key to providing data and control interfaces to the outside world.

[0025] HTTP server 124 is a server-side program that receives and processes HTTP requests and returns HTTP responses. Its core function is to respond to HTTP requests from clients, complete data interaction, configuration distribution, or business processing. It is both the receiver and the processor in HTTP communication.

[0026] Gateway server 126 serves as a hub service component between the IoT sensing layer and the network layer. Its core function is to perform multi-protocol conversion, converting short-range communication protocols such as BLE into compatible IP protocols such as MQTT and HTTP.

[0027] The configuration storage module 128 is used to store various key configuration parameters of the LoRa gateway based on non-volatile storage media, providing a standardized configuration read and write interface for other modules, supporting configuration updates and encryption protection, ensuring that the configuration is not lost when power is off and can be quickly loaded when the system starts up.

[0028] It is understood that the LoRa gateway 120 mentioned above is only a specific example. In actual applications, it may include more or fewer modules, or some of the modules may be replaced. No specific limitations are made here.

[0029] The LoRa gateway configuration system described above can be used in scenarios where neither a wireless nor a wired network exists. In such cases, mobile terminals can configure the LoRa gateway via Bluetooth. For details, please refer to [link to relevant documentation]. Figure 4 And a description of the relevant content. Mobile terminals can also be used in scenarios with wireless LAN, wired network, or mobile network access. In this case, the mobile terminal can configure the LoRa gateway through the wireless network or wired network. For details, please refer to [link to relevant documentation]. Figure 7 And a description of the related content.

[0030] See Figure 4 , Figure 4 This is a flowchart illustrating a LoRa gateway configuration method provided in this application. Figure 4 As shown, the LoRa gateway configuration method of this application includes: S101: The mobile terminal sends the first configuration request to the GATT server of the LoRa gateway via Bluetooth.

[0031] The first configuration request includes the first configuration information. For example... Figure 5As shown, the first configuration request includes a preamble, access address, PDU payload, and CRC checksum. The preamble is a synchronization header field for wireless transmission and also serves as the start marker for the data packet. The access address is a unique identifier for Bluetooth BLE data packets. The PDU payload includes an opcode, a request feature handle, a feature value, etc. The opcode identifies the specific operation type; for example, opcode 0x01 indicates a write request; opcode 0x52 indicates a write command; and opcode 0x00 indicates a read request. The request feature handle indicates the location of the feature. The feature value carries the first configuration information. The CRC checksum is a checksum calculated using a fixed CRC algorithm based on all binary data from the preamble, access address, and PDU payload.

[0032] The first configuration information is in JSON format and is used to configure the LoRa gateway. This first configuration information includes the HTTP method, path, headers, and message body.

[0033] HTTP methods are used to indicate how to operate on a configuration object. The configuration object can be one or more of the following: service set identifier, IP address, subnet mask, gateway address, DNS server address, transport protocol, operating frequency band, spreading parameters, antenna gain, receive gain, transmit power, number of channels, modulation mode, network authentication parameters, data processing rules, gateway identifier, gateway operating mode, restart policy, logging level, device name, device number, time zone / time synchronization, language / display configuration, etc. Operation methods can include one or more of the following: query data (GET), create data (POST), update data (PUT), partially update data (PATCH), delete data (DELETE), retrieve only response headers (HEAD), etc.

[0034] The path indicates the location of the configuration object within the LoRa gateway. Different configuration objects have different locations within the LoRa gateway. For example, when the configured object is a service set identifier, the path could be / api / setconfig, etc.

[0035] The message body indicates the configuration parameters of the configuration object. These parameters differ for different configuration objects. For example, if the configuration object is an IP address, the configuration parameter could be 192.168.1.100; if the configuration object is a subnet mask, the configuration parameter could be 255.255.255.0.

[0036] The header is used to specify the data format or authentication. For example, the header may include: host, message body format and encoding, message body length in bytes, authentication information, etc.

[0037] It is understandable that the above first configuration information is only a specific example, and in actual applications, more data may be included.

[0038] S102: The GATT server will pass through the first configuration request.

[0039] The specific implementation process of the GATT server passing through the first configuration request includes: Step 1: The GATT server extracts the configuration data in JSON format from the first configuration request.

[0040] Specifically, after receiving the first configuration request, the GATT server performs CRC verification and access address matching on the request at the link layer. If the CRC verification and access address matching are successful, the PDU payload is parsed to obtain the opcode, request feature handle, and feature value, which are then passed to the ATT layer. The ATT layer reads the feature value based on the opcode (e.g., write request 0x01) and the request feature handle. After reading the feature value, the ATT layer extracts the configuration data in JSON format from it. Subsequently, the GATT server locates and reads the HTTP method, path, headers, and message body according to preset field mapping rules.

[0041] Step 2: The GATT server carries the HTTP method in the HTTP method field, the path in the request path field, the headers in the request header field, and the message body in the message body field, thereby obtaining the configuration data in the HTTP request format and obtaining the first configuration request after pass-through.

[0042] like Figure 6 As shown, the first configuration request after pass-through includes a request start line field, request header fields, and message body fields. The request start line field includes the HTTP method field, request path field, etc.

[0043] The GATT server will carry the extracted HTTP method in the HTTP method field of the HTTP request start line, and the request path in the request path field of the start line; it will organize the extracted request headers in the "Key:Value" format and carry them in the request header field; and it will carry the JSON format configuration data in the message body field.

[0044] S103: The GATT server sends the first configuration request after pass-through to the gateway server via HTTP.

[0045] S104: The gateway server sends the first configuration request after passing through to the configuration storage module for storage via the HTTP API interface.

[0046] S105: The gateway server sends the first configuration response to the GATT server.

[0047] The first configuration response is a response to the first configuration request. For example... Figure 7 As shown, the first configuration response uses an HTTP response format, including a response start line field, response header fields, and a message body field. The response start line field includes a status code field.

[0048] The first configuration response includes response data. The response data should include at least the following three implementation methods: Method 1: The response data includes an HTTP status code. The HTTP status code is a 3-digit numeric identifier in the HTTP response start line, used to notify the processing result / status of the first configuration request. HTTP status codes are divided into four main categories based on their first digit, for example: The HTTP status code can be 2xxx, which indicates a successful response to the first configuration request. The HTTP status code can be 3xxx, which indicates that the first configuration request needs to be further processed. The HTTP status code can be 4xxx, which indicates that the first configuration request failed due to a client-side issue. The HTTP status code can be 5xxx, which indicates that the first configuration request failed due to a server-side issue.

[0049] Method 2: The response data includes HTTP status codes and response information. An introduction to HTTP status codes can be found above and will not be repeated here. Response information can be used to indicate whether the response was successful or failed; for example, the response information could be "success" or "fail," etc.

[0050] Method 3: The response data includes the HTTP status code, response information, and data content. An explanation of HTTP status codes and response information can be found above and will not be repeated here. The first configuration response can also include data content, such as temperature data, humidity data, etc.

[0051] Here, the HTTP status code can be carried in the status code field of the response start line, and the response information and data content can be carried in the message body field.

[0052] S106: The GATT server will perform reverse pass-through of the first configuration response.

[0053] The GATT server will perform reverse pass-through of the first configuration response, specifically including the following steps: Step 1: The GATT server extracts the HTTP response data from the first configuration response.

[0054] The GATT server extracts HTTP response data from the first configuration response in at least the following ways: Method 1: When the response data includes an HTTP status code, the GATT server extracts the HTTP status code from the status code field of the response start line field of the first configuration response.

[0055] Method 2: When the response data includes an HTTP status code and response information, the GATT server extracts the HTTP status code from the status code field of the response start line field of the first configuration response and extracts the response information from the message body field of the first configuration response.

[0056] Method 3: When the response data includes HTTP status code, response information, and response data, the GATT server extracts the HTTP status code from the status code field of the response start line field of the first configuration response, and extracts the response information and data content from the message body field of the first configuration response.

[0057] Step 2: The GATT server carries the HTTP status code in a JSON-formatted data body to obtain the JSON-formatted response data.

[0058] The GATT server carries HTTP status codes in a JSON data body in at least the following ways: Method 1: When the response data includes an HTTP status code, the GATT server will carry the HTTP status code in a JSON format data body.

[0059] Method 2: When the response data includes HTTP status codes and response information, the GATT server will carry the HTTP status codes and response information in a JSON format data body.

[0060] Method 3: When the response data includes HTTP status codes, response information, and response data, the GATT server will carry the HTTP status codes, response information, and response data in a JSON format data body.

[0061] Step 3: The GATT server obtains the first configuration response after reverse pass-through based on the JSON format response data.

[0062] S107: The GATT server sends the first configuration response after reverse pass-through to the mobile terminal via Bluetooth.

[0063] See Figure 8 , Figure 8This is a flowchart illustrating a LoRa gateway configuration method provided in this application. Figure 8 As shown, the LoRa gateway configuration method of this application includes: S201: The mobile terminal sends a second configuration request to the HTTP server of the LoRa gateway via a wireless LAN, wired network, or mobile network.

[0064] The second configuration request includes second configuration information, which is used to configure the LoRa gateway.

[0065] In one specific embodiment, the second configuration information includes a request start line field, request header fields, and message body fields. The request start line field includes an HTTP method field, a request path field, and so on.

[0066] The HTTP method field is used to carry the HTTP method. The HTTP method indicates the operation mode for the configuration object. The configuration object can be one or more of the following: service set identifier, IP address, subnet mask, gateway address, DNS server address, transport protocol, operating frequency band, spreading parameters, antenna gain, receive gain, transmit power, number of channels, modulation mode, network authentication parameters, data processing rules, gateway identifier, gateway operating mode, restart policy, logging level, device name, device number, time zone / time synchronization, language / display configuration, etc. The operation mode can include one or more of the following: query data (GET), create data (POST), update data (PUT), partially update data (PATCH), delete data (DELETE), retrieve only response headers (HEAD), etc.

[0067] The request path field carries the path. This path indicates the location of the configuration object within the LoRa gateway. Different configuration objects have different locations within the LoRa gateway. For example, when the configured object is a service set identifier, the path could be / api / setconfig, etc.

[0068] The message body field is used to carry the message body. The message body indicates the configuration parameters of the configuration object. Different configuration objects have different configuration parameters. For example, when the configuration object is an IP address, the configuration parameter could be 192.168.1.100; when the configuration object is a subnet mask, the configuration parameter could be 255.255.255.0.

[0069] Request header fields are used to carry headers. These headers specify the data format or authentication. For example, headers may include: host, message body format and encoding, message body length in bytes, authentication information, etc.

[0070] It is understood that the above second configuration information is only a specific example, and in actual applications, more data may be included.

[0071] S202: The HTTP server sends the second configuration request to the gateway server via HTTP.

[0072] S203: The gateway server sends the second configuration request to the configuration storage module for storage.

[0073] S204: The configuration storage module sends a second configuration response to the gateway server.

[0074] The second configuration response is a response to the second configuration request. The second configuration response uses an HTTP response format, including a response start line field, response header fields, and a message body field. The response start line field includes a status code field.

[0075] The second configuration response includes response data. The response data should include at least the following three implementation methods: Method 1: The response data includes an HTTP status code. The HTTP status code is a 3-digit numeric identifier in the HTTP response start line, used to notify the user of the processing result / status of the second configuration request. HTTP status codes are divided into four main categories based on their first digit, for example: The HTTP status code can be 2xxx, which indicates a successful response to the second configuration request. The HTTP status code can be 3xxx, which indicates that the second configuration request needs to be further processed. The HTTP status code can be 4××, which indicates that the second configuration request failed due to a client-side issue. The HTTP status code can be 5xxx, which indicates that the second configuration request failed due to a server-side issue.

[0076] Method 2: The response data includes HTTP status codes and response information. An introduction to HTTP status codes can be found above and will not be repeated here. Response information can be used to indicate whether the response was successful or failed; for example, the response information could be "success" or "fail," etc.

[0077] Method 3: The response data includes the HTTP status code, response information, and data content. An explanation of HTTP status codes and response information can be found above and will not be repeated here. The second configuration response can also include data content, such as temperature data, humidity data, etc.

[0078] Here, the HTTP status code can be carried in the status code field of the response start line, and the response information and data content can be carried in the message body field.

[0079] S205: The gateway server sends the second configuration response to the HTTP server via HTTP.

[0080] S206: The HTTP server sends the second configuration response to the mobile terminal via a wireless LAN, wired network, or mobile network.

[0081] In the above scheme, the GATT server can pass through configuration requests received from Bluetooth. The passed-through configuration requests are in HTTP format, so they can be sent directly to the gateway server for processing. The HTTP server can also receive configuration requests from Wi-Fi, wired networks, and mobile networks, and send the received configuration requests directly to the gateway server. Therefore, the LoRa gateway can be compatible with Bluetooth, Wi-Fi, wired networks, and mobile networks simultaneously, flexibly adapting to the usage requirements of various scenarios. Furthermore, only one gateway server is needed to provide services for various scenarios such as Bluetooth, Wi-Fi, wired networks, and mobile networks, eliminating the need to develop separate gateway servers for Bluetooth, Wi-Fi, wired networks, and mobile networks, thus avoiding redundant development work and improving development efficiency.

[0082] See Figure 9 , Figure 9 This is a schematic diagram of the structure of a LoRa gateway provided in this application. Figure 9 As shown, the LoRa gateway of this application includes: The receiving module 210 is used to receive a first configuration request sent by a mobile terminal via Bluetooth, wherein the first configuration request includes first configuration information, the first configuration information is used to configure the LoRa gateway, and the first configuration information includes configuration data in JSON format. The pass-through module 220 is used to pass through the first configuration request, wherein the pass-through includes: converting the JSON format configuration data into HTTP request format configuration data; The first sending module 230 is used to send the first configuration request after transparent transmission to the gateway server via HTTP. The first configuration request after transparent transmission includes configuration data in HTTP request format. The second sending module 240 is used to send the first configuration request after transparent transmission to the configuration storage module for storage via an HTTP API interface.

[0083] For the sake of simplicity, no further details are provided here. Figure 9 The LoRa gateway shown is described in detail; please refer to [link / reference]. Figure 4 as well as Figure 8 The specific implementation process of the LoRa gateway configuration method shown.

[0084] See Figure 10 , Figure 10 This is a schematic diagram of the structure of an electronic device provided in this application. The electronic device in this embodiment includes: a bus 302, a processor 304, a memory 306, and a communication interface 308. The processor 304, the memory 306, and the communication interface 308 communicate with each other via the bus 302. It should be understood that this application does not limit the number of processors and memories in the electronic device.

[0085] Bus 302 can be a Peripheral Component Interconnect Express (PCIe) bus, an Extended Industry Standard Architecture (EISA) bus, a Unified Bus (Ubus or UB), a Compute Express Link (CXL) bus, a Cache Coherent Interconnect for Accelerators (CCIX) bus, etc. The Unified Bus is also known as the Lingqu Bus. Buses can be divided into address buses, data buses, control buses, etc. For ease of representation, Figure 10 The bus 302 may be represented by a single line, but this does not mean that there is only one bus or one type of bus. The bus 302 may include a path for transmitting information between various components of an electronic device (e.g., memory 306, processor 304, communication interface 308).

[0086] Processor 304 may include any one or more of the following computing devices: central processing unit (CPU), graphics processing unit (GPU), microprocessor (MP) or digital signal processor (DSP), ASIC, FPGA, CPLD, NPU, SoC, offload card, accelerator card, etc.

[0087] Memory 306 may include volatile memory, such as random access memory (RAM). Processor 304 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD). Furthermore, memory 306 may also be implemented using storage class memory (SCM), phase change memory (PCM), or other types of storage media.

[0088] It is worth noting that the same type of storage medium can be configured in the same computing device to realize the function of memory 306, or two or more types of storage media can be configured to realize the function of memory 306. This application does not limit this.

[0089] The memory 306 stores executable program code, which the processor 304 executes to implement the functions of the aforementioned receiving module 210, transparent transmission module 220, first transmitting module 230, and second transmitting module 240, thereby realizing the LoRa gateway configuration method. In other words, the memory 306 stores instructions for executing the LoRa gateway configuration method.

[0090] Alternatively, the memory 306 stores executable code, and the processor 304 executes the executable code to implement the respective functions. Figure 9 The LoRa gateway shown demonstrates its functionality, thereby implementing the LoRa gateway configuration method. Specifically, the memory 306 stores instructions for executing the LoRa gateway configuration method.

[0091] The communication interface 308 uses transceiver modules, such as, but not limited to, network interface cards and transceivers, to enable communication between electronic devices and other devices or communication networks.

[0092] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions, capable of running on an electronic device or stored on any usable medium. When the program product is run on at least one electronic device, it causes the at least one electronic device to perform... Figure 4 The LoRa gateway configuration method shown, or Figure 8 The LoRa gateway configuration method is shown below.

[0093] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium capable of being stored by a computing device or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct an electronic device to execute... Figure 4 The LoRa gateway configuration method shown, or instructions for electronic devices to perform... Figure 8 The LoRa gateway configuration method is shown below.

[0094] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions, which, when loaded and executed on a computer, generate all or part of the processes or functions described in the embodiments of the present invention. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one network site, computer, server, or data center to another network site, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access, or it can be a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape, etc.), an optical medium (e.g., DVD, etc.), or a semiconductor medium (e.g., solid-state drive), etc. 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.

Claims

1. A LoRa gateway configuration method, characterized in that, The LoRa gateway includes a GATT server, a gateway server, and a configuration storage module. The method includes: The GATT server receives a first configuration request sent by a mobile terminal via Bluetooth, wherein the first configuration request includes first configuration information, the first configuration information being used to configure the LoRa gateway, and the first configuration information including configuration data in JSON format. The GATT server will pass through the first configuration request, wherein the passing through includes: converting the JSON format configuration data into HTTP request format configuration data; The GATT server sends the first configuration request after passing through to the gateway server via HTTP. The first configuration request after passing through includes configuration data in the HTTP request format. The gateway server sends the first configuration request after pass-through to the configuration storage module for storage via an HTTP API interface.

2. The LoRa gateway configuration method according to claim 1, characterized in that, After the gateway server sends the first configuration request after transparent transmission to the configuration storage module for storage via an HTTP API interface, the method further includes: The gateway server sends a first configuration response to the GATT server, wherein the first configuration response includes response data in HTTP response format; The GATT server performs reverse pass-through on the first configuration response, wherein the reverse pass-through includes: converting the HTTP response data into JSON response data; The GATT server sends the first configuration response after reverse pass-through to the mobile terminal via Bluetooth, wherein the first configuration response after reverse pass-through includes the response data in JSON format.

3. The LoRa gateway configuration method according to claim 1 or 2, characterized in that, The LoRa gateway also includes an HTTP server. The HTTP server receives a second configuration request sent by the mobile terminal via a wireless local area network, a wired network, or a mobile network. The second configuration request includes second configuration information, which is used to configure the LoRa gateway. The HTTP server sends the second configuration request to the gateway server via HTTP; The gateway server sends the second configuration request to the configuration storage module for storage.

4. The LoRa gateway configuration method according to claim 3, characterized in that, After the gateway server sends the second configuration request to the configuration storage module for storage, the method further includes: The configuration storage module sends a second configuration response to the gateway server, wherein the second configuration response is used to indicate that the second configuration request has been processed. The gateway server sends the second configuration response to the HTTP server via HTTP; The HTTP server sends the second configuration response to the mobile terminal via a wireless LAN, a wired network, or a mobile network.

5. The LoRa gateway configuration method according to claim 1, characterized in that, The GATT server will transmit the first configuration request transparently, including: The GATT server extracts JSON-formatted configuration data from the first configuration request. The JSON-formatted configuration data is used to configure the configuration object. The JSON-formatted configuration data includes an HTTP method, a path, headers, and a message body. The HTTP method is used to indicate the operation method of the configuration object. The path is used to indicate the location of the configuration object in the LoRa gateway. The message body is used to indicate the configuration parameters of the configuration object. The headers are used to indicate the format of the configuration parameters. The GATT server carries the HTTP method in the HTTP method field, the path in the request path field, the header in the request header field, and the message body in the message body field, thereby obtaining the configuration data of the HTTP request format and obtaining the first configuration request after pass-through.

6. The LoRa gateway configuration method according to claim 2, characterized in that, The GATT server performs reverse pass-through of the first configuration response, including: The GATT server extracts response data in the HTTP response format from the first configuration response, wherein the response data in the HTTP response format includes an HTTP status code; The GATT server encapsulates the HTTP status code within a JSON-formatted data body to obtain the JSON-formatted response data. The GATT server obtains the first configuration response after the reverse pass-through based on the JSON format response data.

7. A LoRa gateway configuration device, characterized in that, include: A receiving module is configured to receive a first configuration request sent by a mobile terminal via Bluetooth, wherein the first configuration request includes first configuration information, the first configuration information is used to configure the LoRa gateway, and the first configuration information includes configuration data in JSON format. A pass-through module is used to pass through the first configuration request, wherein the pass-through includes: converting the JSON format configuration data into HTTP request format configuration data; The first sending module is used to send the first configuration request after passing through to the gateway server via HTTP. The first configuration request after passing through includes configuration data in HTTP request format. The second sending module is used to send the first configuration request after transparent transmission to the configuration storage module for storage via an HTTP API interface.

8. A LoRa gateway, characterized in that, include: A processor and a memory, wherein the processor is connected to the memory, the memory is used to store instructions, and the processor is used to read the instructions from the memory to perform the method as claimed in any one of claims 1-6.

9. A program product containing instructions, characterized in that, When the instruction is executed by the electronic device, the electronic device performs the method as described in any one of claims 1-6.

10. A readable storage medium, characterized in that, Includes program instructions, which, when executed by an electronic device, cause the electronic device to perform the method as described in any one of claims 1-6.