Wireless communication apparatus and method

Abstract

To provide a wireless communication apparatus and method capable of realizing efficient communication.SOLUTION: According to an embodiment, provided is a wireless communication apparatus configured to perform multi-hop communication through a wireless multi-hop network. The wireless communication apparatus includes management means, first compression processing means, first encryption processing means, and transmission means. The management means manages a first compression rule when the wireless communication apparatus is a transmission node. The first compression processing means compresses a network header or a transport header by applying the first compression rule. The first encryption processing means encrypts the network header and network data after the compression. The transmission means transmits a packet including the encrypted network header and the encrypted network data. The first compression rule is shared with another wireless communication apparatus which is a receiving node.SELECTED DRAWING: Figure 3

Description

[Technical field]

[0001] FIELD OF THE DISCLOSURE Embodiments of the present invention relate to wireless communication devices and methods. [Background technology]

[0002] In recent years, it has become known to construct wireless multi-hop networks and perform multi-hop communication for purposes such as sensing in a wide area. Multi-hop communication is a communication method that realizes long-distance communication by transferring data (packets) in a bucket brigade format among multiple nodes (wireless communication devices) that constitute the wireless multi-hop network. Multi-hop communication has advantages in terms of the cost of constructing the network (the installation cost of each node) and scalability.

[0003] However, in the above-mentioned wireless multi-hop network, the size of data that can be transmitted and received in multi-hop communication (i.e., the data area allocated to the payload contained in a packet transmitted and received in the wireless multi-hop network) may be small, which may prevent efficient communication. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Special Publication No. 2020-502833 [Non-patent literature]

[0005] [Non-Patent Document 1] Bluetooth Mesh Profile 1.0.1, [online], Internet<URL:https: / / www.bluetooth.com / ja-jp / specifications / specs / mesh-profile-1-0-1 / > [Non-Patent Document 2] RFC 8824 Static Context Header Compression, [online], Internet<URL:https: / / datatracker.ietf.org / doc / rfc8824 / > Summary of the Invention [Problem to be solved by the invention]

[0006] Therefore, an object of the present invention is to provide a wireless communication device and method capable of realizing efficient communication. [Means for solving the problem]

[0007] According to an embodiment, there is provided a wireless communication device that performs multi-hop communication via a wireless multi-hop network. The wireless communication device includes a management means, a first compression processing means, a first encryption processing means, and a transmission means. The management means manages a first compression rule when the wireless communication device is a transmitting node in the multi-hop communication. The first compression processing means compresses a transport header included in a network header or network data by applying the first compression rule. The first encryption processing means encrypts the network header and the network data after the compression. The transmission means transmits a packet including the encrypted network header and the encrypted network data. The first compression rule is shared with another wireless communication device that is a receiving node in the multi-hop communication. [Brief description of the drawings]

[0008] [Figure 1] 1 is a diagram showing an example of a network configuration including a wireless communication device according to a first embodiment. [Diagram 2] FIG. 1 shows an example of an application of a wireless multi-hop network. [Diagram 3] FIG. 2 is a diagram showing an example of the functional configuration of a wireless communication device. [Figure 4]FIG. 2 is a diagram showing an example of a hardware configuration of a wireless communication device. [Diagram 5] 10 is a flowchart showing an example of a processing procedure of an application data transmission process. [Figure 6] FIG. 4 is a diagram for conceptually explaining header compression in the embodiment; [Figure 7] 10 is a flowchart showing an example of a processing procedure of an application data receiving process. [Figure 8] 11 is a flowchart showing an example of a processing procedure of a packet forwarding process. [Figure 9] FIG. 11 is a diagram showing an example of a compression rule in the second embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] Hereinafter, an embodiment will be described with reference to the drawings. (First embodiment) Fig. 1 shows an example of a network configuration including wireless communication devices according to the first embodiment. In Fig. 1, wireless communication devices 10-1 to 10-6 configured to be capable of performing short-range wireless communication, for example, are shown.

[0010] In addition, the short-distance wireless communication in this embodiment includes wireless communication based on BLE (Bluetooth Low Energy (registered trademark)). In this case, the wireless communication devices 10-1 to 10-6 are realized by various electronic devices such as IoT (Internet of Things) devices and smartphones that are capable of performing wireless communication based on BLE.

[0011] Here, BLE (Bluetooth Low Energy) has a function of forming a wireless multi-hop network called Bluetooth Mesh, and each of the wireless communication devices 10-1 to 10-6 shown in FIG. 1 operates as a node that constitutes the wireless multi-hop network (wireless multi-hop mesh network) formed by the Bluetooth Mesh.

[0012] In the above-described wireless multi-hop network, for example, multi-hop communication can be performed in which data transmitted from wireless communication device 10-1 is relayed by wireless communication devices 10-2 to 10-5, and the data relayed by wireless communication devices 10-2 to 10-5 is received by wireless communication device 10-6. This allows, for example, wireless communication device 10-1 to realize communication (transmission and reception of data) with wireless communication device 10-6 that is beyond the BLE-based communication range of wireless communication device 10-1.

[0013] Fig. 2 shows an application example of the wireless multi-hop network in this embodiment. In Fig. 2, it is assumed that the wireless multi-hop network is applied to the maintenance management of elevators installed in a building, and the wireless communication device 10-1 shown in Fig. 2 corresponds to a smartphone carried by a maintenance worker, for example.

[0014] In this case, wireless communication device 10-1 can communicate with wireless communication device 10-6 (elevator management device or elevator control device, etc.) installed on the roof of the building, for example, via other wireless communication devices 10-2 to 10-5 placed in the building.

[0015] Here, it is assumed that data transmitted from wireless communication device 10-1 is received by wireless communication device 10-6, and wireless communication device 10-1, which is the source of the data, is called a transmitting node, and wireless communication device 10-6, which is the destination of the data, is called a receiving node. Also, wireless communication devices 10-2 to 10-5, which relay the data transmitted from wireless communication device 10-1 (transmitting node) to wireless communication device 10-6 (receiving node), are called relay nodes.

[0016] In this embodiment, the wireless communication devices 10-1 to 10-6 constituting the wireless multi-hop network can operate as a transmitting node, a receiving node, and a relay node, respectively. Specifically, for example, when the wireless communication device 10-4 operates as a transmitting node and the wireless communication device 10-1 operates as a receiving node, the other wireless communication devices 10-2, 10-3, 10-5, and 10-6 may operate as relay nodes. Furthermore, at least one of the multiple wireless communication devices 10-1 to 10-6 may be a wireless communication device that operates only as a relay node.

