Wireless communication device 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] Embodiments of the present invention relate to a wireless communication device and method.

Background Art

[0002] In recent years, it has been known to construct a wireless multi-hop network for applications such as sensing in a wide area and perform multi-hop communication. Note that multi-hop communication is a communication method in which a plurality of nodes (wireless communication devices) constituting a wireless multi-hop network transfer data (packets) in a bucket relay format to realize long-distance communication. Multi-hop communication has advantages in terms of the cost of constructing a network (the installation cost of each node) and scalability.

[0003] By the way, in the above-mentioned wireless multi-hop network, in multi-hop communication, the size of data that can be transmitted and received (that is, the data area allocated to the payload included in the packets transmitted and received in the wireless multi-hop network) may be small, and there is a possibility that efficient communication cannot be performed.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Non-Patent Documents

[0005]

Non-Patent Document 1

Non-Patent Document 2

[0006] Therefore, the problem that the present invention aims to solve is to provide a wireless communication device and method that can achieve efficient communication. [Means for solving the problem]

[0007] According to one embodiment, a wireless communication device is provided that performs multi-hop communication over a wireless multi-hop network. The wireless communication device comprises 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 network header or a transport header included in network data by applying the first compression rule. The first encryption processing means encrypts the network header and the network data after compression. The transmission means transmits a packet containing the encrypted network header and the encrypted network data. The first compression rule is shared with other wireless communication devices that are receiving nodes in the multi-hop communication. 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, which includes a network header and encrypted network data encrypted by the other wireless communication device. The first cryptographic processing means decrypts the network header and network data contained in the received packet. The decrypted network header or the transport header contained in the decrypted network header or the decrypted network data is compressed by the other wireless communication device by applying the second compression rule. The first compression processing means decrypts the decrypted network header or the transport header contained in the decrypted network header or the decrypted network data by referring to the second compression rule. The network header and network data contained in the received packet are provided with compression rule identification information for identifying the second compression rule applied when the network header or the transport header was compressed. The first cryptographic processing means decrypts the network header or the transport header if the second compression rule identified by the compression rule identification information is managed. The transmitting means forwards the packet to another wireless communication device if the second compression rule identified by the compression rule identification information is not managed. [Brief explanation of the drawing]

[0008] [Figure 1] A diagram showing an example of a network configuration including a wireless communication device according to the first embodiment. [Figure 2] A diagram illustrating an example of a wireless multi-hop network application. [Figure 3] A diagram showing an example of the functional configuration of a wireless communication device. [Figure 4] A diagram showing an example of the hardware configuration of a wireless communication device. [Figure 5] A flowchart illustrating an example of the processing steps for application data transmission. [Figure 6] A diagram illustrating the header compression in this embodiment. [Figure 7] A flowchart illustrating an example of the processing procedure for receiving application data. [Figure 8] A flowchart illustrating an example of the processing steps for packet forwarding. [Figure 9] A diagram showing an example of a compression rule in the second embodiment. [Modes for carrying out the invention]

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

[0010] In this embodiment, short-range wireless communication includes wireless communication based on BLE (Bluetooth Low Energy®). In this case, wireless communication devices 10-1 to 10-6 are implemented 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 the 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 Figure 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, data transmitted from the wireless communication device 10-1 is relayed by the wireless communication devices 10-2 to 10-5, and the wireless communication device 10-6 receives the data relayed by the wireless communication devices 10-2 to 10-5, enabling multi-hop communication. According to this, for example, the wireless communication device 10-1 can realize communication (data transmission and reception) with the wireless communication device 10-6 beyond the communication range based on the BLE of the wireless communication device 10-1.

[0013] Note that 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 an elevator installed in a building, and the wireless communication device 10-1 shown in FIG. 2 corresponds to, for example, a smartphone held by a maintenance worker.

[0014] In this case, the wireless communication device 10-1 can communicate with, for example, the wireless communication device 10-6 (such as an elevator management device or an elevator control device) installed on the rooftop of the building via other wireless communication devices 10-2 to 10-5 arranged within the building.

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

[0016] In addition, the wireless communication devices 10-1 to 10-6 that constitute the wireless multi-hop network in this embodiment can each operate as a transmission node, a reception node, and a relay node. Specifically, for example, when the wireless communication device 10-4 operates as a transmission node and the wireless communication device 10-1 operates as a reception node, the other wireless communication devices 10-2, 10-3, 10-5, and 10-6 may operate as relay nodes. Further, at least one of the plurality of wireless communication devices 10-1 to 10-6 may be a wireless communication device that operates only as a relay node.

