A method, medium and terminal for accessing a downlink device by an iot table a type extension module

Abstract

The application is suitable for the technical field of Internet of Things electric energy meter, and relates to a method, medium and terminal for connecting type A expansion module of Internet of Things meter to downlink equipment, which comprises the following steps: a downlink function unit establishes a communication link with a downlink expansion device; the downlink function unit informs an Internet of Things meter management module that the downlink expansion device has been connected; the Internet of Things meter management module and the downlink function unit perform handshake authentication; the Internet of Things meter management module and the downlink function unit perform data interaction, including routing forwarding and security encryption and decryption processing of uplink communication messages and downlink communication messages according to a preset routing strategy and a security encryption and decryption strategy; and the downlink function unit periodically sends a heartbeat command to the Internet of Things meter management module to maintain the connection state of the downlink expansion device. The application has the ability to connect the type A module of the Internet of Things meter to the wireless communication or carrier communication of the downlink equipment, improves the power supply capacity of the downlink expansion device, reduces the wiring trouble of field installation, and greatly improves the networking capacity of the downlink equipment of the Internet of Things meter.

Description

Technical Field

[0001] This invention belongs to the field of IoT energy meter technology, and particularly relates to a method, medium and terminal for connecting an IoT meter Type A expansion module to a downlink device. Background Technology

[0002] State Grid IoT energy meters, also known as multi-core module energy meters, are characterized by their ability to connect multiple expansion modules based on the IR46 dual-core design. Type A expansion modules focus on communication (carrier, 4G, etc.), while Type B expansion modules support non-intrusive load identification, photovoltaic four-way functionality, and other scenario-based functions. Due to structural and hardware limitations, the interfaces for expansion modules are restricted. Currently, single-phase IoT meters can connect to a maximum of two expansion modules, and three-phase IoT meters can connect to a maximum of three. For example, if a customer connects a load identification module and a power quality module to a single-phase IoT meter, they will not find additional hardware interfaces to connect another expansion module. Furthermore, due to limitations in downlink transmission distance and difficulties in network cabling, coupled with the fact that Type B expansion modules generally cannot achieve wireless communication, current IoT solutions only implement the uplink communication function of Type A expansion modules, failing to enable downlink device access for Type A expansion modules.

[0003] Patent CN112616119B discloses a Bluetooth uplink communication method for electricity meters, relating to the field of wireless communication for electricity meters. It involves embedding a Bluetooth module in a Type II concentrator and using this module for uplink communication from the electricity meter to the data acquisition master station. During communication, a Bluetooth version comparison is performed, and the lower version is used for compatibility. Furthermore, a multiple retransmission mode is employed during the data exchange phase. However, this patent only implements uplink communication from the electricity meter to the data acquisition master station and does not describe the technical solutions for how downlink devices can access the system, thus exhibiting the same drawbacks as existing technologies.

[0004] Therefore, how to provide a method for connecting IoT meter type A extension modules to downlink devices to improve the networking capabilities of IoT downlink devices is a problem that urgently needs to be solved by those in this technical field. Summary of the Invention

[0005] To address the shortcomings of existing technologies, the purpose of this invention is to provide a method for IoT meter type A extension module to access downlink devices, thereby solving the problem that in existing technologies, type A extension modules only achieve uplink communication and fail to achieve downlink device access, resulting in poor networking capabilities of IoT meter downlink devices; in addition, this invention also provides a medium and terminal for IoT meter type A extension module to access downlink devices.

[0006] To solve the above-mentioned technical problems, the present invention adopts the following technical solution:

[0007] In a first aspect, the present invention provides a method for an IoT meter Type A extension module to access a downlink device, wherein the Type A extension module includes an uplink communication unit, a routing unit, and a downlink functional unit, and the method includes the following steps:

[0008] S10. The downlink functional unit establishes a communication link with the downlink extension device;

[0009] S20. The downlink functional unit notifies the IoT table management module that the downlink extension device has been connected;

[0010] S30. The IoT table management module and the downlink functional unit perform handshake authentication.

[0011] S40. The IoT table management module interacts with the downlink functional unit, including routing and forwarding uplink and downlink communication messages and performing security encryption and decryption processing according to preset routing and security encryption / decryption strategies.