[0017] The above-mentioned Bluetooth Mesh realizes highly reliable multi-hop communication by flooding communication. In flooding communication, each node constituting a wireless multi-hop network operates to forward data to all nodes within a communicable range of the node when performing multi-hop communication. In such flooding communication, since there is no need to select a specific route for multi-hop communication, network management is simple, and communication can be continued without major problems even if communication is interrupted between some nodes in the network.

[0018] By the way, Bluetooth Mesh performs flooding communication by using the beacon transmission mode of BLE, but the packet transmitted as a beacon in this beacon transmission mode has a very small data area allocated to the payload of only a dozen bytes. Therefore, only simple data such as control messages can be transmitted by a single packet, and the applicable applications (such as applications for generating data to be transmitted) are limited.

[0019] In this case, it is possible to divide large data into multiple packets and transmit them. However, in the above-mentioned flooding communication, a packet is duplicated (forwarded to all surrounding nodes) every time it passes through a relay node, so if data is divided into many packets and transmitted, the wireless multi-hop network may be overflowed with packets (the network load may increase). This may cause the wireless multi-hop network to collapse, and communication may not be possible between the nodes that make up the wireless multi-hop network, making it impossible to perform multi-hop communication (flooding communication).

[0020] For this reason, in order to use Bluetooth Mesh for various applications (services), it is necessary to expand the data area (payload size) allocated to the payload included in the packet.In this case, since the overall size (maximum length) of a packet in Bluetooth Mesh is determined by the Bluetooth standard, in order to expand the payload size, it is necessary to reduce the data area allocated to the header (information) etc. included in the packet (i.e., the data area other than the payload) and allocate the reduced data area to the payload.

[0021] Therefore, in this embodiment, a configuration is described in which the data area allocated to the payload is expanded (enlarged) by compressing the headers included in packets transmitted and received in a wireless multi-hop network formed, for example, by Bluetooth Mesh.

[0022] Fig. 3 shows an example of the functional configuration of a wireless communication device according to this embodiment. Note that the wireless communication device 10 shown in Fig. 3 represents, for example, one of the wireless communication devices 10-1 to 10-6 shown in Fig. 1. The same applies to the following description.

[0023] As shown in FIG. 3, the wireless communication device 10 includes a compression rule management unit 11, a transmission / reception unit 12, an application management unit 13, an application processing unit 14, a network management unit 15, and a network processing unit 16.

[0024] When a wireless communication device 10 joins a wireless multi-hop network formed by Bluetooth Mesh, the wireless communication device 10 needs to be authenticated by a device called a provisioner. The procedure for receiving authentication from the provisioner is called provisioning. In provisioning, two types of keys and a compression rule are distributed (assigned) to the wireless communication device 10.

[0025] The two types of keys distributed in provisioning include a Network Key and an Application Key used to encrypt and decrypt data. The Network Key is a key (information) based on a common key cryptosystem shared throughout the entire wireless multi-hop network. The Application Key is a key (information) based on a common key cryptosystem prepared for each application applied to the wireless communication device 10. The Application Key is used to protect application data, and the Network Key is used to protect the entire packet. For this reason, the application data is encrypted with the Application Key, and then network information and the like are added, and the entire data is encrypted with the Network Key.

[0026] Compression rules distributed during provisioning are used to compress headers when packets are sent and to decompress headers when packets are received.

[0027] The compression rule management unit 11 manages (holds) the above-mentioned compression rules. Specifically, the compression rule management unit 11 manages, for example, the compression rules when the wireless communication device 10 is a transmitting node in multi-hop communication for each receiving node in the multi-hop communication. Note that the compression rules when the wireless communication device 10 is a transmitting node in multi-hop communication are shared with other wireless communication devices 10 that are receiving nodes in the multi-hop communication.

[0028] Furthermore, the compression rule management unit 11 manages, for example, the compression rules for the case where the wireless communication device 10 is a receiving node in multi-hop communication, for each transmitting node in the multi-hop communication. Note that the compression rules for the case where the wireless communication device 10 is a receiving node in multi-hop communication are shared with other wireless communication devices 10 that are transmitting nodes in the multi-hop communication.

[0029] In other words, the compression rule management unit 11 manages all compression rules when the wireless communication device 10 is a transmitting / receiving node. Note that the compression rules managed by the compression rule management unit 11 are assigned identification information (hereinafter, referred to as a compression rule ID) by the provisioner for identifying the compression rule (i.e., a combination of transmitting / receiving nodes and a type of application).

[0030] The transmission / reception unit 12 transmits and receives packets. Specifically, when the wireless communication device 10 operates as a transmitting node, the transmission / reception unit 12 transmits packets to other wireless communication devices. Also, when the wireless communication device 10 operates as a receiving node or a relay node, the transmission / reception unit 12 receives packets transmitted from other wireless communication devices.

[0031] The application management unit 13 has a function of managing application data. In this embodiment, the application data is data (data to be transmitted) generated based on an application applied to the wireless communication device 10, and corresponds to the payload included in a packet transmitted and received in the wireless multi-hop network as described above.

[0032] The application processing unit 14 executes various processes on the application data. The application processing unit 14 holds the Application Key distributed in the above-mentioned provisioning. The application processing unit 14 includes a compression processing unit 14a and an encryption processing unit 14b.

[0033] The compression processing unit 14a compresses application data when transmitting a packet by applying compression rules managed by the compression rule management unit 11. In addition, the compression processing unit 14a expands application data when receiving a packet by referring to the compression rules managed by the compression rule management unit 11.

[0034] The cryptographic processing unit 14b encrypts application data when transmitting a packet, using the Application Key held in the application processing unit 14. The cryptographic processing unit 14b decrypts application data when receiving a packet, using the Application Key held in the application processing unit 14.

[0035] The network management unit 15 has a function of managing communications (packet transmission) via the wireless multi-hop network. The network management unit 15 executes, for example, a process of generating a header included in a packet.

[0036] The network processor 16 executes various processes on the header included in the packet. The network processor 16 holds the Network Key distributed in the above-mentioned provisioning. The network processor 16 includes a compression processor 16a and an encryption processor 16b.

[0037] In this embodiment, a packet transmitted and received via the wireless multi-hop network includes a network header and network data corresponding to a network payload. The network header is a header that is added or referenced in processing at the network layer.

[0038] The network data includes application data corresponding to a transport header and a transport payload. The transport header is a header that is added or referenced in the process of the transport layer.

[0039] Compression processing unit 16a compresses a network header or a transport header when transmitting a packet by applying compression rules managed by compression rule management unit 11. Compression processing unit 16a also expands a network header or a transport header when receiving a packet by referring to compression rules managed by compression rule management unit 11.