[0017] Note that the above-described Bluetooth Mesh realizes highly reliable multi-hop communication by flooding communication. In flooding communication, each node constituting the wireless multi-hop network operates to transfer data to all nodes within the range that can communicate with the node when performing multi-hop communication. In such flooding communication, since there is no need to select a specific path for multi-hop communication, network management is simple, and communication can be continued without major problems even if communication interruption occurs between some nodes in the network.

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

[0019] In this case, it might be considered to divide large data into multiple packets for transmission. However, in the flooding communication described above, packets are duplicated each time they pass through an intermediate node (forwarded to all surrounding nodes), so if data is divided into many packets for transmission, packets may overflow the wireless multi-hop network (increasing the network load). This could cause the wireless multi-hop network to collapse, making communication between the nodes constituting the wireless multi-hop network impossible and potentially preventing multi-hop communication (flooding communication) from being performed.

[0020] Therefore, in order to use Bluetooth Mesh for a variety of applications (services), it is necessary to expand the data area (payload size) allocated to the payload contained in the packet. In this case, since the overall size (maximum length) of the 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. contained in the packet (i.e., data area other than the payload) and allocate the reduced data area to the payload.

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

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

[0023] As shown in Figure 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] Here, when the wireless communication device 10 joins the 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 obtaining this authentication from the provisioner is called provisioning. In provisioning, two types of keys and compression rules are distributed (assigned) to the wireless communication device 10.

[0025] The two types of keys distributed during provisioning include a Network Key and an Application Key, which are used to encrypt and decrypt data. The Network Key is a key (information) based on a symmetric-key cryptographic scheme shared across the entire wireless multi-hop network. The Application Key is a key (information) based on a symmetric-key cryptographic scheme 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. Therefore, application data is encrypted with the Application Key, network information is added, and the entire package is then encrypted with the Network Key.

[0026] The compression rules distributed during provisioning are used to compress the header when sending packets and to decompress the header when receiving packets.

[0027] The compression rule management unit 11 manages (maintains) the compression rules described above. Specifically, the compression rule management unit 11 manages the compression rules for each receiving node in a multi-hop communication, for example, when the wireless communication device 10 is the transmitting node in the multi-hop communication. The compression rules for when this wireless communication device 10 is the transmitting node in the 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 compression rules for each transmitting node in a multi-hop communication, for example, when the wireless communication device 10 is a receiving node in the multi-hop communication. The compression rules for this wireless communication device 10 when it is a receiving node in the multi-hop communication are shared with other wireless communication devices 10 that are transmitting nodes in the same multi-hop communication.

[0029] In other words, the compression rule management unit 11 manages all compression rules when the wireless communication device 10 acts as a transmitting / receiving node. 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 to identify the compression rule (i.e., the combination of transmitting / receiving nodes and the type of application).

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

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

[0032] The application processing unit 14 performs various processes on the application data. The application processing unit 14 holds the Application Key distributed in the provisioning described above. 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 a packet is transmitted by applying compression rules managed by the compression rule management unit 11. Furthermore, the compression processing unit 14a decompresses application data when a packet is received by referring to the compression rules managed by the compression rule management unit 11.

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

[0035] The network management unit 15 has the function of managing communication (packet transmission) over a wireless multi-hop network. The network management unit 15 performs processes such as generating headers included in packets.

[0036] The network processing unit 16 performs various operations on the header included in the packet. The network processing unit 16 holds the Network Key distributed in the provisioning described above. The network processing unit 16 includes a compression processing unit 16a and an encryption processing unit 16b.

[0037] In this embodiment, packets transmitted and received via a wireless multi-hop network include network data corresponding to a network header and a network payload. The network header is a header that is added or referenced during network layer processing.

[0038] Furthermore, network data includes application data corresponding to the transport header and transport payload. The transport header is a header that is added or referenced during processing at the transport layer.

[0039] The compression processing unit 16a compresses the network header or transport header when a packet is transmitted by applying the compression rules managed by the compression rule management unit 11. Furthermore, the compression processing unit 16a decompresses the network header or transport header when a packet is received by referring to the compression rules managed by the compression rule management unit 11.

[0040] The encryption processing unit 16b encrypts the network header and network data when a packet is transmitted using the Network Key held in the network processing unit 16. The encryption processing unit 16b decrypts the network header and network data when a packet is received using the Network Key held in the network processing unit 16.

[0041] Furthermore, while Figure 3 primarily describes the functional configuration of a wireless communication device 10 operating as a transmitting / receiving node, a wireless communication device 10 operating as a relay node may omit some of the functional configurations shown in Figure 3. Specifically, a 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 parts 11 to 16 shown in Figure 3.

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

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

