KR100937924B1 - Method of protocol header compression for supporting mobility of 6lowpan network - Google Patents

Abstract

PURPOSE: A protocol header compression method for simultaneously supporting a network based portability protocol for dynamically supporting a node-based mobility protocol and 6LoWPAN network is provided to support the mobility support protocol of 6LoWPAN by efficiently compressing a binding message. CONSTITUTION: A gateway(110) decodes 6LoWPAN packet going out from 6 LoWPAN(300) to an internet. The gateway encodes the packet from internet into 6LoWPAN. An MPC(Mobile PAN Coordinator) has two network interfaces. The interfaces connect internal and external networks of a mobile PAN network.

Description

Protocol Header Compression Method for Mobility Support in 6LOREPANIC Networks {METHOD OF PROTOCOL HEADER COMPRESSION FOR SUPPORTING MOBILITY OF 6LOWPAN NETWORK}

Embodiments of the present invention relate to an IEEE 802.15.4 low-power wireless personal area network (WPAN) supporting 6LoWPAN, that is, IPv6, and more particularly, to a method for supporting mobility in a 6LoWPAN network and a system using the same.

A ubiquitous sensor network (USN) is a service infrastructure that recognizes people, objects, or environment information from tags or sensor nodes installed at various locations, integrates, processes, and applies the recognized information to various services. In the past, assigning IP to each sensor node was considered an inadequate resource waste for this USN. Accordingly, USN has been developed using low-power wireless networks such as non-IP ZigBee.

However, because of advantages such as robustness of the TCP / IP scheme and ease of connection to an existing IP-based network, an IP scheme based USN has also been studied. On the other hand, IPv6 can provide as many IPs as can be given to all sensor nodes in the world, and IEEE 802.15.4 is aimed at low-power, simple hardware, so it will support IPv6 in PHY / MAC of IEEE 802.15.4 low-power WPAN. The discussion of 6LoWPAN has begun as an enabling technology.

Meanwhile, even when the sensor node in the sensor network moves, the connection to the IPv6 network should be maintained. This is called mobility. In general, mobility technology is a node-based mobility technology that imparts mobility to each sensor node, and each sensor node does not support mobility but mobility across the sensor network, including its sensor nodes, through a mobile router (MR). Consider a network-based mobility technology that grants A technology supporting node-based mobility is MIPv6 (mobile IPv6), and a network-based mobility technology is a network mobility (NEMO) protocol.

MIPv6 is a representative standard protocol for supporting host-based mobility, and maintains a logical session with a CN (correspond node) even when a mobile node (MN) moves from a home network to a new network. Support communication. The NEMO protocol is a standard protocol for network-based mobility support. Even though all nodes (MNNs) in a mobile network move and connect to a new network, the NEMO protocol maintains logical connections of all mobile MNNs. The NEMO protocol is a version in which a mobile router flag is added to MIPv6. The NEMO protocol registers binding information of a mobile network by exchanging a binding update message (BU) and a binding acknoweldge message (BA) like MIPv6.

On the other hand, 6LoWPAN has a small data packet size of up to 127 bytes, 102 bytes except the MAC header, and only 81 bytes can be used for data transmission when the security function is applied. However, since IPv6 must have a header size of 40 bytes even if the IPv6 option header is excluded, the actual data loading space available in 6LoWPAN can be much smaller. Furthermore, since the IPv6 network defines a transmission unit of up to 1280 bytes, in order to use IPv6 technology in the IEEE 802.15.4 network, 6LoWPAN has an adaptation layer between the IP layer and the MAC layer to compress the IPv6 packet header. It also defines a technique for fragmentation / reasembly packets. 6LoWPAN protocol headers generally include mesh, fragmentation, dispatch, and header compression (HC) information, which are carried in the load space used by the MAC of IEEE 802.15.4. Mesh headers are used for mesh routing and fragmentation headers are used for fragmentation / reassembly techniques. The packet type of 6LoWPAN is determined as the value of the dispatch header. For example, if the dispatch header starts with 00, it means that the frame is not a LoWPAN frame. If it starts with 01, it means that the next header is a compressed or uncompressed IPv6 header. Also, if it starts with 10, it refers to the mesh header. If it starts with 11, it means header for fragmentation / reassembly. In addition, HC has information on IP, UDP header.

Mobility support is recognized as an important technology in the USN (Ubiquitous Sensor Network) research. Among the existing mobility technologies, MIPv6 and NEMO Basic Support Protocol (NEMO) are IETF's standardized protocols, and are core technologies for supporting IP mobility of hosts and networks on the existing Internet. However, when the MIPv6 and NEMO protocols are applied to the USN without modification, the size of the binding message is inevitable in many ways.

