JP4961718B2

JP4961718B2 - ネットワーク通信システム

Info

Publication number: JP4961718B2
Application number: JP2005320920A
Authority: JP
Inventors: 宏宮田; 慎一藤澤
Original assignee: Yokogawa Electric Corp
Current assignee: Yokogawa Electric Corp
Priority date: 2005-07-28
Filing date: 2005-11-04
Publication date: 2012-06-27
Anticipated expiration: 2025-11-04
Also published as: JP2007060608A

Description

本発明は、ネットワーク通信システムに関し、詳しくは、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に基づき定義されるZigBeeネットワークを挟むようにIPに基づき定義されるネットワークが両者のプロトコルで使用可能なゲートウェイを介して接続され、
前記ゲートウェイは、
送信にあたってはIPに基づくパケットをIEEE802.15.4に基づくフレームのペイロードに収まるように分割するパケット分割部と、
受信にあたっては分割されたIPに基づくパケットを組み立てるパケット組立部と、
前記IEEE802.15.4に基づき定義されるネットワークをIPネットワーク的に１ホップとするホップリミット制御部と、
ICMPエラーメッセージを検出することによりICMPエラーメッセージを先頭の１フレームのみに制限して転送するICMPエラーメッセージ転送部を有し、
前記ネットワークには、一部にIPに基づくパケットが格納されたIEEE802.15.4に基づくフレームが伝送されることを特徴とするネットワーク通信システムである。

これらにより、ネットワークケーブルの敷設が困難なエリアや、テロや地震などに代表されるようなネットワークケーブルや電源が正常に稼動することを期待できない災害時などに使えるネットワーク通信システムが実現できる。

以下、本発明について、図１を用いて説明する。図１は本発明の実施例を示す構成図であり、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物理層１３およびEthernetネットワーク層１４を介してパケット転送部１５に入力され、さらにホップリミット制御部１６に入力される。IPパケットの大きさがZigBeeフレームのペイロードに収まらない場合には、パケット分割部１７で所定の大きさに分割された後、ICMPエラーメッセージ転送部１８、ZigBeeネットワーク層１９およびIEEE802.15.4物理層２０を介してZigBeeネットワーク１に出力される。

ホップリミット制御部１６は、IEEE802.15.4に基づき定義されるネットワーク１をIPネットワーク的に１ホップとして、通過するパケットのホップ数を１つずつ減じるように制御する。

ICMPエラーメッセージ転送部１８は、ICMPエラーメッセージの通過を確認することにより、転送効率を高くするために、先頭の１フレームのみを転送するように制御する。

これに対し、IPv6ネットワーク８からIPv6ネットワーク７に向かって伝送される分割されたIPパケットデータは、IEEE802.15.4物理層２０およびZigBeeネットワーク層１９を介してパケット組立部２１に入力され、元の大きさのIPパケットに組み立てられる。元の大きさに組み立てられたIPパケットは、Ethernetネットワーク層１４およびEthernet物理層１３を介して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部に含まれるデータが分割されたパケットか否かを示す。

この値が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物理層１３およびEthernetネットワーク層１４の例を示しているが、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機器
１３ Ethernet物理層
１４ Ethernetネットワーク層
１５パケット転送部
１６ホップリミット制御部
１７パケット分割部
１８ ICMPエラーメッセージ転送部
１９ ZigBeeネットワーク層
２０ IEEE802.15.4物理層

Claims

IEEE802.15.4に基づき定義されるZigBeeネットワークを挟むようにIPに基づき定義されるネットワークが両者のプロトコルで使用可能なゲートウェイを介して接続され、
前記ゲートウェイは、
送信にあたってはIPに基づくパケットをIEEE802.15.4に基づくフレームのペイロードに収まるように分割するパケット分割部と、
受信にあたっては分割されたIPに基づくパケットを組み立てるパケット組立部と、
前記IEEE802.15.4に基づき定義されるネットワークをIPネットワーク的に１ホップとするホップリミット制御部と、
ICMPエラーメッセージを検出することによりICMPエラーメッセージを先頭の１フレームのみに制限して転送するICMPエラーメッセージ転送部を有し、
前記ネットワークには、一部にIPに基づくパケットが格納されたIEEE802.15.4に基づくフレームが伝送されることを特徴とするネットワーク通信システム。