[0044] Although not shown in Figure 4, if the wireless communication device 10 is implemented by a smartphone, the wireless communication device 10 may further include a touchscreen display or the like, in which an input device and a display device are integrated.

[0045] Furthermore, in this embodiment, some or all of the parts 11 to 16 shown in Figure 3 may be implemented by having the CPU 101 shown in Figure 4 execute a predetermined program, i.e., by software; they may be implemented by hardware such as an IC (Integrated Circuit); or they may be implemented by a configuration combining software and hardware.

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

[0047] Referring to the flowchart in Figure 5, an example of the processing procedure for application data transmission will be explained. Note that the application data transmission process is performed by the wireless communication device 10, which operates as a transmitting node in multi-hop communication.

[0048] First, the application management unit 13 generates application data based on the application applied to the wireless communication device 10 (step S1). The application data may also be data acquired from sensors or other devices 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 compression rules for each receiving node (i.e., the destination of the application data) in multi-hop communication. 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 and the application data are compared, and if there is a part of the application data that can be compressed, 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 need to be compressed.

[0051] When the process in 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 the Application Key held by the application processing unit 14.

[0052] Next, the network management unit 15 generates a transport header by performing transport layer processing (step S4). The transport header generated in step S4 is, for example, one byte and consists of multiple fields.

[0053] Furthermore, the network management unit 15 generates a network header by performing network layer processing (step S5). The network header generated in step S5 consists of multiple fields, similar to the transport header described above.

[0054] In the flooding communication described above, packets are forwarded to all nodes within communication range. In this case, to avoid packets being continuously forwarded indefinitely within the wireless multi-hop network and to ensure proper communication within the wireless multi-hop network, the number of times a packet can be forwarded is managed using TTL (Time To Live). This allows for forwarding processes such as deducting 1 from the TTL if it is 1 or greater and forwarding the packet to another node, or discarding the packet without forwarding it if the TTL is 0.

[0055] The network header described above includes fields for setting the address of the transmitting node (wireless communication device 10) and the address of other receiving nodes (wireless communication devices 10), as well as a field for setting the TTL (hereinafter referred to as the TTL field).

[0056] Next, the compression processing unit 16a included in the network processing unit 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 the compression rules corresponding to the destination of the application data described above to the header. Specifically, in step S6, the compression rules are compared with each header, and if there are any parts of the header that can be compressed, processing is performed to compress the header.

[0057] Furthermore, as mentioned above, it is possible to compress application data by applying compression rules. Therefore, it can be said that these compression rules include rules for compressing application data and rules for compressing headers (transport header and network header).

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

[0059] In step S7, the encryption of the network header and network data is performed using the Network Key held in the network processing unit 16 as described above. However, encryption using a technique such as obfuscation may be applied to the network header.

[0060] Furthermore, 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. In other words, in this embodiment, two stages of encryption are performed on the application data and on the network header and network data.

[0061] Next, the compression processing unit 16a obtains from the compression rule management unit 11 the compression rule ID assigned to the compression rule applied to compress the header in step S6 (the compression rule applied to compress the application data in step S2). 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 step S7 as described above (step S8).

[0062] When the process in step S8 is executed, the network management unit 15 generates a packet containing a network header and network data to which a compression rule ID was assigned in step S8 (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 flooding communication described above, the packet transmitted in step S10 is received by all wireless communication devices 10 located within communication range of the wireless communication device 10.

[0064] In this embodiment, since the network header is also included in the encryption, it is preferable to perform compression before the encryption of the network header and network data (network payload) when all data can be accessed (i.e., all data is available). However, in Bluetooth Mesh, the transport header and network header are generated after the application data has been encrypted in advance, so by the time the network header and network data are encrypted, the application data has already been encrypted, making it difficult to compress the application data at this time.

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

[0066] The following describes the header compression in this embodiment. In this embodiment, for example, if the wireless communication device 10, which is the transmitting node, and another wireless communication device 10, which is the receiving node, both commonly recognize the values ​​set in each field that constitutes the header (network header and transport header), then it is considered that the field can be omitted in the packet. In other words, header compression in this embodiment means omitting at least some of the multiple fields that constitute each of the network header and transport header described above.

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

[0068] When the network header and transport header shown in the upper part of Figure 6 are compressed, for example, at least one of the multiple fields that make up the network header and the multiple fields that make up the transport header are omitted, thereby compressing the network header and transport header and reducing the size that the header occupies in the packet.

[0069] The lower part of Figure 6 shows the compressed network header, transport header, and application data. In the example shown in the lower part of Figure 6, several fields other than the TTL field that make up the network header are omitted, and all fields that make up the transport header (i.e., the transport header itself) are omitted.

[0070] This type of network header and transport header compression allows for expansion of the size of the application data within the packet (i.e., the payload size), even if a compression rule ID is assigned as described above.

[0071] In network header compression, 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, which constitutes the network header as described above, is not omitted.

[0072] While header compression has been explained here, the compression of application data described above is carried out from a similar perspective. In other words, if the wireless communication device 10, which is the transmitting node, and the other wireless communication device 10, which is the receiving node, both commonly recognize, for example, a portion of the application data, then that application data can be compressed by omitting that portion of the application data.

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

[0074] First, the transmitting / receiving unit 12 receives packets transmitted or forwarded from other wireless communication devices 10 via a wireless multi-hop network (step S11). The packets received in step S1 are similar to the packets transmitted in step S10 shown in Figure 5 above, and have a structure in which a compression rule ID is attached 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 queries the compression rule management unit 11 using the compression rule ID. This allows the compression processing unit 16a to determine whether 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) by the compression rule management unit 11 (step S12).

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