[0012] S50. The downlink functional unit periodically sends heartbeat commands to the IoT table management module to maintain the connection status of the downlink extension device.

[0013] Furthermore, in step S40, the Type A extension module determines whether the received message should be forwarded to the uplink channel or to the downlink functional unit for processing, based on the control field and client address in the DL / T698.45 protocol.

[0014] Furthermore, the routing strategy of the Type A extension module includes:

[0015] When the transmission direction bit DIR=1 and the start flag bit PRM=0, it is determined that the report was initiated by the server and the message is forwarded to the uplink channel.

[0016] When the transmission direction bit DIR=1 and the start flag bit PRM=1, further judgment is made based on the client address: if the client address is in the range of 30H-7FH, the message is forwarded to the downlink channel; otherwise, the message is forwarded to the uplink channel.

[0017] In other cases, the message will be forwarded to the downlink channel.

[0018] Furthermore, the IoT table management module distinguishes between uplink security services and downlink security services based on the client address, logical address, and service type, and processes them using different encryption and decryption algorithms respectively.

[0019] Furthermore, the routing and security encryption / decryption strategies of the IoT table management module include:

[0020] Upon receiving a security request, if the client address is within the range of 30H-7FH, then perform downlink channel security decryption; otherwise, perform uplink channel security decryption.

[0021] When receiving insecure response data, if the client address is in the range of 30H-7FH, it is encrypted and then forwarded to the downlink functional unit; if the client address is 13H, it is processed within the IoT table.

[0022] If the client address is another address, it will be encrypted and then forwarded to the uplink communication unit.

[0023] Furthermore, when the Type A extension module is detected to be unplugged or an offline notification is received from the downlink extension device, the IoT table management module will remove the downlink extension device from the extension module list and report the change information to the terminal or main station.

[0024] Furthermore, in S10, the communication method includes one or more of carrier communication, RS485 communication, wireless communication, and serial communication.

[0025] Furthermore, in S20, the communication protocol is DL / T698.45, and the OMD (Object Method Descriptor) is 4031FE00, which notifies the IoT table management module of the access, heartbeat, or offline status of the downlink extension device.

[0026] In a second aspect, the present invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described above.

[0027] Thirdly, the present invention also provides an electronic terminal, comprising: a processor and a memory; the memory is used to store a computer program, and the processor is used to execute the computer program stored in the memory to cause the terminal to perform the method described above.

[0028] Compared with existing technologies, the method, medium, and terminal for connecting the IoT meter Type A extension module to the downlink device provided by this invention have at least the following advantages:

[0029] In existing technologies, Type A expansion modules only implement uplink communication and fail to enable downlink device access, resulting in poor downlink device networking capabilities for IoT meters. This invention, without altering the hardware structure of the IoT meter, adds a routing unit to the Type A expansion module, enabling interactive routing management for both uplink and downlink communication. This transforms the Type A expansion module from a simple communication module into a multi-functional module capable of both uplink communication and data collection, as well as downlink expansion applications. This expands the functionality of single-phase IoT meters from two expansion modules to three, and three-phase IoT meters from three to four, increasing the application scenarios for IoT meters. Furthermore, the Type A expansion module in this invention is larger and has a stronger power supply than the original Type B expansion module, allowing for more convenient design and functional selection. It also enables larger-volume, lower-power wireless or HPLC downlink communication, reducing downlink cabling and networking difficulties, and expanding communication... The improved communication distance significantly reduces the difficulty of on-site construction. This invention modifies the IoT meter internally (the Type A extension module is also part of the IoT meter as a whole), without involving modifications to the uplink terminal and main station. The downlink extension access function of the Type A extension module belongs to the Type B extension function and is still managed by the IoT meter, maintaining consistent interaction and security policies, and offering good compatibility with terminals and the main station. This invention extends the IoT meter's downlink extension module access capability by one channel. On the Type A extension module, wired, wireless, or carrier transmission can be selected based on the specific network configuration of the downlink devices, improving the convenience of downlink extension device network access. It is also compatible with current centralized procurement schemes for IoT meters by the main station and terminals, facilitating the application and promotion of IoT meter extension functions and greatly improving the networking capability of IoT meter downlink devices. Attached Figure Description

