A method, system, device and medium for NB-IoT terminal state synchronization

Abstract

The present application relates to the technical field of Internet of Things communication, and particularly relates to an NB-IoT terminal state synchronization method, system, device and medium. The method comprises the following steps: receiving a batch query request issued by an Internet of Things platform in a broadcast mode, wherein the batch query request carries a hash check value of a target terminal identifier list and a query type identifier; performing consistency check on a locally maintained terminal identifier set according to the hash check value; after the check is passed, generating a compressed response frame according to the query type identifier and a pre-defined terminal identifier sorting rule, wherein the compressed response frame comprises a header, a bitmap area and a difference area, each bit in the bitmap area corresponds to the state of a target terminal, and the difference area stores the incremental encoding of numerical data relative to a reference value; and reporting the compressed response frame to the Internet of Things platform. Through a broadcast triggering mechanism, N times of point-to-point downlink paging is merged into a single broadcast, thereby solving the signaling storm problem in the concurrent query of a large number of terminals.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) communication technology, and in particular to an NB-IoT terminal status synchronization method, system, device, and medium. Background Technology

[0002] With the commercialization and widespread adoption of NB-IoT (Narrowband Internet of Things) technology, a massive number of low-power terminals (such as smart water meters and smart streetlights) have emerged in fields such as smart cities and public utilities, often reaching the scale of hundreds of thousands or even millions. IoT platforms face enormous signaling pressure and transmission efficiency bottlenecks when performing periodic full-scale status checks on these terminals (such as querying online / offline status and reading basic readings).

[0003] Currently, optimization of IoT data transmission efficiency mainly focuses on general data compression, edge computing architecture, and underlying algorithm optimization. The most similar technical solutions include: replacing keys in JSON messages with short codes using shared dictionaries (such as DSC / LPCE) or serialization tools like CBOR / Protobuf; using general compression libraries such as Huffman, LZW, and ZSTD for data compression; deploying deep learning models (such as CNN and Transformer) on edge computing nodes for data feature extraction and reconstruction; or performing data cleaning and aggregation at the edge; and optimizing access at the physical or link layer (such as non-orthogonal frequency hopping preamble design).

[0004] However, existing technologies still have significant shortcomings in addressing the specific need for full-scale status inspection of massive NB-IoT terminals. The main technical deficiencies are as follows: Firstly, the signaling storm caused by the interaction model: Existing general compression technologies and traditional CoAP / MQTT protocols are all based on a question-and-answer point-to-point interaction model. When facing the full status inspection of millions of NB-IoT terminals, the number of interaction rounds is proportional to the number of terminals, resulting in a multiplication of downlink paging signaling, which can easily cause network congestion and signaling storms.

[0005] Secondly, there is a mismatch between computing power and application scenarios: solutions based on deep learning or complex matrix operations have high computational overhead and are not suitable for NB-IoT terminals with extremely limited resources or lightweight business scenarios that only need to transmit Boolean states (0 / 1). Furthermore, they cannot solve the problem of format redundancy in application layer protocols.

[0006] Third, the message format has high redundancy: traditional JSON / XML text formats contain a lot of redundant key names. Even when using common compression algorithms (such as ZSTD and LZ4), the message header overhead is still too high when transmitting boolean states (such as online / offline), resulting in low payload utilization.

[0007] Fourth, there is a lack of consistency verification mechanism: existing batch processing solutions focus more on data transmission itself and lack a consistency verification mechanism for the dynamic changes of the identities (ID list) of a large number of terminal groups, which can easily lead to errors in the objects being checked or data distortion. Summary of the Invention

[0008] The technical problem to be solved by the present invention is to provide an NB-IoT terminal status synchronization method, system, device and medium to solve the technical problem of communication efficiency bottleneck in the context of massive low power wide area network (LPWAN) scenarios in the prior art.