[0077] In other words, 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 explained in the application data transmission process described above. 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 the transport header and encrypted application data.

[0079] When the process in step S13 is executed, the compression processing unit 16a obtains the target compression rule described above from the compression rule management unit 11. By referring to the obtained target compression rule, the compression processing unit 16a decompresses the network header decoded in step S13 and the transport header included in the decoded network data (step S14). In step S14, processing is performed to restore the fields that were omitted in the header compression in the application data transmission process described above.

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

[0081] In addition, the application processing unit 14 may hold multiple Application Keys, but the Application Key used in the processing of step S15 can be identified, for example, based on the header (or the value set in a predetermined field that constitutes it) that is expanded in step S14.

[0082] Furthermore, although not shown in Figure 7, even if the wireless communication device 10 is, for example, participating in a wireless multi-hop network (i.e., holding a Network Key), if it does not hold an Application Key, the wireless communication device 10 cannot receive application data. For this reason, if the wireless communication device 10 (application processing unit 14) does not hold an Application Key, the processing in 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 perform the processing as a relay node, as described later.

[0083] When the process in step S15 is executed, the compression processing unit 14a obtains the target compression rule described above from the compression rule management unit 11. The compression processing unit 14a decompresses the application data decoded in step S15 by referring to the obtained target compression rule (step S16). In step S16, a process is executed to restore a portion of the application data that was omitted during the compression of the application data in the application data transmission process described above.

[0084] Next, the application management unit 13 retrieves the application data that was deployed in step S16 (step S17).

[0085] As described above, when the wireless communication device 10 operates as a receiving node, the processing in steps S13 to S17 is executed, allowing application data to be extracted from the received packets.

[0086] Note that this assumes that the application data is compressed during the application data transmission process. However, if the application data is not compressed, the process in step S16 may be omitted.

[0087] On the other hand, if the compression rule in question is determined not to be 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, the network header extracted from the packet is encrypted using the Network Key, so 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 Figure 7, if the wireless communication device 10 is not, for example, participating in a wireless multi-hop network, and the wireless communication device 10 (network processing unit 16) does not hold a Network Key, the process in step S18 is not executed, and the application data reception process is terminated.

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

[0091] When the process in 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 in step S20 is executed, the network management unit 15 generates a packet in which the network header included 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 forwarded (transmitted) from the transceiver 12 to other wireless communication devices 10 via the wireless multi-hop network (step S22). According to the flooding communication described above, the packet forwarded in step S22 is received by all wireless communication devices 10 located within communication range of the wireless communication device 10.

[0094] As described above, when the wireless communication device 10 operates as a relay node, the processing in steps S18 to S22 is executed, allowing the TTL to be updated appropriately and packets to be forwarded.

[0095] While this explanation focuses on cases where packets are forwarded, as mentioned above, if the TTL is "0", the packet will not be forwarded and will be discarded.

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

[0097] However, in order to access the destination address field, the encrypted network header must be decrypted using the Network Key.

[0098] Furthermore, in this embodiment, the destination address field may be omitted due to the compression of the network header. In this case, the destination address field cannot be accessed without decompressing the network header.

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

[0100] Furthermore, in order to decompress the network header contained in all packets received by the wireless communication device 10, the wireless communication device 10 (compression rule management unit 11) needs to manage (maintain) all the compression rules provided in the wireless multi-hop network. Such a configuration puts pressure on the memory area used to manage these compression rules and increases the processing time for provisioning and distributing the compression rules.

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

