A method and system for intelligent registration of IoT devices based on semantic IoT middleware

Abstract

This invention discloses an intelligent registration method for IoT devices based on semantic IoT middleware. It utilizes the rich device semantics within device protocol banner information, employing a combination of corpus and rule-based methods to identify device triple entities. Web crawling technology is used to collect device information from online device review and retail websites. Based on the device ontology, a unified format of device information is extracted and stored in a device ontology database. The device ontology database is searched using triples as search criteria, and complete device information is matched and stored in a device information database, completing automatic registration. If no entity is identified in the banner information, device information is actively collected using device manuals submitted by device manufacturers. Rule-based methods are used to extract device information based on the device ontology structure, which is stored in both the device ontology database and the device information database, completing intelligent registration.

Description

Technical Field

[0001] This invention relates to the fields of device application protocol banner information entity recognition, semantic IoT middleware, and intelligent registration of IoT devices, specifically to an intelligent registration method and system for IoT devices based on semantic IoT middleware. Background Technology

[0002] With the increasing integration of the Internet of Things (IoT) into various sectors, the number of IoT devices is growing rapidly. The heterogeneity of these underlying devices presents a significant challenge to interoperability in the IoT today. To mitigate this heterogeneity, numerous standards for device access, protocols, frameworks, abstractions, and specifications have been proposed. Building upon this, a crucial prerequisite for devices to enter the IoT and communicate and function normally is their registration in a unified manner. Therefore, providing a consistent solution is essential for supporting the seamless registration of heterogeneous IoT devices. Furthermore, the physical information of the devices themselves provides upper-layer users with reasonable suggestions for arranging the deployment environment. For example, the ambient temperature for deploying devices can be adjusted based on their operating temperature range, providing temperature thresholds for normal device operation. Therefore, providing the device's own information during registration is also necessary. Currently, most registration methods involving physical device information rely on developers manually inputting the information they are interested in. With a large number of devices, this method is inefficient and has a high error rate. Summary of the Invention

[0003] The purpose of this invention is to address the problems of heterogeneous information in IoT devices, coarse-grained registration of device information, and the need for extensive manual input in existing device registration technologies. This invention proposes a smart IoT device registration method based on semantic IoT middleware. This method consists of two parts: First, identifying device triplet entities from the banner information of the device application protocol as search conditions to match complete device information based on ontology and complete registration. Second, actively collecting device information by utilizing device manufacturers' user-submitted device manuals to form ontology-based device information and complete registration. The results of this invention demonstrate that both methods can effectively achieve smart registration of complete device information.

[0004] The specific technical solution for achieving the objective of this invention is as follows:

[0005] A method for intelligent registration of IoT devices based on semantic IoT middleware includes the following specific steps:

[0006] Step 1: Using the data acquisition module, obtain the device's application protocol content and parse it into a unified text format to form the device's banner information. This includes the following specific methods:

[0007] (1) After the device joins the network, it continuously sends information to the server using a protocol. A passive listening technique is employed to capture and analyze the binary data sent by the device without affecting the normal operation of the current router or gateway. Unlike traditional passive listening, the passive listening module f1 does not need to capture the complete TCP connection or perform specific protocol parsing. A small amount of binary data is randomly acquired, and the device's IP address is obtained based on the length of the IP address and the fixed offset between the destination and source IP addresses. Based on the relationship between binary protocol data and IP addresses, the mapping formula is defined as follows:

[0008] f1(b i ) = IP i

[0009] IP i b represents the IP address of the i-th device. i This indicates the retrieved binary data;

[0010] (2) The active protocol detection module f2 obtains the protocol banner based on the IP address obtained by the passive listening module f1. A half-open connection is used to detect the device's active ports. If the device port is open, an ACK+SYN is returned to initiate a half-open connection; otherwise, an RST+SYN is returned to terminate the TCP connection. The mapping formula is defined as follows:

[0011] f2(IP i ) = Port i

[0012] Port i This represents the list of active ports for the i-th device, and its IP address. i This represents the IP address of the i-th device;

[0013] (3) After the active detection module f2 provides the device's live port, the protocol parsing module f3 constructs a payload for the live port and obtains the response information of the live port, i.e., the protocol banner information. Based on the obtained banner information, the protocol is parsed. Since different protocols have different banner information formats, a protocol parsing template is used to convert the protocol banner information into a unified string format for subsequent operations. The mapping relationship between the protocol and the banner information is as follows:

[0014] f3(Port ij )=b ij

[0015]

[0016] Where b ijB represents the banner information for the j-th protocol of the i-th device. i Represents the banner information for the i-th device, Port i This represents the list of live ports for the i-th device.

[0017] Step 2: Convert the banner information of the device protocol into a banner word list through the banner information preprocessing module, specifically including the following steps:

[0018] (1) Convert the original banner information into a list of individual words and process it using the rules and corpus file proposed in this invention;

[0019] (2) Propose information rules unrelated to device information, such as new deactivation rules and time regular expressions, and use these rules to remove protocol-irrelevant words, thereby reducing the misidentification rate of model numbers. The rules are shown in Table 1:

[0020] Table 1. New Disabling Rules and Time Regular Expressions

[0021]

[0022]

[0023] (3) For industrial protocols such as S7, Modbus, and Ethernet / IP, a not_banner anti-ambiguity model file is created, and the fields involved in the file are deleted when collecting the original banner information; For long protocols such as HTTP and HTTPS, the banner information is too long, and the equipment-related information is concentrated in the title field or body field, so keywords are used to filter the information.