[0040] The encryption / decryption processing unit 16b encrypts the network header and network data when transmitting a packet, using the network key held in the network processing unit 16. The encryption / decryption processing unit 16b decrypts the network header and network data when receiving a packet, using the network key held in the network processing unit 16.

[0041] Also, while the functional configuration of the wireless communication device 10 operating mainly as a transmitting / receiving node has been described in Fig. 3, for example, a wireless communication device 10 operating as a relay node may omit some of the functional configuration shown in Fig. 3. Specifically, the wireless communication device 10 operating as a relay node may have a functional configuration in which the application management unit 13 and the application processing unit 14 are omitted from the units 11 to 16 shown in Fig. 3.

[0042] Fig. 4 shows an example of a hardware configuration of the wireless communication device 10 shown in Fig. 3. As shown in Fig. 4, the wireless communication device 10 includes a CPU 101, a non-volatile memory 102, a main memory 103, a communication device 104, and the like.

[0043] The CPU 101 is a processor that controls the operation of each component in the wireless communication device 10. The CPU 101 executes various programs loaded from a non-volatile memory 102, which is a storage device, to a main memory 103. The communication device 104 is configured to perform at least the above-mentioned wireless communication based on BLE.

[0044] Although omitted in FIG. 4, when the wireless communication device 10 is realized by a smartphone, the wireless communication device 10 may further include a touch screen display in which an input device and a display device are integrated.

[0045] In addition, in this embodiment, some or all of the units 11 to 16 shown in FIG. 3 may be realized by causing the CPU 101 shown in FIG. 4 to execute a predetermined program, that is, by software, or by hardware such as an IC (Integrated Circuit), or by a configuration that combines software and hardware.

[0046] Hereinafter, an operation of the wireless communication device 10 according to the present embodiment when performing application data communication (i.e., transmitting and receiving application data) will be described. Here, a process when transmitting application data to another wireless communication device 10 via the wireless multi-hop network (hereinafter, referred to as application data transmission process) and a process when receiving application data transmitted from the other wireless communication device 10 (hereinafter, referred to as application data reception process) will be described.

[0047] An example of a procedure for application data transmission processing will be described with reference to the flowchart of Fig. 5. Note that the application data transmission processing is executed by the wireless communication device 10 operating as a transmitting node in multi-hop communication.

[0048] First, the application management unit 13 generates application data based on an application to be applied to the wireless communication device 10 (step S1). Note that the application data may be data acquired from a sensor or the like connected to the wireless communication device 10.

[0049] Next, the compression processing unit 14a included in the application processing unit 14 compresses the application data generated in step S1 (step S2).

[0050] As described above, the compression rule management unit 11 manages the compression rule for each receiving node (i.e., destination of application data) in multi-hop communication, and the compression of the application data in step S2 is performed by applying the compression rule corresponding to the destination of the application data generated in step S1 to the application data. Specifically, in step S2, for example, the compression rule is compared with the application data, and if there is a compressible portion in the application data, a process is executed to compress the application data. Note that depending on the compression rule and the application data, the application data may not be compressed.

[0051] After the process of step S2 is executed, the encryption processing unit 14b encrypts the application data compressed in step S2 (step S3). The encryption of the application data in step S3 is performed using an Application Key held in the application processing unit 14.

[0052] Next, network management unit 15 executes a process of the transport layer to generate a transport header (step S4). Note that the transport header generated in step S4 is, for example, one byte and is composed of a plurality of fields.

[0053] Furthermore, the network management unit 15 executes network layer processing to generate a network header (step S5). Note that the network header generated in step S5 is composed of a plurality of fields, similar to the above-mentioned transport header.

[0054] In the above-mentioned flooding communication, a packet is forwarded to all nodes within a communication range. In this case, in order to avoid the packet being forwarded forever in the wireless multi-hop network and to realize appropriate communication in the wireless multi-hop network, the number of times the packet can be forwarded is managed using TTL (Time To Live). According to this, for example, if the TTL is "1" or more, the packet is forwarded to another node by subtracting "1", and if the TTL is "0", the packet is discarded without being forwarded.

[0055] The multiple fields that make up the network header described above include a field in which the address of the wireless communication device 10, which is the transmitting node, and the address of another wireless communication device 10, which is the receiving node, are set, as well as a field in which the TTL is set (hereinafter referred to as the TTL field).

[0056] Next, the compression processor 16a included in the network processor 16 compresses the transport header generated in step S4 and the network header generated in step S5 (step S6). The header compression in step S6 is performed by applying a compression rule corresponding to the destination of the application data to the header. Specifically, in step S6, the compression rule is compared with each header, and if there is a compressible portion in the header, a process is performed to compress the header.

[0057] In addition, since it is possible to compress application data by applying the compression rules as described above, the compression rules can be said to include rules for compressing application data and rules for compressing headers (transport headers and network headers).

[0058] When the process of step S6 is executed, the crypto-processing unit 16b encrypts the network header and network data (network payload) compressed in step S6 (step S7).

[0059] As described above, the encryption of the network header and network data in step S7 is performed using the Network Key held in the network processing unit 16, but the network header may also be encrypted using a technique known as obfuscation.

[0060] The network data encrypted in step S7 includes the transport header compressed in step S6 and the application data (transport payload) encrypted in step S3. That is, in this embodiment, two-stage encryption is performed on the application data, the network header, and the network data.

[0061] Next, the compression processing unit 16a obtains the compression rule ID assigned to the compression rule applied to compress the header in the above-mentioned step S6 (the compression rule applied to compress the application data in step S2) from the compression rule management unit 11. The network processing unit 16 assigns the compression rule ID obtained by the compression processing unit 16a to the network header and network data encrypted in the above-mentioned step S7 (step S8).

[0062] When the process of step S8 is executed, the network management unit 15 generates a packet including the network header to which the compression rule ID has been added in step S8 and the network data (step S9).

[0063] The packet generated in step S9 is transmitted from the transceiver 12 to other wireless communication devices 10 via the wireless multi-hop network (step S10). According to the above-mentioned flooding communication, the packet transmitted in step S10 is received by all wireless communication devices 10 located within a range in which the wireless communication device 10 can communicate with the wireless communication device 10.

[0064] Here, in this embodiment, since the network header is also included in the encryption target, it is preferable to perform compression when all data can be referenced (i.e., all data is available), that is, before encrypting the network header and network data (network payload). However, in Bluetooth Mesh, the application data is encrypted in advance and then the transport header and network header are generated, so that the application data has already been encrypted when the network header and network data are encrypted, and it is difficult to compress the application data at this timing.

