CN103561079A - Wireless sensor network data interaction method based on XMPP - Google Patents

Abstract

The invention discloses a data interaction method of a wireless sensor network based on the XMPP protocol. The corresponding operation request data packet; the source client of the wireless sensor network sends the generated operation request data packet to the target client, and waits for the response of the target client; When operating the request data packet, a corresponding response data packet is generated, and forwarded to the executive body of the target client for execution. The invention can solve the problems of compatibility and interoperability among various application protocols of the wireless sensor network, and contributes to the large-scale deployment and development of the wireless sensor network.

Description

A data interaction method for wireless sensor networks based on XMPP protocol

Technical Field

The present invention belongs to the technical field of industrial wireless sensor networks, and specifically relates to an XMPP data interaction method in wireless sensor networks (Wireless Sensor Networks, WSN for short).

Background Art

Since the Internet technology, WSN technology has become one of the most important IT hot technologies affecting mankind in the 21st century. Its application has also become the focus of human attention and has been widely used in various application fields. However, WSN still has many problems, such as the imperfect WSN standard system and the inconsistent data formats in various application fields, which has made the large-scale deployment and application of WSN a major problem.

XMPP (Extensible Messaging and Presence Protocol), as an instant information transmission specification based on XML language, has the characteristics of good openness, strong real-time performance and easy extensibility. It has been widely used in the Internet. Extending it to WSN can solve the problems of incompatibility between application protocols and inconsistent data formats in WSN.

However, the existing XMPP is mainly developed for instant messaging, mainly targeting applications such as chat systems, entertainment and email, and has a relatively complex architecture; while WSN is mainly aimed at applications such as data aggregation, data publishing and network management, and has a relatively simple architecture. Therefore, there are still some problems in directly applying the existing XMPP protocol to WSN.

In order to meet the requirements of large-scale deployment and development of WSN, it is very necessary to propose an instant message transmission method specifically for WSN, as pointed out in the article "An instant message transmission method based on XMPP protocol" (Pei Wenjiang, Wang Xiaoshu, Zhang Shuqiang, Wang Kai, Sun Qingqing, Zhang Yifeng, Yang Yang, Zhan Jinshi, Di Wei, Zhu Guanghui, Miao Ruihua, Shen Yanzhen. An instant message transmission method based on XMPP protocol [P]. Chinese patent: 201210087194.4). At present, there are very few instant message transmission methods for WSN. For example, the above patent only describes a method for realizing data transmission between instant messages within and outside the enterprise, and does not propose an instant message transmission method specifically for WSN.

In view of the above shortcomings, the present invention customizes and optimizes the XMPP protocol based on the needs and characteristics of WSN, designs a lightweight XMPP protocol for wireless sensor networks, utilizes the characteristics of objects, designs an XMPP data interaction format with read, write, execute, publish and report functions, and proposes an XMPP data interaction method based on WSN, aiming to solve the problem of inconsistent data formats in various application fields of WSN, so as to promote large-scale deployment and development of WSN.

Summary of the invention

In view of the above shortcomings in the prior art, the purpose of the present invention is to provide a data interaction method for a wireless sensor network based on the XMPP protocol that can solve the incompatibility between various application fields of WSN. The technical solution of the present invention is as follows: A data interaction method for a wireless sensor network based on the XMPP protocol, which comprises the following steps:

101. When the source client of the wireless sensor network receives a read request instruction, a write request instruction, or an execute request instruction for operating the target client, the source client of the wireless sensor network generates a corresponding read request instruction data packet, a write request instruction data packet, or an execute request instruction data packet, and jumps to step 102;

When the source client of the wireless sensor network receives a publishing request instruction or a report request instruction for operating the target client, the source client of the wireless sensor network generates a corresponding publishing request instruction data packet and a report request instruction data packet; and jumps to step 103;

102. The source client of the wireless sensor network sends the read request instruction data packet, write request instruction data packet, or execute request instruction data packet generated in step 101 to the target client, and waits for the response of the target client; when the target client receives the read request instruction data packet, write request instruction data packet, or execute request instruction data packet sent by the source client of the wireless sensor network, it generates a corresponding response data packet and forwards it to the execution mechanism of the target client for execution, thereby completing the read operation, write operation, or execute operation;

103. The source client of the wireless sensor network sends the publishing request instruction data packet or the reporting request instruction data packet generated in step 101 to the target client to complete the publishing operation or the reporting operation.

Furthermore, the XMPP protocol includes <object/>, <request/>, <response/>, <error/>, <command/>, <method/>, <attribute/>, <inargument/> and <outargument/> elements.