[0024] (4) Create a device_tag corpus file. The initial corpus file only contains device-related words. Since the device-related words in the banner information are complex in form but similar in content, the Wikipedia corpus and NLTK tool are used to generate synonyms for device-related words to form the final device_tag corpus file;

[0025] (5) Use words or phrases in the device_tag file as keywords to extract key fields from protocol information. Retain the content of the line containing the keyword and the following line to form the key field. If content exists, extract it. If the key field is still too long, use the proposed key field reduction rules to shorten it. Specifically, the key field reduction rules state that the key field must contain at most three "<>" characters, meaning that at most the content of the line preceding, following, and next to the keyword in standard HTML must be retained. The rules are shown in Table 2.

[0026] Table 2 Key Field Reduction Rules

[0027]

[0028] (6) The processed corpus is segmented and part-of-speech tagged using NLTK. Finally, stop words are removed. Based on the existing English stop word list, stop words that fit this experiment are added, including punctuation marks, protocol flag fields, and service information.

[0029] Step 3: Using the device entity recognition module, identify words representing the brand, type, and model from the banner's word list, including the following specific methods:

[0030] (1) Based on a search of online device sales and evaluation websites, we collected IoT device brands and device types from across the internet. The device types were categorized into three levels: major categories, intermediate categories, and minor categories, with the minor categories further subdivided. Class in type Major categories. Device brands and types are stored in the corpus. If a new device brand or type is added, the corresponding corpus list will be updated. The brand and type list in the corpus is easy to expand and maintain.

[0031] (2) First, the brand and type corpus list is segmented into words. The segmented list is then used to perform BIO tagging of the banner word list related to brands and types. First, the first-level rules are used to initially filter model-related words. The second-level rules process pure letter words, pure number words, and words containing " / " or "_" within the model names. Finally, the third-level rules determine the final...<brand,type,model> Triplet.

[0032] (3) The first layer of rules consists of two parts: First, the first layer of initial rules is proposed to label the model, where the equipment model consists of the following three forms:

[0033] 1) Pure numbers;

[0034] 2) Combinations of numbers and letters;

[0035] 3) Combinations of numbers, letters, and "-", where numbers and letters are present simultaneously;

[0036] The initial rules for the first layer are shown in Table 3:

[0037] Table 3 Initial Rules for the First Layer

[0038]

[0039] In the first-level initial rules, in addition to the three forms mentioned above, strings containing " / " were added. Secondly, a not_tag file was created based on the first-level initial rules. String ambiguity was eliminated by deleting strings that conformed to the model number rule "number? + keyword + number?", where the keyword included HTML tags, encoding types involved in the protocol, and element attribute words in the protocol. The first-level initial model number rules processed by the not_tag corpus were defined as the first-level rules.

[0040] (4) Based on the first layer of rules, establish a second layer of rules to handle the following three cases:

[0041] 1) For cases involving pure numbers that meet the first-level rules, at most M1 words were searched before finding the label "brand" or "model". The rule for handling this case is defined as model extraction rule 1.

[0042] 2) For cases that do not conform to the first-level rules but consist of several pure English strings, the characters currently marked as "model" are searched forward by up to M2 characters. If a word marked as brand is found, the English characters in the middle are marked as model. The rule for handling this case is defined as model extraction rule 2.

[0043] 3) For cases involving XX / YY or XX_YY, where XX must conform to the first-level rule or represent "Series", the rule for handling this case is defined as model extraction rule 3.

[0044] (5) After processing with the second-level rules, the complete model number can be determined relatively accurately. However, a large number of strings that do not belong to the model number are misidentified as model numbers. Therefore, words labeled as brand, type, and model number will form an exponential number of triples, which is detrimental to the next step of the ontology search. Thus, a third-level rule is established. This third-level rule reduces the misidentification rate of model numbers by increasing the connection between brand, type, and model number. The third rule includes the following specific situations:

[0045] 1) Model number determination: The model number is the word closest to the brand name and the distance between them is less than the fixed value M3;

[0046] 2) Type Determination: Words marked as "type" are used as candidate device models, and device type priorities are set, defining network communication devices as having a lower priority than ordinary devices. Since devices like ordinary temperature sensors do not have built-in network capabilities and must rely on intermediate devices (such as smart gateways) to connect to the network, this allows for the identification of devices at lower levels below these intermediate devices. Furthermore, under different type classifications, the priority is defined as: Major Type < Sub-type < Minor Type. If two or more types are identified in the banner information and belong to different levels of device types, only the highest priority device type is retained as the final device type.

[0047] Step 4: The device information ontology structure and device attribute information structure are proposed through the device information ontology generation module, and fine-grained device information of the device to be identified is generated and stored in the device information database. This includes the following specific methods:

[0048] (1) Propose a device information ontology structure and a device attribute information structure that conform to the present invention;

[0049] The ontology contains 8 entity classes, among which the Thing class is the common parent class of all entity classes defined in OWL. The following is a detailed description of the other 7 entity classes:

[0050] 1) Device: Indicates the IoT device to be identified in this invention;

[0051] 2) Basic_logo: Represents the triplet identifier of the IoT device.<brand,type,model> ;

[0052] 3) Basic_Parameter: Represents the basic hardware configuration parameters of the IoT device;

[0053] 4) Function_Features: Represents the functional parameters of an IoT device when it is working normally;

[0054] 5) Work_Envionment: Represents the environmental parameters for the normal operation of IoT devices;

[0055] 6) Exterior: Indicates the appearance parameters of the IoT device;