In addition, the mobility support protocol of the current 6LoWPAN network is not designed to support both node-based and network-based mobility, and since the header compression for binding messages does not consider the address allocation method of the 6LoWPAN network. Redundant transmission of network prefixes wastes resources and power in networks with limited battery life and system performance.

In addition, in the conventional header compression scheme, since the effective range is changed by compressing a sequence number, a compatibility problem occurs due to a difference in the effective range in binding update. This has a limitation in that binding update failures occur in other nodes other than 6LoWPAN in supporting mobility of 6LoWPAN network.

An object of the present invention is to solve the problems of the prior art as described above, and the mobile IPv6 and NEMO protocol for node-based mobility and network-based mobility to effectively compress the binding message to fit the 6LoWPAN environment to support the mobility support protocol of 6LoWPAN To provide.

In order to achieve the above object, a method of supporting 6LoWPAN mobility according to an aspect of the present invention is a method of simultaneously supporting a node-based mobility protocol and a network-based mobility protocol in a 6LoWPAN network.

Setting, in a first header of a 6LoWPAN packet, a bit pattern indicating that a second header following the first header is a compressed IPv6 mobility header (LOWPAN_MH);

Setting a first bit indicating whether the binding operation currently performed in the second header is a binding operation according to one of a node-based mobility protocol and a network-based mobility protocol; And

And compressing the binding message according to the protocol corresponding to the setting value of the first bit to generate a compressed binding message.

Preferably, the first header may be a dispatch header.

Preferably, the second header may include a second bit indicating whether the binding operation is binding update (BU) or binding confirmation (BA).

Preferably, the second header may include a third bit indicating whether a lifetime information field in the binding message is compressed information.

Preferably, the second header may include a fourth bit indicating whether a checksum information field in the binding message is compressed information.

Preferably, when the binding operation is a binding update (BU), the second header is a fifth bit indicating whether to request a binding confirmation (BA) operation from a destination node, and acts as a home agent (HA) for the destination node. And a sixth bit indicating whether to request a message, a seventh bit indicating whether the binding message includes a home address, and an eighth bit indicating whether the binding message includes a network prefix.

Preferably, when the binding operation is binding confirmation (BA), the second header may include fifth to eighth bits indicating status information defined in the 6LoWPAN standard.

6LoWPAN mobility support method according to another aspect of the present invention,

A method of simultaneously supporting a node-based mobility network and a network-based mobility protocol in a 6LoWPAN network, wherein the method

Setting, in a first header of a 6LoWPAN packet, a bit pattern indicating that a second header following the first header is a compressed IPv6 mobility header (LOWPAN_MH);

A first bit indicating whether a binding operation currently performed in the second header is a binding operation according to a node-based mobility protocol or a network-based mobility protocol; and whether the binding operation is a binding update (BU) or a binding confirmation (BA). Setting a second bit indicating whether or not); And

The method may include generating a compressed binding message by compressing the uncompressed binding message according to a protocol and a binding operation according to the setting values of the first and second bits.

Advantageously, if said binding operation is a binding update (BU), said compressed binding message comprises: a home address fragment excluding a network prefix from a home address in said uncompressed binding message; And

It may include the SLA ID extracted from the network prefix.

Preferably, the compressed binding message may further include compressed lifetime information obtained by compressing a lifetime field value in the uncompressed binding message.

Preferably, the second header may include a third bit indicating whether a lifetime information field in the binding message is compressed lifetime information.

Preferably, when the binding operation is a binding update (BU), the second header is

A fifth bit indicating whether to request binding confirmation (BA) operation to the destination node, a sixth bit indicating whether to request operation as a home agent (HA) for the destination node, a seventh bit indicating whether the binding message includes a home address, and The binding message may include an eighth bit indicating whether the binding message includes a network prefix.

Preferably, the compressed binding message is

It may further include a sequence number and compressed lifetime information.

Preferably, when the binding operation is binding confirmation (BA), the compressed binding message may include a sequence number and compressed lifetime information.

A mobile device according to another aspect of the present invention is a mobile device that communicates within a 6LoWPAN network, and the device may generate a compressed binding message by performing the 6LoWPAN mobility support method.

The 6LoWPAN mobility support method according to another aspect of the present invention is a method for simultaneously supporting a node-based mobility protocol and a network-based mobility protocol in a 6LoWPAN network composed of a mobile node and a mobile network.