The advantages and beneficial effects of the present invention are as follows:

The data interaction method of the wireless sensor network based on the XMPP protocol of the present invention takes into account the high real-time performance, low power consumption and incompatibility between the existing application protocols of WSN, adopts the XMPP technology with strong real-time performance, good flexibility and easy expansion, and designs the XMPP data interaction format with reading, writing, execution, publishing and reporting functions to unify the data interaction format of various application fields of WSN. Therefore, the XMPP data interaction method of the present invention not only meets the application requirements of WSN, but also contributes to the large-scale deployment and development of WSN.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is a diagram of a data object application scenario in a preferred embodiment of the present invention;

Figure 2 Read service implementation process flow chart;

Figure 3 writes a flow chart of the service implementation process;

Figure 4 is a flow chart of the execution service implementation process;

Figure 5 is a flow chart of the publishing service implementation process;

Figure 6 Report service implementation process flow chart.

DETAILED DESCRIPTION

A non-limiting embodiment is provided below in conjunction with the accompanying drawings to further illustrate the present invention. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the present invention. In addition, in the following description, the description of known structures and technologies is omitted to avoid unnecessary confusion of the concept of the present invention.

As shown in Figure 1, in the data interaction method of the wireless sensor network based on the XMPP protocol proposed by the present invention, each device node should have a data object. Since the object encapsulates attributes and methods, the attributes are the relevant parameters in the device node, and the methods are the interface functions for accessing these attributes. The methods supported by the data object designed by the present invention are shown in Table 1, which mainly includes five public methods such as read, write, execute, publish and report, that is, the data object provides five data services such as read, write, execute, publish and report. The private methods in the execution method are methods that may be added in the future, and the present invention has not yet defined them. When a device node wants to perform a corresponding operation on another device node, it can be achieved by using the data service provided by the data object to operate the data object.

Table 1

As described in Table 1, the data objects in the device node provide read, write, execute, publish and report services. These data services are introduced separately below.

(1) Reading service

Read service is a service provided by the data object in the device, which means that the visitor can obtain the attribute value in the data object by "reading". Read service belongs to the passive command acceptance service, that is, in WSN, the attribute of the data object in the device is read in a passive way. Read service includes read request and read response, whose identifiers are request and response/error respectively.

request: a read request identifier, indicating a request made by a visitor to obtain the attribute value of a data object in the device.

response: is a read response identifier, indicating that the visitor has successfully read the attribute value of the data object in the device.

error: A read response identifier indicating that an error occurred when the visitor read the attribute value of a data object in the device.

(2) Write service

Write service is a service provided by the data object in the device, which means that the operator can write the corresponding value to the attribute of the data object as its attribute value through the "write" method. Like the read service, the write service is a passive command acceptance service, that is, in WSN, the attribute of the data object in the device is implemented in a passive way. The write service includes write request and write response, and their identifiers are request and response/error respectively.

request: is a write request identifier, indicating that the operator wants to write the corresponding value to the attribute of the data object.

response: is a write response identifier, indicating that the operator has successfully written the corresponding value to the attribute of the data object.

error: A write response identifier, indicating that an error occurred when the operator wrote the corresponding value to the attribute of the data object.

(3) Execution services

Execution service is a service provided by the data object in the device, which means that the executor can execute some private methods on the attributes in the data object, such as creation or deletion. Execution service is the same as the read service and write service mentioned above, which is a passive command acceptance service. That is, in WSN, the attributes of the data object in the device are implemented in a passive way.

(4) Publishing services

The publishing service is a service provided by the data object in the device, which means the method used by one party in the communication to publish relevant information based on the information it receives from other devices.

In contrast to the above-mentioned read, write and execute services, the publish-subscribe service defined by the data service protocol belongs to the active command service, that is, in WSN, the attributes of the data objects in the device are published and subscribed in an active way. For example, when the sensor node needs to obtain relevant information from the server, it actively sends subscription information to the server. After receiving the subscription information, the server will actively publish the subscribed information to one or more subscribed sensor nodes within a certain period of time. The publish-subscribe service method is mainly used for occasions such as periodic data updates.

(5) Reporting services

The reporting service is a service provided by the data object in the device, which indicates the method used by the device to actively initiate non-periodic information transmission to the other party of the communication in case of emergencies, abnormal conditions or other situations.

Like the publish-subscribe service, the report service is an active command service. The report service is similar to the "push" mechanism. For example, when the data collected by the sensor exceeds the preset upper and lower limits, the sensor node pushes the alarm data information to the gateway. This service method is mainly used for non-periodic data updates and other occasions.