[0056] 7) Data: Represents the working data generated by IoT devices, which can be constructed using O&M and SensorML modeling languages.

[0057] The relationships between entity classes are shown in Table 4:

[0058] Table 4 Explanation of Relationships Between Entity Classes

[0059] Basic_logo Device is_logo The three-element unique identifier for IoT devices Device Basic_logo has_logo IoT devices are uniquely identified by the triplet. Device Basic_Parameter hasBasic_parameters IoT devices have hardware configuration parameters Device Function_Features hasFunction_features IoT devices have functional parameters Device Work_Envionment hasWork_envionment IoT devices have environmental parameters Device Exterior hasExterior Appearance of IoT devices Device Data hasData IoT devices generate data Data Device isData Data is from IoT devices

[0060] (2) Use web crawlers to crawl device information from various online sales platforms and device evaluation platforms and filter out non-IoT devices;

[0061] (3) Based on the device information attribute rules, capture the relevant attribute information of the device and store it in the database. Convert the database data into ontology files according to the device information ontology and store them in the ontology repository.

[0062] Step 5: If the device entity triple can uniquely identify an IoT device, then call the automatic registration module to register the device entity triple.<brand,type,model> As a search condition, the proposed registration rules are used to search for information in the ontology repository, and the information in the ontology repository is matched to complete the device information, thereby generating an ontology file of the device information to be identified.

[0063] The registration rules are shown in Table 5:

[0064] Table 5 Registration Rules Explanation

[0065]

[0066] Step 6: If the device entity triple cannot uniquely identify an IoT device, then the device vendor registration module is invoked to actively collect device information, including the following specific methods:

[0067] (1) The middleware actively sends a request to the equipment vendor user to register equipment information. The equipment vendor provides the equipment information file, and the format of the information file is not limited.

[0068] (2) Extract file information based on the device information attributes, form the device ontology file according to the device information ontology structure, and add it to the ontology repository and device information database respectively to complete the device information registration when the banner information is missing or the complete triplet cannot be identified, so as to ensure the integrity of the device information and complete the active collection of device information.

[0069] Step 7: The upper-layer user interface layer provides a unified API for upper-layer users using Python scripts, enabling transparent access to the device information database using Sparql. This upper-layer user interface layer grants query permissions to ordinary users and CRUD (Create, Read, Update, Delete) permissions to developers, thereby facilitating the maintenance and expansion of the device information database.

[0070] Based on the above methods, this invention also proposes an intelligent registration system for IoT devices based on semantic IoT middleware, comprising three parts: data acquisition, intelligent registration, and an upper-layer interface layer. The data acquisition includes an active detection module, a passive listening module, and a protocol parsing module. The intelligent registration utilizes the device protocol banner information parsed from the protocol, and through a banner information preprocessing module, a device entity recognition module, and a device information ontology generation module, converts the banner information into a device ontology file, which is then stored in a device information database to achieve automatic registration of device information. If the entity information in the banner information cannot uniquely identify a device, the system interacts with the device manufacturer to actively collect device information and extracts device information from the device manual to implement the device manufacturer registration module. The upper-layer interface layer provides a transparent device access interface for ordinary users.

[0071] The data acquisition, intelligent registration, and upper interface layer form a vertical structure from bottom to top.

[0072] The beneficial effects of this invention are as follows:

[0073] The present invention proposes an intelligent registration method for IoT devices based on semantic IoT middleware to shield heterogeneous device information, register fine-grained information describing the device itself, reduce the cost of manual registration of device information, and achieve plug-and-play functionality for devices.

[0074] This invention offers a novel approach to intelligent registration of IoT devices, focusing on fine-grained device description information and reducing the cost and error rate of manual input. Simultaneously, by leveraging the consistency of semantic ontology, it masks the heterogeneity of IoT devices, ensuring compatibility with different manufacturers and device types. A unified interface is provided to upper-level users, enabling transparent access while guaranteeing privacy. This achieves intelligent registration of IoT devices that is easily accessible to upper-level users.

[0075] This invention addresses the heterogeneity of device information by leveraging semantic IoT middleware. It analyzes how to acquire and convert device information into a unified format for registration, and how to enable transparent access by allowing users to shield the detailed underlying device structure. Simultaneously, this invention proposes an intelligent registration method that combines automatic registration with proactive collection of device information based on device vendor user registration. This ensures the availability and fine-grained nature of device information, improving upon the current situation where fine-grained device information can only be manually entered. Furthermore, this invention proposes a method for retrieving device information from device banner information.<brand,type,model> This invention provides a method for identifying triplet entities. This method is scalable and has high accuracy. Therefore, it can be considered a general intelligent registration method for IoT devices, possessing strong practicality. Attached Figure Description

[0076] Figure 1 This is a structural diagram of a semantic Internet of Things middleware;

[0077] Figure 2 This is a schematic diagram of the workflow framework for the data acquisition module;

[0078] Figure 3 A schematic diagram of the framework for preprocessing banner information;

[0079] Figure 4 This is a schematic diagram of a device entity recognition framework based on banner information;

[0080] Figure 5 A schematic diagram of the module framework for generating device information ontology;

[0081] Figure 6 This is a schematic diagram of the device information body structure;

[0082] Figure 7 This is a schematic diagram of device information attributes;

[0083] Figure 8 This is a schematic diagram of the intelligent device registration framework, which includes an automatic registration module and a device vendor registration module.

[0084] Figure 9 A schematic diagram illustrating the possible values ​​of the long / short protocol boundary N;