[0009] The technical solution of the present invention to solve the above-mentioned technical problems is as follows: In a first aspect, the present invention provides an NB-IoT terminal state synchronization method, comprising: Receive batch query requests broadcast by the Internet of Things platform, wherein the batch query requests carry the hash check value of the target terminal identifier list and the query type identifier; Perform consistency checks on the locally maintained set of terminal identifiers based on the hash verification value; After the verification is passed, a compressed response frame is generated according to the query type identifier and the predefined terminal identifier sorting rules. The compressed response frame includes a header, a bitmap area and a difference area. Each bit in the bitmap area corresponds to the status of a target terminal. The difference area stores the incremental encoding of numerical data relative to the reference value. The compressed response frame is reported to the IoT platform.

[0010] Based on the above technical solution, the present invention can be further improved as follows.

[0011] Furthermore, the predefined terminal identifier sorting rule is to arrange them in ascending order according to the International Mobile Equipment Identity (IMEI) or according to the hash slots.

[0012] Furthermore, the method for generating the difference partition is as follows: Obtain the difference between the current numerical data and the baseline value issued by the IoT platform; The difference is encoded using variable-length integer encoding to obtain incremental encoding; The reference value is a reference value carried or pre-configured by the IoT platform in batch query requests.

[0013] Furthermore, the step of performing consistency verification on the locally maintained set of terminal identifiers based on the hash verification value includes: Calculate the hash value of the locally maintained set of terminal identifiers; The calculated hash value is compared with the hash verification value carried in the batch query request; If the comparison matches, the verification passes; if the comparison does not match, the response is rejected or a full synchronization of the terminal identifier set is triggered.

[0014] Furthermore, the header of the compressed response frame includes the lower 16 bits of the terminal identifier list hash value and a type identifier, which is used to distinguish between status queries and reading queries; The bitmap area at the junction is used to carry the online status of each target terminal; The differential partition is an optional region. When the query type is identified as a reading query, the differential partition stores the incremental codes of each target terminal in sequence according to a predefined terminal identifier sorting rule.

[0015] Furthermore, the step of reporting the compressed response frame to the IoT platform includes: When the data volume of the compressed response frame exceeds the threshold for a single transmission, the compressed response frame is reported to the IoT platform in blocks using a restricted application protocol block transmission mechanism.

[0016] Furthermore, applications on the IoT platform side include: Determine the list of target terminal identifiers to be queried, and sort the list of target terminal identifiers according to the predefined terminal identifier sorting rules; Calculate the hash checksum of the target terminal identifier list; Generate batch query requests carrying hash verification values ​​and query type identifiers, and broadcast the batch query requests to each target terminal; Receive compressed response frames returned by each target terminal; The state of each target terminal is analyzed based on the bitmap area, and the numerical data of each target terminal is analyzed based on the difference area.

[0017] To achieve the above objectives, a second aspect of the present invention provides an NB-IoT terminal status synchronization system, comprising: a platform-side subsystem and a terminal-side subsystem; The platform-side subsystem includes: The list sorting module is used to determine the list of target terminal identifiers to be queried, and sort the list of target terminal identifiers according to a predefined terminal identifier sorting rule; The hash calculation module is used to calculate the hash verification value of the sorted list of target terminal identifiers; The request generation module is used to generate batch query requests carrying hash check values ​​and query type identifiers; The CoAP proxy module broadcasts batch query requests to each target terminal; and receives compressed response frames returned by each target terminal. The response parsing module is used to parse the status of each target terminal based on the bitmap area and to parse the numerical data of each target terminal based on the difference partition. The terminal-side subsystem includes: The request receiving module is used to receive batch query requests sent by the IoT platform via broadcast. The consistency verification module is used to perform consistency verification on the locally maintained set of terminal identifiers based on the hash verification value carried in the batch query request. The compressed response generation module is used to generate a compressed response frame after the verification is passed, based on the query type identifier and the predefined terminal identifier sorting rules. The compressed response frame includes a header, a bitmap area and a difference area. Each bit in the bitmap area corresponds to the status of a target terminal. The difference area stores the incremental encoding of numerical data relative to the reference value. The reporting module is used to upload compressed response frames to the IoT platform.