Receiving a 6LoWPAN packet comprising a first header, a second header and a compressed binding header;

Checking from the bit pattern of the first header whether the second header is a compressed IPv6 mobility header (LOWPAN_MH);

Determining whether the binding operation currently performed from the first bit of the second header is a binding operation according to one of a node-based mobility protocol and a network-based mobility protocol;

Determining from the second bit of the second header whether the binding operation is a binding update (BU) or a binding confirmation (BA); And

Restoring the uncompressed binding message from the compressed binding header according to the determined mobility protocol and the type of the binding operation.

Preferably, if the mobility protocol is a node-based mobility protocol and the binding operation is a binding update (BU),

The compressed binding header may include a home address fragment excluding a network prefix from a home address in the uncompressed binding message; And an SLA ID extracted from the network prefix,

Restoring the uncompressed binding message may include extracting the upper 48 bits of a network prefix from a destination address of the compressed binding header; And

And combining the upper 48 bits of the network prefix, the home address fragment, and the SLA ID to restore the IPv6 address of the mobile node.

Preferably, if the mobility protocol is a network-based mobility protocol and the binding operation is a binding update (BU),

The compressed binding header may include a home address fragment excluding a network prefix from a home address in the uncompressed binding message; And an SLA ID extracted from the network prefix,

Restoring the uncompressed binding message may include extracting the upper 48 bits of a network prefix from a destination address of the compressed binding header; And

And combining the upper 48 bits of the network prefix, the home address fragment, and the SLA ID to restore the IPv6 address of the mobile network.

Preferably, when the binding operation is binding confirmation (BA), the compressed binding header may include a sequence number and compressed lifetime information.

Preferably, the second header may include a third bit indicating whether a lifetime information field in the compressed binding header is in a compressed state.

Preferably, when the binding operation is a binding update (BU), the second header is

A fifth bit indicating whether to request binding confirmation (BA) operation to the destination node, a sixth bit indicating whether to request operation as a home agent (HA) for the destination node, a seventh bit indicating whether the binding message includes a home address, and The binding message may include an eighth bit indicating whether the binding message includes a network prefix.

A mobile device according to another aspect of the present invention is a mobile device that communicates within a 6LoWPAN network, and the device may recover the uncompressed binding message from the received compressed binding header by performing the 6LoWPAN mobility support method. .

As described above, the embodiments of the present invention effectively compress the binding message of the MIPv6 and NEMO protocols to support the node-based mobility and the network-based mobility of the 6LoWPAN network, so that the BU of the MIPv6 is 32 bytes to 13 bytes, BA was compressed from 12 bytes to 3 bytes, respectively, BU of the NEMO protocol was compressed from 40 bytes to 13 bytes, and BA was compressed from 12 bytes to 3 bytes, respectively. This binding message compression improves handoff performance and is expected to increase energy efficiency due to reduced size of binding message.

Hereinafter, by attaching the structure of the uncompressed binding message of the standard MIPv6 and NEMO protocol and the structure of the binding message compressed through the compression technique of the present invention, a person having ordinary knowledge in the technical field of the present invention can be easily implemented. It will be described in more detail.

The 6LoWPAN network is a system with nodes with limited computation and battery performance, so it cannot afford the overhead of applying both network stacks to process IP-based network packets. In addition, the IPv6 packet has a maximum transmission size of 1280 bytes, but the maximum transmission size of the IEEE 802.15.4 packet is 127 bytes, which is a big difference. To solve this problem, 6LoWPAN has an adaptation layer between the MAC layer and the network layer of the OSI layer structure. In this adaptation layer, mesh routing, header compression, and fragmentation are performed, and information on whether a corresponding packet is a compressed IPv6 packet or an uncompressed IPv6 packet is set using a dispatch header.

In the present invention, the mobility header can be supported by the dispatch header to support the mobility protocol.

1 illustrates the exchange of binding messages according to the configuration and movement of 6LoWPAN network according to the present invention.

As shown in FIG. 1, the 6LoWPAN network for supporting mobility is composed of the following elements.

6LoWPAN gateway (GW): The gateway provides a connection between the PAN and the Internet. In FIG. 1, the HA 110 of the mobile network 400 and the mobile nodes 200 of the mobile nodes (MN) are illustrated. The home agent (HA) 120 and the foreign agent 130 of the visiting nodes may be referred to as gateways. The gateway 110 decodes and forwards 6LoWPAN packets going from the 6LoWPAN 300 to the Internet 100 and encodes packets coming into the 6LoWPAN 300 from the Internet 100 to conform to the protocol of the 6LoWPAN standard. .