[0085] Figure 10 A schematic diagram showing the values ​​of distance parameters M1, M2, and M3;

[0086] Figure 11 This is a schematic diagram of part of the device information body file;

[0087] Figure 12 This is a diagram illustrating the matching results of devices based on registration rules. Detailed Implementation

[0088] The invention will be further described in detail below with reference to the specific embodiments and accompanying drawings. Except for the contents specifically mentioned below, the processes, conditions, and experimental methods for implementing the invention are all common knowledge and general knowledge in the art, and the invention does not have any particular limitations.

[0089] This invention discloses an intelligent registration method for IoT devices based on semantic IoT middleware. Utilizing the rich device semantics within the banner information of device application protocols, a method combining semantic databases and rules is employed to identify device triple entities. Web crawling technology is used to collect device information from online device review and retail websites. Based on the proposed device ontology, a unified form of device information is extracted and stored in a device ontology database. The device ontology database is searched using triples as search criteria, and complete device information is matched and stored in a device information database, completing automatic registration. If no entity is identified in the banner information, device information based on the device ontology structure is extracted using device manuals submitted by device vendors, and stored in both the device ontology database and the device information database to complete intelligent registration. This intelligent registration method, relying on semantic middleware, provides users with a unified access interface, shields the heterogeneity of underlying devices, and enables plug-and-play functionality.

[0090] The present invention will now be described in detail with reference to the accompanying drawings.

[0091] This invention relates to a method for intelligent registration of IoT devices based on semantic middleware. It relies on semantic IoT middleware, the structure of which is shown in the attached figure. Figure 1 As shown. The present invention includes the following specific steps:

[0092] Step 1: Using the attached Figure 2 The data acquisition module shown detects the application protocol content of the device and parses it into a unified text format to form the device's banner information, including the following specific methods:

[0093] (1) After the device joins the network, it continuously sends information to the server using a protocol. A passive listening technique is employed to capture and analyze the binary data sent by the device without affecting the normal operation of the current router or gateway. Unlike traditional passive listening, the passive listening module f1 does not need to capture the complete TCP connection or perform specific protocol parsing. A small amount of binary data is randomly acquired, and the device's IP address is obtained based on the length of the IP address and the fixed offset between the destination and source IP addresses. Based on the relationship between binary protocol data and IP addresses, the mapping formula is defined as follows:

[0094] f1(b i ) = IP i

[0095] IP i b represents the IP address of the i-th device. i This indicates the retrieved binary data;

[0096] (2) The active protocol detection module f2 obtains the protocol banner based on the IP address obtained by the passive listening module f1. A half-open connection is used to detect the device's active ports. If the device port is open, an ACK+SYN is returned to initiate a half-open connection; otherwise, an RST+SYN is returned to terminate the TCP connection. The mapping formula is defined as follows:

[0097] f2(IP i ) = Port i

[0098] Port i This represents the list of active ports for the i-th device, and its IP address. i This represents the IP address of the i-th device;

[0099] (3) After the active detection module f2 provides the device's live port, the protocol parsing module f3 constructs a payload for the live port and obtains the response information of the live port, i.e., the protocol banner information. Based on the obtained banner information, the protocol is parsed. Since different protocols have different banner information formats, a protocol parsing template is used to convert the protocol banner information into a unified string format for subsequent operations. The mapping relationship between the protocol and the banner information is as follows:

[0100] f3(Port ij )=b ij

[0101]

[0102] Where b ij B represents the banner information for the j-th protocol of the i-th device. i Port representing the banner information of the i-th device i This represents the list of live ports for the i-th device.

[0103] Step 2: Attach the banner information of the device. Figure 3 The banner information preprocessing module shown converts the banner information into a list of banner words, specifically including the following steps:

[0104] (1) Convert the original banner information into a list of individual words and process it using the rules and corpus file proposed in this invention;

[0105] (2) Propose information rules unrelated to device information, such as new deactivation rules and time regular expressions, and use these rules to remove protocol-irrelevant words, thereby reducing the misidentification rate of model numbers. The rules are shown in Table 1:

[0106] Table 1. New Disabling Rules and Time Regular Expressions

[0107]

[0108] (3) For industrial protocols such as S7, Modbus, and Ethernet / IP, a not_banner anti-ambiguity model file is created, and the fields involved in the file are deleted when collecting the original banner information; For long protocols such as HTTP and HTTPS, the banner information is too long, and the equipment-related information is concentrated in the title field or body field, so keywords are used to filter the information.

[0109] (4) Create a device_tag corpus file. The initial corpus file only contains device-related words. Since the device-related words in the banner information are complex in form but similar in content, the Wikipedia corpus and NLTK tool are used to generate synonyms for device-related words to form the final device_tag corpus file;

[0110] (5) Use words or phrases in the device_tag file as keywords to extract key fields from protocol information. Retain the content of the line containing the keyword and the following line to form the key field. If content exists, extract it. If the key field is still too long, use the proposed key field reduction rules to shorten it. Specifically, the key field reduction rules state that the key field must contain at most three "<>" characters, meaning that at most the content of the line preceding, following, and next to the keyword in standard HTML must be retained. The rules are shown in Table 2.

[0111] Table 2 Key Field Reduction Rules

[0112]

[0113] (6) Use NLTK to segment and tag the processed corpus; finally remove stop words and add stop words that fit this experiment to the existing English stop word list, including punctuation marks, protocol flag fields (protocol name, protocol operator, protocol service response number, such as 2XX, 4XX, etc.), and service information (login, register, welcome, server, name, type, id).