[0030] To more clearly illustrate the solution of the present invention, a brief introduction will be given to the drawings used in the description of the embodiments below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0031] Figure 1 A flowchart illustrating a method for connecting an IoT meter type A extension module to a downlink device, as provided in an embodiment of the present invention;

[0032] Figure 2 This is a schematic diagram of the network topology for connecting a Type A extension module of an IoT table to a downlink extension device, provided in an embodiment of the present invention.

[0033] Figure 3 This is a schematic diagram illustrating the process of connecting an IoT meter type A extension module to an IoT meter in a method for connecting an IoT meter type A extension module to a downlink device, as provided in an embodiment of the present invention.

[0034] Figure 4 This is a block diagram of the IoT table structure in a method for connecting an IoT table type A extension module to a downlink device, provided in an embodiment of the present invention. Detailed Implementation

[0035] To facilitate understanding of the present invention, a more complete description will be given below with reference to the accompanying drawings. Preferred embodiments of the invention are shown in the drawings. However, the invention can be implemented in many different forms and is not limited to the embodiments described herein. Rather, these embodiments are provided to provide a thorough and complete understanding of the disclosure of the invention.

[0036] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein in the description of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention.

[0037] This invention provides a method for an IoT meter Type A extension module to access a downlink device. This method is applied to the process of providing secure access authentication for the downlink slave device of the IoT meter Type A extension module. The Type A extension module includes an uplink communication unit, a routing unit, and a downlink functional unit. The method for the IoT meter Type A extension module to access the downlink device includes the following steps:

[0038] S10. The downlink functional unit establishes a communication link with the downlink extension device; S20. The downlink functional unit notifies the IoT table management module that the downlink extension device has been connected; S30. The IoT table management module and the downlink functional unit perform handshake authentication; S40. The IoT table management module and the downlink functional unit interact with data, including routing and forwarding uplink and downlink communication messages and performing security encryption and decryption processing according to preset routing and security encryption / decryption policies; S50. The downlink functional unit periodically sends heartbeat commands to the IoT table management module to maintain the connection status of the downlink extension device.

[0039] This invention improves the power supply capability of downlink extension devices, provides downlink devices with wireless or carrier communication capabilities, reduces wiring hassles during on-site installation, and greatly enhances the networking capability of IoT meter downlink devices.

[0040] To enable those skilled in the art to better understand the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings.

[0041] This invention provides a method for connecting a Type A extension module of an IoT meter to a downlink device. It is applied to the secure access authentication process of the downlink slave device in a Type A extension module of an IoT energy meter. By adding a secure access and interaction extension downlink module to the traditional Type A carrier uplink module, the Type A extension module of the smart IoT meter becomes a composite module capable of both uplink communication and data collection, as well as downlink extension functions. Figures 1 to 4 In this embodiment, the Type A extension module includes an uplink communication unit, a routing unit, and a downlink functional unit. The method includes the following steps:

[0042] S10. The downlink functional unit establishes a communication link with the downlink extension equipment.

[0043] Specifically, in this embodiment, the communication methods include carrier communication, RS485 communication, wireless communication and serial communication. The establishment of the communication link is determined by the specific application scenario requirements. For example, after the Type A expansion module and the downlink expansion device can communicate through protocol interaction, the existence of the downlink expansion device and the successful networking can be confirmed.

[0044] S20: The downlink functional unit notifies the IoT meter management module that the downlink extension device has been connected. The communication protocol is DL / T698.45, and the OMD is 4031FE00. It also notifies the IoT meter management module of the access, heartbeat, or offline status of the downlink extension device.