Mobile PAN coordinator (MPC): MPC is a control device for sensor networks that supports network-based mobility. The MPC 410 has two network interfaces for connection with internal and external networks of the mobile PAN network 400. Through these two network interfaces, even when the MPC 410 loses its connection with the external network during the movement, the Mobile Network Nodes (MNNs, 420) remain connected to the MPC 410 and continue to connect to the new network. Since the MNNs 420 do not need to perform a handoff process at the time of connection, overhead of network traffic and binding message exchange can be reduced. The MPC 410 becomes a PAN coordinator for the MNNs 420, and in the external network, the mobile network looks like one sensor node. The MNNs 420 may also be connected to another external sensor network 300 through the MPC 410.

Static PAN coordinator: A fixed fan coordinator is a PAN control device of a typical sensor network with no mobility. The fixed fan coordinator 310 may be an access point of the MPC 410 of the mobile network 400 and the MN 420 that is a mobile sensor node.

Mobile Network Nodes: Local Fixed Nodes (LFNs) are ones of mobile nodes that are actually mobile but appear to be fixed, relatively mobile, in a mobile network.

Fixed node: A fixed sensor node, which is a general sensor node having no mobility, and may be an access point of the MPC 410 of the mobile network 400 and the MN 420 which is a mobile sensor node.

In FIG. 1, node-based mobility may be illustrated as what happens when a mobile node (MN) 200 moves into a second personal area network (PAN2), where network-based mobility moves to a second by a mobile network 400. It can be exemplified as what happens when the user moves near the personal area network PAN2.

When node-based mobility and network-based mobility occur, the MN 200 and the MPC 410 are connected at the new location, and each HA 120 and 110 originally attached to each other by including a newly generated address in PAN2 in a binding message. Is sent to the server (via the Binding Update / Binding Ack). Through the binding message, the original HAs 120 and 110 store updated binding information (Home Address (HoA), mobile network prefix (MNP), etc.) in each binding cache. Subsequently, a new location of the corresponding mobile node 200 or 420 is intercepted by intercepting a packet transmitted from the corresponding node 500 to the destination address of the mobile node 200 or 420 as a destination. Transfer it to node address (HoA).

FIG. 2 is a diagram illustrating a header (LOWPAN_MH) including a pattern of a dispatch header for mobility support of 6LoWPAN and compression information of a mobility protocol according to the present invention.

As shown in FIG. 2, in order to support the mobility support protocol according to the present invention, a pattern (01000011) indicating that a compressed IPv6 mobility header follows is followed by patterns of the dispatch header 620. Will be added.

The pattern 01000011 is merely an example, and may be appropriately selected from the reserved patterns among the patterns of the current dispatch header 620.

The 6LoWPAN network can quickly divide and process packets for binding update by using this information in the adaptation layer, that is, the compressed mobility protocol header 610 followed by the dispatch header 620. In addition, the 6LoWPAN gateway can obtain information about the compression of the mobility protocol through the compressed mobility protocol header, that is, LOWPAN_MH 610, and use this information to restore the mobility packet and transmit it to the HA in the 6LoWPAN external network. have.

Each field of the LOWPAN_MH 610 is as follows. Bit 0 is a bit for distinguishing node-based mobility from network-based mobility. For example, bit 0 may be set to 0 for MIPv6 packet for node-based mobility and to 1 for NEMO protocol for network-based mobility.

Next, bit 1 is a bit for distinguishing a binding update (BU) message from a binding confirmation message. If the packet is a packet for a binding update message, 0 is used for the binding confirmation message. If the packet can be set to 1.

Subsequently, bit 2 is a bit indicating whether the lifetime information of the binding is compressed and may be set to 0 if the life information is not compressed and 1 if it is compressed. In MIPv6, when a mobile node moves to an external network, the mobile node matches its home address (HoA) with the home agent (HA) by registering a care of address (CoA), which is an address obtained from a newly entered external network. This is called binding, which is invalid if it is not updated within a certain lifetime. In the MIPv6 standard, lifespan information consists of 16 bits and the unit is 4 seconds. In order to compress the size of information, for example, if this unit is set to 8 seconds, 16 bits of life information can be compressed to 8 bits.

Bit 3 indicates whether or not to compress checksum information of the binding message. Bit 3 may be set to 0 if the checksum information is not compressed and to 1 if it is compressed.