[0114] Step 3: Using the attached Figure 4 The device entity recognition module shown identifies words representing brand, type, and model from the banner's word list, including the following specific methods:

[0115] (1) Based on a search of online equipment sales and evaluation websites, a total of 1885 equipment brands and 2040 equipment types were collected. These equipment types were categorized into three levels according to their coverage: major categories, intermediate categories, and minor categories. The minor categories... Class in type The system is divided into three main categories (29 in total), intermediate categories (139 in total), and minor categories (1872 in total). Device brands and types are stored in the corpus. Adding new device brands and types updates the corresponding corpus list, making the brand and type lists in the corpus easily expandable and maintainable.

[0116] (2) The brand and type corpus list is segmented into words, and the segmented list is used to perform BIO tagging of banner words related to brands and types. First, the first-level rules are used to initially filter words related to model numbers. The second-level rules are used to process words containing only letters, only numbers, and words containing " / " or "_". Finally, the third-level rules are used to determine the final list.<brand,type,model> Triplet.

[0117] (3) The first layer of rules consists of two parts: First, the first layer of initial rules is proposed to label the model, where the equipment model consists of the following three forms:

[0118] 1) Pure numbers;

[0119] 2) Combinations of numbers and letters;

[0120] 3) Combinations of numbers, letters, and "-", where numbers and letters are present simultaneously;

[0121] The initial rules for the first layer are shown in Table 3:

[0122] Table 3 Initial Rules for the First Layer

[0123]

[0124] In the first-level initial rules, in addition to the three forms mentioned above, strings containing " / " were added. Secondly, a not_tag file was created based on the first-level initial rules. String ambiguity was eliminated by deleting strings that conformed to the model number rule "number? + keyword + number?", where the keyword included HTML tags, encoding types involved in the protocol, and element attribute words in the protocol. The first-level initial model number rules processed by the not_tag corpus were defined as the first-level rules.

[0125] (4) Based on the first layer of rules, establish a second layer of rules to handle the following three cases:

[0126] 1) Model extraction rule 1: For cases involving pure numbers that meet the first-level rule, at most M1 words will be searched to find those labeled as brand or model, where M1 = 5;

[0127] 2) Model extraction rule 2: Handle cases that do not conform to the first-level rules but consist of several pure English strings, such as HP (brand) color (color) Laser (English) mfp (English) 178nw (model). The characters currently marked as "model" are searched forward by up to M2 characters. If a word marked as brand is found, the English characters in the middle are marked as model, where M2 = 5.

[0128] 3) Model extraction rule 3: Process the form XX / YY or XX_YY, requiring XX to conform to the first level rule or XX to represent "Series".

[0129] (5) After processing by the second-level rules, the complete model number can be determined relatively accurately. However, a large number of strings that do not belong to the model number are misidentified as model numbers. Therefore, words labeled as brand, type, and model number will form an exponential number of triples, which is detrimental to the next step of the ontology search. Thus, a third-level rule is established. This third-level rule reduces the misidentification rate of model numbers by increasing the connection between brand, type, and model number. The third-level rule includes the following specific situations:

[0130] 1) Model determination: The model is the word closest to the brand name and the distance between them is less than a fixed value M3, where M3 = 20;

[0131] 2) Type Determination: Words marked as "type" are used as candidate device models, and device type priorities are set, defining network communication devices as having a lower priority than ordinary devices. Since devices like ordinary temperature sensors do not have built-in network capabilities and must rely on intermediate devices (such as smart gateways) to connect to the network, this allows for the identification of devices at lower levels below these intermediate devices. Furthermore, under different type classifications, the priority is defined as: Major Type < Sub-type < Minor Type. If two or more types are identified in the banner information and belong to different levels of device types, only the highest priority device type is retained as the final device type.

[0132] Step 4: Through the attachment Figure 5 The module for generating device information ontology, as shown, proposes a device information ontology structure and a device information attribute structure, and generates fine-grained device information of the device to be identified, which is stored in the device information database. This includes the following specific methods:

[0133] (1) Submitting an appendix Figure 6 The device information body structure and appendix shown Figure 7The device information attributes include eight entity classes in the ontology. The Thing class is the common parent class of all entity classes defined in OWL. The following are detailed descriptions of the other seven entity classes:

[0134] 1) Device: Indicates the IoT device to be identified in this invention;

[0135] 2) Basic_logo: Represents the triplet identifier of the IoT device.<brand,type,model> ;

[0136] 3) Basic_Parameter: Represents the basic hardware configuration parameters of the IoT device;

[0137] 4) Function_Features: Represents the functional parameters of an IoT device when it is working normally;

[0138] 5) Work_Envionment: Represents the environmental parameters for the normal operation of IoT devices;

[0139] 6) Exterior: Indicates the appearance parameters of the IoT device;

[0140] 7) Data: Represents the working data generated by IoT devices, which can be constructed using O&M and SensorML modeling languages.

[0141] The relationships between entity classes are shown in Table 4:

[0142] Table 4 Explanation of Relationships Between Entity Classes

[0143]

[0144]

[0145] (2) Use web crawlers to crawl device information from various online sales platforms and device evaluation platforms and filter out non-IoT devices;

[0146] (3) Based on the device information attribute rules, capture the relevant attribute information of the device and store it in the database. Convert the database data into ontology files according to the device information ontology and store them in the ontology repository.