[0045] Specifically, in this embodiment, the Type A extension module is internally divided into an uplink communication unit, a routing unit, and a downlink functional unit. The uplink communication unit functions identically to the original Type A extension module's uplink communication function, responsible for receiving and forwarding uplink messages. The downlink functional unit is responsible for establishing the link with the downlink extension device, implementing specific downlink functions, and handling the handshake and security authentication process with the management module, as well as secure encryption and decryption of communication messages. Specific functional implementations include, but are not limited to, DL / T698.45 protocol and downlink extension device protocol conversion (the downlink protocol may not be a State Grid standard protocol, such as Modbus or other protocols), periodic data reading, and some AI algorithm control processing strategies. The routing unit implements message identification and routing strategy forwarding between the uplink communication unit and the downlink functional unit. Based on step S10, after confirming the downlink extension device's access, the downlink functional unit notifies the IoT table management module that the downlink extension device is connected (the communication protocol is DL / T698.45, the OMD is 4031FE00, see Table 1 below, and the status is "connected").

[0046] Table 1

[0047]

[0048] S30, the IoT meter management module and the downlink functional unit perform handshake authentication.

[0049] Specifically, in this embodiment, the IoT meter management module receives the access notification from the Type A extension module and initiates a handshake process with the Type A extension module (the handshake process is the standard process for IoT meter extension modules, mainly obtaining the logical address, device type, encryption serial number, etc. of the extension module through the 40310200 protocol), and obtains the logical address of the downlink functional unit of the Type A extension module; after the handshake is completed, the management module reports the Type A extension module change event and performs security authentication with the Type A extension module according to the module category (the module category determines whether security authentication is required, or whether to use a soft algorithm / ESAM hard encryption algorithm for security authentication). The security authentication process is the same as the original extension module identity authentication process. The difference is that the IoT meter management module forwards the corresponding extension logical address message to the serial port of the Type A extension module based on the downlink extension logical address obtained from the handshake.

[0050] S40, the IoT table management module interacts with the downlink functional unit, including routing and forwarding uplink and downlink communication messages and performing security encryption and decryption processing according to preset routing and security encryption / decryption strategies.

[0051] Specifically, in this embodiment, the uplink communication process is the interaction process between the main station or terminal and the IoT meter through uplink channels such as carrier wave or 4G communication. According to the electricity meter interaction process, it includes services such as application connection, reading, setting, and method operation. Simultaneously, there are security services requiring encryption and decryption operations. This is forwarded through the Type A extension module. The downlink communication process is the interaction process between the IoT meter and the downlink extension device of the Type A extension module. The service content and protocols are the same as the uplink communication. The difference lies in the interaction between the IoT meter and the downlink extension device (or downlink functional unit) connected to the Type A extension module. A single operation (e.g., recalling data) by the main station or terminal to the downlink extension device includes both the uplink and downlink communication processes. In this embodiment, the Type A extension module combines uplink communication and downlink extension module functions into one. The downlink extension device connected to the Type A extension module of the IoT meter can be completely considered as a newly added Type B extension module for the main station and terminal. The operation process of the Type B extension module by the main station and terminal is exactly the same, thus ensuring compatibility with existing main station terminal centralized meter reading management schemes. Since the interaction between the Type A extension module and the IoT table management module uses a serial communication port for both uplink and downlink, the serial communication messages between the Type A extension module and the IoT table management module need to identify the destination device for the next interaction and forwarding. This is especially important because uplink and downlink security services are based on the unified DL / T698.45 protocol: Security Request and Security Reply services. Therefore, utilizing existing fields in DL / T698.45, a unified routing interaction mechanism and strategy are defined to ensure correct destination identification, correct forwarding, and proper security encryption / decryption processing during the serial communication between the IoT table management module and the Type A extension module.

[0052] In this embodiment, firstly, the object-oriented protocol defines client roles, especially in the DL / T698.45 protocol, which further clarifies the role definitions of each client, as shown in Table 2:

[0053] Table 2

[0054]

[0055] Based on the definition of the client address, it can be assumed that the client address of the energy meter slave device is in the range of 30H-7FH. Therefore, in this embodiment, it is clearly stated that the client address initiated by all slave devices (extension modules) is strictly between 30H-7FH.

[0056] In addition, DL / T698.45 defines the control field C of the protocol as one byte, used bit by bit or in combination, as defined in Table 3 below:

[0057] Table 3

[0058]

[0059] Transmission direction bit and start flag bit definition:

[0060] Transmission direction bit: bit7=0 indicates that this frame was sent by the client; bit7=1 indicates that this frame was sent by the server.

[0061] Startup flag: bit6=0 indicates that this frame was initiated by the server; bit6=1 indicates that this frame was initiated by the client.

[0062] Furthermore, in this embodiment, the routing strategy for the Type A extended module includes:

[0063] In the Type A extended module routing unit, without modifying the DL / 698.45 protocol, a routing policy based on the control domain and client address was formulated, as shown in Table 4 below:

[0064] Table 4

[0065]

[0066] As shown in Table 4, the Type A extension module has two forwarding scenarios where it needs to forward received energy meter messages to the uplink channel; in other scenarios, the messages are forwarded to the downlink functional unit for processing. When the downlink functional unit receives a security message, it performs encryption and decryption using the security method agreed upon between the downlink extension module and the IoT meter. When the uplink communication unit receives a security message, it follows the same strategy as before: it does not perform any processing and directly forwards it to the IoT meter for encryption and decryption.

[0067] Furthermore, in this implementation, the routing strategy of the IoT table management module includes:

[0068] The messages received by the IoT meter management module at the serial port of the Type A extension module may be either uplink or downlink communication messages, and both directions of communication messages have services such as request, response, reporting, and encryption / decryption. Furthermore, the IoT meter management module adopts an operating system multi-process (APP) design, with each process responsible for different services; currently, the State Grid IoT meter defines APPs such as system APP, security APP, meter APP, and extension APP; the interaction between processes uses pure APDU exchange, without link layer related information (such as no control domain information), and the client address, logical address, service type, etc., are defined in the interaction structure, as shown in the example below:

[0069] typedef struct

[0070] {

[0071] uint8_t LogicAddr; / * Logical address: * /

[0072] uint8_t NeedNext; / * Flag indicating whether there are subsequent frames, application layer framing flag * /

[0073] uint8_t ServiceType; / * Service type * /

[0074] uint8_t AddrType; / * Address type: single address, broadcast address, group address, etc. * /

[0075] uint8_t PortNum; / * Source port or destination port, encryption and decryption operations can be performed based on the port number * /

[0076] uint8_t CryptType; / * Encryption type: such as plaintext + MAC, ciphertext, etc. * /

[0077] uint8_t ClientAddr; / * Client address (source) * /

[0078] uint8_t Rerse1; / *Reserved* /

[0079] uint16_t LenData; / *APDU length: The actual length of the transmitted APDU * /

[0080] uint16_t MaxLen; / * Maximum APDU BUF size for message routing allocation, default 2K * /

[0081] uint32_t AppPid; / * The PID of the target app * /

[0082] uint8_t ApduData[]; / * APDU data * /

[0083] }ST_APP_OBJECT;

[0084] In response, this embodiment defines routing and security encryption / decryption strategies for the IoT table management module's APP protocol forwarding module:

[0085] This embodiment distinguishes between uplink services (including security services) and downlink services (including security services) by using client address, logical address, and service type. It summarizes all security services and communication application scenarios of the IoT table. To illustrate the business processing logic, it is summarized in the following table (Table 5):

[0086] Table 5

[0087]

[0088] Based on Table 5 above, the secure app routing strategy and secure decryption strategy can be obtained as follows:

[0089] 1) Upon receiving a security request (Security_request), further determine whether it is uplink or downlink security decryption based on the client address. If the client is 30H-7FH, it is considered to be encrypted data sent by the carrier downlink function unit and downlink security decryption is performed. For other clients, it is considered to be uplink security request data and uplink security decryption is performed.

[0090] 2) Upon receiving a security response (Security_response), the client address is 00H, and it is a plaintext + MAC service. Further, based on the plaintext content, it can be determined whether it is a security response to be reported (in the DL / T698.45 protocol, the security response reported by the electricity meter is currently fixed as plaintext + MAC). If it is not a security response to be reported, it is considered to be an encrypted response message sent by the downlink function module of the carrier, and downlink channel security response decryption processing is performed.