[0065] For this reason, in this embodiment, compression is divided into two stages similar to the above-mentioned two-stage encryption, and compression is performed immediately before each encryption. Specifically, application data is compressed immediately before the encryption of the application data in step S3 shown in Fig. 5, and the network header and the transport header included in the network data are compressed immediately before the encryption of the network header and the network data in step S7. With this configuration, it is possible to appropriately compress application data and headers even in Bluetooth Mesh.

[0066] An outline of header compression in this embodiment will be described below. In this embodiment, when the values ​​set in the fields constituting the header (network header and transport header) are commonly recognized between, for example, a wireless communication device 10 which is a transmitting node and another wireless communication device 10 which is a receiving node, it is considered that the fields can be omitted in the packet. In other words, header compression in this embodiment means omitting at least a part of the multiple fields constituting each of the network header and transport header described above.

[0067] Here, Fig. 6 conceptually illustrates header compression in this embodiment. The upper part of Fig. 6 illustrates the network header, transport header, and application data before compression. As shown in the upper part of Fig. 6, the network header is composed of multiple fields including, for example, a TTL field. Similarly, the transport header is also composed of multiple fields.

[0068] When the network header and transport header shown in the upper part of Figure 6 are compressed, for example by omitting at least one of the multiple fields that make up the network header and at least one of the multiple fields that make up the transport header, the network header and the transport header are compressed and the size that the headers occupy in the packet is reduced.

[0069] The lower part of Fig. 6 shows the network header, transport header, and application data after compression. In the example shown in the lower part of Fig. 6, multiple fields other than the TTL field constituting the network header are omitted, and all fields constituting the transport header (i.e., the transport header itself) are omitted.

[0070] By compressing the network header and the transport header in this way, even if a compression rule ID is assigned as described above, it is possible to expand the size that application data occupies in a packet (that is, the payload size).

[0071] In addition, in the compression of a network header, at least one of the multiple fields constituting the network header is omitted, but the number of fields omitted depends on the compression rules described above. However, the TTL field constituting the network header as described above is not omitted.

[0072] Although the header compression has been described here, the above-mentioned application data compression is performed from a similar perspective. In other words, if a part of the application data is commonly recognized between the wireless communication device 10 that is the transmitting node and another wireless communication device 10 that is the receiving node, the application data can be compressed by omitting a part of the application data.

[0073] Next, an example of a procedure of application data reception processing will be described with reference to the flowchart of Fig. 7. Note that the application data reception processing is executed by the wireless communication device 10 operating as a receiving node or a relay node in multi-hop communication.

[0074] First, the transmitting / receiving unit 12 receives a packet transmitted or forwarded from another wireless communication device 10 via the wireless multi-hop network (step S11). The packet received in step S1 is the same as the packet transmitted in step S10 shown in Fig. 5, and has a structure in which a compression rule ID is added to an encrypted (or obfuscated) network header and encrypted network data.

[0075] Next, the compression processing unit 16a included in the network processing unit 16 obtains a compression rule ID from the packet received in step S11, and uses the compression rule ID to make an inquiry to the compression rule management unit 11. As a result, the compression processing unit 16a determines whether or not the compression rule to which the compression rule ID obtained from the packet is assigned (hereinafter referred to as the target compression rule) is managed (held) in the compression rule management unit 11 (step S12).

[0076] In this embodiment, the compression rule management unit 11 manages compression rules when the wireless communication device 10 is a transmitting node and compression rules when the wireless communication device 10 is a receiving node. For this reason, the fact that a target compression rule is managed by the compression rule management unit 11 in application data reception processing (i.e., when a packet is received) means that the wireless communication device 10 is a receiving node.

[0077] That is, if it is determined that the target compression rule is managed by the compression rule management unit 11 (YES in step S12), the wireless communication device 10 operates as a receiving node. In this case, the encryption processing unit 16b extracts the network header and network data from the packet received in step S11.

[0078] Here, the network header and network data extracted from the packet are encrypted using the Network Key as described in the above application data transmission process. Therefore, the encryption processing unit 16b decrypts the network header and network data extracted from the packet using the Network Key held in the network processing unit 16 (step S13). The network data decrypted in step S13 includes a transport header and encrypted application data.

[0079] When the process of step S13 is executed, the compression processing unit 16a acquires the above-mentioned target compression rule from the compression rule management unit 11. The compression processing unit 16a expands the network header decoded in step S13 and the transport header included in the decoded network data by referring to the acquired target compression rule (step S14). Note that in step S14, a process is executed to restore the fields omitted in the header compression in the above-mentioned application data transmission process.

[0080] Here, the application data included in the network data decrypted in step S13 as described above is encrypted using the Application Key as described in the application data transmission process above. Therefore, the encryption processing unit 14b included in the application processing unit 14 decrypts the application data included in the network data using the Application Key held in the application processing unit 14 (step S15).

[0081] Note that the application processing unit 14 may hold multiple Application Keys, and the Application Key used in the processing of step S15 can be identified, for example, based on the header expanded in step S14 (the value set in a specific field constituting the header).

[0082] 7, even if the wireless communication device 10 participates in a wireless multi-hop network (i.e., holds a Network Key), if the wireless communication device 10 does not hold an Application Key, the wireless communication device 10 cannot receive application data. Therefore, if the wireless communication device 10 (application processing unit 14) does not hold an Application Key, the process of step S15 is not executed, and the application data reception process is terminated. Note that if the wireless communication device 10 (application processing unit 14) does not hold an Application Key, the wireless communication device 10 may execute a process as a relay node, which will be described later.

[0083] When the process of step S15 is executed, the compression processing unit 14a acquires the above-mentioned target compression rule from the compression rule management unit 11. The compression processing unit 14a expands the application data decrypted in step S15 by referring to the acquired target compression rule (step S16). Note that in step S16, a process is executed to restore a part of the application data that was omitted in the compression of the application data in the above-mentioned application data transmission process.

[0084] Next, the application management unit 13 acquires the application data expanded in step S16 (step S17).

[0085] As described above, when the wireless communication device 10 operates as a receiving node, the process of steps S13 to S17 is performed, whereby application data can be extracted from the received packet.

[0086] It is assumed here that the application data is compressed in the application data transmission process. However, if the application data is not compressed, the process of step S16 may be omitted.

[0087] On the other hand, if it is determined that the target compression rule is not managed by the compression rule management unit 11 (NO in step S12), the wireless communication device 10 operates as a relay node. In this case, the encryption processing unit 16b extracts the network header from the packet received in step S11.

[0088] As described above, since the network header extracted from the packet is encrypted using the Network Key, the encryption processing unit 16b decrypts the network header using the Network Key held in the network processing unit 16 (step S18).

[0089] Although not shown in FIG. 7, if the wireless communication device 10 has not joined a wireless multi-hop network, for example, and the wireless communication device 10 (network processing unit 16) does not hold a Network Key, the process of step S18 is not executed, and the application data reception process is terminated.