[0147] Step 5: If the aforementioned device entity triple can uniquely identify an IoT device, then call the attached... Figure 8 The automatic registration module shown will register the device entity triple.<brand,type,model> As search criteria, the registration rules proposed in Table 5 are used to search for information in the ontology repository, and the information in the ontology repository is matched to complete the device information, thereby generating an ontology file of the device information to be identified.

[0148] Table 5 Registration Rules Explanation

[0149]

[0150] Step 6: If the device entity triple cannot uniquely identify an IoT device, then call the attached... Figure 8 The equipment vendor registration module shown actively collects equipment information, including the following specific methods:

[0151] (1) The middleware actively sends a request to the equipment vendor user to register equipment information. The equipment vendor provides the equipment information file, and the format of the information file is not limited.

[0152] (2) Extract file information based on the device information attributes, form the device ontology file according to the device information ontology structure, and add it to the ontology repository and device information database respectively to complete the device information registration when the banner information is missing or the complete triplet cannot be identified, so as to ensure the integrity of the device information and complete the active collection of device information.

[0153] Step 7: The upper-layer user interface layer provides a unified API for upper-layer users using Python scripts, enabling transparent access to the device information database using Sparql. This upper-layer user interface layer grants query permissions to ordinary users and CRUD (Create, Read, Update, Delete) permissions to developers, thereby facilitating the maintenance and expansion of the device information database.

[0154] In collecting banner information, this invention uses banner information for all protocols of 10,000 different IoT devices collected from Censys and Shodan, along with annotations about the brand, type, and model of the devices, as the dataset for this invention. A total of 27 brands and 35 device types were collected, covering sensor devices, smart home devices, industrial devices, security devices, network devices, and communication devices. Among them are 5 types of industrial devices that use proprietary device communication protocols. Other types of device protocols include standard application layer protocols such as FTP, HTTP, HTTPS, TELNET, SSH, and SNMP.

[0155] For the dataset of this invention, this invention conducted tests on the values ​​of the protocol limit N for parameter length and shortness, and distance parameters M1, M2 and M3. At the same time, it verified the necessity of the three-layer rule proposed in the device information entity recognition module and the experimental results of the entity recognition method. Finally, it statistically analyzed the matching results based on the registration rules.

[0156] The present invention uses the following two formulas to calculate the accuracy and false recognition rate (FAR) to evaluate the application effect of the entity recognition method in the present invention.

[0157]

[0158]

[0159] This invention statistically analyzed the accuracy, false positive rate, time, and number of triples for different N values ​​ranging from 500 to 3000. The value of N as "not N" indicates the effect without the parameter N. The statistical results are shown in the appendix. Figure 9 As shown, when N equals 700, the accuracy is the highest and the false positive rate is the lowest. Secondly, regarding labeling time, when N equals 700, the time is too short, and the number of generated triples is also too low. Therefore, N is set to 700. When N is 3000, the accuracy, false positive rate, and number of generated triples all change significantly, and the effect is not good; therefore, the range is set up to 3000. Without using N, the accuracy is the lowest, while the false positive rate, labeling time, and number of generated triples are the highest. Therefore, our scheme of adding N is both feasible and necessary.

[0160] This invention statistically analyzed the values ​​of distance parameters M1, M2, and M3 in the dataset, and the statistical results are shown in the attached figure. Figure 10 As shown, M1 is mostly distributed in [1,3], and the frequency of occurrence in [5,10] is 0. Therefore, the value range of M1 is M1≤5. M2 is mostly distributed in [2,4], and the frequency of occurrence in [6,10] is 0. Therefore, the value range of M2 is M2≤5. M3 is mostly distributed in [1,5]. Its frequency of occurrence in other ranges less than 20 is extremely small, close to 0, and its frequency of occurrence in ranges greater than 20 is 0. Therefore, the value range of M3 is M3≤20.

[0161] The present invention statistically analyzed the recognition results under the three-layer rules of the device information entity recognition method, as shown in Table 6:

[0162] Table 6 shows the performance of entity recognition methods under first-level, second-level, and third-level rules.

[0163] layer 90％ 52％ 341955 Second floor 99.38％ 8.9％ 68106 Three floors 99.48％ 4.66％ 28639

[0164] As can be seen, adding the second layer of rules significantly improves accuracy, while the false positive rate and the number of triples decrease significantly. Adding the third layer of rules again significantly reduces both the false positive rate and the number of triples. This is because the third layer of rules removes many falsely identified strings. Therefore, the three-layer rule proposed in this invention is necessary and feasible.

[0165] This invention statistically analyzed the performance of the device information entity recognition method on industrial equipment, ordinary networked devices, and the overall dataset, and the comparison results are shown in Table 7:

[0166] Table 7. Recognition Results of Entity Identification Method for Equipment Information

[0167] Industrial equipment (using proprietary protocols) 99.1％ 0.14％ ordinary network devices 99.6％ 5.1％ overall 99.48％ 4.66％

[0168] This invention can generate the device's body file, attached. Figure 11 This displays partial ontology file information for the Brother ads-2100 scanner, which defines the relationships between entities and detailed attribute data in the device's Basic_parameter.

[0169] This invention categorizes and statistically analyzes the devices in the dataset according to the registration rules, and the statistical results are attached. Figure 12 As shown, most devices conform to rules 1, 3, and 8. Among the devices we collected, 56.2% of the devices can be automatically registered without the device manufacturer submitting documents, while 43.8% of the devices require the device manufacturer to submit device instruction documents as needed for registration, thus completing the proactive collection of device information and achieving intelligent device registration.