[0018] Thirdly, the present invention provides an electronic device, comprising: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions, which, when executed by the processor, implement the steps of an NB-IoT terminal state synchronization method.

[0019] Fourthly, the present invention provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the NB-IoT terminal state synchronization method.

[0020] The advantages of this invention over the prior art are as follows: First, it achieves batch triggering with zero downlink signaling overhead: through the UDP broadcast triggering mechanism, N point-to-point downlink pagings are merged into a single broadcast, solving the signaling storm problem when a large number of terminals query concurrently. Secondly, an extremely compressed binary synchronization protocol is constructed: using a predefined ID bitmap and base value differential encoding method, the status query response message is compressed to O(1) space complexity, reducing air interface resource occupation and terminal power consumption; Third, ensure the consistency and integrity of massive amounts of data: introduce a verification mechanism based on the hash of the terminal ID list to ensure that the platform and the terminal have a consistent understanding of the queried group and prevent data synchronization errors caused by the addition or deletion of devices; Fourth, a lightweight architecture compatible with existing infrastructure: without relying on edge computing power or changing the base station core network, it achieves millisecond-level full state synchronization and high-concurrency processing capabilities solely through application layer protocol innovation. Attached Figure Description

[0021] Figure 1This is a flowchart illustrating a method for synchronizing the state of an NB-IoT terminal. Figure 2 A comparison diagram of the communication flow between a traditional method for NB-IoT terminal status synchronization and the present invention; Figure 3 This is a schematic diagram of the compressed response frame structure for an NB-IoT terminal state synchronization method. Figure 4 This is a schematic diagram of the electronic device of the present invention. Detailed Implementation

[0022] The technical solutions of the embodiments of the present invention will be described below with reference to the accompanying drawings. In the description of the present invention, unless otherwise stated, " / " indicates that the objects before and after are in an "or" relationship. For example, A / B can represent A or B. The "or" in the present invention is merely a description of the relationship between the related objects, indicating that three relationships can exist. For example, A or B can represent: A alone, A and B simultaneously, and B alone. A and B can be singular or plural. Furthermore, in the description of the present invention, unless otherwise stated, "multiple" refers to two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items.

[0023] Furthermore, to facilitate a clear description of the technical solutions of the embodiments of the present invention, the terms "first" and "second" are used in the embodiments of the present invention to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that the terms "first" and "second" are not necessarily different.

[0024] In this embodiment of the invention, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary" or "for example" in this embodiment of the invention should not be construed as superior or more advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner for ease of understanding.

[0025] Example 1, an embodiment of the present invention, provides an NB-IoT terminal state synchronization method. This method is executed on the terminal side. See [link to example]. Figure 1 , Figure 1The complete logical flow of batch query processing on the terminal side is described: The terminal first receives the query request issued by the platform and verifies whether the hash check value of the target terminal identifier list carried in it is consistent with the local pre-configuration; if they are inconsistent, the request is discarded; if they are consistent, different operations are performed according to the query type: if it is a status query, the local online flags are traversed to generate a bitmap; if it is a reading query, the current value is obtained and the increment is calculated with the baseline value to generate a difference partition; finally, the header, bitmap, and difference partition are concatenated into a compressed frame and reported through the CoAP protocol. This process ensures data consistency and efficient encoding. The specific steps are as follows: Step S101: Receive a batch query request broadcast from the IoT platform. The IoT platform leverages the NB-IoT network's support for downlink UDP (User Datagram Protocol) broadcasting in compliant frequency bands to send batch query requests in a single broadcast, rather than sending point-to-point query requests to each terminal individually. This batch query request carries a hash checksum of the target terminal identifier list and a query type identifier. The hash checksum is the hash value calculated from the target terminal identifier list using a hash algorithm (such as SHA-256), used for consistency verification on the terminal side. The query type identifier indicates the type of query; for example, 0x01 indicates a status query (querying online / offline), and 0x02 indicates a reading query (querying numerical data such as water consumption and voltage). Figure 2 As shown, by using a broadcast triggering mechanism, N point-to-point downlink pagings are merged into a single broadcast, and the downlink signaling overhead is independent of the number of target terminals, thus solving the signaling storm problem when a large number of terminals query concurrently.