[0091] 3) Upon receiving insecure response data (Get_respons, Action_response, Set_response, Connect_response, etc.), process it according to the client address. If it is 30H-7FH, encrypt it and forward it to the carrier downlink function unit. If it is 13H, it indicates that the request was initiated by the IoT table (security APP) itself, and the response from the downlink function unit is processed internally by the IoT table. If it is another client address (such as 0ZH, AZH), encrypt it and forward it to the carrier uplink communication unit.

[0092] 4) Upon receiving an unencrypted reporting request, if it is 0ZH, the request will be encrypted and then forwarded to the carrier uplink communication unit. If it is an APP client address (e.g., 10H), it will be directly forwarded to the corresponding business APP for processing.

[0093] 5) For ordinary unencrypted requests (Get_request, Set_request, Action_request, etc.) not listed in the table, they can be forwarded directly based on the logical address.

[0094] Upon receiving a security service message, the system determines whether it is an uplink or downlink security service based on the above strategy. Different encryption / decryption (algorithm) methods are then used for encryption / decryption to obtain the plaintext before further routing and forwarding decisions are made. The routing and security processing of the IoT table management module are handled within the system APP and security APP within the IoT table management module itself, without involving modifications to other business APPs. This ensures good business compatibility, and the overall table business logic does not require modification.

[0095] S50: The downlink functional unit periodically sends heartbeat commands to the IoT table management module to maintain the connection status of the downlink extended devices.

[0096] Specifically, in this embodiment, if the downlink extension device goes offline or communication fails for an extended period (heartbeat cycle), the IoT table management module is notified, and the downlink extension device exits (OMD: 4031FE00, status is exited). When the management module detects that the Type A extension module has been unplugged or receives a 4031 module disconnection notification, it removes the downlink extension device module from the extension module list and reports it to the terminal or master station for device file management. After the downlink extension device goes offline, the Type A extension module can still function as an uplink communication module to communicate with the uplink terminal or master station, without affecting the normal data collection function.

[0097] This invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method of this embodiment.

[0098] This invention also provides an electronic terminal, including: a processor and a memory; the memory is used to store a computer program, and the processor is used to execute the computer program stored in the memory, so that the terminal performs the method of this embodiment.

[0099] As will be understood by those skilled in the art, the computer-readable storage medium described in this embodiment allows for the implementation of all or part of the steps in the above method embodiments by computer program-related hardware. The aforementioned computer program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0100] The electronic terminal provided in this embodiment includes a processor, a memory, a transceiver, and a communication interface. The memory and the communication interface are connected to the processor and the transceiver and complete communication between them. The memory is used to store computer programs, the communication interface is used to perform communication, and the processor and the transceiver are used to run the computer programs, so that the electronic terminal performs the steps of the above method.

[0101] Compared with existing technologies, the method, medium, and terminal for connecting the IoT meter's Type A expansion module to downlink devices described in the above embodiments have the problem that existing technologies only implement uplink communication and fail to enable downlink device access, resulting in poor networking capabilities of IoT meters' downlink devices. This invention, without changing the hardware structure of the IoT meter, adds a routing unit to the Type A expansion module to achieve communication interaction and routing management between uplink and downlink. This transforms the Type A expansion module from a simple communication module into a composite functional module capable of both uplink communication and data collection, and downlink expansion applications. This expands single-phase IoT meters from two expansion modules to three, and three-phase IoT meters from three to four, increasing the application scenarios for IoT meters. Furthermore, the Type A expansion module in this invention is larger and has a greater power capacity than the original Type B expansion module, allowing for more convenient design and stronger functional selection. It can also achieve larger-volume and lower-power wireless or HPLC downlink communication, reducing downlink cabling and networking difficulties, and expanding communication capabilities. The distance significantly reduces the difficulty of on-site construction. This invention modifies the IoT meter internally (the Type A extension module is also part of the IoT meter as a whole), without involving modifications to the uplink terminal and the main station. The downlink extension access function of the Type A extension module belongs to the Type B extension function and is still managed by the IoT meter, with consistent interaction and security policies, and good compatibility with terminals and the main station. This invention extends the IoT meter's downlink extension module access capability by one channel. On the Type A extension module, wired transmission, wireless transmission, or carrier transmission can be selected according to the specific networking situation of the downlink extension device, improving the convenience of downlink extension device networking access. At the same time, it is compatible with the current centralized procurement scheme of IoT meters for the main station and terminals, which helps to promote the application of IoT meter extension functions and greatly improves the networking capability of IoT meter downlink devices.