[0090] Next, the network management unit 15 updates the value (i.e., the TTL) set in the TTL field constituting the network header decrypted in step S18 (step S19). Specifically, in step S19, the TTL is updated by subtracting "1" from the TTL.

[0091] After the process of step S19 is executed, the encryption processing unit 16b re-encrypts the network header using the network key held in the network processing unit 16 (step S20).

[0092] When the process of step S20 is executed, the network management unit 15 generates a packet in which the network header contained in the packet received in step S11 is the network header encrypted in step S20 (step S21).

[0093] The packet generated in step S21 is transferred (transmitted) from the transceiver 12 to other wireless communication devices 10 via the wireless multi-hop network (step S22). According to the above-mentioned flooding communication, the packet transferred in step S22 is received by all wireless communication devices 10 located within a range in which the wireless communication device 10 can communicate with the wireless communication device 10.

[0094] As described above, when the wireless communication device 10 operates as a relay node, the processes of steps S18 to S22 are executed, whereby the TTL can be appropriately updated and packets can be forwarded.

[0095] Although the case where the packet is forwarded has been described above, if the TTL is "0" as described above, the packet is discarded without being forwarded.

[0096] Generally, as described above, a network header included in a packet received via a wireless multi-hop network has a field (hereinafter, referred to as a destination address field) in which the address of the node to which the packet is to be sent (i.e., the receiving node) is set. Therefore, the wireless communication device 10 that receives the packet can determine whether the wireless communication device 10 is a receiving node or a relay node by referring to the destination address field.

[0097] However, in order to refer to the destination address field, it is necessary to decrypt the encrypted network header using the network key.

[0098] In addition, in this embodiment, the destination address field may be omitted by compressing the network header. In this case, the destination address field cannot be referenced unless the network header is expanded.

[0099] Considering that a large number of packets are transmitted and received in flooding communication, decoding and expanding the above-mentioned network header every time a packet is received by the wireless communication device 10 may hinder smooth multi-hop communication.

[0100] Furthermore, in order to decompress network headers contained in all packets received by the wireless communication device 10, the wireless communication device 10 (compression rule management unit 11) needs to manage (hold) all compression rules prepared in the wireless multi-hop network. This configuration puts a strain on the memory area for managing the compression rules and increases the processing time for provisioning to distribute the compression rules.

[0101] For this reason, the wireless communication device 10 according to the present embodiment employs a configuration for managing compression rules when the wireless communication device 10 is a transmitting / receiving node. With this configuration, the wireless communication device 10 can determine whether the wireless communication device 10 is a receiving node or a relay node by comparing a compression rule ID assigned in another wireless communication device 10 (transmitting node) with a compression rule ID assigned to a compression rule managed in the wireless communication device 10 (compression rule management unit 11) without decoding and decompressing the network header.

[0102] In addition, this embodiment assumes a case where flooding communication is performed, in which the number of times a packet can be forwarded is managed using the TTL, but when the wireless communication device 10 is a relay node, it is necessary to update the TTL and forward the packet. However, in a configuration in which the wireless communication device 10 is configured to manage compression rules when the wireless communication device 10 is a transmitting / receiving node as described above, when the wireless communication device 10 is a relay node, it does not manage compression rules for expanding a network header included in a received packet. For this reason, in this embodiment, compression that omits the TTL field in which the TTL is set is not performed so that the relay node can properly update the TTL.

[0103] For example, the TTL set in the TTL field constituting the network header included in a packet received by the wireless communication device 10 varies depending on the initial value and the route (number of hops) of the packet until it reaches the wireless communication device 10, so the TTL cannot be set in advance between the transmitting and receiving nodes (i.e., the compression rule). That is, in this embodiment, it can be said that compression that omits the TTL field cannot be performed.

[0104] Incidentally, in the above-mentioned FIG. 7, it is assumed that there is one receiving node (destination), but if, for example, the addresses of multiple wireless communication devices 10 are set in the destination address field constituting the network header, a process of forwarding the packet (hereinafter referred to as packet forwarding process) may be further executed when the process shown in FIG. 7 is executed.

[0105] An example of the procedure of the above-mentioned packet forwarding process will be described below with reference to the flowchart in Fig. 8. Note that the process shown in Fig. 8 is assumed to be executed after the process of step S14, separately from the process of step S15 and subsequent steps shown in Fig. 7.

[0106] First, network management unit 15 refers to the destination address field among the multiple fields constituting the network header expanded in step S14 shown in Fig. 7, and determines whether or not it is necessary to forward the packet (step S31). In step S31, if the address set in the destination address field is, for example, a broadcast address or a group address in which multiple addresses are specified (i.e., there is a receiving node other than wireless communication device 10), it is determined that it is necessary to forward the packet. On the other hand, in step S31, if the address set in the destination address field is only the address of wireless communication device 10, it is determined that it is not necessary to forward the packet.

[0107] If it is determined that the packet needs to be forwarded (YES in step S31), the network management unit 15 updates the value (i.e., TTL) set in the TTL field among the multiple fields that make up the network header (step S32). Note that the process of step S32 corresponds to the process of step S19 shown in FIG. 7.

[0108] When the process of step S32 is executed, the compression processor 16a included in the network processor 16 compresses the network header reflecting the TTL updated in step S32 and the transport header expanded in step S14 shown in Fig. 7 (step S33). Note that the process of step S33 is similar to the process of step S6 shown in Fig. 5, and therefore a detailed description thereof will be omitted here. Note that the compression in step S33 is performed by applying the above-mentioned target compression rule to the network header and the transport header.

[0109] Next, the encryption processing unit 16b encrypts the network header and network data compressed in step S33 (step S34). Note that the process of step S34 is similar to the process of step S7 shown in FIG. 5, and therefore a detailed description thereof will be omitted here.

[0110] When the process of step S34 is executed, the network processor 16 assigns the compression rule ID assigned to the target compression rule to the network header and network data encrypted in step S34 (step S35).

[0111] When the process of step S35 is executed, the network management unit 15 generates a packet including the network header to which the compression rule ID has been added in step S35 and the network data (step S36).

[0112] The packet generated in step S36 is transferred (transmitted) from the transceiver unit 12 to another wireless communication device 10 via the wireless multi-hop network (step S37).

[0113] On the other hand, if it is determined in step S31 that there is no need to forward the packet (NO in step S31), the packet forwarding process is terminated.

[0114] According to the packet forwarding process shown in FIG. 8, the wireless communication device 10 is able to further forward the packet to another wireless communication device 10 at the stage where it acquires network header information from the packet in the application data reception process shown in FIG.