The application scenarios corresponding to the data objects are shown in Figure 1. In Figure 1, WSN represents WSN, data stream 1 represents that sensor nodes can perform read, write and execute operations; data stream 2 represents that sensor nodes can perform read, write and execute operations with remote device nodes, and the data transmitted by data stream 1 and data stream 2 are all iq messages; data stream 3 represents that remote device nodes can publish relevant messages to sensor nodes in WSN, and the data transmitted is presence messages. Data stream 4 represents that one of the sensor nodes in WSN can report its relevant information to another sensor node; data stream 5 represents that remote device nodes can report their relevant information to sensor nodes in WSN; data stream 6 represents that sensor nodes in WSN can report their relevant information to remote device nodes, and the data transmitted by data streams 4, 5 and 6 are all message messages; the aforementioned data services will be introduced in detail below.

For the XMPP data interaction method based on WSN, it is necessary to design its data interaction syntax and the implementation method of each data service in the data object. The following will describe these two parts in detail.

1. Data interaction syntax design

In WSN, the communication between one object and another is realized by operating an <object/> element. The present invention defines its namespace as ' http://jabber.org/protocol/wsn-object '. The <object/> element defined by this namespace should be used as the first-level child element of the <message/> section, <presence/> section and <iq/> section. The <object/> element must contain the "from" attribute and the "to" attribute, which represent the source object and the destination object respectively. Its basic syntax is as follows.

(1) Syntax of sending request

(2) Syntax of reply response

or

As described above, in addition to some elements defined by the XMPP core protocol, the present invention also defines elements such as <object/>, <request/>, <response/>, <error/>, <command/>, <method/>, <attribute/>, <inargument/> and <outargument/>. If necessary, more elements can be added in the future.

2. Design of implementation methods for each data service in the data object

When designing an XMPP data interaction method based on wireless sensor networks, the characteristics of XMPP and WSN need to be considered comprehensively. Since the XMPP protocol is based on XML streams, and the XML streams transmit XML sections, such as <message/> sections, <presence/> sections, and <iq/> sections, when XMPP is applied to WSNs, the communication data between the devices is also based on XML streams. In view of this, the implementation of data services in the WSN data objects defined in the present invention can be achieved by extending the <message/> section, <presence/> section, and <iq/> section.

In the XMPP core protocol, three basic semantics are defined, namely, message semantics <message>, presence semantics <presence/>, and IQ semantics <iq/>. Among them, the <message/> section type can be regarded as a "push" mechanism for one entity to push messages to another entity, similar to the Source/sink communication mode in the WSN technical standard; the <presence/> section type can be regarded as a basic broadcast or "publish-subscribe" mechanism for multiple entities to receive information from a subscribed entity, similar to the publish-subscribe communication mode in the WSN technical standard; and the <iq/> section type is a request-response mechanism for one entity to make a request to another entity and respond to it, similar to the client-server communication mode in the WSN technical standard. The following will introduce the implementation method of each data service in detail.

(1) Design of read service implementation method

As mentioned above, the read service includes a read request and a read response service. XMPP stipulates that when an entity receives a read request, it must reply with a read response. This process uses a request-response mechanism. Therefore, the implementation of the read service can be achieved by extending the <iq/> section with a request-response mechanism. This article stipulates that an entity that receives an iq request of type "request" must reply with an iq response of type "response" or "error", and the <iq/> section must contain type and id attributes. The specific implementation format designed by the present invention is as follows.

a) Read request format

In the read request format, iq indicates that this message is an <iq/> section type message; id='get-id' indicates an interactive behavior; type='get' indicates that this <iq/> section wants to obtain a certain attribute value; from='source address' indicates the source address of the entity sending the read request; to='destination address' indicates the destination address of the entity receiving the read request; all of the above are attributes of the <iq/> section. <object/> is the first-level child element of the <iq/> section, which is extended by this article and indicates that the child element of the <iq/> section is an object; xmlns=' http://jabber.org/protocol/wsn-object ' is the namespace of the <object/>element;from='sourceobject' indicates the source object that sends the read request; to='targetobject' indicates the destination object that receives the read request information; <request/> is the child element of <object/> and indicates that the source object is to perform the requested operation. It must contain a "var" attribute to indicate the public method to be executed, such as var='read' here, which indicates that the source object is to perform a read operation; <attribute/> is the child element of <request/> and it must contain a "var" attribute to indicate the object attribute to be read.

b) Read response format