[0026] In an optional embodiment, the hash algorithm used in the consistency verification is not limited to SHA-256, and can be replaced by MD5, CRC32, or the lightweight SM3 national cryptographic algorithm. Any fingerprint that can generate a unique identifier list for comparison falls within the scope of protection of the consistency verification of this invention.

[0027] In an optional embodiment, under a network policy that does not support UDP broadcasting, a CoAP Observe (subscription) mode can be used instead. The platform subscribes to the terminal state, and the terminal only actively reports when the state changes or a specific time window arrives. This scheme sacrifices the mandatory synchronization of broadcasting, but still solves the message redundancy problem through differential coding, and is an equivalent alternative solution to address the core pain point of this invention.

[0028] It should be noted that, Figure 2The left side illustrates the traditional NB-IoT batch status query method: the platform sequentially initiates CoAP GET requests to N terminals, each terminal returns an independent JSON response, requiring a total of N round-trip times (RTTs), resulting in high signaling overhead and long processing time. The right side illustrates the solution of this invention: the platform sends a batch query request containing hash checksums of a list of target terminal identifiers via UDP broadcast (or unicast). All target terminals listen and construct compressed responses (bitmaps, differential data) in parallel, returning them via the uplink, requiring only 1 RTT. The arrow colors in the diagram distinguish between downlink (red) and uplink (green), indicating the order-of-magnitude optimization in the number of interaction rounds achieved by this invention.

[0029] Step S102: Perform a consistency check on the locally maintained set of terminal identifiers based on the hash check value. After receiving a batch query request, the terminal extracts the hash check value and calculates the hash value of the locally maintained set of terminal identifiers, comparing the two. If they match, it means the queried group recognized by the terminal is consistent with the platform, and the check passes. If they don't match, it means the terminal identifier set on the terminal side is out of sync with the platform side (e.g., the addition or deletion of devices is not synchronized). In this case, the terminal refuses to respond or triggers a full synchronization of the terminal identifier set. This consistency check mechanism ensures the accuracy of broadcast synchronization, prevents data reporting errors caused by the lag in the terminal-side identifier list, and guarantees data consistency in large-scale systems.

[0030] Step S103: After successful verification, a compressed response frame is generated based on the query type identifier and a predefined terminal identifier sorting rule. The platform and the terminal pre-agree on a globally unique terminal identifier sorting rule, such as ascending order by terminal IMEI (International Mobile Equipment Identity) or by hash slot. During batch queries, the terminal determines its position in the bitmap according to this sorting rule. Figure 3As shown, the compressed response frame consists of three parts: a header, a bitmap area, and a difference partition. The header is 2 bytes long and contains the lower 16 bits of the hash value of the terminal identifier list (used for platform-side consistency verification) and a type identifier (0x01 = status, 0x02 = reading). In the bitmap area, each bit corresponds to the online status of a target terminal according to the predefined terminal identifier sorting rules (bit value 1 represents online, 0 represents offline), so that the status information of N target terminals only needs to occupy a compact space of ⌈N / 8⌉ bytes, realizing a state expression with O(1) space complexity. The difference partition is an optional area. When the query type is a reading query, the difference partition stores the incremental encoding of the numerical data of each target terminal relative to the baseline value in sequence according to the predefined terminal identifier sorting rules. For numerical data, the terminal obtains the difference between the current value and the baseline value issued by the IoT platform and encodes the difference using variable-length integer encoding (such as LEB128). In scenarios where the reading changes slowly, the difference is usually a small integer, which occupies only 1 to 2 bytes after encoding, much lower than the original 4 to 8 bytes of floating-point representation. By combining bitmap encoding and differential encoding, the status query response message is compressed to O(1) space complexity, which is more than 95% compared to the traditional JSON reporting message (each message is no less than 30 bytes).