[0115] As described above, the wireless communication device 10 (transmitting node) of this embodiment manages the compression rule (first compression rule) when the wireless communication device 10 is a transmitting node in multi-hop communication, compresses the transport header included in the network header or network data by applying the compression rule, encrypts the network header and network data after the compression, and transmits a packet including the encrypted network header and the encrypted network data.

[0116] In addition, the wireless communication device 10 (receiving node) of this embodiment manages a compression rule (second compression rule) when the wireless communication device 10 is a receiving node in multi-hop communication, receives a packet transmitted from another wireless communication device 10 and including a network header and network data encrypted in the other wireless communication device 10, decrypts the encrypted network header and the encrypted network data, and expands the decrypted network header or a transport header included in the decrypted network data by referring to the compression rule.

[0117] In this embodiment, the compression rule is shared between the wireless communication devices 10 that are transmitting and receiving nodes. Specifically, this sharing of the compression rule can be realized by distributing the compression rule to the wireless communication devices 10 that are transmitting and receiving nodes at the time of provisioning when the wireless communication device 10 that is a transmitting node or a receiving node joins the wireless multi-hop network. In this embodiment, such a configuration makes it possible to appropriately expand the network header or transport header compressed in the wireless communication device 10 that is a transmitting node in the wireless communication device 10 that is a receiving node.

[0118] In this embodiment, by compressing the network header or transport header as described above, the data area occupied by the header in the packet can be reduced, and therefore the data area (i.e., payload size) allocated to application data in the packet can be expanded. In other words, in this embodiment, the amount of application data that can be transmitted in one packet can be increased, so that the number of packets transmitted and received via the wireless multi-hop network can be reduced, and efficient communication can be realized.

[0119] In addition, the network header and network data included in the packet transmitted from the wireless communication device 10 according to this embodiment are assigned a compression rule ID for identifying the compression rule that was applied when the network header or the transport header included in the network header was compressed.

[0120] A wireless communication device 10 that receives a packet decodes the network header and network data if the compression rule identified by the compression rule ID given to the network header and network data included in the packet is managed by the wireless communication device 10. On the other hand, a wireless communication device 10 that receives a packet transfers (transmits) the packet to another wireless communication device 10 if the compression rule identified by the compression rule ID given to the network header and network data included in the packet is not managed by the wireless communication device 10.

[0121] With this configuration, a wireless communication device 10 that receives a packet can determine that the wireless communication device 10 is a receiving node or a relay node and can operate appropriately as the receiving node or relay node without decoding and expanding the network header contained in the packet (i.e., without referencing the destination address field).

[0122] According to the configuration of the present embodiment described above, for example, by compressing and expanding the header according to a compression rule suitable for Bluetooth Mesh (packet format), the payload size can be expanded in a format that can coexist with the security function (usage) of the Bluetooth Mesh.

[0123] In this embodiment, the payload size (data area allocated to application data in a packet) may be expanded by compressing the network header or transport header, but the application data may be compressed by applying the compression rule described above when the packet is transmitted. With this configuration, the amount of application data that can be transmitted in one packet can be increased, thereby achieving more efficient communication.

[0124] In addition, in the present embodiment, the compression rule is distributed at the time of provisioning when the wireless communication device 10 joins the wireless multi-hop network (i.e., the compression rule is shared at the time of provisioning), but the compression rule may be distributed (shared) at a time other than provisioning. Specifically, the compression rule may be hard-coded in advance, for example, at the time of manufacturing the wireless communication device 10 according to the application to be applied. Furthermore, the compression rule may be shared between the wireless communication devices 10 that are the transmitting node and the receiving node when performing application data communication. In this case, the compression rule may be created (prepared) in the wireless communication device 10 that is the transmitting node and transmitted (distributed) to the wireless communication device 10 that is the receiving node, or may be created (prepared) in the wireless communication device 10 that is the receiving node and transmitted (distributed) to the wireless communication device 10 that is the transmitting node.

[0125] In addition, in this embodiment, a wireless multi-hop network formed by Bluetooth Mesh has been described, but the wireless communication device 10 of this embodiment may be applied to a wireless multi-hop network formed by a communication technology that transmits and receives packets by performing two-stage encryption, such as encrypting application data and encrypting a network header and network data.

[0126] Second embodiment Next, a second embodiment will be described below. In this embodiment, a specific example of the compression rule explained in the first embodiment will be explained.

[0127] Fig. 9 shows an example of a compression rule in this embodiment. In the example shown in Fig. 9, a compression rule based on Static Context Header Compression (SCHC) is shown.

[0128] SCHC is an IP header compression standard standardized by RFC. In SCHC, a table that describes how to compress / decompress is shared as a compression rule between sending and receiving nodes. SCHC is primarily intended for use with IP headers, and is not intended to compress headers in packets (Bluetooth packets) sent and received in wireless multi-hop networks formed by Bluetooth Mesh.

[0129] For this reason, in this embodiment, a description will be given of compression rules (rule table) that are applicable to Bluetooth Mesh (Bluetooth packets) based on the above-mentioned SCHC.

[0130] 9, the compression rule in this embodiment includes field length, Target Value (hereinafter referred to as TV), Match Operation (hereinafter referred to as MO), and Compression / Decompression Actions (hereinafter referred to as CDA) in association with each of the fields constituting the network header, transport header, etc., contained in the packet. Note that TV, MO, and CDA are terms used in SCHC.

[0131] The field length indicates the length of the value set in the associated field (i.e., the field size), and is expressed in bits, for example. The TV indicates a candidate value (candidate value of the field) set in the associated field. The MO indicates the relationship between the associated TV and the value set in the field, and corresponds to, for example, a criterion for determining whether or not to apply CDA. The CDA indicates the compression / decompression method for the associated field.

[0132] 9, the fields include IVI, NIC, CTL, TTL, Seq, Src Addr, Dst Addr, SEG, AKF, AID, OpCode, Param, Net MIC, and Trans MIC. Note that the IVI field, NIC field, CTL field, TTL field, Seq field, Src Addr field, and Dst Addr field constitute a network header, and the SEF field, AKF field, and AID field constitute a transport header.

[0133] A value related to the Network Key is set in the IVI field, and this value is unique as long as communication is performed within the same network. For this reason, the IVI field can be omitted by sharing the value set in the field in the compression rule. In this case, TV "0", MO "equal", and CDA "not-sent" are associated with the IVI field in the compression rule shown in Figure 9. This indicates that if the value set in the IVI field matches "0", the IVI field is omitted.

