(57)【要約】【課題】ネットワークケーブルの敷設が困難なエリアや、テロや地震などに代表されるような、ネットワークケーブルや電源が正常に稼動することを期待できないような災害時などに使えるネットワーク通信システムを提供すること。【解決手段】  IEEE802.15.4に基づき定義されるネットワークを挟むようにIPに基づき定義されるネットワークが両者のプロトコルで使用可能なゲートウェイを介して接続され、一部にIPに基づくパケットが格納されたIEEE802.15.4に基づくパケットが伝送されるネットワーク通信システムであって、  前記IPに基づくパケットのヘッダアドレスは圧縮されていることを特徴とするもの。【選択図】                    図１
2007074197.tif 000002
【特許請求の範囲】
【請求項１】
IEEE802.15.4に基づき定義されるネットワークを挟むようにIPに基づき定義されるネットワークが両者のプロトコルで使用可能なゲートウェイを介して接続され、一部にIPに基づくパケットが格納されたIEEE802.15.4に基づくパケットが伝送されるネットワーク通信システムであって、
前記IPに基づくパケットのヘッダアドレスは圧縮されていることを特徴とするネットワーク通信システム。
【請求項２】
前記各ゲートウェイは、前記IPに基づくパケットのヘッダアドレスの圧縮/再組立てを行うことを特徴とする請求項１記載のネットワーク通信システム。
【請求項３】
前記各ゲートウェイは、前記IPに基づくパケットのヘッダアドレスの圧縮/再組立てを行うための共通データベースを有することを特徴とする請求項１または請求項２記載のネットワーク通信システム。
【請求項４】
前記共通データベースはマッピングテーブルであることを特徴とする請求項３記載のネットワーク通信システム。
【請求項５】
前記ゲートウェイは、設定した前記IPに基づくパケットのヘッダアドレスの圧縮ルールを他のゲートウェイに転送することを特徴とする請求項１記載のネットワーク通信システム。
【請求項６】
前記ゲートウェイは、前記IPに基づくパケットのヘッダアドレスの圧縮を自動的に割り当てるとともに、割当てルールを他のゲートウェイに転送することを特徴とする請求項１記載のネットワーク通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク通信システムに関し、詳しくは、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が規定するフレームサイズは127Byteであり、ZigBeeフレームとしては102Byteである。これはIPv6の最小MTU(Maximum Transfer Unit)値を満たさない。
【０００９】
また、IPv6のヘッダは40byteとIEEE802.15.4のネットワークに対して大きいため、そのままIPv6を通すことは非効率であり、そのヘッダを圧縮できると効率的な通信を提供できることになる。現時点では、このIEEE802.15.4に基づくネットワークを使ってIPv6を通過させるという提案はなされていない。
【００１０】
本発明は、このような従来の問題点に着目したものであり、その目的は、ネットワークケーブルの敷設が困難なエリアや、テロや地震などに代表されるような、ネットワークケーブルや電源が正常に稼動することを期待できないような災害時などに使えるネットワーク通信システムを提供することにある。
【課題を解決するための手段】
【００１１】
このような課題を達成するために、請求項１の発明は、
IEEE802.15.4に基づき定義されるネットワークを挟むようにIPに基づき定義されるネットワークが両者のプロトコルで使用可能なゲートウェイを介して接続され、一部にIPに基づくパケットが格納されたIEEE802.15.4に基づくパケットが伝送されるネットワーク通信システムであって、
前記IPに基づくパケットのヘッダアドレスは圧縮されていることを特徴とするネットワーク通信システムである。
【００１２】
請求項２の発明は、請求項１記載のネットワーク通信システムにおいて、
前記各ゲートウェイは、前記IPに基づくパケットのヘッダアドレスの圧縮/再組立てを行うことを特徴とする。
【００１３】
請求項３の発明は、請求項１または請求項２記載のネットワーク通信システムにおいて、
前記各ゲートウェイは、前記IPに基づくパケットのヘッダアドレスの圧縮/再組立てを行うための共通データベースを有することを特徴とする。
【００１４】
請求項４の発明は、請求項３記載のネットワーク通信システムにおいて、
前記共通データベースはマッピングテーブルであることを特徴とする。
【００１５】
請求項５の発明は、請求項１記載のネットワーク通信システムにおいて、
前記ゲートウェイは、設定した前記IPに基づくパケットのヘッダアドレスの圧縮ルールを他のゲートウェイに転送することを特徴とする。
【００１６】
請求項６の発明は、請求項１記載のネットワーク通信システムにおいて、
前記ゲートウェイは、前記IPに基づくパケットのヘッダアドレスの圧縮を自動的に割り当てるとともに、割当てルールを他のゲートウェイに転送することを特徴とする。
【発明の効果】
【００１７】
これらにより、ネットワークケーブルの敷設が困難なエリアや、テロや地震などに代表されるようなネットワークケーブルや電源が正常に稼動することを期待できない災害時などに使えるネットワーク通信システムが実現できる。
【発明を実施するための最良の形態】
【００１８】
以下、本発明について、図１を用いて説明する。図１は本発明の実施例を示す構成図であり、IPネットワークがIPv6ネットワークとして構成されている例を示している。第１のIPv6ネットワーク７と第２のIPv6ネットワーク８の間にゲートウェイ９，１０を介してZigBeeネットワーク１が接続されている。ここで、ゲートウェイ９，１０は、ZigBeeとIPv6両方のネットワークプロトコルを使うことができるものとする。
【００１９】
前述のように、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ヘッダ内のホップリミットを１つ減じる。
【００２５】
図４はIPv6ヘッダの基本部分の構成図である。IPv6ヘッダの基本部分40Byteのうち、Source Address(送信元アドレス)が16Byte、Destination Address(あて先アドレス)が16Byteで合計32Byteになり、80%を占めている。ここで、このアドレス部分を小さくすることができれば、前述のように通信の効率化を図ることができる。具体的にIPv6ヘッダを小さくする方法を以下に説明する。
【００２６】
ゲートウェイ９は、IPv6網７で受け取ったパケットを、ゲートウェイ１０のZigBeeネットワーク上のインタフェースに向けて転送する。IPv6機器１２へパケットを送信するのにあたり、そのパケットをゲートウェイ１０のZigbee側のインタフェースに向けて送ればよいことを知る方法としては、静的な経路制御や動的な経路制御が考えられる。
【００２７】
IPv6の16Byte(128Bit)のアドレスに静的に2Byteのアドレスを割り当てるのにあたっては、例えばそれぞれのゲートウェイ９，１０において手動で行う。ここで、2Byteで表現できる数は65,535であり、IPv6のアドレスで表現できる数に比べると圧倒的に少ない。しかし、限定された用途であれば、十分なアドレス空間といえる
【００２８】
具体的には、図１の各機器が以下のようなアドレスを持つものとする。
IPv6機器１１のIPv6アドレス(3ffe:501:ffff:1::1000)
IPv6機器１２のIPv6アドレス(3ffe:501:ffff:2::2000)
これらのアドレスに対して、下記のように2Byteのアドレスを割り当てる。
IPv6機器１１のIPv6アドレス(3ffe:501:ffff:1::1000)  => 0x000a
IPv6機器１２のIPv6アドレス(3ffe:501:ffff:2::2000)  => 0x000b
この際、0x000a,0x000bはいずれも未アサインのものである必要がある。つまり１つの2Byteのアドレスを二つ以上のIPv6アドレスに割り当ててはいけない。他にもZigBeeネットワークを超えて通信するIPv6の機器があれば、それらも同様に登録する。
【００２９】
必要なアドレスの割り当てを全てのゲートウェイで行うが、その割当内容はどのゲートウェイでも同じ内容であるべきである。この割当情報のデータベースをマッピングテーブルと呼ぶ。全てのゲートウェイが同じマッピングテーブルを持つものとして、以下に実際の動作を示す。
【００３０】
(ａ)IPv6機器１１がIPv6機器１２に対してパケットを送信する。このパケットをパケットＡと呼ぶ。
(ｂ)パケットＡは、ゲートウェイ９に届く。
【００３１】
(ｃ)ゲートウェイ９は図５のIPv6パケットを受信して図６のパケットを生成する。これは送信元および宛先のIPv6アドレスを2Byteのアドレスに置き換えたものでり、このパケットをパケットＢと呼ぶ。パケットＡとパケットＢの差は28Byteとなる。
【００３２】
(ｄ)ゲートウェイ９はZigBeeヘッダにコンテンツヘッダを付加し、さらにパケットＢをそのペイロード部分に付加する。生成したパケットＢをZigBeeフレームのペイロード部分にのせるが、その前にコンテンツヘッダを付加する。このコンテンツヘッダを図７に示す。そして、そのZigBeeフレームをZigBee網に転送する。これは、ZigBeeのネットワーク層の機能により、ゲートウェイ１０に送り届けられる。コンテンツヘッダやパケットの分割が必要となった場合の処理は、アドレスの置き換えを行った後に行うとよい。ここでは、何らかの手法を用いてZigBeeパケットをゲートウェイ１０に送り届けるものとする。
【００３３】
(ｅ)ゲートウェイ１０は、受信したZigBeeフレームからパケットＢを抜き出し、必要があれば再組み立てを行う。ゲートウェイ１０は、抜き出したパケットＢのアドレスとマッピングテーブルから、本来あるべきIPv6アドレスを送信元アドレスと宛先アドレスに置き換えてパケットＡを再現し、第２のIPv6ネットワーク８にパケットＡを送信する。
【００３４】
ZigBeeネットワーク１からくるIPv6パケットは、このようなアドレス置き換えが行われたパケットであるという前提を持てば、ゲートウェイ１０は無条件にアドレス置き換え処理に入ることができるが、アドレス置き換えを行わない使い方や他の将来のヘッダの省略方式等にも対応できるように、コンテンツヘッダにおいて、ヘッダ形式を示せる識別子があるとより拡張性や汎用性が提供できる。具体的には、パケットＢのようなフォーマットのパケットが含まれていることを示すPayload Type値を割り当てる。
【００３５】
図７のコンテンツヘッダを用いて、Payload Typeに以下の値を割り当てる。
Payload Type:4Bit長の値で、Payload部に含まれるデータの種別を示す。
1(0001)：IPv6
2(0010)：IPv4
3(0011)：IPv6 Compressed Header  (パケットBのフォーマット)
【００３６】
(ｆ)ICMP Error Message
第２のIPv6ネットワーク８において、転送したIPv6パケットが何らかの問題により、ICMPv6 Error Messageを引き起こしたとする。これに対しては、以下の３段階で対処する。
ICMPv6メッセージが中間ルータにより送信された場合、そのルータのアドレスは登録されていないことがある。そこで、ゲートウェイ１０は、まずデフォルトとして、アドレス置き換えをせずにそのまま送付する。
次に、ICMPv6 Error Messageのペイロード部分は、元パケットを含んでいる。したがって、ゲートウェイ１０は、IPv6ヘッダのみを置き換える。
そしてさらに、ゲートウェイ１０は、IPv6ヘッダのみならず、ICMPv6のペイロード部分に含まれるIPv6アドレスも変換する。
【００３７】
上記説明におけるアドレスのサイズは2byteとしているが、より用途の制限されたネットワークではもっと小さくすることも可能である。逆に、よりスケーラビリティを確保したい場合はもっと大きくすることも可能である。
【００３８】
設定したアドレスを他のゲートウェイに配布する仕組みとして、上記説明では全てのゲートウェイにおいて同様の設定を行わせているが、一台で設定したアドレスの割当ルールを他のゲートウェイに転送することも考えられる。
【００３９】
上記説明では静的にアドレスの割当を行っているが、動的な割当を行うことも考えられる。また、その際には、割り当てたアドレスルールを他のゲートウェイに通知する必要がある。
【００４０】
上記説明では、パケットＢのようなフォーマットのパケットが含まれていることを示すPayload Type値を割り当てているが、コンテンツヘッダにおいて、Payload TypeにはIPv6の値を入れておき、アドレスが圧縮されていることを示すフラグをコンテンツヘッダ内に持たせることも可能である。
【００４１】
図８は、このような新しいコンテンツヘッダフォーマットの説明図である。図７との差分はData Control内部のみなので、Data Controlの内部について説明する。
・Payload Type：
4Bit長の値、Payload部に含まれるデータの種別を示す。
1(0001)：IPv6
2(0010)：IPv4
・Fragment Flag：
Payload部に含まれるデータが分割されたパケットか、否かを示す。
0：分割されていないパケットが含まれる
1：分割されているパケットが含まれる。
この値が1のときにコンテンツヘッダにフラグメントオフセット、More Flag、ID        のフィールドが含まれる。この値が0のときはこれらのフィールドは含まれない。
・Compress Flag：
ヘッダのアドレス部が2byteに置き換えられたか、否かを示す。
0：通常の16Byteのアドレスを利用している。
1：2byteにおきかえれたアドレスを利用している。
・Reserved：
未使用。0を格納する。
【００４２】
IPパケットのペイロードが十分に小さい場合（例えば20Byte以下）は、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部の各フィールドを説明する。
・Payload Type：
4Bit長の値を有するもので、ペイロードに含まれるデータの種別を示す。
1(0001)：IPv6
2(0010)：IPv4
3(0011)：IPv6 Compressed Header
・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を付加することで得ることができる。再組み立てが終わったパケットは、ネットワーク８に送信する。
【００５５】
ゲートウェイ１０に接続された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ネットワーク１に出力される。マッピングテーブル２２は、IPv6の16Byte(128Bit)のアドレスに静的に例えば2Byteのアドレスを割り当てるためのデータベースとして機能する。なお、IPv6のアドレスに割り当てる圧縮アドレス長は2Byteに限るものではなく、用途に応じて増減できるものとする。
【００５７】
ホップリミット制御部１６は、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パケット全体を転送するか、一部のパケットのみを転送するかを、切り替え可能にしてもよい。
【００６９】
コンテンツヘッダのフォーマットは、IANAによるプロトコルアサイン番号を用いて、かつ、フラグメント情報を固定的に付加するようなコンテンツヘッダも考えられる。図１０に静的なコンテンツヘッダのフォーマットを示す。
【００７０】
現時点では、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パケットのパケットフォーマット構成例図である。
【図４】IPv6ヘッダの基本部分の構成図である。
【図５】ゲートウェイ９が受信するIPv6パケットの説明図である。
【図６】ゲートウェイ９が生成するIPv6パケットの説明図である。
【図７】コンテンツヘッダフォーマット構成例図である。
【図８】新しいコンテンツヘッダフォーマット構成例図である。
【図９】ゲートウェイ９の構成例図である。
【図１０】静的なコンテンツヘッダ構成例図である。
【図１１】アプリケーションサポートサブレイヤフレームフォーマット構成例図である。
【図１２】アプリケーションサポートサブレイヤにおけるFrame Controlの構成例図である。
【図１３】ZigBeeのフレームフォーマット構成例図である。
【図１４】ZigBeeネットワークの概念図である。
【図１５】IPv6やIPv4ネットワーク上にZigBeeパケットを流すネットワークの概念図である。
【符号の説明】
【００８０】
１  ZigBeeネットワーク
７，８  IPv6ネットワーク
９，１０  ゲートウェイ
１１，１２  IPv6機器
１３  Eternet物理層
１４  Eternetネットワーク層
１５  パケット転送部
１６  ホップリミット制御部
１７  パケット分割部
１８  ICMPエラーメッセージ転送部
１９  ZigBeeネットワーク層
２０  IEEE802.15.4物理層
【図１】
2007074197.tif 000003
【図２】
2007074197.tif 000004
【図３】
2007074197.tif 000005
【図４】
2007074197.tif 000006
【図５】
2007074197.tif 000007
【図６】
2007074197.tif 000008
【図７】
2007074197.tif 000009
【図８】
2007074197.tif 000010
【図９】
2007074197.tif 000011
【図１０】
2007074197.tif 000012
【図１１】
2007074197.tif 000013
【図１２】
2007074197.tif 000014
【図１３】
2007074197.tif 000015
【図１４】
2007074197.tif 000016
【図１５】
2007074197.tif 000017