[0031] It should be noted that, in an optional embodiment, in scenarios where terminal states are highly continuous (such as when all water meters in a building are online simultaneously), in order to further improve the compression rate, the bitmap area can use run-length encoding (RLE) to count and compress consecutive identical bits instead of the original bitmap.

[0032] It should be noted that, in an optional embodiment, in environments requiring cross-platform compatibility and self-describing advantages, such as multi-vendor deployments, the compressed response frame may also encapsulate the bitmap and differential data using the standard CBOR (Concise Binary Object Representation) or MessagePack binary format.

[0033] Step S104: The compressed response frame is reported to the IoT platform. The terminal sends the generated compressed response frame to the IoT platform via the uplink. When the data volume of the compressed response frame exceeds the single transmission threshold, the CoAP (Constrained Application Protocol) Block-wise Transfer mechanism is used to report the compressed response frame in blocks, ensuring compatibility with the existing protocol stack. Each target terminal responds concurrently after receiving the broadcast, and the uplink uses a random access method to avoid collisions.

[0034] The technical advantages of this embodiment are as follows: Through the UDP broadcast triggering mechanism, N point-to-point downlink pagings are merged into a single broadcast, achieving batch triggering with zero downlink signaling overhead; through bitmap encoding, the states of N terminals are compressed into a compact bitmap of N / 8 rounded-up bytes, achieving state expression with O(1) space complexity; through base value differential and variable-length integer encoding, numerical data is compressed to 1 to 2 bytes; through a hash verification mechanism, the platform and terminals ensure consistent understanding of the queried group. Taking 100,000 terminals as an example, the traditional method requires sending 100,000 CoAP GET requests, with a total traffic of approximately 2.3GB and a time consumption exceeding 4 hours; using the method of this invention, the online status of 100,000 terminals only requires a 12.5KB bitmap, and the water consumption increment averages 2 bytes per terminal, or 200KB, with a total traffic of approximately 212.5KB, a compression rate exceeding 90%, and synchronization can be completed within 10 minutes.

[0035] It should be noted that, in the actual deployment test of the present invention in the Fuzhou smart water meter project, it supported the daily inspection of 300,000 smart water meters and 35,000 smart streetlights, reduced message volume by 72%, reduced platform CPU load by 45%, and shortened query completion time from 4 hours to 8 minutes, effectively solving the signaling congestion problem during the concentrated reporting in the early morning.

[0036] Example 2, as Figure 2 As shown, this embodiment provides an NB-IoT terminal state synchronization method. This method is executed on the IoT platform side and is used in conjunction with the terminal-side method in Embodiment 1. The method includes the following steps: Step S201: Determine the list of target terminal identifiers to be queried, and sort the list of target terminal identifiers according to a predefined terminal identifier sorting rule. The IoT platform determines the scope of target terminals for this inspection based on business needs, and sorts the list of target terminal identifiers according to a pre-agreed sorting rule with the terminal side (such as sorting by IMEI in ascending order or hash slots) to ensure that the mapping relationship between each bit in the bitmap and the terminal is consistent between the platform and the terminal.

[0037] Step S202: Calculate the hash verification value of the target terminal identifier list. The platform uses a hash algorithm (such as SHA-256) to calculate the hash verification value of the sorted target terminal identifier list. This hash verification value will be sent to the terminal as part of the batch query request, and is used by the terminal to verify the consistency between the local terminal identifier set and the target terminal identifier list on the platform side.