Bits 4 through 7 depend on whether the packet is a BU or BA packet, that is, depending on the value of bit 1, the role assigned to each of them can be different. A case of the update (BU) packet will be described.

Bit 4 represents the Acknowledgment Request bit of the binding message, and is set to 1 when the mobile node requests a binding acknowledgment (BA) response from the home agent (HA) as a response to the binding update (BU) message. Can be. Bit 5 represents the home registration bit of the binding message, and can be set to 1 when the destination node requests to operate as HA. Bit 6 represents the home address (Home address or HoA) inclusion bit of the binding message, and is set to 1 when the binding update (BU) message includes the HoA of the mobile node (MN) or the mobile fan coordinator (MPC). Can be. Bit 7 may be set to 1 when the binding message is a NEMO protocol and contains a network prefix of mobile network nodes.

Subsequently, when bit 1 indicates that the message is a binding acknowledgment (BA) message, four bits from bits 4 to 7 may be set as status information for confirming the result of the binding.

3 is a block diagram showing compression of a binding update message of MIPv6 according to the present invention.

As shown in FIG. 3, the uncompressed MIPv6 binding update header 630 includes an 8-bit payload proto, a header length, a header length, a portable header type, and a reserved type. ) Field, 16-bit Checksum, Sequence # field, 1-bit A, H, L, K field, 12-bit reserved field, 16-bit Lifetime field, 8-bit It consists of a next header, a header length, an option type, an option length field, and a 128-bit home address field.

Among these, payload protocol, header length, mobility header type, next header, option type, and option length fields have a fixed value or a known value (eg, mobility protocol type, header length, etc.), and therefore, within the corresponding PAN. While using the 6LoWPAN protocol, the information is not essential and can be removed. These fields are fields that can be restored by the 6LoWPAN gateway when the binding message goes out to the external network. In this way, 64 bits can be reduced.

Next, the A and H fields have already included respective information in the LOWPAN_MH 610. Here, the A field is set when the mobile node requests an acknowledgment (BA) upon receiving a binding update (BU) message. The H field is a field set by the mobile node when it requires the receiving node to act as the home agent of the mobile node.

The L and K fields are optional fields. The L bit is a Link-Local Address Compatibility field and is set when the home address reported by the mobile node has the same interface identifier as the link local address of the mobile node. According to RFC 4944 on the transmission of IPv6 packets over an IEEE 802.15.4 network distributed in September, the interface identifiers of the link-local address and the mobile node's home address are always generated and used in the same way and can always be regarded as 1. And therefore may be omitted. The K field is a Key Management Mobility Capability field, which indicates whether the protocol used to establish an IPsec secure connection between the mobile node and the home agent is valid after any movement. However, since the IPsec is not defined at this time and its support is not guaranteed, the K field may be omitted.

The lifetime field may be compressed as described for LOWPAN_MH 610. The checksum field is not necessary at this stage because the binding update (BU) and acknowledgment (BA) messages are error checked using the FCHK field of IEEE 802.15.4 as the MAC payload in the IEEE 802.15.4 MAC layer. It can be removed. The 6LoWPAN gateway can recalculate and add checksums when restoring compressed messages. In this way, 40 bits can be reduced.

In the case of a sequence number field, compression does not compress the HA because its compatibility range is different from that of the HA for binding update.

In order to send a binding update (BA) message for binding update from MIPv6 to HA, a home address option field for containing HoA of the mobile node is needed. Here, the HoA of the mobile node is a network address generated by the home network and is set as the subnetwork address of the HA. In order to lighten the binding message, the compressed binding update (BA) message does not contain the entire 128-bit IPv6 address as the HoA of the mobile node. As shown in FIG. 3, in the present invention, the compressed binding update message includes a 64-bit HoA (Home address w / o network prefix) fragment from which the network prefix has been removed, and an SLA ID including lower 16 bits among the components of the network prefix. (Site Level Aggregation Identifier). With these two fields, we can restore the complete HoA of the mobile node. The reason for this can be found in the IPv6 address format, which consists of bits that are assigned and fixed by the ISP and SLA ID and interface ID for subnetwork configuration. The upper 48-bit address of the network prefix constituting the HoA of the mobile node can be obtained from the address of the HA set as the destination. You can get the home address fragment of the bit. In this way, 48 bits can be reduced.

When restoring a mobile node's HoA, you can get the 128-bit IPv6 address by combining the high 48-bit network prefix, the 16-bit SLA ID, and the 64-bit home address fragment from which the network prefix has been removed. It becomes HoA.