[0102] Furthermore, this embodiment assumes a case where flooding communication is performed, and in such flooding communication, the number of times a packet can be forwarded is managed using TTL. However, if the wireless communication device 10 is a relay node, it is necessary to update the TTL and forward the packet. However, as described above, if the wireless communication device 10 is configured to manage compression rules when it is a transmitting / receiving node, the wireless communication device 10 does not manage compression rules for decompressing the network header contained in the received packet when it is a relay node. For this reason, in this embodiment, in order for the relay node to be able to update the TTL appropriately, compression that omits the TTL field in which the TTL is set is not performed.

[0103] Furthermore, for example, the TTL set in the TTL field that constitutes the network header included in the packet received by the wireless communication device 10 differs depending on the initial value and the packet's path (number of relays) until it reaches the wireless communication device 10. Therefore, it is not possible to pre-set the TTL between the transmitting and receiving nodes (i.e., in the compression rule). In other words, in this embodiment, it can be said that compression that omits the TTL field is not possible.

[0104] By the way, Figure 7 above assumes that there is only one receiving node (destination). However, if, for example, the destination address field that constitutes the network header contains the addresses of multiple wireless communication devices 10, then when the process shown in Figure 7 is executed, a process to forward the packet (hereinafter referred to as packet forwarding) may be executed in addition.

[0105] The following shows an example of the processing procedure for the packet forwarding process described above, referring to the flowchart in Figure 8. Note that the processing shown in Figure 8 is assumed to be executed after the processing in step S14, separate from the processing from step S15 onwards shown in Figure 7.

[0106] First, the network management unit 15 refers to the destination address field, one of the multiple fields that make up the network header expanded in step S14 shown in Figure 7, and determines whether or not the packet needs to be forwarded (step S31). In step S31, it is determined that the packet needs to be forwarded if the address set in the destination address field is, for example, a broadcast address or a group address that specifies multiple addresses (i.e., there is a receiving node other than the wireless communication device 10). On the other hand, in step S31, it is determined that the packet does not need to be forwarded if the address set in the destination address field is only the address of the wireless communication device 10.

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

[0108] When the process in step S32 is executed, the compression processing unit 16a included in the network processing unit 16 compresses the network header, which reflects the TTL updated in step S32, and the transport header, which was decompressed in step S14 as shown in Figure 7 (step S33). Note that the process in step S33 is the same as the process in step S6 as shown in Figure 5 above, so a detailed explanation is omitted here. The compression in step S33 is performed by applying the target compression rule described above to the network header and the transport header.

[0109] Next, the encryption processing unit 16b encrypts the network header and network data that were compressed in step S33 (step S34). Since the process in step S34 is the same as the process in step S7 shown in Figure 5 above, a detailed explanation is omitted here.

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

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

[0112] The packets generated in step S36 are transferred (transmitted) from the transceiver 12 to other wireless communication devices 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 Figure 8 above, the wireless communication device 10 can further forward the packet to another wireless communication device 10 once it has obtained network header information from the packet during the application data reception process shown in Figure 7.

[0115] As described above, the wireless communication device 10 (transmitting node) according to this embodiment manages a 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 compression, and transmits a packet containing the encrypted network header and the encrypted network data.

[0116] Furthermore, the wireless communication device 10 (receiving node) according to 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 that includes a network header and encrypted network data encrypted by the other wireless communication device 10, decrypts the encrypted network header and encrypted network data, and decompresses the transport header included in the decrypted network header or the decrypted network data by referring to the compression rule.

[0117] In this embodiment, the compression rules are shared between the transmitting and receiving nodes, which are the wireless communication devices 10. Specifically, this sharing of compression rules can be achieved, for example, by distributing them to the transmitting and receiving nodes, which are the wireless communication devices 10, during provisioning when the transmitting or receiving node joins the wireless multi-hop network. In this embodiment, this configuration makes it possible for the receiving node, which is the wireless communication device 10, to properly decompress the network header or transport header that has been compressed in the transmitting node, which is the wireless communication device 10.