[0102] Obviously, the embodiments described above are merely preferred embodiments of the present invention, and not all embodiments. The accompanying drawings illustrate preferred embodiments of the present invention, but do not limit the scope of the patent. The present invention can be implemented in many different forms; rather, these embodiments are provided to provide a more thorough and complete understanding of the disclosure of the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing specific embodiments, or make equivalent substitutions for some of the technical features. Any equivalent structures made using the content of this specification and drawings, directly or indirectly applied to other related technical fields, are similarly within the scope of patent protection of this invention.

Claims

1. A method for connecting an IoT meter Type A expansion module to a downlink device, characterized in that, The Type A module includes an uplink communication unit, a routing unit, and a downlink functional unit. The method includes the following steps: S10. The downlink functional unit establishes a communication link with the downlink extension device; S20. The downlink functional unit notifies the IoT table management module that the downlink extension device has been connected; S30. The IoT table management module and the downlink functional unit perform handshake authentication. S40. The IoT table management module interacts with the downlink functional unit, including routing and forwarding uplink and downlink communication messages and performing security encryption and decryption processing according to preset routing and security encryption / decryption strategies. The routing strategy for the Type A module includes: When the transmission direction bit DIR=1 and the start flag bit PRM=0, it is determined that the report was initiated by the server and the message is forwarded to the uplink channel. When the transmission direction bit DIR=1 and the start flag bit PRM=1, further judgment is made based on the client address: if the client address is in the range of 30H-7FH, the message is forwarded to the downlink channel; otherwise, the message is forwarded to the uplink channel. In other cases, the message will be forwarded to the downlink channel; The routing and security encryption / decryption strategies of the IoT table management module include: Upon receiving a security request, if the client address is within the range of 30H-7FH, then perform downlink channel security decryption; otherwise, perform uplink channel security decryption. Upon receiving a security response, if the client address is 00H, the uplink channel reporting response is decrypted; otherwise, the downlink channel security response is decrypted. When receiving insecure response data, if the client address is in the range of 30H-7FH, it is encrypted and then forwarded to the downlink functional unit; if the client address is 13H, it is processed within the IoT table. If the client address is another address, it will be encrypted and then forwarded to the uplink communication unit; S50. The downlink functional unit periodically sends heartbeat commands to the IoT table management module to maintain the connection status of the downlink extension device.

2. The method for connecting an IoT meter type A expansion module to a downlink device according to claim 1, characterized in that, In step S40, the type A module determines whether to forward the received message to the uplink channel or to the downlink functional unit for processing based on the control field and client address in the DL / T698.45 protocol.

3. The method for connecting an IoT meter type A expansion module to a downlink device according to claim 2, characterized in that, The IoT table management module distinguishes between uplink security services and downlink security services based on the client address, logical address, and service type, and processes them using different encryption and decryption algorithms respectively.

4. The method for connecting an IoT meter type A expansion module to a downlink device according to claim 1, characterized in that, When the A-type module is detected to be unplugged or an offline notification is received from the downlink extension device, the IoT table management module will remove the downlink extension device from the extension module list and report the change information to the terminal or main station.

5. The method for connecting an IoT meter type A expansion module to a downlink device according to claim 1, characterized in that, In S10, the communication method includes one or more of carrier communication, RS485 communication, wireless communication and serial communication.

6. The method for connecting an IoT meter type A expansion module to a downlink device according to claim 1, characterized in that, In step S20, the communication protocol is DL / T698.45, and the OMD is 4031FE00, which notifies the IoT meter management module of the access, heartbeat, or offline status of the downlink extension device.

7. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 6.

8. An electronic terminal, characterized in that, include: Processor and memory; The memory is used to store a computer program, and the processor is used to execute the computer program stored in the memory to cause the terminal to perform the method as described in any one of claims 1 to 6.

Images