[0038] Step S203: Generate a batch query request carrying a hash checksum and query type identifier, and broadcast the batch query request to each target terminal. The platform encapsulates the batch query request into a standard CoAP over UDP message through the CoAP proxy module and sends it to the NB-IoT base station via the core network. The base station then broadcasts the query request to the target terminal group via the air interface. For queries of numerical data, the platform also carries a baseline value (such as yesterday's reading) in the batch query request, or pre-configures the baseline value to each target terminal. This baseline value is used by the terminal to calculate the difference between the current value and the baseline value to achieve differential encoding.

[0039] Step S204: Receive compressed response frames returned by each target terminal, parse the status of each target terminal according to the bitmap area, and parse the numerical data of each target terminal according to the difference partition. After receiving the compressed response frames returned by each terminal, the platform first verifies whether the lower 16 bits of the hash value in the header are consistent with the locally calculated value to ensure the reliability of the data source. Then, according to the predefined terminal identifier sorting rules, each bit in the bitmap area is mapped to the corresponding target terminal, with a bit value of 1 indicating online and a bit value of 0 indicating offline. For the difference partition, the incremental encoding is read sequentially according to the predefined terminal identifier sorting rules, decoded, and algebraically added to the corresponding base value to restore the numerical data of each target terminal without loss. The platform returns the decompressed and restored structured data to the synchronization system to complete full status synchronization.

[0040] The technical advantages of this embodiment are as follows: the platform can trigger concurrent responses from all target terminals with a single broadcast, eliminating the need for individual paging and resulting in zero downlink signaling overhead; by parsing bitmap areas and difference partitions, the status and numerical data of massive terminals can be efficiently restored, significantly reducing platform CPU load and drastically shortening query completion time. In the actual verification of the Fuzhou smart water meter project, it supports daily inspections of 300,000 smart water meters and 35,000 smart streetlights, reducing message volume by 72%, platform CPU load by 45%, and query completion time from 4 hours to 8 minutes.

[0041] Example 3 provides an NB-IoT terminal status synchronization system. When deployed in a real network, this system requires no modification to the base station or core network; only the addition of a CoAP proxy on the platform side and SDK support on the terminal side is needed, offering high compatibility and ease of deployment. The system includes a platform-side subsystem and a terminal-side subsystem, with the following specific structure: The platform-side subsystem, as a business system, is responsible for generating, issuing, and restoring query commands, including: The list sorting module is used to determine the list of target terminal identifiers to be queried, and sort the list of target terminal identifiers according to a predefined terminal identifier sorting rule (such as ascending order by IMEI) to ensure the consistency of the bit mapping relationship between the platform and the terminal. The hash calculation module, connected to the list sorting module, is used to calculate the hash verification value of the sorted target terminal identifier list, which serves as the verification benchmark for preventing lag on the terminal side. The request generation module, connected to the hash calculation module, is used to generate batch query requests carrying the hash verification value and query type identifier (such as status query or reading query); The CoAP proxy module, connected to the request generation module, acts as a gateway for the platform's interaction with the NB-IoT network. It receives batch query requests from the request generation module via its internal interface, encapsulates them into standard CoAP over UDP messages, and sends them to the NB-IoT base station via the core network. The base station then broadcasts these messages to the target terminal group over the air interface. Simultaneously, this module also receives compressed response frames transmitted back from the terminals via the base station. The response parsing module, connected to the CoAP proxy module, is used to decompress and restore the compressed response frames received by the CoAP proxy module. It parses the online status of each target terminal based on the bitmap area in the compressed response frame, parses the numerical data of each target terminal based on the difference partitions and pre-stored baseline values, and returns the restored structured data to the IoT platform business system.

[0042] The terminal-side subsystem is embedded in each NB-IoT terminal (supported in the form of an SDK) and is responsible for command reception, verification, and compressed encoding reporting, including: The request receiving module is used to receive batch query requests sent by the NB-IoT base station via air interface broadcast, and extract the hash verification value and query type identifier carried in them; The consistency verification module, connected to the request receiving module, is used to perform consistency verification on the locally maintained set of terminal identifiers based on the hash verification value carried in the batch query request. If the verification is inconsistent, it indicates that the terminal-side identifier list is lagging, and the response is rejected or a full synchronization is triggered. The compressed response generation module, connected to the consistency verification module, is used to generate a compressed response frame after the verification passes, based on the query type identifier and the predefined terminal identifier sorting rules. The compressed response frame includes a header, a bitmap area, and a difference partition. Each bit in the bitmap area corresponds to the status of a target terminal (1 represents online, 0 represents offline). The difference partition stores the incremental encoding of numerical data relative to the baseline value issued by the platform (such as using LEB128 encoding). The reporting module, connected to the compressed response generation module, is used to transmit the generated compressed response frames back to the CoAP agent module of the IoT platform via the base station, thereby completing the concurrent and efficient synchronization of the status.

[0043] In this embodiment, the system ensures the accuracy of issued instructions through list sorting and hash generation on the platform side, and ensures the simplicity and error prevention of response data through consistency verification and bitmap / differential compression mechanism on the terminal side. Combined with the protocol encapsulation and transparent transmission of CoAP proxy, it achieves efficient synchronization of the status of massive terminals without modifying the existing base station and core network.

[0044] Example 4: In some embodiments, the NB-IoT terminal state synchronization system of the present invention can be implemented using a combination of hardware and software. As an example, the NB-IoT terminal state synchronization system of the present invention can be a processor in the form of a hardware decoding processor, which is programmed to execute the NB-IoT terminal state synchronization method of the present invention. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0045] The modules described in the embodiments of this invention can be implemented in software or hardware. The names of the modules are not, in some cases, limiting the scope of the module itself.