[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, thereby expanding the data area allocated to application data in the packet (i.e., the payload size). In other words, in this embodiment, the amount of application data that can be transmitted in a single packet can be increased, thereby reducing the number of packets transmitted and received over a wireless multi-hop network and enabling efficient communication.

[0119] Furthermore, the network header and network data included in the packets transmitted from the wireless communication device 10 according to this embodiment are assigned a compression rule ID to identify the compression rule applied when the network header or the transport header included in the network header was compressed.

[0120] When a wireless communication device 10 receives a packet, if the compression rule identified by the compression rule ID attached to the network header and network data contained in the packet is managed by the wireless communication device 10, it decodes the network header and network data. On the other hand, if the compression rule identified by the compression rule ID attached to the network header and network data contained in the packet is not managed by the wireless communication device 10, it forwards (transmits) the packet to another wireless communication device 10.

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

[0122] According to the configuration of this embodiment described above, the payload size can be expanded in a way that is compatible with the use of the Bluetooth Mesh security function, for example, by compressing and decompressing the header according to compression rules suitable for Bluetooth Mesh (packet format).

[0123] In this embodiment, the payload size (the data area allocated to application data in a packet) can be expanded by compressing the network header or transport header. However, the application data may also be compressed by applying the compression rules described above when the packet is transmitted. Such a configuration allows for a greater increase in the amount of application data that can be transmitted in a single packet, thereby enabling more efficient communication.

[0124] Furthermore, although this embodiment describes the distribution of compression rules during provisioning when the wireless communication device 10 joins a wireless multi-hop network (i.e., the sharing of compression rules is performed during provisioning), the distribution (sharing) of such compression rules may be performed at times other than provisioning. Specifically, the compression rules may be hardcoded in advance, for example, during the manufacturing of the wireless communication device 10, depending on the application to which they are applied. In addition, the compression rules may be shared between the transmitting node and the receiving node wireless communication device 10 when performing application data communication. In this case, the compression rules may be created (prepared) in the transmitting node wireless communication device 10 and transmitted (distributed) to the receiving node wireless communication device 10, or they may be created (prepared) in the receiving node wireless communication device 10 and transmitted (distributed) to the transmitting node wireless communication device 10.

[0125] Furthermore, although this embodiment describes a wireless multi-hop network formed by Bluetooth Mesh, the wireless communication device 10 according to this embodiment may also be applied to a wireless multi-hop network formed by a communication technology that performs encryption in two stages, such as encryption of application data and encryption of the network header and network data, when sending and receiving packets.

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

[0127] Figure 9 shows an example of a compression rule in this embodiment. The example shown in Figure 9 illustrates a compression rule based on SCHC (Static Context Header Compression).

[0128] SCHC is an IP header compression standard standardized by RFCs. SCHC shares a table of compression rules that describes how to compress / decompress data between transmitting and receiving nodes. SCHC is primarily applied to IP headers and is not intended to compress the headers of packets (Bluetooth packets) transmitted and received in wireless multi-hop networks formed by Bluetooth Mesh.

[0129] Therefore, in this embodiment, we will describe the compression rules (rule table) applicable to Bluetooth Mesh (Bluetooth packets) based on the SCHC described above.

[0130] As shown in Figure 9, the compression rules in this embodiment include 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), corresponding to each of the fields constituting the network header and transport header included 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, for example, in bits. TV indicates the candidate value to be set in the associated field (the candidate value for that field). MO indicates the relationship between the associated TV and the value set in the field, and corresponds to, for example, the criteria for deciding whether or not to apply CDA. CDA indicates the compression / decompression method for the associated field.

[0132] As shown in Figure 9, the fields include IVI, NIC, CTL, TTL, Seq, Src Addr, Dst Addr, SEG, AKF, AID, OpCode, Param, Net MIC, and Trans MIC. The IVI, NIC, CTL, TTL, Seq, Src Addr, and Dst Addr fields constitute the network header, while the SEF, AKF, and AID fields constitute the transport header.

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

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

[0135] The value set for the CTL field differs depending on whether the payload contained 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 contained in the packet is application data. In this case, the value set for the CTL field is expected to be 0. For this reason, in the compression rule shown in Figure 9, the CTL field is associated with TV "0", MO "equal", and CDA "not-sent". This indicates that the CTL field is omitted when the value set in the CTL field matches the specific value "0".

[0136] As mentioned above, the TTL field contains a value that is updated according to the number of transfers (i.e., every hop) (i.e., the number of transfers possible), so it is not possible to pre-determine the value between the sending and receiving nodes (by predicting the value and including it in the compression rule). For this reason, the TV corresponding to the TTL field is not listed in the compression rule shown in Figure 9. In addition, the TTL field in the compression rule shown in Figure 9 is associated with MO "ignore" and CDA "value-sent". This indicates that the TTL field will not be omitted (i.e., it will not be subject to compression) without comparing the value set in the TTL field with the TV.

[0137] The Seq field contains a sequence number, and this sequence number differs for each packet. Therefore, it is difficult to determine the value to be set in the Seq field (i.e., to record it in TV). However, the field size (field length) of the Seq field is 24 bits. In this case, if we consider that the leftmost few bits of the value set in the Seq field do not change frequently, it can be said that these few bits can be partially omitted. In this case, in the compression rule shown in Figure 9, the Seq field is associated with TV "0x00", MO "equal", and CDA "LSB (Least Significant Bit)". According to this, if 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 that byte is transmitted).