[0134] Like the IVI field, the NIC field is set with a value related to the Network Key, and this value is unique as long as communication is performed within the same network. However, a specific value (fixed value) is set in the NIC field according to the network configuration. For this reason, in the compression rule shown in FIG. 9, the NIC field is associated with TV "X1", MO "equal", and CDA "not-sent". This indicates that if the value set in the NIC field matches the specific value "X1", the NIC field is omitted.

[0135] The value set in the CTL field differs depending on whether the payload included in the packet is application data or control data for maintaining the network. In this embodiment, it is assumed that application data communication is performed, and the payload included in the packet is application data. In this case, the value set in the CTL field is assumed to be 0. For this reason, in the compression rule shown in FIG. 9, TV "0", MO "equal", and CDA "not-sent" are associated with the CTL field. This indicates that when the value set in the CTL field matches the specific value "0", the CTL field is omitted.

[0136] As described above, the TTL field is set with a value (i.e., the possible number of transfers) that is updated according to the number of transfers (i.e., for each hop), so it is not possible to determine the value in advance between the sending and receiving nodes (i.e., to predict the value and write it in the compression rule). For this reason, the compression rule shown in FIG. 9 does not state a TV that corresponds to the TTL field. Also, in the compression rule shown in FIG. 9, the MO "ignore" and CDA "value-sent" are associated with the TTL field. This indicates that the TTL field will not be omitted (i.e., will not be compressed) without comparing the value set in the TTL field with the TV.

[0137] A sequence number is set in the Seq field, and the value of the sequence number is different for each packet. For this reason, it is difficult to specify the value set in the Seq field (i.e., to write it in the TV). However, the field size (field length) of the Seq field is 24 bits. In this case, it can be said that it is possible to partially omit the leftmost few bits of the value set in the Seq field, assuming that the value does not change frequently. In this case, in the compression rule shown in FIG. 9, the Seq field is associated with TV "0x00", MO "equal", and CDA "LSB (Least Significant Bit)". According to this, it is indicated that when the leftmost byte of the value set in the Seq field matches a specific value, "0x00", the leftmost byte is omitted (i.e., the LSB excluding the byte is transmitted).

[0138] The address of the wireless communication device 10, which is a transmitting node, is set in the Src Addr field. The address of the wireless communication device 10, which is a receiving node, is set in the Dst Addr field. In this embodiment, as described in the first embodiment, the transmitting and receiving nodes in the compression rule are uniquely determined by distributing the compression rule for each combination of transmitting and receiving nodes. For this reason, the Src Addr field in the compression rule shown in FIG. 9 is associated with TV "X2", MO "equal", and CDA "not-sent". This indicates that the Src Addr field is omitted when the value set in the Src Addr field matches the uniquely determined address of the transmitting node "X2". Similarly, the Dst Addr field in the compression rule shown in FIG. 9 is associated with TV "X3", MO "equal", and CDA "not-sent". This indicates that the Dst Addr field is omitted when the value set in the Src Addr field matches the uniquely determined address of the receiving node "X3". In other words, if the addresses of the sending and receiving nodes are fixed addresses, the Src Addr field and the Dst Addr field can be compressed to be completely eliminated.

[0139] As described above, the transport header is made up of a SEG field, an AKF field, and an AID field, and the total field size of the SEG field, the AKF field, and the AID field is 1 byte.

[0140] The SEG field is set with a value indicating whether or not segmentation, in which application data is divided into multiple packets for transmission, will occur. The value set in the SEG field may be predicted by estimating the size of application data according to the application applied to the transmitting and receiving nodes. The compression rule shown in FIG. 9 assumes that no segmentation will occur, and TV "0", MO "equal", and CDA "not-sent" are associated with the SEG field. This indicates that if the value set in the SEG field matches a specific value "0", the SEG field will be omitted. If segmentation occurs, another field will be added to manage the segmentation.

[0141] In the AKF field and the AID field, values ​​related to the Application Key are set. When the Application Key is used, 1 is always set in the AKF field, and an ID determined by an application applied to the transmitting and receiving nodes is set in the AID field. Therefore, if the application applied to the transmitting and receiving nodes is the same, the values ​​set in the AKF field and the AID field can be shared in advance between the transmitting and receiving nodes. In this case, in the compression rule shown in FIG. 9, the AKF field is associated with TV "1", MO "ignore", and CDA "not-sent". This indicates that the AKF field is omitted without comparing the value set in the AKF field with the TV. In addition, in the compression rule shown in FIG. 9, the AID field is associated with TV "X4", MO "equal", and CDA "not-sent". This indicates that the AID field is omitted when the value set in the AID field matches the ID "X4" determined by the application.

[0142] In addition, the OpCode field and the Param field in the compression rule correspond to application data (i.e., payload included in a packet). For example, when the application data includes a predetermined value, the value (i.e., a part of the application data) can be omitted (compressed) by SCHC. Specifically, for example, in Bluetooth Mesh, an OpCode field is added to the beginning of the application data, and the type of application applied to the transmitting / receiving node (a value indicating the type) is set in the OpCode field. In other words, when the types of applications applied to the transmitting / receiving node are limited, a specific value (fixed value) is set in the OpCode field. In this case, TV "X5", MO "equal", and CDA "not-sent" are associated with the OpCode field in the compression rule shown in FIG. 9. According to this, it is shown that when the value set in the OpCode field matches the specific value "X5", the OpCode field is omitted.

[0143] On the other hand, the application data itself is set in the Param field. In the compression rule shown in FIG. 9, TV "-", MO "ignore", and CDA "value-sent" are associated with the Param field. This indicates that the Param field is not omitted (i.e., is not compressed) without comparing the value set in the Param field with the TV. Note that, when only a specific value is set in the Param field, the Param field may be omitted (compressed) by SCHC. Furthermore, for example, as described in the Seq field, it is also possible to configure the Param field so that only a part of the value (application data itself) set in the Param field is omitted.

[0144] Since a different value (e.g., a hash value for error correction) is set in the Net MIC (Network MIC) field and the Trans MIC (Transport MIC) field for each application data, it is not possible to predetermine the value between the transmitting and receiving nodes (to predict the value and write it in the compression rule). For this reason, TV "-", MO "ignore", and CDA "value-sent" are associated with the Net MIC field and the Trans MIC field in the compression rule shown in Fig. 9. This indicates that the Net MIC field and the Trans MIC field are not omitted (i.e., are not subject to compression) without comparing the values ​​set in the Net MIC field and the Trans MIC field with the TV.

[0145] When the compression rule shown in Fig. 9 is applied, the wireless communication device 10, which is the transmitting node, can compress the network header so as to omit the IVI field, NIC field, CTL field, part of the Seq field, Src Addr field, and Dst Addr field that constitute the network header, and can compress the transport header so as to omit the SEG field, AKF field, and AID field that constitute the transport header. Furthermore, when the compression rule shown in Fig. 9 is applied, the OpCode field can be further omitted (compressed).

