(57)【要約】【課題】ネットワークケーブルの敷設が困難なエリアや、テロや地震などに代表されるような、ネットワークケーブルや電源が正常に稼動することを期待できないような災害時などに使えるネットワーク通信システムを提供すること。【解決手段】  IEEE802.15.4に基づき定義されるネットワークを挟むようにIPに基づき定義されるネットワークが両者のプロトコルで使用可能なゲートウェイを介して接続され、  これらネットワークには、一部にIPに基づくパケットが格納されたIEEE802.15.4に基づくパケットが伝送されることを特徴とするもの。【選択図】                    図１
2007060608.tif 000002
【特許請求の範囲】
【請求項１】
IEEE802.15.4に基づき定義されるネットワークを挟むようにIPに基づき定義されるネットワークが両者のプロトコルで使用可能なゲートウェイを介して接続され、
これらネットワークには、一部にIPに基づくパケットが格納されたIEEE802.15.4に基づくパケットが伝送されることを特徴とするネットワーク通信システム。
【請求項２】
前記ゲートウェイは、
送信にあたってはIPに基づくパケットをIEEE802.15.4に基づくパケットのペイロードに収まるように分割するパケット分割部と、
受信にあたっては分割されたIPに基づくパケットを組み立てるパケット組立部、
を有することを特徴とする請求項１記載のネットワーク通信システム。
【請求項３】
前記ゲートウェイは、
前記IEEE802.15.4に基づき定義されるネットワークをIPネットワーク的に１ホップとするホップリミット制御部を有することを特徴とする請求項１記載のネットワーク通信システム。
【請求項４】
前記ゲートウェイは、
ICMPエラーメッセージを検出することによりICMPエラーメッセージデータを選択的に制限して転送するICMPエラーメッセージ転送部を有することを特徴とする請求項１記載のネットワーク通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク通信システムに関し、詳しくは、IEEE802.15.4により規格化されているZigBee(ジグビー、登録商標)のネットワーク層を用いてIP(インターネットプロトコル)に基づく通信を行うシステムに関するものである。
【背景技術】
【０００２】
図１５はZigBeeネットワークの概念図である。図１５において、ZigBeeネットワーク１はIEEE802.15.4で定義されているネットワークである。ZigBeeネットワーク機器Ａ〜ＦはIEEE802.15.4の規格に適合するものである。IEEE802.15.4で定義されているZigBeeネットワークは、ZigBeeネットワーク機器同士を接続するものであり、パケットをフォワーディングする機能を持つ。これにより、ZigBeeネットワーク機器AからZigBeeネットワーク機器Fの相互間でパケットを送受信することができる。ここで、ZigBeeネットワークはZigBeeネットワーク機器Ａ〜Ｆ同士の通信を行うことを目的とするものであり、本発明のようにIPを通すということを想定していない。
【０００３】
なお厳密な規定に従えば、ZigBeeネットワーク機器はアプリケーション層までZigBeeの仕様に則ったものでなければならないが、本発明ではアプリケーション層までは求めず、ネットワーク層（あるいは、IEEE802.15.4上の相応の機能）までを利用する。
【０００４】
ところで、Internet Engineering Task Force (IETF)では、ZigBeeネットワーク機器をInternet Protocol(IPv6)が使えるようにしようという試みがある。
【０００５】
また、図１６に示すように、第１のZigBeeネットワーク２と第２のZigBeeネットワーク３の間にゲートウェイ４，５を介してIPv6やIPv4ネットワーク６を接続し、このIPv6やIPv4ネットワーク６上にZigBeeパケットを流すことにより、ZigBeeネットワーク機器Ｇ〜Ｌ間での通信を提供するという試みも行われている。
【０００６】
【特許文献１】特表２００５−５１２４６１
【０００７】
特許文献１には、インターネットプロトコルを用いて人に電子情報をルーティングする方法が記載されている。具体的には、機器に対してではなく人に対してアドレスを割り当て、その人の近くにある端末に自分に割り当てられたアドレスを入力することで、その人宛のパケットをその人の近くの機器に送信するようにしたものである。
【０００８】
ここで、ZigBeeは、本人を認証するための装置が持つインターフェースの一つとして記載されているが、本発明のように、ZigBeeネットワークを用いてIP(インターネットプロトコル)に基づく通信を行うことは開示されていない。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
IEEE802.15.4でZigBeeのネットワークフレームフォーマットを使う場合はデータペイロード部が102Byteである。これはIPv6の最小MTU(Maximum Transfer Unit)値を満たさない。現時点では、このIEEE802.15.4に基づくネットワークを使ってIPv6を通過させるという提案はなされていない。
【００１０】
また、IPv6のパケットは40Byte以上のヘッダサイズを持つため、そのままIPｖ6を通すことは非効率である。
【００１１】
本発明は、このような従来の問題点に着目したものであり、その目的は、ネットワークケーブルの敷設が困難なエリアや、テロや地震などに代表されるような、ネットワークケーブルや電源が正常に稼動することを期待できないような災害時などに使えるネットワーク通信システムを提供することにある。
【課題を解決するための手段】
【００１２】
このような課題を達成するために、請求項１の発明は、
IEEE802.15.4に基づき定義されるネットワークを挟むようにIPに基づき定義されるネットワークが両者のプロトコルで使用可能なゲートウェイを介して接続され、
これらネットワークには、一部にIPに基づくパケットが格納されたIEEE802.15.4に基づくパケットが伝送されることを特徴とするネットワーク通信システムである。
【００１３】
請求項２の発明は、請求項１記載のネットワーク通信システムにおいて、
前記ゲートウェイは、
送信にあたってはIPに基づくパケットをIEEE802.15.4に基づくパケットのペイロードに収まるように分割するパケット分割部と、
受信にあたっては分割されたIPに基づくパケットを組み立てるパケット組立部、
を有することを特徴とする。
【００１４】
請求項３の発明は、請求項１記載のネットワーク通信システムにおいて、
前記ゲートウェイは、
前記IEEE802.15.4に基づき定義されるネットワークをIPネットワーク的に１ホップとするホップリミット制御部を有することを特徴とする。
【００１５】
請求項４の発明は、請求項１記載のネットワーク通信システムにおいて、
ICMPエラーメッセージを検出することによりICMPエラーメッセージデータを選択的に制限して転送するICMPエラーメッセージ転送部を有することを特徴とする。
【発明の効果】
【００１６】
これらにより、ネットワークケーブルの敷設が困難なエリアや、テロや地震などに代表されるようなネットワークケーブルや電源が正常に稼動することを期待できない災害時などに使えるネットワーク通信システムが実現できる。
【発明を実施するための最良の形態】
【００１７】
以下、本発明について、図１を用いて説明する。図１は本発明の実施例を示す構成図であり、IPネットワークがIPv6ネットワークとして構成されている例を示している。第１のIPv6ネットワーク７と第２のIPv6ネットワーク８の間にゲートウェイ９，１０を介してZigBeeネットワーク１が接続されている。ここで、ゲートウェイ９，１０は、ZigBeeとIPv6両方のネットワークプロトコルを使うことができるものとする。ただし、本発明では、IP的な宛先とZigBee機器の転送先の対応については対象外とする。
【００１８】
前述のように、IPv6のパケットサイズに対してZigBeeのフレームサイズは大幅に小さいため、効率よくデータを送る仕組みが必要になる。すなわち、ZigBeeのフレームサイズ制限の中で、効率よくIPv6パケットを送信するための仕組みである。
【００１９】
図１において、一方のIPv6機器１１から他方のIPv6機器１２に向けてパケットを送信するのにあたり、パケットを受け取った一方のゲートウェイ９が適切に他方のゲートウェイ１０へ届け、そのパケットを他方のゲートウェイ１０が適切に他方のIPv6機器１２に届ける例について説明を行う。
【００２０】
この目的を達成するためには、IPパケットをそのままZigBeeのフレームに載せる手法が考えられる。ZigBeeのフレームは図２のようにあらわされる。図２において、Frame Controlは本フレームがデータであることを示すものとする。Destination AddressにはZigBeeネットワーク内のあて先アドレスが入り、Source AddressにはZigBeeネットワーク内の送信元アドレスが入る。また、その他のフィールドは、フレームがあて先方向に位置するゲートウェイに到達できるために適切な値を持つものとする。
【００２１】
図２に示すZigBeeフレームフォーマットのペイロード部分には、図３に示すようなIPv6パケットが格納される。拡張性を持たせるために、IPv6パケットの前にコンテンツヘッダとよばれるヘッダを挿入する。このコンテンツヘッダについては後述する。拡張ヘッダのサイズNおよびMは拡張ヘッダの種類に依存する。
【００２２】
送信元は、このパケットのペイロード部分にIPv6パケットを格納してZigBeeネットワーク内のあて先アドレス宛に送る。図１で説明すると、ゲートウェイ９が受信したIPv6パケットをZigBeeのフレームに格納し、ZigBeeネットワークを経由してゲートウェイ１０に送信する。
【００２３】
ゲートウェイ１０は受信したZigBeeフレームのペイロードからIPv6パットを取り出し、IPv6網８に転送する。ゲートウェイ９はIPv6パケットを転送する際にIPv6ヘッダ内のホップリミットを１つ減じる。
【００２４】
IPパケットのペイロードが十分に小さい場合（例えば41Byte以下）は、IPv6パケットをそのまま格納できることから支障はない。非常に小さなデータを送るようにデザインされたネットワークであれば、これで運用が可能となる。
【００２５】
IPv6パケットがZigBeeフレームのペイロードに収まらないサイズになる場合が起こりうる。一般にIPv6ネットワークでは、転送しようとするパケットが転送しようとするネットワーク（リンク）のMTU値よりも大きければ、転送しようとしている機器が転送先のMTU値を通知するためにICMP(Internet Control Message Protocol)v6 Error Message(Packet Too Big)を送信元に送信することが求められている。
【００２６】
しかしながら、IPv6において保証しなければならない最小MTU値は1280 octetであり、これより小さなMTU値は送信元に伝えてはならない。ZigBeeのケースでは、実際には1280 octetより小さなパケットでもZigBeeのペイロードには収まらない。IPv6の仕様上、1280 octetより小さなMTU値を送信元に送ることはできないため、ゲートウェイ９がパケットを分割して転送を行う。
【００２７】
このとき、ゲートウェイ９はMTU=1280にしたPacket Too Bigメッセージを送信することもできるが、ペイロードに対するヘッダサイズが大きくなるため、結果的にPacket Too Bigメッセージを送らないほうが効率的である。一方、１パケットあたりのサイズが大きくなると、パケットの分割や、ゲートウェイ内での再組み立てに必要となる作業領域のサイズも多く必要となるため、Packet Too Bigメッセージを送信するか否か、送信する場合には指定するMTU値をシステムとして固定で持つか、設定可能とすることも考えられる。IPv6のデフォルトでは、Ethernet(登録商標)上のパケットサイズが1500byteであることから、必要があれば1500byteのMTUを通知するものとする。
【００２８】
以下に示すパケットの分割の手法は、上記のPacket Too Bigメッセージを送るか否かによらず利用できる。
【００２９】
ゲートウェイ９からIPv6パケットを分割送信する場合、それを受け取ったゲートウェイ１０が再組み立てをする手法と、IPv6パケットのあて先機器が再組み立てをする場合とが考えられる。IPv6プロトコルでは、途中のルータがパケットを分割しない仕様となっているため、これに従うならば、ZigBeeネットワーク、ここでいうゲートウェイ９とゲートウェイ１０の間をブラックボックス化し、ゲートウェイ９に入っていくパケットはゲートウェイ１０から出てくるときに分割されているべきではない。つまり、ゲートウェイ１０は再組立を行った後、IPv6ネットワーク８に転送すべきである。また、これにより、受信ノードはパケットを再組み立てする必要がなくなるため、この処理に要する負荷が軽減される。仮に、受信側のIPv6機器１２が組み立てるようにすると、分割された各パケットにIPv6ヘッダを付加しなければならないため、ネットワーク効率が悪くなる。
【００３０】
ZigBeeネットワークをブラックボックス化する手法について説明する。ZigBeeでは、分割されたデータを運ぶ仕様は現時点では定義されていない。そこで、分割されたデータを運ぶ仕組みまで含め、以下に説明する。
【００３１】
(a)  送信側（ゲートウェイ９）
IPv6パケットの前に、図４に示すようなコンテンツヘッダを付加して送信する。このコンテンツヘッダは、ZigBeeフレームのペイロードに入っているデータ種別を表す情報をゲートウェイ９，１０で共有するためのものである。
【００３２】
まず、コンテンツヘッダの各フィールドについて説明する。
・Data Control部
このヘッダに続くパケットの種類や性質を表すものである。
【００３３】
・フラグメントオフセット部
このヘッダに続くペイロードの先頭ビットがオリジナルIPv6パケットにおける何バ      イト目に当たるかを示す。上記で、1500byteまでのパケットをZigBee網を通すこと      にしているため、11Bitとしている。この長さは、転送を許容しているIPv6パケット      のサイズに依存する。
【００３４】
・More Flag
このパケットが分割された最後のパケットであるか否かを示す。最後のパケットで      ある場合０を、そうでない場合は１をセットする。
【００３５】
・ID部
パケットが分割されている場合は一連のパケットの元パケットが同じであることを      示すための識別子であり、送信元アドレス、あて先アドレスに加え、この値が一致      したフレームがひとつのパケットに再組み立てされる。
【００３６】
次に、コンテンツヘッダData Control部の各フィールドを説明する。
・ペイロード Type:
4Bit長の値を有するもので、ペイロードに含まれるデータの種別を示す。
【００３７】
1(0001) : IPv6
2(0010) : IPv4
・Fragment Flag:
ペイロードに含まれるデータが分割されたパケットか否かを示す。
【００３８】
0: 分割されていないパケットが含まれる
1: 分割されているパケットが含まれる。
【００３９】
この値が1のときにコンテンツヘッダにフラグメントオフセット、More Flag、I          Dのフィールドが含まれる。この値が0のときはこれらのフィールドは含まれな          い。
【００４０】
・Reserved：
未使用。0を格納する。
【００４１】
(ｂ)  受信側（ゲートウェイ１０）
受信したパケットのコンテンツヘッダのFragment Flagが0の場合、このパケットは分割されていないため、コンテンツヘッダに続くペイロードに含まれているIPv6パケットを抜き出し、IPv6ネットワーク８に送信する。
【００４２】
受信したパケットのコンテンツヘッダのFragment Flagが1の場合、このパケットは分割されているため、ゲートウェイ１０において再組み立てされる。ZigBeeヘッダの送信元アドレスと、あて先アドレスと、コンテンツヘッダのIDが同じものは、元となるパケットが同じであると判断する。これらのパケットにおけるコンテンツヘッダに続くペイロード部分を、コンテンツヘッダのオフセット値にしたがって組み立てる。IPv6パケットの全体の長さは、IPv6パケットのヘッダに含まれるペイロード長フィールドに40byteを付加することで得ることができる。再組み立てが終わったパケットは、ネットワーク８に送信する。最初に到着した分割されたパケットの受信時間から一定時間（例えば60秒）経過しても、分割されたすべてのパケットが到着しなかった場合、そのパケットは破棄される。
【００４３】
ゲートウェイ１０に接続されたIPv6ネットワーク８において問題が発生し、ゲートウェイ９に接続されているIPv6ネットワーク７上のIPv6ホスト宛にエラーメッセージが送られることがある。ゲートウェイ１０がこのようなパケットを受け取った場合は、IEEE802.15.4ネットワーク１を経由してゲートウェイ９へICMPエラーメッセージを転送する。ICMPメッセージがIEEE802.15.4のフレームに入りきらない場合は、上記と同様の分割・再組み立て処理を行うことで、あて先のIPv6アドレスにパケットを届ける。
【００４４】
図５は、図１で用いるゲートウェイ９，１０の構成例図であり、ゲートウェイ９について示している。IPv6ネットワーク７からIPv6ネットワーク８に向かって伝送されるIPパケットデータは、IPv6層の下位層で動作するEthernet物理層１３およびEternetネットワーク層１４を介してパケット転送部１５に入力され、さらにホップリミット制御部１７に入力される。IPパケットの大きさがZigBeeフレームのペイロードに収まらない場合には、パケット分割部１７で所定の大きさに分割された後、ICMPエラーメッセージ転送部１８、ZigBeeネットワーク層１９およびIEEE802.15.4物理層２０を介してZigBeeネットワーク１に出力される。
【００４５】
ホップリミット制御部１６は、IEEE802.15.4に基づき定義されるネットワーク１をIPネットワーク的に１ホップとして、通過するパケットのホップ数を１つずつ減じるように制御する。
【００４６】
ICMPエラーメッセージ転送部１８は、ICMPエラーメッセージの通過を確認することにより、転送効率を高くするために、先頭の１フレームのみを転送するように制御する。
【００４７】
これに対し、IPv6ネットワーク８からIPv6ネットワーク７に向かって伝送される分割されたIPパケットデータは、IEEE802.15.4物理層２０およびZigBeeネットワーク層１７を介してパケット組立部２１に入力され、元の大きさのIPパケットに組み立てられる。元の大きさに組み立てられたIPパケットは、Eternetネットワーク層１４およびEternet物理層１３を介してIPv6ネットワーク７に出力される。
【００４８】
これらにより、IPv6ネットワークケーブルの敷設が困難な環境であっても、複数のZigBee機器を相互通信可能な間隔で配置することによって、IPv6ネットワーク間を結ぶことができる。
【００４９】
例えば、地震やテロのように途中経路において電源の供給ができなくなった場合であっても、IEEE802.15.4は電池で稼動させることができるため、状況を選ばす利用することができる。
【００５０】
また、一時的にネットワークを構築できるので、工事現場や移動体などでも利用することができる。
【００５１】
なお、ゲートウェイ９,１０でのトラフィックの選別にあたっては、帯域が狭いため、IEEE802.15.4ネットワークを通すパケットを選別することで、効率化(最適化)を図ることができる。例えば、IPv6のトラフィッククラスや、Flow Labelといったフィールドで通すべきトラフィックを選別することができる。また、フィルタリングなどにより通すパケットとそうでないものを振り分けてもよい。
【００５２】
ゲートウェイ９,１０における優先制御については、帯域が狭いため、どのパケットを優先的に扱うかを選別することで、効率化(最適化)を図ることができる。例えば、IPv6のトラフィッククラスや、Flow Labelといったフィールドで通すべきトラフィックを選別することができる。
【００５３】
ホップリミットの制御は、ゲートウェイ９の代わりに受信側のゲートウェイ１０において行うことも可能である。ホップリミットを送信側と受信側のいずれで減じるかをシステムとして定義し、一貫性を保つ必要がある。
【００５４】
ゲートウェイ９,１０が許容するIPv6パケットのサイズは、チューニング項目と考えられるので、可変にしておくことが望ましい。これは、ゲートウェイ９,１０がPacket Too Bigメッセージに入れて送るMTUの値によって、オーバーヘッドとなるIPv6ヘッダ数に影響が出てくることに基づく。MTU値が小さいとIPv6ヘッダの占める割合は多くなり、MTU値が大きいとゲートウェイ９,１０の中で十分な作業エリアが必要となるし、パケット一つ一つの遅延が大きくなる。
【００５５】
なお上記説明では、IPv6を転送する仕組みについて説明したが、IPv4についても適用することができる。IPv4を通す場合には、元のパケットにDon't Fragment Flagが設定されていないと通常のIPフラグメントを行うことができるため、受信側でパケットを再組立する必要がなくなる。しかし、分割された各パケットにIPv4ヘッダが必ずつくことからオーバヘッドが大きくなる。したがって、本発明と同様の手法をとることが望ましい。
【００５６】
ICMPv6 Error Messageのパケットサイズは1280Byteまで許容されており、かつ、そのサイズを超えない範囲で、エラーの元となったパケットのより多くの部分を送信する。1280byteのパケットは、ZigBeeのフレームにすると10フレームを超えるため、最初の1フレーム分のみを転送することで効率化を図ることができる。したがって、ICMPv6パケット全体を転送するか、一部のパケットのみを転送するかを、切り替え可能にしてもよい。
【００５７】
図６はIDを拡張したフレームフォーマット例図である。図６のData Control部の各フィールドについて説明する。
【００５８】
・Payload Type:
4Bit長の値、Payload部に含まれるデータの種別を示す。
【００５９】
1(0001) : IPv6
2(0010) : IPv4
・Fragment Flag: Payload部に含まれるデータが分割されたパケットか否かを示す。
【００６０】
0: 分割されていないパケットが含まれる
1: 分割されているパケットが含まれる。
【００６１】
この値が1のときにコンテンツヘッダにフラグメントオフセット、More Flag、I
Dのフィールドが含まれる。この値が0のときはこれらのフィールドは含まれな
い。
【００６２】
・Reserved：未使用。0を格納する。
【００６３】
次にコンテンツヘッダの各フィールドを説明する。
・Data Control部
このヘッダに続くパケットの種類をあらわす。パケットがGatewayを通るだけであれ
ば不要となる。IANAの定義に則らないのであればより小さなサイズにできる。
【００６４】
・フラグメントオフセット部
このヘッダに続くペイロード部の先頭ビットがオリジナルIPv6パケットにおける何
バイト目に当たるかを示す。上記で、1500byteまでのパケットをZigBee網を通すこ
とにしているため11Bit必要である。この長さは、許容しているパケットのサイズに
依存する。
【００６５】
・ID部
パケットが分割されている場合、一連のパケットの元パケットが同じであることを      示すための識別子である。送信元アドレス、あて先アドレスに加え、この値が一致      したフレームがひとつのパケットに再組み立てされる。IDは0から65535までの数字
を繰り返し使う。
【００６６】
コンテンツヘッダのフォーマットは、IANAによるプロトコルアサイン番号を用いて、かつ、フラグメント情報を固定的に付加するようなコンテンツヘッダも考えられる。図７に静的なコンテンツヘッダのフォーマットを示す。
【００６７】
図８は図７のIDを拡張した場合のフォーマットを示す。図８において、フラグメントオフセットのサイズ11bitのフラグメントオフセットは2047までしか表現できない。より大きなサイズのパケットを扱うために、図６のフラグメントオフセットに続くReservedフィールドの一部をフラグメントオフセットに割り当てることが考えられる。図９は、Reservedフィールドの5bitをすべてフラグメントオフセットに割り当てた例を示す。
【００６８】
ペイロード長を含めたフレームフォーマットについて説明する。図６，８，９のフレームフォーマットは、フレームの長さをフレーム外から取得しうることを前提としているため、ペイロード長を入れるフィールドを定義していない。汎用的なソリューションとしては、フレームにペイロード長を入れるほうが好ましいため、ペイロード長がわかるようなフレームを定義することも考えられる。
【００６９】
図１０はペイロード長を含むコンテンツヘッダフォーマットを示す。
・Fragment  Flag:2Bit長
ペイロード部に含まれるデータが分割されたパケットか否か、またどの部分かを
示す。
【００７０】
00: フラグメントなし
01:First Fragment
10:Last Fragment
11:中間フラグメント
【００７１】
・ID:16Bit長
オリジナルパケットの識別子である。送信元アドレス、あて先アドレス、IDが同じ      値であればそれらのフレームは同じパケットの一部であると判断できる。最大数に      達したら０リセットする。
【００７２】
・Payload Type:6Bit 長
ペイロード部に含まれるデータ種別を示す
1(000001)：  IPv6
2(000010)：  IPv4
中間フラグメントとLastフラグメントはCのフォーマットを用いる。
【００７３】
・Fragment #:4Bit 長
フラグメントされたフレームの順番を表す。この値からオフセット位置を算出する      ことができる。フラグメントされた最後のフレーム以外はフレーム長最大までペイ
ロードを埋める必要がある。
【００７４】
・Payload Length:7Bit 長
フラグメントされたフレームのペイロード長を示す。
【００７５】
・Reserved:1 or 3Bit長
0クリア
【００７６】
図１０のフレームフォーマットは、ペイロード長を入れている。しかしフラグメントが必要なケースでは、ペイロードにできるだけたくさんのデータをつめたほうがオーバーヘッド効率が高くなる。したがって、1st Fragmentや中間フラグメントはペイロードに最大のデータを含むものと定義することは自然である。ここで、1st Fragmentおよび中間フラグメントはフレームサイズの最大値と同じサイズを持たなければならないと定義することにより、図１１に示すような暗黙のペイロード長を利用するコンテンツヘッダフォーマットのフレームの利用が可能となる。
【００７７】
・Fragment  Flag:2Bit長
ペイロード部に含まれるデータが分割されたパケットか否か、またどの部分かを示      す。
【００７８】
00: フラグメントなし
01:First Fragment
10:Lastフラグメント
11:中間フラグメント
中間フラグメントとLastフラグメントはCのフォーマットを用いる。
【００７９】
Lastフラグメントが到着した場合、1stフラグメントに含まれるIPv6のペイロード
長からパケット全体のサイズを導くことができる。また、Lastフラグメントに含ま
れるフラグメント順番からオフセット値を導くことができる。オリジナルパケット
の全体長とオフセット値とからLastフラグメントに含まれるペイロード長が算出で
きる。逆に、Lastフラグメント到着時、1stフラグメントが未到着であれば、まず
は、ペイロード長を91byteとして扱い、1stフラグメント到着時に正しい長さを算
出する。もし、物理層レベルでのフレームサイズを知ることができるなど、ほかの
手法でパケットの長さを得ることができるなら、このような計算は必ずしも必要で
はない。
【００８０】
中間フラグメントのフレーム長が102byteでない場合はそのパケットは破棄する。
【００８１】
・ID:16Bit長
オリジナルパケットの識別子。送信元アドレス、あて先アドレス、IDが同じ値であ
ればそれらのフレームは同じパケットの一部であると判断できる。
【００８２】
最大数に達したら０リセットする。
【００８３】
・Payload Type:6Bit 長
ペイロード部に含まれるデータ種別を示す
1(000001)：  IPv6
2(000010)：  IPv4
・Fragment #:4Bit 長
フラグメントされたフレームの順番を示す。この値からオフセット位置を算出する
ことができる。フラグメントされた最後のフレーム以外はフレーム長最大までペイ
ロードを埋める必要がある。
【００８４】
・Payload Length:7Bit 長
フラグメントされたフレームのペイロード長。
【００８５】
・Reserved:2 or 3Bit長
0クリア
【００８６】
現時点では、ZigBeeネットワーク層の仕様において、分割されたデータを運ぶ仕組みが定義されていないが、将来この仕組みが定義された場合には、本発明のパケットを分割、再組立するための仕組みを、ZigBeeネットワーク仕様で置き換えることも可能となる。
【００８７】
なお、図５では、Ethernet物理層１３およびEternetネットワーク層１４の例を示しているが、IEEE.802.11a,11b,11gに基づくFast EthernetやGigabit Ethernetなどを用いてもよい。
【００８８】
ゲートウェイ９,１０上で何らかのZigBeeアプリケーションを動かす必要がある場合、ゲートウェイ９,１０では、そのアプリケーション用のフレームと本発明で用いているIPv6を含んだフレームを区別する必要がある。そのような時は、図１２に示すようなフォーマットのアプリケーションサポートサブレイヤを用いる。具体的には前述図２のペイロード部分（斜線部）にはさらに図１２のようなフォーマットのフレームが格納される。このヘッダにより、パケットが到着したノード上のどの処理部にデータを渡せばよいのかを示すことができる。
【００８９】
図１２のフォーマットにおいて、実際には通常のunicastパケットの送信になるため、Source Endpointは不要となるが、これについては、別項のアプリケーションサポートサブレイヤFrame ControlのIndirect Address Modeにおいて説明する。Destination EndpointやCluster Identifier, Profile Identifierには、IPv6パケットの転送を行う機能についての適切な値を入れる。
【００９０】
図１２のアプリケーションサポートサブレイヤにおけるFrame Controlは、図１３に示すようなフォーマット構成になっている。図１３の各フィールドは、ZigBeeの仕様に則った最適な値を持つものであり、現時点では具体的に以下のような値をとる。
【００９１】
Frame Type：00 (Data)
Delivery Mode : 00 (Normal Unicast)
Indirect Address Mode : 0 (Source Endpointは不要)
Security : 0 (不使用。基本的に0または1のどちらでも可、必要に応じて利用する。)
Ack Request : 0 (不要)
Reserved : 0
【００９２】
図１２のアプリケーションサポートサブレイヤにおけるペイロード部分には、図４に示すコンテンツヘッダに続き図３に示すようなIPv6パケットが格納される。
【００９３】
ZigBeeネットワーク層のフレームにおけるフレームコントロールの中には、図１４に示すようにフレームタイプを指定する2bitのフレームタイプサブフィールドがある。現在、このサブフィールドには、以下のような値が定義されている。
【００９４】
00 : Data
01 : NWK Command
10-11 : Reserved
【００９５】
本発明のように、単にZigBee網を通過するためのフレームとして10または11を割り当てることにより、上記のような通過するためだけのフレームにアプリケーションサポートサブレイヤを利用する必要はなくなるので、効率化を図ることができる。
【００９６】
フレームタイプサブフィールドで、上記のようなトンネリングに使われているパケットに"10"を割り当てた例を以下に示す。
【００９７】
00 : Data
01 : NWK Command
10 : Tunnel
11 : Reserved
【００９８】
以上説明したように、本発明によれば、ネットワークケーブルの敷設が困難な地域や、テロや地震などに代表されるようなネットワークケーブルや電源が正常に稼動することを期待できない災害時などに有効なネットワーク通信システムが実現できる。
【図面の簡単な説明】
【００９９】
【図１】本発明の一実施例を示す構成図である。
【図２】ZigBeeのフレームフォーマット構成例図である。
【図３】IPv6パケットのパケットフォーマット構成例図である。
【図４】コンテンツヘッダフォーマット構成例図である。
【図５】ゲートウェイ９の構成例図である。
【図６】IDを拡張したフレームフォーマット例図である。
【図７】静的なコンテンツヘッダ構成例図である。
【図８】図７のIDを拡張した場合のフォーマット例図である。
【図９】Reservedフィールドの5bitをすべてフラグメントオフセットに割り当てた例を示す。
【図１０】ペイロード長を含むコンテンツヘッダフォーマット例図である。
【図１１】暗黙のペイロード長を利用したコンテンツヘッダフォーマット例図である。
【図１２】アプリケーションサポートサブレイヤフレームフォーマット構成例図である。
【図１３】アプリケーションサポートサブレイヤにおけるFrame Controlの構成例図である。
【図１４】ZigBeeのフレームフォーマット構成例図である。
【図１５】ZigBeeネットワークの概念図である。
【図１６】IPv6やIPv4ネットワーク上にZigBeeパケットを流すネットワークの概念図である。
【符号の説明】
【０１００】
１  ZigBeeネットワーク
７，８  IPv6ネットワーク
９，１０  ゲートウェイ
１１，１２  IPv6機器
１３  Eternet物理層
１４  Eternetネットワーク層
１５  パケット転送部
１６  ホップリミット制御部
１７  パケット分割部
１８  ICMPエラーメッセージ転送部
１９  ZigBeeネットワーク層
２０  IEEE802.15.4物理層
【図１】
2007060608.tif 000003
【図２】
2007060608.tif 000004
【図３】
2007060608.tif 000005
【図４】
2007060608.tif 000006
【図５】
2007060608.tif 000007
【図６】
2007060608.tif 000008
【図７】
2007060608.tif 000009
【図８】
2007060608.tif 000010
【図９】
2007060608.tif 000011
【図１０】
2007060608.tif 000012
【図１１】
2007060608.tif 000013
【図１２】
2007060608.tif 000014
【図１３】
2007060608.tif 000015
【図１４】
2007060608.tif 000016
【図１５】
2007060608.tif 000017
【図１６】
2007060608.tif 000018