[0138] The Src Addr field is set to the address of the wireless communication device 10, which is the transmitting node. The Dst Addr field is set to the address of the wireless communication device 10, which is the receiving node. In this embodiment, as described in the first embodiment above, the transmitting and receiving nodes in the compression rule are uniquely determined by the configuration in which a compression rule is distributed for each combination of transmitting and receiving nodes. For this reason, in the compression rule shown in Figure 9, the Src Addr field 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 address "X2", which is a uniquely determined transmitting node. Similarly, in the compression rule shown in Figure 9, the Dst Addr field 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 address "X3", which is a uniquely determined receiving node. In other words, if the addresses of the sending and receiving nodes are fixed, the data can be compressed by completely eliminating the Src Addr and Dst Addr fields.

[0139] As described above, the transport header consists of a SEG field, an AKF field, and an AID field, and the sum of the field sizes of the SEG field, AKF field, and AID field is 1 byte.

[0140] The SEG field is set to a value indicating whether or not segmentation occurs, where application data is divided into multiple packets for transmission. The value set in the SEG field can sometimes be predicted by estimating the size of the application data, depending on the application applied to the sending and receiving nodes. In the compression rule shown in Figure 9, it is assumed that segmentation does not occur, and the SEG field is associated with TV "0", MO "equal", and CDA "not-sent". This indicates that the SEG field is omitted if its value matches the specific value "0". If segmentation occurs, another field is added to manage that segmentation.

[0141] The AKF and AID fields are set with values ​​related to the Application Key. When using the Application Key, the AKF field is always set to 1, and the AID field is set to an ID determined by the application applied to the sending and receiving nodes. Therefore, if the application applied to the sending and receiving nodes is the same, the values ​​set in the AKF and AID fields can be shared between the sending and receiving nodes in advance. In this case, in the compression rule shown in Figure 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 TV. Also, in the compression rule shown in Figure 9, the AID field is associated with TV "X4", MO "equal", and CDA "not-sent". This indicates that the AID field is omitted if the value set in the AID field matches the application-defined ID "X4".

[0142] In the compression rules, the OpCode and Param fields correspond to the application data (i.e., the payload contained in the packet). For example, if the application data contains a predetermined value, that value (i.e., part of the application data) can be omitted (compressed) by SCHC. Specifically, in Bluetooth Mesh, for example, an OpCode field is added to the beginning of the application data, and this OpCode field is set to a value indicating the type of application applied to the transmitting and receiving nodes. That is, if the types of applications applied to the transmitting and receiving nodes are limited, a specific value (fixed value) is set in the OpCode field. In this case, in the compression rules shown in Figure 9, the OpCode field is associated with TV "X5", MO "equal", and CDA "not-sent". This indicates that if the value set in the OpCode field matches the specific value "X5", the OpCode field is omitted.

[0143] On the other hand, the Param field is set to the application data itself. In the compression rule shown in Figure 9, the Param field is associated with TV "-", MO "ignore", and CDA "value-sent". This indicates that the Param field will not be omitted (i.e., excluded from compression) without comparing the value set in the Param field with TV. Note that if only specific values ​​are set in the Param field, the Param field may be omitted (compressed) by SCHC. Furthermore, as explained in the case of the Seq field, for example, it is also possible to configure the system to omit only a portion of the value set in the Param field (the application data itself).

[0144] The Net MIC (Network MIC) and Trans MIC (Transport MIC) fields are set to different values ​​for each application data (for example, hash values ​​for error correction), making it impossible to pre-determine the values ​​between the sending and receiving nodes (by predicting these values ​​and including them in the compression rules). For this reason, in the compression rules shown in Figure 9, the Net MIC and Trans MIC fields are associated with TV "-", MO "ignore", and CDA "value-sent". This indicates that the Net MIC and Trans MIC fields are not omitted (i.e., excluded from compression) without comparing the values ​​set in the Net MIC and Trans MIC fields with TV.

[0145] When the compression rules shown in Figure 9 above are applied, the wireless communication device 10, which is the transmitting node, can compress the network header by omitting the IVI field, NIC field, CTL field, part of the Seq field, the Src Addr field, and the Dst Addr field that constitute the network header, and can also compress the transport header by omitting the SEG field, AKF field, and AID field that constitute the transport header. Furthermore, when the compression rules shown in Figure 9 are applied, the OpCode field can be further omitted (compressed).

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

