JP2007074198A

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

Info

Publication number: JP2007074198A
Application number: JP2005257490A
Authority: JP
Inventors: Hiroshi Miyata; 宏宮田
Original assignee: Yokogawa Electric Corp
Current assignee: Yokogawa Electric Corp
Priority date: 2005-09-06
Filing date: 2005-09-06
Publication date: 2007-03-22

Abstract

【課題】
ネットワークケーブルの敷設が困難なエリアや、テロや地震などに代表されるような、ネットワークケーブルや電源が正常に稼動することを期待できないような災害時などに使えるネットワーク通信システムを提供すること。
【解決手段】
IEEE802.15.4に基づき定義されるネットワークを挟むようにIPに基づき定義されるネットワークが両者のプロトコルで使用可能なゲートウェイを介して接続され、一部にIPに基づくパケットが格納されたIEEE802.15.4に基づくパケットが伝送されるネットワーク通信システムであって、
前記ゲートウェイは、IPv6の経路表と、転送先ゲートウェイを示す転送表を有することを特徴とするもの。
【選択図】図１

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(インターネットプロトコル)に基づく通信を行うことは開示されていない。

ところで、ZigBeeネットワークを介してIPに基づき定義される複数のネットワーク間を選択的に接続するのにあたり、例えばIPv6のプロトコルに基づくルーティングが考えられる。この場合、ZigBeeネットワークとIPv6のネットワークとを区別する必要があり、両ネットワーク間における転送制御が必要になる。

また、IEEE802.15.4が規定するフレームサイズは127Byteであり、ZigBeeフレームとしては102Byteである。これはIPv6の最小MTU(Maximum Transfer Unit)値を満たさない。

さらに、IPv6のヘッダは40byteとIEEE802.15.4のネットワークに対して大きいため、そのままIPv6を通すことは非効率であるが、そのヘッダを圧縮できると効率的な通信を提供できることになる。

本発明は、このような従来の問題点に着目したものであり、その目的は、ネットワークケーブルの敷設が困難なエリアや、テロや地震などに代表されるような、ネットワークケーブルや電源が正常に稼動することを期待できないような災害時などに使えるネットワーク通信システムを提供することにある。

このような課題を達成するために、請求項１の発明は、
IEEE802.15.4に基づき定義されるネットワークを挟むようにIPに基づき定義されるネットワークが両者のプロトコルで使用可能なゲートウェイを介して接続され、一部にIPに基づくパケットが格納されたIEEE802.15.4に基づくパケットが伝送されるネットワーク通信システムであって、
前記ゲートウェイは、IPv6の経路表と、転送先ゲートウェイを示す転送表を有することを特徴とする。

請求項２の発明は、請求項１記載のネットワーク通信システムにおいて、
前記IPv6の経路表は、少なくとも、パケットの送信先アドレスと、あて先アドレスのプレフィックス長データと、次ホップアドレスを含むことを特徴とする。

請求項３の発明は、請求項１または請求項２記載のネットワーク通信システムにおいて、
前記転送表は、少なくとも、パケットの送信先アドレスと、あて先アドレスのプレフィックス長データと、転送先ゲートウェイアドレスを含むことを特徴とする。

請求項４の発明は、請求項１記載のネットワーク通信システムにおいて、
前記ゲートウェイは、
送信にあたってはIPに基づくパケットをIEEE802.15.4に基づくパケットのペイロードに収まるように分割するパケット分割部と、
受信にあたっては分割されたIPに基づくパケットを組み立てるパケット組立部、
を有することを特徴とする。

請求項５の発明は、請求項１から請求項４のいずれかに記載のネットワーク通信システムにおいて、
前記IPに基づくパケットのヘッダアドレスは圧縮されていることを特徴とする。

請求項６の発明は、請求項１に記載のネットワーク通信システムにおいて、
前記ネットワークには、一部にIPに基づくパケットが格納されたIEEE802.15.4に基づくパケットが伝送されることを特徴とする。

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