[0046] An electronic device according to an embodiment of the present invention includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements any of the above-mentioned NB-IoT terminal state synchronization methods. That is, an electronic device according to an embodiment of the present invention may include, but is not limited to: a processor and a memory; the memory is used to store the computer program; the processor is used to execute an NB-IoT terminal state synchronization method shown in any embodiment of the present invention by calling the computer program.

[0047] In one alternative embodiment, an electronic device is provided, such as Figure 4 As shown, Figure 4The illustrated electronic device 4000 includes a processor 4001 and a memory 4003. The processor 4001 and the memory 4003 are connected, for example, via a bus 4002. Optionally, the electronic device 4000 may further include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 4004 is not limited to one type, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of the present invention.

[0048] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this invention. Processor 4001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0049] Bus 4002 may include a path for transmitting information between the aforementioned components. Bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 4002 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 4 The bus 4002 is represented by only one thick line, but this does not mean that there is only one bus or one type of bus.

[0050] The memory 4003 may be ROM (Read Only Memory) or other types of static storage devices capable of storing static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices capable of storing information and instructions, or EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto.

[0051] The memory 4003 stores application code (computer program) for executing the present invention, and its execution is controlled by the processor 4001. The processor 4001 executes the application code stored in the memory 4003 to implement the content shown in the foregoing method embodiments.

[0052] Among them, electronic devices can also be terminal devices, which can be any device that can install applications, including at least one of smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, smart TVs, and smart in-vehicle devices.

[0053] It should be noted that, Figure 4 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0054] An embodiment of the present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-described NB-IoT terminal state synchronization methods.

[0055] Alternatively, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, a floppy disk, and an optical data storage device, etc.

[0056] In an exemplary embodiment, a computer program product or computer program is also provided, which includes computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the aforementioned NB-IoT terminal state synchronization method.

[0057] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0058] It should be understood that the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of methods and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0059] The computer-readable storage medium provided in this invention can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EEPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0060] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the method shown in the above embodiments.

[0061] The above description is merely a preferred embodiment of the present invention and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this invention is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this invention.

[0062] It should be noted that the terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and represent a limitation on a specific order or sequence. Where appropriate, the order of use for similar objects can be interchanged so that the embodiments of this application described herein can be implemented in an order other than that shown or described.

[0063] Those skilled in the art will recognize that this invention can be implemented as a system, method, or computer program product. Therefore, this invention can be specifically implemented in the following forms: it can be entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software, generally referred to herein as a "circuit," "module," or "system." Furthermore, in some embodiments, this invention can also be implemented as a computer program product contained in one or more computer-readable media, which includes computer-readable program code.