[0147] Furthermore, the compression rule described in this embodiment applies when all fields that are listed as optional in the compression rule (i.e., in the example shown in Figure 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 optional fields other than the NIC field listed in the compression rule (e.g., the IVI field) can be omitted, if the value set in the NIC field does not match the fixed value "X1", the compression rule will not be applied (i.e., no compression will be performed). Since decompressing network headers and transport headers, etc., that have been compressed by applying only a part of the compression rule may be complicated, this embodiment adopts a configuration in which the compression rule is applied when all fields to be compressed can be omitted, as described above, so that the compressed network headers and transport headers, etc., can be properly decompressed.

[0148] As described above, in this embodiment, the compression rule includes, for example, candidate values ​​(TV) for fields constituting the network header or transport header. When the candidate value of a field matches the value set for a field constituting the network header and transport header, the field is omitted to compress the network header and transport header. In this embodiment, this configuration makes it possible to achieve compression of network headers and transport headers, etc., based on compression rules applicable to SCHC-based Bluetooth Mesh (Bluetooth packets) as shown in Figure 9.

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

[0150] According to at least one embodiment described above, it is possible to provide a wireless communication device and method that can achieve efficient communication.

[0151] While several embodiments of the present invention have been described, these embodiments are presented as examples only and are not intended to limit the scope of the invention. These embodiments can be carried out in a variety of other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their variations are included in the scope and spirit of the invention, as well as in the claims and their equivalents. [Explanation of symbols]

[0152] 10, 10-1, 10-6… Wireless communication device, 11… Compression rule management unit, 12… Transmit / receive 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. In 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 that compresses a network header or a transport header included in network data by applying the first compression rule, A first cryptographic processing means that encrypts the network header and the network data after compression, A transmission means for transmitting a packet containing the encrypted network header and the encrypted network data, Receiving means and It is equipped with, The first compression rule is shared with other wireless communication devices that are receiving nodes in the multi-hop communication. The management means manages the 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, which includes a network header and encrypted network data encrypted by the other wireless communication device. The first cryptographic processing means decrypts the network header and network data contained in the received packet, The decoded network header or the 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 decompresses the decoded network header or the transport header contained in the decoded network data by referring to the second compression rule, The network header and network data included in the received packet are provided with compression rule identification information for identifying the second compression rule applied when the network header or transport header was compressed. The first cryptographic processing means decrypts the network header or the transport header when the second compression rule identified by the compression rule identification information is being managed. The transmission means forwards the packet to another wireless communication device if the second compression rule identified by the compression rule identification information is not managed. Wireless communication device.

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 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 transport header by omitting the field if the candidate value of the field included in the first compression rule matches the value set in the field that constitutes the network header or the transport header. The wireless communication device according to claim 1.

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 a portion of the value when a candidate value of a field included in the first compression rule matches a portion of the value set in a field constituting the network header or the transport header.

5. A second compression processing means compresses the 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, It is equipped with, The network data includes the transport header and the encrypted application data. The wireless communication device according to 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 when the wireless communication device or the other wireless communication device is provisioned upon joining the wireless multi-hop network.

7. The wireless communication device according to claim 1, wherein the second compression rule is distributed to the wireless communication device and the other wireless communication device when the wireless communication device or the other wireless communication device which is a transmitting node in the multi-hop communication joins the wireless multi-hop network during provisioning.

8. The wireless communication device according to any one of claims 1 to 7, wherein the data area allocated to the data to be transmitted in the multi-hop communication in the packet is expanded by compressing the network header or the transport header.

9. A method performed by a wireless communication device that performs multi-hop communication via a wireless multi-hop network, The wireless communication device manages the first compression rule when it is the transmitting node in the multi-hop communication, By applying the first compression rule, the network header or the transport header included in the network data is compressed, The network header and network data are encrypted after the aforementioned compression. To transmit a packet containing the encrypted network header and the encrypted network data. It is equipped with, The first compression rule is shared with other wireless communication devices that are receiving nodes in the multi-hop communication. The aforementioned management includes managing a second compression rule when the wireless communication device is a receiving node in the multi-hop communication, Receiving a packet transmitted from another wireless communication device, which includes a network header and encrypted network data encrypted by that other wireless communication device, Decrypting the network header and network data contained in the received packet. It further comprises, The decoded network header or the transport header included in the decoded network data is compressed by applying the second compression rule in the other wireless communication device. The method further comprises decompressing the decoded network header or the transport header contained in the decoded network data by referring to the second compression rule, The network header and network data included in the received packet are provided with compression rule identification information for identifying the second compression rule applied when the network header or transport header was compressed. The decoding described above includes decoding the network header or the transport header when a second compression rule identified by the compression rule identification information is in control. The aforementioned transmission includes forwarding the packet to another wireless communication device if the second compression rule identified by the compression rule identification information is not managed. method.

Images