以下、本発明について、図１を用いて説明する。図１は本発明の実施例を示す構成図であり、IPネットワークがIPv6ネットワークとして構成されている例を示している。第１のIPv6ネットワーク７と第２のIPv6ネットワーク８と第３のIPv6ネットワーク９の間にゲートウェイ１０〜１２を介してZigBeeネットワーク１が接続されている。ここで、ゲートウェイ１０〜１２は、ZigBeeとIPv6両方のネットワークプロトコルを使うことができるものとする。

図１において、例えばIPv6機器１４宛のパケットはゲートウェイ１１に送り届けられ、IPv6機器１５宛のパケットはゲートウェイ１２に送り届けられる必要がある。

そこで、本発明では、各ゲートウェイ１０〜１２に、IPv6の経路表と、転送先ゲートウェイを示す転送表を設けている(図１１参照)。なお転送表は、動的に交換する方法と静的に設定する方法が考えれられるが、本実施例では静的に設定する例を説明する。

IPv6の経路表レコードは、一般的に以下のような情報を持つ。
a)あて先アドレス
パケットの送信先アドレスであり、本レコードの対象となるアドレスを示す。パケットは、転送すべきパケットのあて先アドレスと本アドレスの上位Nbitが一致した場合、本レコードに示された転送情報に則って転送される。ここで、Nbitは次に説明するあて先のプレフィックス長で指定された値である。

b)あて先のプレフィックス長（ネットマスク）
a)で指定したあて先アドレスのどの部分をこのレコードの対象とするかを示す。

c)次ホップアドレス
転送すべきパケットのあて先アドレスと、a)で指定したあて先アドレスがb)で指定した長さ分の上位Bitがマッチした場合、転送すべきゲートウェイのアドレスを設定する。実際には、次ホップルータのアドレスや、近隣のノードの下位レイヤのアドレス、インタフェース名なども格納される(16byte以上)。これらのほかにも、各々の次ホップがどのネットワークインタフェースにつながっているかを示す情報なども含まれる。

転送表の各レコードは、少なくとも以下の項目をもつ。
a)あて先アドレス
パケットの送信先アドレスであり、ネットワークアドレス(Prefix)単位や、ホストアドレス単位で指定できるようにする。また、次に示すあて先のプレフィックス長を用いて、プレフィックスをブロックで指定することができる (16byte以上) 。

b)あて先のプレフィックス長
a)で指定した送信先アドレスのどの部分をこのレコードの対象とするかを示す。例えば、転送すべきパケットのあて先アドレスの上位64Bitがマッチした場合、このレコードで指定するゲートウェイに転送する場合は、64を設定する。同様に、128bitすべてのアドレスが一致する求める場合は、128を指定する (1byte以上) 。

c)転送先ゲートウェイ
転送すべきパケットのあて先アドレスと、a)で指定したあて先アドレスがb)で指定した長さ分の上位Bitがマッチした場合、転送すべきゲートウェイのZigBeeアドレスを設定する(2byte以上)。

これらテーブル間において、あて先アドレスへの次ホップがゲートウェイとなるような場合、経路情報ではゲートウェイのアドレスを直接書かずに、仮想インタフェースを指定する。ゲートウェイは次ホップとしてこの仮想インタフェースを指定された場合、さらに転送表から転送先を検索し、該当パケットに対して必要があれば圧縮アドレスの置き換えを行い、必要があればパケット分割処理を行い、次ホップのゲートウェイに転送する。

図1において、IPv6機器１３からIPv6機器１４宛に送信したパケットがゲートウェイ１１に届けられる手順を説明する。なお、図1の各機器やネットワークは、それぞれ以下のようなアドレスを持つものとする。
IPv6ネットワーク７Prefix1: 3ffe:501:ffff:1000::/64
IPv6ネットワーク８Prefix2: 3ffe:501:ffff:2000::/64
IPv6ネットワーク９Prefix3: 3ffe:501:ffff:3000::/64
IPv6機器１３: 3ffe:501:ffff:1000::f
IPv6機器１４: 3ffe:501:ffff:2000::f
IPv6機器１５: 3ffe:501:ffff:3000::f
ゲートウェイ１０_IPv6: 3ffe:501:ffff:1000::1
ゲートウェイ１０_ZigBee: 0x1001
ゲートウェイ１１_IPv6: 3ffe:501:ffff:2000::2
ゲートウェイ１１_ZigBee: 0x1002
ゲートウェイ１２_IPv6: 3ffe:501:ffff:3000::3
ゲートウェイ１２_ZigBee: 0x1003