The read response is divided into two cases: a successful read response and an error read response. For a successful read response, the present invention designs its format as follows:

In the format of a successful read response, type=’result’ indicates that this <iq/> section is a response result and the response is successful; from=’source address’ indicates the entity source address of the response to the read request; to=’destination address’ indicates the entity destination address of the response to the read request, that is, the entity address of the entity that initiated the read request; <response/> is a child element of <object/>, indicating that the object is to perform a response operation and the response to the read request is successful; <attribute/> is a child element of <response/>, which must contain a "var" attribute to indicate the object attribute being responded to, which may contain the attribute value being read, such as the attribute value here is the attribute value being read.

In view of the read response error, the present invention designs the format as follows:

In the format of the read response error, type='error' indicates that this <iq/> section is the response result, and an error occurred during the response process; <error/> is a child element of <object/>, indicating that the object is to perform a response operation and the response is an error. It must contain a type attribute to indicate the error type, such as type='error-type', where the value of error-type can be cancel (no retry), continue (continue), modify (retry after changing data), auth (retry after providing a certificate) or wait (retry after waiting). In addition, the <error/> element must also contain a child element, namely defined-condition here, and this child element must conform to the 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace. For its value, refer to Defined Conditions in Section 8.3.3 of RFC6120 in IETF. Among them, the parts of the read response format that are the same as those in the read request format are not repeated here, and refer to the description of the read request format. The communication process for implementing the read service between the two entities is shown in Figure 2.

(2) Write a service implementation method design

The write service includes a write request service and a write response service, and its implementation is similar to that of the read service, and is also implemented by extending the <iq/> section. The present invention designs its specific implementation format as follows.

a) Write request format

In the write request format, type=’set’ indicates that this <iq/> section wants to set or modify a certain attribute value; from=’source address’ indicates the source address of the entity sending the write request; to=’destination address’ indicates the destination address of the entity receiving the write request; all of the above are attributes of the <iq/> section. <object/> is the first-level child element of the <iq/> section, which is extended by this article, indicating that the child element of the <iq/> section is an object; <request/> is a child element of <object/>, indicating that the source object wants to perform the requested operation, and it must contain a "var" attribute to indicate the public method to be executed, such as var=’write’ here, indicating that the source object wants to perform a write operation; <attribute/> is a child element of <request/>, and it must contain a "var" attribute, such as var=’objectattribute’, to indicate which attribute of the object is to be written, and it should contain the attribute value to be written, such as attribute value here.

b) Write response format

Similar to the read response, the write response is also divided into two cases: write response success and write response error. For a write response success, the present invention designs its format as follows:

In the format of a successful write response, type=’result’ indicates that this <iq/> section is a response result and the response is successful; from=’source address’ indicates the source address of the entity sending the write response; to=’destination address’ indicates the destination address of the entity receiving the write response; <response/> is a child element of <object/>, indicating that the object is to perform a response operation and the response write operation is successful. Here, since there is no content to be returned, <response/> is empty.

In view of the write response error, the present invention designs the format as follows:

In the format of the write response error, type='error' indicates that this <iq/> section is a response result and an error occurred during the response process; <error/> is a child element of <object/>, indicating that the object is to perform a response operation and the response is an error. It must contain a type attribute, such as type='error-type', where the description of error-type can refer to the description of error-type in the read response error. The communication process for implementing the write service between the two entities is shown in Figure 3.

(3) Design of execution service implementation method

Since the execution service, like the read service and the write service, is a passive instruction receiving service, it needs to be requested before responding. Therefore, the present invention implements it by extending the <iq/> section with a request-response mechanism. The specific implementation format of the execution service is as follows.

a) Execution request format

In the execution request format, id=’execute-id’ indicates an interactive behavior; type=’X’ indicates the execution method, where X can be set or get; from=’source address’ indicates the source address of the entity that initiates the execution operation; to=’destination address’ indicates the destination address of the entity that receives the execution operation; <request/> is a child element of <object/>, indicating that the source object is to perform a request operation. It must contain a “var” attribute to indicate the public method to be executed, such as var=’execute’ here, indicating that the source object is to perform an execution operation; <method/> is a child element of <request/>, and it must contain a “var” attribute to indicate the private method to be executed. This private method will be added when needed in the future and is not defined in this article; <inargument/> is a child element of <method/>, and it must contain a “var” attribute, such as var=’argument_name’, to indicate which parameter is to be executed. It may contain specific content to be executed as needed, such as inargument value here, or it may not contain corresponding content.

b) Execution response format