[0146] In this case, the wireless communication device 10, which is the receiving node, can restore each field compressed as described above (i.e., expand the header) by referring to the compression rules shown in Fig. 9. Specifically, for example, the IVI field can be restored by setting "0" in a field with a field length of 1 bit, and the NIC field can be restored by setting "X1" in a field with a field length of 7 bits. By similarly restoring other fields omitted in compression, the network header, transport header, etc. before compression can be obtained.

[0147] The compression rule described in this embodiment is applied when all of the fields described in the compression rule as being omissible (that is, in the example shown in FIG. 9, the IVI field, NIC field, CTL field, Seq field, Src Addr field, Dst Addr field, SEG field, AKF field, AID field, and OpCode field to be compressed) can be omitted. Specifically, even if an omissible field other than the NIC field described in the compression rule (for example, the IVI field, etc.) can be omitted, for example, if the value set in the NIC field does not match the fixed value "X1", the compression rule is not applied (that is, compression is not performed). Since it is considered that the process becomes complicated when the network header and the transport header, etc. compressed by applying only a part of the compression rule are expanded, in this embodiment, a configuration is adopted in which the compression rule is applied when all of the fields to be compressed can be omitted as described above, so that the compressed network header and the transport header, etc. can be appropriately expanded.

[0148] As described above, in this embodiment, the compression rule includes, for example, a candidate value (TV) of a field constituting a network header or a transport header, and when the candidate value of the field matches a value set in the field constituting the network header and the transport header, the network header and the transport header are compressed by omitting the field. In this embodiment, with such a configuration, it is possible to realize compression of the network header, the transport header, etc. based on a compression rule applicable to Bluetooth Mesh (Bluetooth packet) based on SCHC as shown in Fig. 9.

[0149] In this embodiment, as described above in the Seq field shown in Fig. 9, when a candidate value (TV) of a field included in the compression rule matches a part of a value set in a field constituting a header (network header or transport header), the header may be compressed by omitting a part of the value. With this configuration, it is possible to compress even a part of a field, thereby improving the compression efficiency.

[0150] According to at least one of the embodiments described above, it is possible to provide a wireless communication device and method capable of achieving efficient communication.

[0151] Although some embodiments of the present invention have been described, these embodiments are presented as examples and are not intended to limit the scope of the invention. These embodiments can be implemented in various other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their modifications are included in the scope of the invention and its equivalents described in the claims, as well as in the scope and spirit of the invention. [Explanation of symbols]

[0152] 10, 10-1, 10-6...wireless communication device, 11...compression rule management unit, 12...transmitter / receiver unit, 13...application management unit, 14...application processing unit, 14a...compression processing unit, 14b...encryption processing unit, 15...network management unit, 16...network processing unit, 16a...compression processing unit, 16b...encryption processing unit, 101...CPU, 102...non-volatile memory, 103...main memory, 104...communication device.

Claims

1. A wireless communication device that performs multi-hop communication via a wireless multi-hop network, a management means for managing a first compression rule when the wireless communication device is a transmitting node in the multi-hop communication; a first compression processing means for compressing a network header or a transport header included in the network data by applying the first compression rule; a first encryption processing means for encrypting the network header and the network data after the compression; a transmitting means for transmitting a packet including the encrypted network header and the encrypted network data; Equipped with The first compression rule is shared with another wireless communication device that is a receiving node in the multi-hop communication. Wireless communication device.

2. 2. The wireless communication device according to claim 1, wherein the network header and network data included in the packet are provided with compression rule identification information for identifying a first compression rule that was applied when the network header or the transport header was compressed.

3. the first compression rule includes candidate values ​​for fields constituting the network header or the transport header; The first compression processing means compresses the network header or the transport header by omitting a field when a candidate value for the field included in the first compression rule matches a value set in the field constituting the network header or the transport header.

2. The wireless communication device of claim 1.

4. 4. The wireless communication device according to claim 3, wherein the first compression processing means compresses the network header or the transport header by omitting part of a value when a candidate value of a field included in the first compression rule matches a part of a value set in a field constituting the network header or the transport header.

5. a second compression processing means for compressing data to be transmitted in the multi-hop communication by applying the first compression rule; a second encryption processing means for encrypting the compressed data; Equipped with The network data includes the transport header and the encrypted application data.

2. The wireless communication device of claim 1.

6. The wireless communication device according to claim 1 , wherein the first compression rule is distributed to the wireless communication device and the other wireless communication device at the time of provisioning when the wireless communication device or the other wireless communication device joins the wireless multi-hop network.

7. Further comprising receiving means, the management means manages a second compression rule when the wireless communication device is a receiving node in the multi-hop communication; The receiving means receives a packet transmitted from another wireless communication device, the packet including a network header encrypted in the other wireless communication device and network data encrypted in the other wireless communication device; The first cryptographic processing means decrypts a network header and network data included in the received packet, the decoded network header or a transport header included in the decoded network data is compressed by applying the second compression rule in the other wireless communication device; The first compression processing means expands the decoded network header or a transport header included in the decoded network data by referring to the second compression rule.

2. The wireless communication device of claim 1.

8. a network header and network data included in the received packet are provided with compression rule identification information for identifying a third compression rule that was applied when the network header or the transport header was compressed; The first encryption processing means decrypts the network header or the transport header when a third compression rule identified by the compression rule identification information is managed as the second compression rule.

8. The wireless communication device according to claim 7.

9. 9. The wireless communication device according to claim 8, wherein the transmitting means transfers the packet to another wireless communication device when a third compression rule identified by compression rule identification information included in the received packet is not managed as the second compression rule.

10. The wireless communication device of claim 7, wherein the second compression rule is distributed to the wireless communication device and the other wireless communication device that is a transmitting node in the multi-hop communication at the time of provisioning when the wireless communication device or the other wireless communication device that is a transmitting node in the multi-hop communication joins the wireless multi-hop network.

11. The wireless communication device according to any one of claims 1 to 10, wherein the network header or the transport header is compressed to expand a data area in the packet allocated to data to be transmitted in the multi-hop communication.

12. A method executed by a wireless communication device performing multi-hop communication through a wireless multi-hop network, comprising: managing a first compression rule when the wireless communication device is a transmitting node in the multihop communication; compressing a network header or a transport header included in the network data by applying the first compression rule; encrypting the network header and the network data after said compression; transmitting a packet including the encrypted network header and the encrypted network data; Equipped with The first compression rule is shared with another wireless communication device that is a receiving node in the multi-hop communication. method.

Images