ゲートウェイ１０は、IPv6の経路表に図２のようなレコードを持つ。ここで、ID1のレコードは、3ffe:501:ffff:1000::/64が、ゲートウェイ１０の実インタフェースがアタッチされているネットワークであることを示している。

またゲートウェイ１０は、転送表に図３のようなレコードを持つ。ここで、ID1のレコードは、3ffe:501:ffff:2000::/64宛のパケットは、ゲートウェイ１１宛に転送することを示している。

これら一連の処理をステップ順に示すと以下のようになる。
1)IPv6機器１３がIPv6機器１４宛にパケットAを送信する。
2)パケットAはゲートウェイ１０に到達する。
3)ゲートウェイ１０は自身のIPv6の経路表を検索し、次ホップとして仮想インタフェース”VIF_ZigBee"を得る。
4)ゲートウェイ１０は自身の転送表を検索し、転送先として、ゲートウェイ１１のZigBeeのアドレス"0x1002"を得る。
5)ゲートウェイ１０は必要に応じて後述のような圧縮アドレスの置き換えを行う。
6)ゲートウェイ１０は必要に応じて後述のようなパケットの分割を行う。
7)ゲートウェイ１０はパケットをZigBeeフレームに乗せ、ゲートウェイ１１宛に送信する。
8)ゲートウェイ１１は必要に応じてパケットを再組立、アドレスの置き換えを行い、ゲートウェイ１１上のIPv6経路表を検索し、適切な次ホップへパケットを転送する。この例では、ゲートウェイ１１はIPv6機器１４のMACアドレスを取得し、そのアドレス宛にパケットを転送する。

これらにより、IPv6ネットワークケーブルの敷設が困難な環境であっても、複数のZigBee機器を相互通信可能な間隔で配置することによって、IPv6ネットワーク間を結ぶことができる。

例えば、地震やテロのように途中経路において電源の供給ができなくなった場合であっても、IEEE802.15.4は電池で稼動させることができるため、状況を選ばす利用することができる。

また、一時的にネットワークを構築できるので、工事現場や移動体などでも利用することができる。

なお、上記実施例では、転送するゲートウェイの経路表において仮想インタフェースを指定して転送表を検索させ、転送表からZigBeeの転送先となるゲートウェイのアドレスを得ているが、ゲートウェイによっては直接、経路表にZigBeeの転送先アドレスを書くことも可能である。

また、受信側のゲートウェイがパケットを組み立てる前に転送表を検索することによって、該当パケットが他のゲートウェイに再度転送されるか否かを判断できる。もし分割された一連のフレームを再度転送する必要がある場合は、パケット組立はオーバーヘッドとなるため先頭パケットにおいて転送の要不要を判断し、それ以降はZigBeeのあて先アドレス、送信元アドレス、フラグメントIDから一連のパケットであると判断して分割されたまま転送することが可能となる。

あるゲートウェイが転送できるIPv6ネットワークプレフィックスが増えたときや接続されたIPv6ネットワークのプレフィックスが変更された場合など、ゲートウェイとその転送できるIPv6プレフィックスの組み合わせ情報を自動で更新できるようにしてもよい。これにより、メンテナンスコストを安く収めることができる。特にゲートウェイの台数が増えたときの効果は大きい。

ところで、図１のネットワーク構成でIPパケットを転送するのにあたり、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機器１３: (3ffe:501:ffff:1000::f)
IPv6機器１４: (3ffe:501:ffff:2000::f)
IPv6機器１５: (3ffe:501:ffff:3000::f)
これらのアドレスに対して、下記のように2Byteのアドレスを割り当てる。
IPv6機器１３: (3ffe:501:ffff:1000::f) => 0x000a
IPv6機器１４: (3ffe:501:ffff:2000::f) => 0x000b
IPv6機器１５: (3ffe:501:ffff:3000::f) => 0x000c
この際、0x000a,0x000b,0x000cはいずれも未アサインのものである必要がある。つまり１つの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部の各フィールドを説明する。
・ペイロード 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に限るものではなく、用途に応じて増減できるものとする。IPv6の経路表２６および転送先ゲートウェイを示す転送表２７は、前述のようにパケットの転送先を指定するための制御を行う。

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

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