When the source object that initiates the execution operation performs an operation on the attribute of the destination object, the source object needs to know the result of the execution of this operation for subsequent operations (for example, if the execution of an operation is successful, there is no need to continue to send the execution command; if the execution of an operation fails, the execution command needs to be re-initiated). The execution response can be divided into two situations: successful execution response and error. The format of the successful execution response designed by the present invention is as follows:

In case of an error in the execution response, the format is designed as follows:

The communication process between the two entities to implement the execution service is shown in Figure 4.

(4) Design of publishing service implementation method

The publishing service defined in the present invention is based on the publish-subscribe mechanism. Therefore, the present invention is implemented by extending the <presence/> section with the publish-subscribe mechanism. The other two sections, such as <message/>: push mechanism and <iq/>: request-response mechanism, are not suitable for the implementation of the publishing service. According to the relevant definition of XMPP, the publishing format designed by the present invention is as follows:

In the publish-subscribe format, presence indicates that this message is a <presence/> section type message; from=’source address’ indicates the address of the publishing entity, to=’destinationaddress’ indicates the address of the entity receiving the published information. When the published information is broadcast, there should be no to attribute in the <presence/> section; from=’source object’ indicates the source object of the published message, and to=’target object’ indicates the destination object receiving the published message; <command/> is a child element of <object/> and must contain a “var” attribute, such as var=’publish’, indicating that the source object is to be published; <attribute/> is a child element of <command/> and must contain a “var” attribute, such as var=’object attribute’, indicating which attribute of the object is to be published; it must contain the specific content of the published message, such as the publish information here is the specific content of the publication. The communication process between two entities to implement the publish-subscribe service is shown in Figure 5.

(5) Design of reporting service implementation method

The report service defined in the present invention is based on a "push" mechanism and can be implemented by extending <message/> with a "push" mechanism, while the other two sections, such as <presence/>: publish-subscribe mechanism and <iq/>: request-response mechanism, are not suitable for the implementation of the report service.

The report format designed by the present invention is as follows:

In the report format, message indicates that this message is a <message/> section type message; from=’source address’ indicates the address of the entity that initiates the report; to=’destinationaddress’ indicates the address of the destination entity that receives the report information; type=’X’ indicates the type of environment in which the two communicating parties are located, and “X” can be chat, groupchat, error, or normal; <command/> is a child element of <object/>, indicating the operation to be performed by the source object, and it must contain a “var” attribute to indicate the public method to be executed, such as var=’report’ here, indicating that the source object is to perform a report operation; <attribute/> is a child element of <command/>, and it must contain a “var” attribute to indicate the object attribute to be reported; value is the specific information of the report. The communication process between the two entities to implement the report service is shown in Figure 6.

In this way, the data interaction method of the present invention can unify the data interaction formats of various WSN application fields on the basis of meeting the application requirements of WSN, so as to solve the compatibility and interoperability of various WSN application protocols, and contribute to the large-scale deployment and development of WSN.

The above embodiments should be understood as being only used to illustrate the present invention and not to limit the protection scope of the present invention. After reading the contents of the present invention, technicians can make various changes or modifications to the present invention, and these equivalent changes and modifications also fall within the scope defined by the claims of the XMPP data interaction method based on wireless sensor networks of the present invention.

Claims (2)

1. A data interaction method for a wireless sensor network based on the XMPP protocol, characterized in that it comprises the following steps: 101. When the source client of the wireless sensor network receives a read request instruction or a write request instruction or an execution request instruction for operating the target client, the source client of the wireless sensor network generates a corresponding read request instruction packet or write request Instruction data packet or execution request instruction data packet, and jump to step 102; When the source client of the wireless sensor network receives a release request instruction or a report request instruction for operating the target client, the source client of the wireless sensor network generates a corresponding release request instruction packet and a report request instruction packet; and jumps to Go to step 103; 102. The source client of the wireless sensor network sends the read request instruction data packet or write request instruction data packet or execution request instruction data packet generated in step 101 to the target client, and waits for a response from the target client; When the source client from the wireless sensor network sends a read request command packet or a write request command packet or an execution request command packet, a corresponding response packet is generated and forwarded to the target client’s actuator for execution, completing the read operate or write or perform an operation; 103. The source client of the wireless sensor network sends the release request instruction data packet or the report request instruction data packet generated in step 101 to the target client to complete the release operation or the report operation. 2. The XMPP data interaction method based on wireless sensor network according to claim 1, characterized in that: said XMPP protocol includes <object/>, <request/>, <response/>, <error/>, <command />, <method/>, <attribute/>, <inargument/>, and <outargument/> elements.

Images