[0064] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A method for synchronizing the state of an NB-IoT terminal, characterized in that, include: Receive batch query requests broadcast by the Internet of Things platform, wherein the batch query requests carry the hash check value of the target terminal identifier list and the query type identifier; Perform consistency checks on the locally maintained set of terminal identifiers based on the hash verification value; After the verification is passed, a compressed response frame is generated according to the query type identifier and the predefined terminal identifier sorting rules. The compressed response frame includes a header, a bitmap area and a difference area. Each bit in the bitmap area corresponds to the status of a target terminal. The difference area stores the incremental encoding of numerical data relative to the reference value. The compressed response frame is reported to the IoT platform.

2. The NB-IoT terminal state synchronization method according to claim 1, characterized in that, The predefined terminal identifier sorting rule is to arrange them in ascending order according to the International Mobile Equipment Identity (IMEI) or according to the hash slot.

3. The NB-IoT terminal state synchronization method according to claim 1, characterized in that, The method for generating the difference partition is as follows: Obtain the difference between the current numerical data and the baseline value issued by the IoT platform; The difference is encoded using variable-length integer encoding to obtain incremental encoding; The reference value is a reference value carried or pre-configured by the IoT platform in batch query requests.

4. The NB-IoT terminal state synchronization method according to claim 1, characterized in that, The consistency check of the locally maintained set of terminal identifiers based on the hash check value includes: Calculate the hash value of the locally maintained set of terminal identifiers; The calculated hash value is compared with the hash verification value carried in the batch query request; If the comparison matches, the verification passes; if the comparison does not match, the response is rejected or a full synchronization of the terminal identifier set is triggered.

5. The NB-IoT terminal state synchronization method according to claim 1, characterized in that, The header of the compressed response frame includes the lower 16 bits of the terminal identifier list hash value and a type identifier, which is used to distinguish between status queries and reading queries; The bitmap area at the junction is used to carry the online status of each target terminal; The differential partition is an optional region. When the query type is identified as a reading query, the differential partition stores the incremental codes of each target terminal in sequence according to a predefined terminal identifier sorting rule.

6. The NB-IoT terminal state synchronization method according to claim 1, characterized in that, The step of reporting the compressed response frame to the Internet of Things platform includes: When the data volume of the compressed response frame exceeds the threshold for a single transmission, the compressed response frame is reported to the IoT platform in blocks using a restricted application protocol block transmission mechanism.

7. The NB-IoT terminal state synchronization method according to claim 1, applied to the IoT platform side, characterized in that, include: Determine the list of target terminal identifiers to be queried, and sort the list of target terminal identifiers according to the predefined terminal identifier sorting rules; Calculate the hash checksum of the target terminal identifier list; Generate batch query requests carrying hash verification values ​​and query type identifiers, and broadcast the batch query requests to each target terminal; Receive compressed response frames returned by each target terminal; The state of each target terminal is analyzed based on the bitmap area, and the numerical data of each target terminal is analyzed based on the difference area.

8. An NB-IoT terminal status synchronization system, applied to the method according to any one of claims 1-7, characterized in that, include: Platform-side subsystem and terminal-side subsystem; The platform-side subsystem includes: The list sorting module is used to determine the list of target terminal identifiers to be queried, and sort the list of target terminal identifiers according to a predefined terminal identifier sorting rule; The hash calculation module is used to calculate the hash verification value of the sorted list of target terminal identifiers; The request generation module is used to generate batch query requests carrying hash check values ​​and query type identifiers; The CoAP proxy module broadcasts batch query requests to each target terminal; and receives compressed response frames returned by each target terminal. The response parsing module is used to parse the status of each target terminal based on the bitmap area and to parse the numerical data of each target terminal based on the difference partition. The terminal-side subsystem includes: The request receiving module is used to receive batch query requests sent by the IoT platform via broadcast. The consistency verification module is used to perform consistency verification on the locally maintained set of terminal identifiers based on the hash verification value carried in the batch query request. The compressed response generation module is used to generate a compressed response frame after the verification is passed, based on the query type identifier and the predefined terminal identifier sorting rules. The compressed response frame includes a header, a bitmap area and a difference area. Each bit in the bitmap area corresponds to the status of a target terminal. The difference area stores the incremental encoding of numerical data relative to the reference value. The reporting module is used to upload compressed response frames to the IoT platform.

9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images