これに対し、IPv6ネットワーク８からIPv6ネットワーク７に向かって伝送される分割されたIPパケットデータは、IEEE802.15.4物理層２３およびZigBeeネットワーク層２２を介してパケット組立部２４に入力され、元の大きさのIPパケットに組み立てられる。元の大きさに組み立てられたIPパケットは、Eternetネットワーク層１７およびEternet物理層１６を介してIPv6ネットワーク７に出力される。

なお、ゲートウェイ１０〜１２でのトラフィックの選別にあたっては、帯域が狭いため、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

以上説明したように、本発明によれば、ネットワークケーブルの敷設が困難な地域や、テロや地震などに代表されるようなネットワークケーブルや電源が正常に稼動することを期待できない災害時などに有効なネットワーク通信システムが実現できる。

本発明の一実施例を示す構成図である。 IPv6経路表のレコード例の説明図である。ゲートウェイ転送表のレコード例の説明図である。 ZigBeeのフレームフォーマット構成例図である。 IPv6パケットのパケットフォーマット構成例図である。 IPv6ヘッダの基本部分の構成図である。ゲートウェイ１０が受信するIPv6パケットの説明図である。ゲートウェイ１０が生成するIPv6パケットの説明図である。コンテンツヘッダフォーマット構成例図である。新しいコンテンツヘッダフォーマット構成例図である。ゲートウェイ１０の構成例図である。静的なコンテンツヘッダ構成例図である。アプリケーションサポートサブレイヤフレームフォーマット構成例図である。アプリケーションサポートサブレイヤにおけるFrame Controlの構成例図である。 ZigBeeのフレームフォーマット構成例図である。 ZigBeeネットワークの概念図である。 IPv6やIPv4ネットワーク上にZigBeeパケットを流すネットワークの概念図である。

符号の説明

１ ZigBeeネットワーク
７，８，９ IPv6ネットワーク
１０〜１２ゲートウェイ
１３〜１５ IPv6機器
１６ Eternet物理層
１７ Eternetネットワーク層
１８パケット転送部
１９ホップリミット制御部
２０パケット分割部
２１ ICMPエラーメッセージ転送部
２２ ZigBeeネットワーク層
２３ IEEE802.15.4物理層
２４パケット組立部
２５マッピングテーブル
２６ IPv6の経路表
２７ゲートウェイ転送表

Claims

IEEE802.15.4に基づき定義されるネットワークを挟むようにIPに基づき定義されるネットワークが両者のプロトコルで使用可能なゲートウェイを介して接続され、一部にIPに基づくパケットが格納されたIEEE802.15.4に基づくパケットが伝送されるネットワーク通信システムであって、
前記ゲートウェイは、IPv6の経路表と、転送先ゲートウェイを示す転送表を有することを特徴とするネットワーク通信システム。
前記IPv6の経路表は、少なくとも、パケットの送信先アドレスと、あて先アドレスのプレフィックス長データと、次ホップアドレスを含むことを特徴とする請求項１記載のネットワーク通信システム。
前記転送表は、少なくとも、パケットの送信先アドレスと、あて先アドレスのプレフィックス長データと、転送先ゲートウェイアドレスを含むことを特徴とする請求項１または請求項２記載のネットワーク通信システム。
前記ゲートウェイは、
送信にあたってはIPに基づくパケットをIEEE802.15.4に基づくパケットのペイロードに収まるように分割するパケット分割部と、
受信にあたっては分割されたIPに基づくパケットを組み立てるパケット組立部、
を有することを特徴とする請求項１記載のネットワーク通信システム。
前記IPに基づくパケットのヘッダアドレスは圧縮されていることを特徴とする請求項１から請求項４のいずれかに記載のネットワーク通信システム。
前記ネットワークには、一部にIPに基づくパケットが格納されたIEEE802.15.4に基づくパケットが伝送されることを特徴とする請求項１に記載のネットワーク通信システム。