The LOWPAN_MH 610 of FIG. 2 and the compressed binding update (BU) header 640 of FIG. 3 have substantially the same information and the size when compared to the uncompressed binding update (BU) header 630. It can be compressed from a total of 256 bits to 112 bits.

4 is a block diagram illustrating compression of a binding update (BA) message of the NEMO protocol according to the present invention.

As shown in FIG. 4, the binding update (BU) message of the NEMO protocol (NEMO Basic Support Protocol) may also be compressed as in the case of MIPv6.

As illustrated in FIG. 4, the uncompressed NEMO protocol binding update message (Uncompressed BU) is composed of a destination option header 650 and a mobility header 660.

The destination option header 650 is an 8-bit Next header, a header length, an option type, an option length field, and a 128-bit home address field. It is composed. The mobility header 660 includes an 8-bit payload proto, header length, mobility header type, reserved field, 16-bit checksum, and sequence number. (Sequence #) field, 1-bit A, H, L, K, R field, 11-bit reserved field, 16-bit lifespan field, 8-bit type, length, reserved, prefix length ( Prefix length field, and a 64-bit mobility network prefix option field.

Among these, as in the case of the MIPv6 protocol, the payload protocol, header length, mobility header type, next header, option type, and option length fields may have fixed values or known values (eg, mobility protocol type, header length, etc.). Therefore, while using the 6LoWPAN protocol in the PAN is not necessary information and can be removed. These fields are fields that can be restored by the 6LoWPAN gateway when the binding message goes out to the external network.

Next, each of the A, H, and fields is already included in the LOWPAN_MH 610, and the L, K, and R fields may be omitted. The A, H, L, and K fields have been described above. The R field is a mobile router flag field, which informs the home agent whether a binding update is coming from the mobile router (that is, it is an NEMO network). If the R field is 0, the home agent assumes that the mobile router operates as a mobile node. Since the 0 bit of the LOWPAN_MH 610 indicates whether it is a MIPv6 protocol or an NEMO protocol, the R field may be omitted.

The lifetime field may be compressed to 8 bits as described in LOWPAN_MH 610. The checksum field is not necessary at this stage because the binding update (BU) and acknowledgment (BA) messages are error checked using the FCHK field of IEEE 802.15.4 as the MAC payload in the IEEE 802.15.4 MAC layer. It can be removed. The 6LoWPAN gateway can recalculate and add checksums when restoring compressed messages.

In the case of a sequence number field, compression does not compress the HA because its compatibility range is different from that of the HA for binding update.

In the NEMO protocol, the binding update message includes the HoA of the mobile fan coordinator and the network prefix of the mobile network nodes. To compress this, the present invention uses the features of the NEMO protocol and IPv6 subnetwork configuration. The HoA address of the mobile fan coordinator consists of the network prefix of the upper subnetwork, and the network prefix of the mobile network nodes is the lower subnetwork of the mobile fan coordinator. Therefore, knowing the network prefix of the mobile network nodes, it is possible to calculate the network prefix of the mobile fan coordinator due to the IPv6 subnetwork address assignment structure. In the present invention, instead of including the HoA of the mobile fan coordinator and the network prefix of the mobile network nodes as it is, the 16-bit SLA ID extracted from the network prefix of the mobile network nodes (MNN) and the network prefix in the HoA of the mobile fan coordinator The 64-bit address, except for, is included in the compressed binding update (BU) header 670.

When restoring the HoA of the mobile fan coordinator and the network prefix of the mobile network nodes, the upper 48 bits from the network prefix of the destination address of the binding update (BU) header 610 and the 16-bit SLA ID included in the binding update (BU) and Using the 64-bit home address (HoA), which removes the mobile fan coordinator's network prefix, you can get the home address of the mobile fan coordinator and the 64-bit network prefix of the mobile network nodes.

In this way, the uncompressed binding update (BU) message in the NEMO protocol consists of 160 bits of destination option header 650 and 192 bits of mobility header 660, while a total of 352 bits is used. It consists of the LOWPAN_MH 610 and the compressed binding update header 670 of FIG. 2 and contains substantially the same information as the binding update message, which takes a total of 112 bits but is not compressed.

5 is a block diagram showing the compression of a binding confirmation (BA) message of the MIPv6 and NEMO protocol according to the present invention.

As shown in FIG. 5, all fields of the uncompressed binding confirmation (BA) header 680 are compressed and compressed in a similar manner as in the case of uncompressed binding update messages as described in FIGS. 3 and 4. Obtain a binding confirmation (BA) header 690.

In the compressed binding resolution (BA) header 690, the payload protocol, header length, mobility header type, reserved fields, K field, R field, mobility option field can be removed, and the lifetime field can be cut in half. have.

The Status field containing the result information according to the binding update is included in the LOWPAN_MH 610. In the 6LoWPAN standard, 14 kinds of status information regarding the MIPv6 protocol and four kinds of status information about the NEMO protocol are defined. In this case, since the gateway (GW) plays a role of HA in 6LoWPAN, for example, 131 Home registration not supported, or 132 Not hme subnet, 133 Not Home agent for this mobile node among 18 standard state information codes, State information values that do not fit the 6LoWPAN structure may be unnecessary and may be excluded. Therefore, all the necessary status information can be displayed as a 4-bit status information field.

In this way, the binding confirmation (BA) header 680 needs 160 bits before being compressed, but the compressed binding confirmation (BA) header 690 may only require 32 bits in both the MIPv6 protocol and the NEMO protocol.

As described above, although the present invention has been described by way of limited embodiments and drawings, the present invention is not limited to the above-described embodiments, which can be variously modified and modified by those skilled in the art to which the present invention pertains. Modifications are possible. Accordingly, the spirit of the invention should be understood only by the claims set forth below, and all equivalent or equivalent modifications will fall within the scope of the invention.

1 is a configuration diagram of a 6LoWPAN network to support mobility.

FIG. 2 is a diagram illustrating a configuration of LoWPAN_MH having Dispatch header of 6LoWPAN packet and compression information of mobility protocol to support mobility protocol.

3 is a conceptual diagram illustrating compression of a binding update message of MIPv6 according to the present invention.

4 is a conceptual diagram illustrating compression of a binding update message of the NEMO Basic Support Protocol according to the present invention.

5 is a conceptual diagram illustrating compression of a binding confirmation message between MIPv6 and NEMO Basic Support Protocol according to the present invention.

<Description of the symbols for the main parts of the drawings>

100: Internet network

110: 6LoWPAN Gateway (HA in Mobile Network)

120: 6LoWPAN Gateway (HA on Mobile Node)

130: 6LoWPAN Gateway (FA)

200: mobile node

300: fixed network

310: fixed fan coordinator

320: fixed node

400: mobile network

410: portable fan coordinator

420: mobile network node

500: partner node

600: Pattern and compression information fields for mobility support

610: 6LoWPAN Dispatch header

620: LOWPAN_MH containing compression information and fields of mobility protocol

630: Binding Update (BU) message for uncompressed MIPv6

640: Binding Update (BU) message of MIPv6 compressed according to the present invention

650: Home address option for uncompressed NEMO Protocol binding update (BU) message

660: Binding Update (BU) message for uncompressed NEMO Protocol

670: Binding Update (BU) message of NEMO Protocol compressed according to the present invention

680: Uncompressed Binding Confirmation (BA) Message

690: Binding Confirmation (BA) message compressed by the present invention

Claims (22)

In a method of simultaneously supporting a node-based mobility network and a network-based mobility protocol in a 6LoWPAN network, Setting, in a first header of a 6LoWPAN packet, a bit pattern indicating that a second header following the first header is a compressed IPv6 mobility header (LOWPAN_MH); Setting a first bit indicating whether the binding operation currently performed in the second header is a binding operation according to one of a node-based mobility protocol and a network-based mobility protocol; And And compressing the binding message according to the protocol corresponding to the setting value of the first bit to generate a compressed binding message. The 6LoWPAN mobility support method according to claim 1, wherein the first header is a dispatch header. 2. The method of claim 1, wherein the second header includes a second bit indicating whether the binding operation is a binding update (BU) or a binding confirmation (BA). 4. The method of claim 3, wherein the second header includes a third bit indicating whether a lifetime information field in the binding message is compressed information. 4. The method of claim 3, wherein the second header includes a fourth bit indicating whether a checksum information field in the binding message is compressed information. 4. The method of claim 3, wherein when the binding operation is a binding update (BU), the second header is a fifth bit indicating whether to request a binding confirmation (BA) operation from a destination node, as a home agent (HA) for the destination node. And a sixth bit indicating whether to request an operation, a seventh bit indicating whether the binding message includes a home address, and an eighth bit indicating whether the binding message includes a network prefix. The 6LoWPAN according to claim 3, wherein when the binding operation is binding confirmation (BA), the second header includes fifth to eighth bits indicating status information defined in the 6LoWPAN standard. How to support mobility. In a method of simultaneously supporting a node-based mobility network and a network-based mobility protocol in a 6LoWPAN network, Setting, in a first header of a 6LoWPAN packet, a bit pattern indicating that a second header following the first header is a compressed IPv6 mobility header (LOWPAN_MH); A first bit indicating whether a binding operation currently performed in the second header is a binding operation according to a node-based mobility protocol or a network-based mobility protocol; and whether the binding operation is a binding update (BU) or a binding confirmation (BA). Setting a second bit indicating whether or not); And And compressing the uncompressed binding message to generate a compressed binding message according to a protocol and a binding operation according to the setting values of the first and second bits. 9. The method of claim 8, wherein when the binding operation is a binding update (BU), the compressed binding message comprises: a home address fragment excluding a network prefix from a home address in the uncompressed binding message; And 6LoWPAN mobility support method comprising the SLA ID extracted from the network prefix. 10. The method of claim 9, wherein the compressed binding message further comprises compressed lifetime information obtained by compressing a lifetime field value in the uncompressed binding message. 10. The method of claim 9, wherein the second header includes a third bit indicating whether a lifetime information field in the binding message is compressed lifetime information. The method of claim 9, wherein when the binding operation is a binding update (BU), the second header is A fifth bit indicating whether to request binding confirmation (BA) operation to the destination node, a sixth bit indicating whether to request operation as a home agent (HA) for the destination node, a seventh bit indicating whether the binding message includes a home address, and And a eighth bit indicating whether the binding message includes a network prefix. The method of claim 9, wherein the compressed binding message is 6LoWPAN mobility support method, characterized in that it further comprises a sequence number and compressed lifetime information. The method of claim 8, wherein when the binding operation is a binding confirmation (BA), the compressed binding message includes a sequence number and compressed lifetime information. In a mobile device communicating within a 6LoWPAN network, A mobile device for generating a compressed binding message by performing the 6LoWPAN mobility support method of claim 1. In a 6LoWPAN network consisting of a mobile node and a mobile network, a method of simultaneously supporting a node-based mobility network and a network-based mobility protocol, Receiving a 6LoWPAN packet comprising a first header, a second header and a compressed binding header; Checking from the bit pattern of the first header whether the second header is a compressed IPv6 mobility header (LOWPAN_MH); Determining whether the binding operation currently performed from the first bit of the second header is a binding operation according to one of a node-based mobility protocol and a network-based mobility protocol; Determining from the second bit of the second header whether the binding operation is a binding update (BU) or a binding confirmation (BA); And And restoring an uncompressed binding message from the compressed binding header according to the determined mobility protocol and the type of the binding operation. The method of claim 16, wherein when the mobility protocol is a node-based mobility protocol and the binding operation is a binding update (BU), The compressed binding header may include a home address fragment excluding a network prefix from a home address in the uncompressed binding message; And an SLA ID extracted from the network prefix, Restoring the uncompressed binding message may include extracting the upper 48 bits of a network prefix from a destination address of the compressed binding header; And And combining the upper 48 bits of the network prefix, the home address fragment, and the SLA ID to restore the IPv6 address of the mobile node. The method of claim 16, wherein when the mobility protocol is a network-based mobility protocol and the binding operation is a binding update (BU), The compressed binding header may include a home address fragment excluding a network prefix from a home address in the uncompressed binding message; And an SLA ID extracted from the network prefix, Restoring the uncompressed binding message may include: Extracting the upper 48 bits of a network prefix from the destination address of the compressed binding header; And Recovering the home address of the mobile fan coordinator of the mobile network and the 64-bit network prefix of the mobile network node using the upper 48 bits of the network prefix, the 64-bit home address fragment excluding the network prefix, and the 16-bit SLA ID. 6LoWPAN mobility support method comprising the step. The method of claim 16, wherein the compressed binding header includes a sequence number and compressed lifetime information when the binding operation is binding confirmation (BA). 18. The method of claim 16, wherein the second header includes a third bit indicating whether a lifetime information field in the compressed binding header is in a compressed state. 21. The method of claim 20, wherein when the binding operation is binding update (BU), the second header is A fifth bit indicating whether to request binding confirmation (BA) operation to the destination node, a sixth bit indicating whether to request operation as a home agent (HA) for the destination node, a seventh bit indicating whether the binding message includes a home address, and And a eighth bit indicating whether the binding message includes a network prefix. In a mobile device communicating within a 6LoWPAN network, A mobile device for recovering an uncompressed binding message from a compressed binding header by performing the 6LoWPAN mobility support method of any one of claims 16 to 21.

Images