[0170] This invention also proposes an intelligent registration system for IoT devices based on semantic IoT middleware, comprising three parts: data acquisition, intelligent registration, and an upper-layer interface layer. The data acquisition includes an active detection module, a passive listening module, and a protocol parsing module. The intelligent registration utilizes the device protocol banner information parsed from the protocol, and through a banner information preprocessing module, a device entity recognition module, and a device information ontology generation module, converts the banner information into a device ontology file, which is then stored in a device information database to achieve automatic registration of device information. If the entity information in the banner information cannot uniquely identify a device, the system actively collects device information by interacting with the device manufacturer and extracting device information from the device manual to implement the device manufacturer registration module. The upper-layer interface layer provides a transparent device access interface for ordinary users.

[0171] The data acquisition, intelligent registration, and upper interface layer form a vertical structure from bottom to top.

[0172] The scope of protection of this invention is not limited to the above embodiments. Any variations and advantages that can be conceived by those skilled in the art without departing from the spirit and scope of the inventive concept are included in this invention and are protected by the appended claims.

Claims

1. A method for intelligent registration of IoT devices based on semantic IoT middleware, characterized in that, Includes the following steps: Step 1: Use the data acquisition module to obtain the application protocol content of the device and parse it into a unified text format to form the device protocol banner information; Step 2: Convert the banner information of the device protocol into a banner word list through the banner information preprocessing module; Step 3: Use the device entity recognition module to mark words that are brand, type, and model from the banner word list to form device entity triples; Step 3 includes the following sub-steps: Step 3.1: Based on device information from online device sales and evaluation websites, collect IoT device brands and types from across the network. Device types are categorized into three levels: major categories, intermediate categories, and minor categories, with minor categories ⊂ intermediate categories ⊂ major categories. Store device brands and types in a corpus. If new device brands and types are added, the corresponding corpus list will be updated. The brand and type lists in the corpus are easily expandable and maintainable. Step 3.2: First, segment the brand and type corpus list into words, and use the segmented list to perform BIO tagging of the banner word list related to brands and types; second, use the first-level rules to initially filter the model words, then use the second-level rules to process pure letter words, pure number words, and words containing " / " and "_" in the model words, and finally use the third-level rules to determine the final...<brand,type,model> Triplet; The first layer of rules consists of two parts: First, the initial rules for the first layer are proposed to label the model, where the equipment model consists of the following three forms: 1) Pure numbers; 2) Combinations of numbers and letters; 3) Combinations of numbers, letters, and "-", where numbers and letters are present simultaneously; In the initial rules of the first level, in addition to the three forms mentioned above, a string containing " / " was also added; Secondly, based on the first-level initial rules mentioned above, a not_tag file is created. String ambiguity is eliminated by deleting strings that conform to the model rule and contain the regular expression rule "number?+keyword+number?". The keyword includes HTML tag symbols, encoding types involved in the protocol, and element attribute words in the protocol. The first-level initial model rule after processing the not_tag corpus is defined as the first-level rule. Based on the first layer of rules, a second layer of rules is established to handle the following three cases: 1) When dealing with pure numbers that meet the first-level rules, the initial search can be at most performed. If a word is found to be labeled as "brand" or "model", the rule for handling this case is defined as "Model Extraction Rule 1". 2) For cases that do not conform to the first-level rules but consist of several pure English strings, the characters currently labeled "model" will be searched backwards at most... If a word labeled as a brand is found, the English characters in the middle are marked as the model number. The rule for handling this situation is defined as Model Number Extraction Rule 2. 3) For cases involving XX / YY or XX_YY, where XX must conform to the first-level rule or represent "Series", the rule for handling this case is defined as model extraction rule 3. A third-level rule is established, which reduces the misidentification rate of model numbers by increasing the connection between brand, type, and model number. The third-level rule includes the following specific situations: 1) Model number determination: The model number is determined by the word immediately preceding or following the brand name, with a distance of less than a certain value. ; Type determination: Words marked as types are all candidate device models, and device type priorities are set, defining network communication devices as having a priority < ordinary devices; since devices represented by ordinary temperature sensors do not have network capabilities themselves, they must rely on intermediate devices to enter the network, thus uncovering devices at lower levels below the intermediate devices; secondly, under different type levels, the priority is defined as major type < intermediate type < minor type. If two or more types are identified in the banner information and belong to different levels of device types, only the device type with the highest priority is retained as the final device type; Step 4: The device information ontology structure and device attribute information structure are proposed by generating the device information ontology module, and the fine-grained device information of the device to be identified is generated and stored in the device information database; Step 5: If the device entity triple uniquely identifies an IoT device, the automatic registration module is invoked. The device entity triple is used as a search condition. The proposed registration rules are used to search for information in the ontology repository. The device information is completed by matching the information in the ontology repository, thereby generating an ontology file of the device information to be identified. Step 6: If the device entity triple cannot uniquely identify an IoT device, the device vendor registration module is invoked to actively collect device information from the device file, form an ontology file, and complete the registration. Step 7: The upper-layer user interface layer provides a unified API for upper-layer users using Python scripts, and uses Sparql to transparently access the device information database; the upper-layer user interface layer grants query permissions to ordinary users and CRUD permissions to developers, so as to realize the maintenance and expansion of the device information database.

2. The method for intelligent registration of IoT devices based on semantic IoT middleware according to claim 1, characterized in that, Step 1 includes the following sub-steps: Step 1.1: After the device joins the network, it continuously sends information to the server using a protocol. Passive listening technology is employed to indiscriminately capture and analyze the binary data sent by the device without affecting the normal operation of the current router or gateway. The data acquisition module uses a passive listening module. A small amount of random binary data is obtained. Based on the length of the IP address and a fixed offset between the destination and source IP addresses, the device's IP address is obtained. Based on the relationship between binary protocol data and IP addresses, the mapping formula is defined as follows: in, This represents the IP address of the i-th device. This indicates the retrieved binary data; Step 1.2: Based on the passive listening module The obtained IP address is used for active protocol detection module To obtain the protocol banner, a half-open connection is used to probe for the device's live ports. If the device port is open, an ACK+SYN response is returned to initiate a half-open connection; otherwise, an RST+SYN response is returned to terminate the TCP connection. The mapping formula is defined as follows: in This represents the list of active ports for the i-th device. This represents the IP address of the i-th device; Step 1.3: Active Detection Module After providing the device's live port, the protocol parsing module A payload is constructed for the live port to obtain the response information, i.e., the protocol banner information. The protocol parsing module parses the protocol based on the obtained banner information and uses a protocol parsing template to convert the protocol banner information into a unified string format for subsequent operations. The mapping relationship between the protocol and the banner information is as follows: in This represents the banner information for the j-th protocol of the i-th device. This represents the banner information for the i-th device. This represents the list of live ports for the i-th device.

3. The method for intelligent registration of IoT devices based on semantic IoT middleware according to claim 1, characterized in that, Step 2 includes the following sub-steps: Step 2.1: Convert the original banner information into a list of individual words, and use the banner obtained in step 1.3 of claim 2 ( As the corpus to be processed, the banner information preprocessing module uses rules and corpus files for processing; Step 2.2: Propose new deactivation rules and time regular expressions and define them as rules unrelated to device information. Use the rules to remove protocol-irrelevant words and reduce the misidentification rate of model numbers. Step 2.3: For industrial protocols such as S7, Modbus, and Ethernet / IP, create a not_banner anti-blur model file and delete the relevant fields in the file when collecting the original banner information; for long protocols such as HTTP and HTTPS, the banner information is too long and the device-related information is concentrated in the title field or body field, so use keywords to filter the information. Step 2.4: Create the device_tag corpus file. The initial corpus file only contains device-related words. Since the device-related words in the banner information are complex in form but similar in content, the Wikipedia corpus and NLTK tool are used to generate synonyms for device-related words to form the final device_tag corpus file. Step 2.5: Extract key fields from the protocol information using words or phrases in the device_tag file as keywords. Keep the content of the keyword's current line and the next line to form the key field. If there is content, extract it. If the key field is still too long, use the proposed key field reduction rules to shorten it. The key field reduction rules are specifically stated as follows: the key field contains at most 3 "<>", that is, at most keep the content of the first line, the current line, and the next line of the keyword in standard HTML. Step 2.6: Perform word segmentation and part-of-speech tagging on the processed corpus using NLTK, and finally remove stop words. Add stop words that fit this experiment to the existing English stop word list, including punctuation marks, protocol flag fields, and service information.

4. The method for intelligent registration of IoT devices based on semantic IoT middleware according to claim 1, characterized in that, Step 4 includes the following sub-steps: Step 4.1: Propose a structure that conforms to the device information ontology structure and the device attribute information structure; Step 4.2: Use web crawlers to collect device information from various online sales platforms and device evaluation platforms and filter out non-IoT devices; Step 4.3: Extract relevant attribute information of the device based on the device information attributes and store it in the database. Convert the database data into ontology files based on the device information ontology and store them in the ontology repository.

5. The method for intelligent registration of IoT devices based on semantic IoT middleware according to claim 1, characterized in that, Step 5 includes the following sub-steps: If the device entity triple uniquely identifies an IoT device, the automatic registration module is invoked, the device entity triple is used as a search condition, the proposed registration rules are used to search the information in the ontology repository, the information in the ontology repository is matched to complete the device information, and thus an ontology file of the device information to be identified is generated.

6. The method for intelligent registration of IoT devices based on semantic IoT middleware according to claim 1, characterized in that, Step 6 includes the following sub-steps: If the device entity triple cannot uniquely identify an IoT device, then the device vendor registration module is invoked to actively collect device information. Step 6.1: The middleware proactively sends a request to the equipment vendor user to register equipment information. The equipment vendor provides the equipment information file, and the format of the information file is not limited. Step 6.2: Extract file information based on the proposed device information attributes, form the device ontology file according to the device information ontology structure, and add it to the ontology repository and device information database respectively to complete the device information registration when banner information is missing or the complete triple cannot be identified, so as to ensure the integrity of device information and complete the active collection of device information.

7. A registration system for the IoT device intelligent registration method based on semantic IoT middleware as described in any one of claims 1-6, characterized in that, The system consists of three parts: data acquisition, intelligent registration, and upper-layer interface layer. The data acquisition includes an active detection module, a passive listening module, and a protocol parsing module. The intelligent registration utilizes the device protocol banner information parsed from the protocol. Through a banner information preprocessing module, a device entity recognition module, and a device information ontology generation module, the banner information is converted into a device ontology file and stored in the device information database to achieve automatic device registration. If the entity information in the banner information cannot uniquely identify a device, the system interacts with the device manufacturer to actively collect device information and extracts device information from the device manual to implement the device manufacturer registration module. The upper-layer interface layer provides a transparent device access interface to ordinary users. The data acquisition, intelligent registration, and upper-layer interface layer form a bottom-up vertical structure.

Images