JP2010503276A - Ｚｉｇｂｅｅ／ｉｐゲートウェイ - Google Patents

Abstract

ゲートウェイ（１００）は、Ｚｉｇｂｅｅネットワークのようなパーソナル・エリア・ネットワーク（３０）と、インターネット・プロトコル（２０）・ネットワークとの間の通信を可能にする。ゲートウェイ（１００）は、パーソナル・エリア・ネットワークに接続するための第１のインタフェースデバイス（１０２）と、ＩＰネットワークと接続するための第２のインタフェースデバイス（１０４）と、ゲートウェイコントローラ（１０６）とを含む。ある実施形態においては、ゲートウェイコントローラ（１０６）は、ＰＡＮ（３０）内の１以上のクライアント（３２）に対してＩＰインタフェース（１０２）上のポートを割り当て、パーソナル・エリア・ネットワーク（３０）内のクライアント（３２）を対応するポートと関係づけるためのルーティングテーブル（１１０）をメモリに格納し、ルーティングテーブル（１１０）に基づいてパーソナル・エリア・ネットワーク・クライアント（３２）とＩＰネットワーク（２０）との間でメッセージを運ぶ。他の実施形態においては、ゲートウェイ（１００）はゲートウェイプロキシ（１２０）と協力して働いてもよい。

Description

本発明は、概してパーソナル・エリア・ネットワーク（ＰＡＮ）に関し、より詳しくはパーソナル・エリア・ネットワークをＩＰベースのネットワークに接続する方法に関する。

Ｚｉｇｂｅｅ（登録商標）は、低電力、低データレート、低コストの適用例のための、無線ネットワーク規格である。Ｚｉｇｂｅｅは、電池で動くデバイスからデータがまれに低いレートで送信されるような、自動化、制御、監視及び感知のアプリケーションに対してとても適している。Ｚｉｇｂｅｅプロトコルは、電気電子学会（ＩＥＥＥ）８０２．１５．４規格に基づいている。このＩＥＥＥ規格は、制限された電力、ＣＰＵ及びメモリ資源を有する小デバイスのための、短距離、低電力、低データレート無線インタフェースを定める。

Ｚｉｇｂｅｅは広い産業の支持を有するオープン規格である。オープン規格であるために、様々な製造者によって作られたＺｉｇｂｅｅデバイスは協同して動作するだろう。Ｚｉｇｂｅｅプロトコルは、デバイスが容易に追加され、既存のネットワークから容易に取り除かれうる、アドホックなネットワーキングを可能とする。これらの理由のために、Ｚｉｇｂｅｅテクノロジはマシン・ツー・マシン（Ｍ２Ｍ）アプリケーションのための主要な技術の１つとして現れることが期待されている。

Ｚｉｇｂｅｅテクノロジの最大の能力を実現するためには、パーソナル・エリア・ネットワークに存在するＺｉｇｂｅｅデバイスがＩＰネットワークに接続された他のデバイスと通信することを可能とすることが必要だろう。

本発明は、Ｚｉｇｂｅｅパーソナル・エリア・ネットワークのような多様なネットワークと、ＩＰネットワークとの間の通信に関する。ゲートウェイは、ＩＰネットワークに接続するための第１のインタフェースデバイスと、Ｚｉｇｂｅｅネットワークと接続するための第２のインタフェースデバイスと、ゲートウェイコントローラとを含む。ゲートウェイコントローラは、ＩＰネットワークとＺｉｇｂｅｅネットワークとの間のメッセージをルーティングする。

ある実施形態においては、ゲートウェイコントローラは、Ｚｉｇｂｅｅネットワーク内のクライアントに対してＩＰインタフェースデバイス上のポートを割り当てる。ゲートウェイコントローラは、割り当てられたポートを対応するＺｉｇｂｅｅクライアントに関係づけるルーティングテーブルを保守する。ルーティングテーブルは例えば、Ｚｉｇｂｅｅクライアントについてのネットワークアドレスと、対応するポートとを含んでもよい。ゲートウェイに、ＩＰネットワークからメッセージが到着すると、メッセージがどのポートに到着したかが、対応するＺｉｇｂｅｅクライアントのネットワークアドレスを調べるために用いられる。逆に、Ｚｉｇｂｅｅクライアントからのメッセージは、発信したＺｉｇｂｅｅクライアントのネットワークアドレスに基づいて対応するポートへと出力される。

ある実施形態においては、ゲートウェイはＺｉｇｂｅｅクライアントにポートを割り当て、ルーティングテーブルを保守する、ゲートウェイプロキシと協力して動作してもよい。

他の実施形態においては、ゲートウェイコントローラは、ＩＰクライアントからの要求に応答するＺｉｇｂｅｅエージェントを生成することができる、ノードマネージャを含む。Ｚｉｇｂｅｅエージェントは、要求するＩＰクライアントのために、Ｚｉｇｂｅｅネットワークに関するプレゼンスを提供してもよい。Ｚｉｇｂｅｅエージェントは、Ｚｉｇｂｅｅクライアントにとって、他のどんなＺｉｇｂｅｅアプリケーションのようにも見える。Ｚｉｇｂｅｅエージェントは、ＩＰクライアントによって遠隔制御及び遠隔操作されることができる。

ＩＰネットワーク及びＺｉｇｂｅｅパーソナル・エリア・ネットワークを含む、典型的な通信ネットワークを示す。 Ｚｉｇｂｅｅパーソナル・エリア・ネットワークとＩＰネットワークとの間のゲートウェイの典型例を示す。 標準Ｚｉｇｂｅｅプロトコルスタックを示す。 Ｚｉｇｂｅｅパーソナル・エリア・ネットワークとＩＰネットワークとの間のゲートウェイの、実装例を示す。 典型的なゲートウェイと通信するためのメッセージフォーマットを示す。 ゲートウェイによって用いられるルーティングテーブルの典型例を示す。 ゲートウェイを確立するための手順を示す。 ＩＰクライアントからのメッセージをゲートウェイへと送るための手順を示す。 Ｚｉｇｂｅｅパーソナル・エリア・ネットワークとＩＰネットワークとの間のゲートウェイの、実装例を示す。 Ｚｉｇｂｅｅパーソナル・エリア・ネットワークとＩＰネットワークとの間のゲートウェイの、実装例を示す。 ＩＰネットワーク及びＺｉｇｂｅｅパーソナル・エリア・ネットワークを含む、典型的な通信ネットワークを示す。 ＩＰネットワーク及びＺｉｇｂｅｅパーソナル・エリア・ネットワークを含む、典型的な通信ネットワークを示す。 ＩＭＳメッセージをＺｉｇｂｅｅメッセージへと翻訳する手順を示す。 ＩＰネットワーク及びＺｉｇｂｅｅパーソナル・エリア・ネットワークを含む、典型的な通信ネットワークを示す。 Ｚｉｇｂｅｅパーソナル・エリア・ネットワークとＩＰネットワークとの間のゲートウェイの、実装例を示す。 Ｚｉｇｂｅｅエージェントをゲートウェイ上に生成するための手順を示す。 ＩＰネットワーク及びＺｉｇｂｅｅパーソナル・エリア・ネットワークを含む、典型的な通信ネットワークを示す。 Ｚｉｇｂｅｅエージェントを、ゲートウェイ上に生成するための手順を示す。 シリアル通信のためのメッセージフォーマットを示す。

ここで図面を参照すると、本発明に従う通信ネットワーク１０の典型的な実施形態が、図１に示される。通信ネットワーク１０は、ＩＰクライアント２２が属するＩＰネットワーク２０と、１以上のＺｉｇｂｅｅクライアントを備えるＺｉｇｂｅｅネットワーク３０とを含む。Ｚｉｇｂｅｅ規格は、パーソナル・エリア・ネットワーク（ＰＡＮ）のためのプロトコルを詳細に示し、感知、自動化及び制御アプリケーションのためによく適合する。本発明はしかしながら、他の形のＰＡＮとともに用いられてもよく、Ｚｉｇｂｅｅネットワークに限られるものではない。ゲートウェイ１００はＺｉｇｂｅｅネットワーク３０をＩＰネットワーク２０に接続し、ＩＰネットワーク２０に存在するＩＰクライアント２２がＺｉｇｂｅｅネットワーク３０のＺｉｇｂｅｅクライアント３２と通信することを可能にする。Ｚｉｇｂｅｅクライアント３２は、明かり、センサ等のデバイスを制御するために用いられうる。

図２は、一例としてのゲートウェイ１００を示す。ゲートウェイ１００は、ＩＰネットワーク２０と接続するためのＩＰインタフェースデバイス１０２と、Ｚｉｇｂｅｅネットワーク３０と接続するためのＺｉｇｂｅｅインタフェースデバイス１０４と、ゲートウェイコントローラ１０６とを含む。ＩＰインタフェースデバイス１０２は例えば、イーサネット（登録商標）アダプタ、ＩＥＥＥ８０２．１１．ｘ無線インタフェースアダプタ、又はセルラ送受信器を含んでいてもよい。Ｚｉｇｂｅｅインタフェースデバイスは、ＩＥＥＥ８０２．１５．４無線インタフェースアダプタを含んでいてもよい。ゲートウェイコントローラ１０６は、ＩＰインタフェースデバイス１０２を制御するためのＩＰコントローラ１０６Ａと、Ｚｉｇｂｅｅインタフェースデバイス１０４を制御するためのＺｉｇｂｅｅコントローラ１０６Ｂとを含む。ゲートウェイコントローラ１０６は、動作に必要とされるデータとアプリケーションとを格納するための内部又は外部の関連するメモリを備える、１以上のプログラム可能なプロセッサにおけるソフトウェアとして実装されてもよい。

Ｚｉｇｂｅｅ規格は、限られた電力、ＣＰＵ及びメモリ資源を有する小デバイスのための短距離、低電力、低データレート無線インタフェースを規定する、電気電子学会（ＩＥＥＥ）８０２．１５．４規格に基づいている。Ｚｉｇｂｅｅ規格は、Ｚｉｇｂｅｅクライアント３２間のネットワーキングを可能とする、ネットワーク及びアプリケーションレベルのプロトコルのセットを含む。Ｚｉｇｂｅｅクライアント３２は、Ｚｉｇｂｅｅネットワーク３０内のノードを含む。コーディネイタ、ルータ、及びエンドデバイスの３種類のノードが存在する。様々なノードは、スタートポロジ、ツリートポロジ、又はメッシュトポロジによって相互に接続されていてもよい。ネットワークトポロジにかかわらず、それぞれのＺｉｇｂｅｅネットワーク３０は１つの（そして１つだけの）コーディネイタを含む。コーディネイタは、他のノードが参加できるＺｉｇｂｅｅネットワーク３０を構成し、管理する責任を持つ。いくつかの実施形態においてはコーディネイタはまた、Ｚｉｇｂｅｅネットワーク３０の様々なノード間でのメッセージのルーティングのためのバインディングテーブルを保守してもよい。

ツリー又はメッシュトポロジを用いるＺｉｇｂｅｅネットワーク３０は、少なくとも１つのルータの存在を必要とする。ルータは、Ｚｉｇｂｅｅネットワーク３０内の１つのノードから他のノードへのメッセージを転送し、子ノードが接続することを可能とする。ルータは、Ｚｉｇｂｅｅネットワーク３０に参加するエンドデバイスにとってのローカルなコーディネイタとして働く。エンドデバイスは典型的には、特定のタスクを実行する１以上のアプリケーションをホストする。例えばエンドデバイスは、データを収集及び報告し、並びに家庭内の明かりのようなホームデバイスを制御するためのアプリケーションを有してもよい。

Ｚｉｇｂｅｅネットワーク３０内では、それぞれのノードは一意のアドレスによって特定される。Ｚｉｇｂｅｅネットワーク３０は、２つのアドレス指定機構を採用する。それぞれのノードは、ロングアドレス及びショートアドレスを持つ。ＩＥＥＥアドレス又はＭＡＣアドレスとも呼ばれるロングアドレスは、ＩＥＥＥによって割り当てられた、ノードを一意に特定する６４ビットアドレスである。ネットワークアドレスとも呼ばれるショートアドレスは、Ｚｉｇｂｅｅネットワーク３０のノードをネットワークコーディネイタに対して特定する、１６ビットアドレスである。ネットワークアドレスは、ノードがＺｉｇｂｅｅネットワーク３０に参加する時に、コーディネイタ又はルータによって割り当てられる。

ノードは、１以上のユーザアプリケーションをホストしてもよい。例えば、ネットワーク３０内に温度及び湿度を監視するための１つのアプリケーションが存在してもよい。このようなアプリケーションは、ノード上のエンドポイントと呼ばれる。これらのアプリケーションは、Ｚｉｇｂｅｅネットワーク３０の内部又は外部の他のアプリケーションと、メッセージを送受信してもよい。

ノードに到着したメッセージを適切なアプリケーションに向けるために、それぞれのエンドポイントはエンドポイントアドレスによって特定される。エンドポイントアドレスは、ＩＰアドレスにおけるポートに類似している。クライアント３２は、１から２４０まで番号付けされる、最大２４０のアプリケーション又はエンドポイントを有してもよい。エンドポイント２５５は、ブロードキャスト・エンドポイント・アドレスである。エンドポイント２５５に向けられたメッセージは、ノード上の全てのアプリケーションに配達されるだろう。

アプリケーションは、アプリケーションオブジェクトとしてモデル化される。アプリケーションプロファイルは、関連する又は相補的なアプリケーションオブジェクトの間の相互作用(interaction)を定義する。アプリケーションプロファイルは、パブリックであってもプライベートであってもよい。パブリック・アプリケーション・プロファイルは、異なるベンダからのデバイスが協同作業することを可能とする。プライベート・アプリケーション・プロファイルはプロプライエタリな（独占的な）ものである。Ｚｉｇｂｅｅアライアンスは、多くのパブリックプロファイルを提供する。このようなパブリックプラファイルの１つが、Home Control, Lighting Profile（家庭制御、明かりプロファイル）であり、これは家庭環境における明かりレベルを感知及び制御することに焦点を合わせている。このプロファイルは、Light Sensor Monochromatic（明かりセンサ・単色光）、Switch Remote Control（スイッチ遠隔制御）、Switching Load Controller（ロードコントローラのスイッチ）、及びDimmer Remote Control（薄暗さ遠隔制御）を含む多くのデバイスを定義する。

アプリケーションオブジェクトは、オブジェクト属性及びクラスタを介して、他のアプリケーションオブジェクトと通信する。オブジェクト属性は、アプリケーションオブジェクト間で通信される、データアイテムである。それぞれの属性は、自身の一意な識別子を有する。Ｚｉｇｂｅｅ規格は、オブジェクト属性についてのデータ型のセットを定義する。属性のグルーピングはクラスタを含み、クラスタもまた自身の一意の識別子を有する。クラスタ内の属性には、必須のものもあれば任意のものもある。それぞれのクラスタは、２^１６個までの属性を含むことができる。入力クラスタは、他のアプリケーションオブジェクトによって送られることができる属性からなる。例えば、センサを監視するためのアプリケーションオブジェクトは、センサの読み取りの間の時間間隔を制御する「report time（報告時間）」と呼ばれる属性を有してもよい。出力クラスタは、他のアプリケーションオブジェクトにデータを供給する属性を含む。相補的な入力クラスタと出力クラスタとを備えるアプリケーションオブジェクトは、他のアプリケーションオブジェクトと通信することができる。

アプリケーションオブジェクトは、バインディングとして知られているプロセスを介して通信を開始することができる。バインディングは、アプリケーションオブジェクト間の論理的なリンクを生成する。バインディング機構(binding mechanism)は、情報を生成するアプリケーションを、その情報を使用するアプリケーションと結びつける。情報は、クラスタとして交換される。２つのアプリケーションオブジェクトが結びつけられるためには、それらは相補的な入力クラスタと出力クラスタとを持たなければならない。２つのアプリケーションオブジェクトが結びつくと、１つのアプリケーションオブジェクトの出力クラスタは、他のアプリケーションオブジェクトの入力クラスタと接続される。２つのアプリケーションオブジェクト間のバインディングは、クラスタが生成されたアプリケーションオブジェクトのネットワークアドレス及びエンドポイント（ソース）、クラスタを消費するアプリケーションオブジェクトのネットワークアドレス及びエンドポイント（デスティネーション）、並びにそれらの間で送られるクラスタについてのクラスタＩＤによって特定される。結びつけられたアプリケーションオブジェクトは、ＭＳＧ及びＫＶＰメッセージサービスを用いてメッセージを送受信できる。

バインディング情報が格納されている場所に応じて、ソースからデスティネーションへのクラスタ情報の伝送は、直接的又は間接的である。直接アドレッシングでは、情報を送ったノードが、デスティネーション・アプリケーションオブジェクトが存在するノードについてのネットワークアドレスを決定し、そのデスティネーションアドレスをメッセージに挿入する。異なったノードで複数のアプリケーションオブジェクトがメッセージを受け取る場合、メッセージは複製され、少なくとも１つのデスティネーション・アプリケーションオブジェクトが存在するそれぞれのノードに、複製が送られる。間接アドレッシングでは、出力クラスタはコーディネイタに送られる。コーディネイタは、バインディングテーブルを保守している。コーディネイタは送信ノードのソースアドレスとクラスタＩＤとに基づいて、デスティネーションノードを決定する。コーディネイタは、コーディネイタのバインディングテーブルにおいて、ソースクラスタとアプリケーションアドレスとを含むの全てのエントリを見つけ、それぞれの受信ノードに向けたメッセージを生成する。それぞれのメッセージについて、コーディネイタはメッセージ中にバインディングテーブルからのデスティネーションアドレスを挿入する。

Ｚｉｇｂｅｅ規格は、ネットワーク内のＺｉｇｂｅｅクライアント３２が、他のクライアント３２のアドレス及び能力(capability)を発見することを可能にする発見機構(discovery mechanism)を含む。デバイス発見は、Ｚｉｇｂｅｅクライアント３２が、ネットワーク上の他のクライアントのネットワークアドレスを発見するためにネットワーク３０に問い合わせる(query)ことを可能とする。サービス発見は、Ｚｉｇｂｅｅクライアント３２が他のＺｉｇｂｅｅクライアント３２の能力に関する情報を要求することを可能にする。サービス情報は記述子として格納され、Ｚｉｇｂｅｅクライアント３２のデバイス型及び能力のような情報、並びにＺｉｇｂｅｅクライアント３２上で動作しているアプリケーションの型に関する情報を含んでもよい。Ｚｉｇｂｅｅクライアント３２に格納される、３つの必須な記述子と２つの任意的な記述子とが存在する。必須な記述子は、ノード記述子、ノード電力記述子、及び単純記述子である。任意的な記述子は、複合記述子及びユーザ記述子と呼ばれる。それぞれのＺｉｇｂｅｅクライアント３２について、ただ１つのノード記述子及びノード電力記述子が存在する。エンドポイントに属するそれぞれのアプリケーションについて、単純記述子が存在し、複合記述子とユーザ記述子との少なくとも一方が存在することも可能である。

ノード記述子は、Ｚｉｇｂｅｅクライアント３２の型（すなわち、コーディネイタ、ルータ、又はエンドデバイス）及び能力を記述する。Ｚｉｇｂｅｅクライアント３２の能力又はノードの能力とは、使用されている周波数帯及び最大バッファサイズのような属性である。出力記述子は、どのようにクライアント３２が電力を供給されているかに関する情報を含む。このような情報は、電力モード（すなわちデバイスが常に電源が入っているか、又は定期的に起動するか）、利用可能な電源、現在使用されている電源及び現在の電源レベルを含んでもよい。単純記述子は、Ｚｉｇｂｅｅクライアント３２のエンドポイントに属しているアプリケーションに関する情報を含む。この情報は、アプリケーションが存在するエンドポイントアドレス、アプリケーションが実装するアプリケーションプロファイル、及びサポートされている入力クラスタ及び出力クラスタのリストを含む。単純記述子はまた、対応する複合記述子及びユーザ記述子が存在するか否かを示す。

図３は、電気電子学会（ＩＥＥＥ）８０２．１５．４無線通信規格上に構築された、Ｚｉｇｂｅｅプロトコルスタックを示す。ＩＥＥＥ規格は、無線チャネルを介する通信のための短距離無線インタフェースを規定する。ＩＥＥＥ規格は、プロトコルスタックの物理層及び媒体アクセス制御（ＭＡＣ）層についての仕様を含む。Ｚｉｇｂｅｅ規格は、ユーザアプリケーションをサポートするための、ネットワーク層及びアプリケーション層のプロトコル（本明細書では、まとめてＺｉｇｂｅｅスタック又はＺｉｇｂｅｅプロトコルと呼ばれる）のセットを定義する。ネットワーク層は、ネットワークに参加し、及びネットワークから抜けるための、並びにメッセージを適切な行き先に送るための機構を定義する。ネットワーク層はまた、デバイス発見及びサービス発見のための機構も提供する。これらの機構は、Ｚｉｇｂｅｅノードがネットワーク内の他のノードを発見し、そのようなノードの能力を発見することを可能にする。ネットワーク層はまた、Ｚｉｇｂｅｅネットワークの形成を管理し、ネットワークに参加するデバイスにアドレスを割り当てる。

アプリケーション層は、アプリケーションフレームワーク（ＡＦ）、アプリケーション・サポート・サブレイヤー（ＡＰＳ）、及びＺｉｇｂｅｅデバイスオブジェクトを含む。アプリケーションフレームワークは、アプリケーションとＡＰＳとの間のインタフェースを提供する。ＡＰＳは、アプリケーションオブジェクト間の論理的な結合を生成する、バインディング機構を実装する。メッセージがＺｉｇｂｅｅクライアント３２に到着した時、ＡＰＳが適切なアプリケーションにメッセージを配達する責任を持つ。Ｚｉｇｂｅｅデバイスオブジェクト（ＺＤＯ）は、デバイスのＺｉｇｂｅｅノード型（例えば、コーディネイタ、ルータ、又はエンドデバイス）を表す。Ｚｉｇｂｅｅデバイスオブジェクトはまた、Ｚｉｇｂｅｅネットワーク３０上でのデバイス発見及びサービス発見を開始する。

Ｚｉｇｂｅｅプロトコルは、同一のＺｉｇｂｅｅネットワーク３０内の２以上のＺｉｇｂｅｅクライアント３２が、互いに通信することを可能にする。しかしながら、Ｚｉｇｂｅｅプロトコルは、Ｚｉｇｂｅｅクライアント３２が、ＩＰネットワーク２０内のＩＰクライアント２２と通信することを可能にする機構を提供しない。本発明は、このような通信を促進する、ゲートウェイ機能を提供する。

図４は、本発明の一実施形態に従う、一例としてのゲートウェイ１００を示す。ゲートウェイ１００は、ＺｉｇｂｅｅスタックとＴＣＰ／ＩＰスタックの双方を含む。Ｚｉｇｂｅｅスタックは、ＩＥＥＥ８０２．１５．４インタフェース上に実装された従来のＺｉｇｂｅｅスタックである。ＴＣＰ／ＩＰスタックもまた、ゲートウェイ１００がＩＰネットワーク２０内のＩＰクライアント２２と通信することを可能にする。ゲートウェイ１００がＺｉｇｂｅｅスタックを実装するために、ゲートウェイ１００はＺｉｇｂｅｅネットワーク３０に参加することができ、他のＺｉｇｂｅｅクライアント３２と通信することができる。Ｚｉｇｂｅｅクライアント３２にとっては、ゲートウェイ１００は他のどんなＺｉｇｂｅｅクライアント３２にも見え、ゲートウェイ１００はＺｉｇｂｅｅ規格に従って働く。Ｚｉｇｂｅｅクライアント３２上に存在し、ゲートウェイコントローラ１０６と同じプロファイルＩＤを共有するアプリケーションは、通常のＺｉｇｂｅｅメッセージを用いてゲートウエイ１００と通信できる。

Ｚｉｇｂｅｅクライアント３２上に存在するアプリケーションは、ゲートウェイ１００と通信するために標準的なＭＳＧ又はＫＶＰメッセージを用いてもよい。Ｚｉｇｂｅｅクライアント３２とゲートウェイ１００との間の通信のために、１つのＣＩＤ（例えばＣＩＤ＝１）がデータメッセージ（送られ又は受け取られるデータ）のために用いられる。第２のＣＩＤ（例えばＣＩＤ＝２）は、制御メッセージのために用いられる。Ｚｉｇｂｅｅクライアント３２がデータを送ることを望む時、Ｚｉｇｂｅｅクライアント３２はＭＳＧ又はＫＶＰメッセージを、「１」に等しく設定されたＣＩＤとともに、ゲートウェイ１００に送る。データフィールドは、送信されるデータを含む。同様に、ゲートウェイ１００はＩＰクライアント２２からＺｉｇｂｅｅクライアント３２へとデータを転送するために、ＣＩＤ＝１を用いる。Ｚｉｇｂｅｅクライアント及びゲートウェイは、制御メッセージを送るためにＣＩＤ＝２を用いてもよい。代わりに、アプリケーション層メッセージは、図５に示される標準Ｚｉｇｂｅｅメッセージにカプセル化されることもできる。アプリケーション層メッセージについてのメッセージフォーマットは、メッセージ型フィールド、１以上のメッセージパラメータフィールド、及びデータフィールドを含む。メッセージ型フィールドは、メッセージの型を示す。メッセージパラメータフィールドは、メッセージ型について必要とされるパラメータを与える。データフィールドはメッセージデータを含む。

ゲートウェイ１００は、ＩＰネットワーク２０との接続を保守し、Ｚｉｇｂｅｅクライアント３２とＩＰネットワーク２０内のＩＰクライアント２２との間のメッセージを運ぶことに責任を持つ。ゲートウェイ１００は、ＩＰネットワーク２０内のＩＰクライアント２２と、Ｚｉｇｂｅｅネットワーク３０内のＺｉｇｂｅｅクライアント３２との間の論理関係を保守する。これらの論理関係は、例えばゲートウェイ１００のメモリ中に格納された、ルーティングテーブル１１０において保守される。ゲートウェイ１００は、それぞれのＺｉｇｂｅｅクライアント３２に、ゲートウェイＩＰアドレスにおいて一意なＩＰポートを割り当てる。それぞれのＺｉｇｂｅｅクライアント３２について、ルーティングテーブル１１０はＭＡＣアドレス又はショートアドレスと、対応するポート番号とを格納する。メッセージがゲートウエイ１００に到着すると、ゲートウェイ１００はメッセージをどこへ転送するかを決定するためにルーティングテーブル１１０を用いる。ＩＰネットワーク２０から特定のポートに到着したデータは、ルーティングテーブル１１０中で対応するＭＡＣアドレス又はショートアドレスによって特定されるＺｉｇｂｅｅクライアント３２へ送られる。同様に、Ｚｉｇｂｅｅネットワーク３０内のＺｉｇｂｅｅクライアント３２からメッセージがゲートウェイ１００に到着すると、ゲートウェイ１００は発信ノードのＭＡＣアドレス又はショートアドレスを確認し、ルーティングテーブル中で特定される対応するポートへとデータを出力する。

図６は、ルーティングテーブル１１０の実装例を示す。ルーティングテーブル１１０は５つのフィールド：存在、状態、クライアントＩＤ、ポート及び型を含む。クライアントＩＤフィールドは、Ｚｉｇｂｅｅネットワーク３０内の特定のＺｉｇｂｅｅクライアント３２を特定する。このフィールドは、例えばＺｉｇｂｅｅクライアント３２のＭＡＣアドレス又はショートアドレスを含んでいてもよい。ポートフィールドは、Ｚｉｇｂｅｅクライアント３２に割り当てられたポートについてのポート番号を含む。型フィールドは、Ｚｉｇｂｅｅクライアント３２のデバイス型を示す。デバイス型は、Ｚｉｇｂｅｅクライアント３２によって制御されるデバイスの型を示す。例えば、Ｚｉｇｂｅｅクライアント３２は複数のデバイスを制御してもよく、それゆえ２以上のデバイス型を有してもよい。この場合、Ｚｉｇｂｅｅクライアント３２はルーティングテーブル１１０中に２以上のエントリを有してもよい。ＩＰクライアント２２は、Ｚｉｇｂｅｅクライアント３２のリストを、特定されたデバイス型と対応するポート番号とともに取得するために、ゲートウェイ１００に問い合わせを送ってもよい。クライアントＩＤフィールド、ポートフィールド及び型フィールドは、通常は永続的なものであり、ゲートウェイ１００が確立された時に用意される。

存在フィールド及び状態フィールドは、Ｚｉｇｂｅｅクライアント３２に関する状態情報を含む。存在フィールドは、ノードがゲートウェイ１００によって検出されるか否かを示す。このフィールドはノードが検出された時にはＴＲＵＥに設定されてもよく、そうでなければＦＡＬＳＥに設定されてもよい。状態フィールドは現在のポートの状態を示す。ＩＰクライアント２２がポートに接続されている時には、状態は「接続(connected)」であり、そうでなければ「切断(disconnected)」である。

ゲートウェイ１００を構成するための典型的な手順が、図７に示されている。まず、ゲートウェイ１００はＺｉｇｂｅｅネットワーク３０を確立し、又はＺｉｇｂｅｅネットワーク３０に参加する（ブロック１５０）。ゲートウェイ１００は、Ｚｉｇｂｅｅコーディネイタとして、又はＺｉｇｂｅｅルータとして働いてもよい。Ｚｉｇｂｅｅネットワーク３０を確立し又はＺｉｇｂｅｅネットワーク３０に参加した後で、ゲートウェイ１００はデバイス発見及びサービス発見手順を開始する（ブロック１５２）。ゲートウェイ１００は、Ｚｉｇｂｅｅネットワーク３０によって表される全てのデバイス及び能力への完全なアクセスを提供してもよいし、又はこれらのデバイス及び能力のうち限られた一群に対するアクセスを提供してもよい。デバイス発見及びサービス発見についての手順は、Ｚｉｇｂｅｅプロトコルによって詳細に示される。デバイス発見及びサービス発見手順に続けて、ゲートウェイ１００はそれぞれのＺｉｇｂｅｅクライアント３２にポートを割り当て（ブロック１５４）、ルーティングテーブル１１０を構築する（ブロック１５６）。一度ゲートウェイ１００が使用できるようになると、ゲートウェイ１００は新しいデバイス３２及び新しいサービスについてＺｉｇｂｅｅネットワーク３０に定期的に問い合わせ、ルーティングテーブル１１０を更新をしてもよい。ネットワークから欠落したデバイス３２は削除されてもよい。

一度ゲートウェイ１００が動作すると、ＩＰクライアント２２はＺｉｇｂｅｅクライアント３２との通信を確立することができる。また、Ｚｉｇｂｅｅクライアント３２はＩＰクライアント２２との通信を開始してもよい。

図７Ａは、Ｚｉｇｂｅｅネットワーク３０内のＺｉｇｂｅｅクライアント３２に接続するための、ＩＰクライアント２２によって実行される典型的な手順を示す。この例では、Ｚｉｇｂｅｅネットワーク３０内に存在するＺｉｇｂｅｅクライアント３２についての事前の知識を、ＩＰクライアント２２は持っていないことを仮定する。しかしながら、事前の準備又は事前の通信によって、ＩＰクライアント２２はＺｉｇｂｅｅクライアント３２についての事前の知識を持っていることもありうることが、理解されるだろう。ＩＰクライアント２２は、特定のデバイス型に一致するＺｉｇｂｅｅクライアント３２のリストについて、ゲートウェイ１００に問い合わせる（ブロック１６０）。例えば、家庭の明かりを制御するためのＩＰクライアント２２は、明かりを制御するＺｉｇｂｅｅクライアント３２（例えば、デバイス型＝明かり(LIGHT)）について、ゲートウェイ１００に問い合わせてもよい。ゲートウェイ１００は、適合するデバイスのリストを含む、問い合わせへの応答を送る。応答は、明かりの型及び位置に関する情報を含んでもよい。応答を受け取った後で（ブロック１６２）、ＩＰクライアント２２は明かりを制御するＺｉｇｂｅｅクライアント３２に関連する１以上のポートへの接続を開くことができる（ブロック１６４）。接続要求がゲートウェイ１００で受信されると、対応するポートの状態を「切断」から「接続」へと変更するために、ゲートウェイ１００はルーティングテーブル１１０を更新する。ＩＰクライアント２２はそして、Ｚｉｇｂｅｅクライアント３２にメッセージを送る（ブロック１６６）。メッセージ又はデータが「接続」状態を有するポートに到着すると、ゲートウェイ１００はメッセージ又はデータを対応するクライアント３２に転送する。対応するクライアント３２は、ルーティングテーブル１１０中に格納されたＭＡＣアドレス又はショートアドレスによって特定される。一度ＩＰクライアント２２とＺｉｇｂｅｅクライアント３２との間で接続が確立されると、Ｚｉｇｂｅｅクライアント３２はまたＩＰクライアント２２へとメッセージ及びデータを送り返すことができる。Ｚｉｇｂｅｅクライアント３２の観点からは、ゲートウェイ１００はメッセージ又はデータの発信者であり、到着点である。Ｚｉｇｂｅｅクライアント３２はまた、Ｚｉｇｂｅｅゲートウェイ１００に対してメッセージを送ってもよい。ゲートウェイ１００がＺｉｇｂｅｅクライアント３２からメッセージを受け取ると、メッセージはＺｉｇｂｅｅクライアント３２のソースアドレスに対応するポートへと、もしポートが接続状態にあれば、出力される。ポートが接続状態ではなければ、ポートがアクティブではないことを示すために、ＮＡＫが発信Ｚｉｇｂｅｅクライアントへと送られる。

図８は、ＺｉｇｂｅｅスタックとＴＣＰスタックとが異なるプロセッサにおいて実装される、ゲートウェイ１００の代わりの実施形態を示す。この実施形態では、ＩＰインタフェースデバイス１０２とＺｉｇｂｅｅインタフェースデバイス１０４とは、それぞれ別々のプロセッサを含む。ＩＰインタフェースコントローラ１０６ＡはＩＰインタフェースデバイス１０２上に存在し、Ｚｉｇｂｅｅコントローラ１０６ＢはＺｉｇｂｅｅインタフェースデバイス１０４上に存在する。Ｚｉｇｂｅｅスタックは、Ｚｉｇｂｅｅインタフェースデバイス１０４で終結し、一方ＴＣＰスタックはＩＰインタフェースデバイス１０２で終結する。ＩＰインタフェースデバイス１０２及びＺｉｇｂｅｅインタフェースデバイス１０４は、ＩＰコントローラ１０６ＡとＺｉｇｂｅｅコントローラ１０６Ｂとの間の通信を可能とするシリアルバスによって接続される。前に記述されたルーティングテーブル１１０は、ＩＰコントローラ１０６Ａによって保守される。

ＩＰコントローラ１０６ＡとＺｉｇｂｅｅコントローラ１０６Ｂとの間でデータを運ぶために、単純なシリアル通信プロトコルが用いられる。ＩＰコントローラ１０６ＡとＺｉｇｂｅｅコントローラ１０６Ｂとの間でのメッセージを運ぶための、一例としてのメッセージフォーマットが、図１８に示される。このメッセージフォーマットは、メッセージ型フィールド、１以上のメッセージパラメータフィールド、及びデータフィールドを含む。メッセージ型フィールドは、メッセージの型を示す。メッセージパラメータフィールドは、メッセージ型について要求されるパラメータを与える。データフィールドは、メッセージデータを含む。

典型的なメッセージ型は、ＳＥＮＤ、ＣＯＮＮＥＣＴ／ＤＩＳＣＯＮＮＥＣＴ、ＡＣＫ／ＮＡＣＫを含む。メッセージデータを運ぶために、ＳＥＮＤメッセージがＩＰコントローラ１０６ＡとＺｉｇｂｅｅコントローラ１０６Ｂとの間で送られる。ＣＯＮＮＥＣＴ／ＤＩＳＣＯＮＮＥＣＴメッセージは、特定のＩＰクライアント２２への接続を開き又は切るために、Ｚｉｇｂｅｅコントローラ１０６ＢからＩＰコントローラ１０６Ａへと送られる。ＡＣＫ／ＮＡＣＫメッセージは、ＳＥＮＤ又はＣＯＮＮＥＣＴ／ＤＩＳＣＯＮＮＥＣＴメッセージに応答するために用いられる。他のメッセージもまた、定義されうる。

メッセージパラメータは、メッセージ型に応じて変化しうる。例えば、ＳＥＮＤメッセージについてのメッセージパラメータフィールドは、ＡＤＤＲＥＳＳ要素とＤＡＴＡ ＴＹＰＥ要素とを含んでもよい。ＡＤＤＲＥＳＳエレメントは、発信又は着信Ｚｉｇｂｅｅクライアント３２のＭＡＣアドレスを含んでいてもよい。Ｚｉｇｂｅｅネットワーク３０からＩＰネットワーク２０へと進む伝送のために、このフィールドは発信Ｚｉｇｂｅｅクライアント３２のＭＡＣアドレス又はショートアドレスを含んでいるかもしれない。以下で記述されるように、ゲートウェイ１００はこのアドレスを、データが出力される適切なポートを決定するために用いてもよい。ＩＰネットワークからＺｉｇｂｅｅネットワーク３０への通信のために、ＡＤＤＲＥＳＳエレメントは着信Ｚｉｇｂｅｅクライアント３２のＭＡＣアドレス又はショートアドレスを含んでいてもよい。ＤＡＴＡ ＴＹＰＥ要素は、送信されるデータの型、例えばテキスト、オーディオ、ビデオ、バイナリ等を示すために用いられてもよい。

図９は、Ｚｉｇｂｅｅ／ＩＰクライアント２４がＩＰネットワーク２０内に存在することを可能にするゲートウェイを示す。Ｚｉｇｂｅｅ／ＩＰクライアント２４は、ＺｉｇｂｅｅスタックをＩＰスタック上に実装するデバイスである。ＺＩｇｂｅｅ／ＩＰクライアント２４は、標準Ｚｉｇｂｅｅプロトコルを用いて、Ｚｉｇｂｅｅネットワーク３０内のＺｉｇｂｅｅクライアント３２と通信できる。図４に示される実施形態とは対照的に、ゲートウェイ１００はＺｉｇｂｅｅスタックを終結させない。代わりにゲートウェイ１００は、Ｚｉｇｂｅｅクライアント３２から発信されたＺｉｇｂｅｅメッセージ（Ｚｉｇｂｅｅヘッダを含む）を、ＩＰネットワーク２０上でＺｉｇｂｅｅ／ＩＰクライアント２４へと運ぶためのＩＰパケットにカプセル化する。Ｚｉｇｂｅｅ／ＩＰクライアント２４は、受信されたＩＰパケット中のカプセル化されたＺｉｇｂｅｅメッセージをカプセルから出す(decapsulate)ための、ＺｉｇｂｅｅスタックとＴＣＰ／ＩＰ層との間のアダプテーション層（ＡＤＬ）を含む。反対方向においては、ＡＤＬはＺｉｇｂｅｅメッセージをカプセル化し、ゲートウェイ１００がＺｉｇｂｅｅメッセージをカプセルから出す。ＺｉｇｂｅｅスタックがＺｉｇｂｅｅ／ＩＰクライアント２４によって実装されるために、一度ゲートウェイ１００との接続を確立しＺｉｇｂｅｅネットワーク３０に参加すると、Ｚｉｇｂｅｅ／ＩＰクライアント２４はＺｉｇｂｅｅネットワーク３０に対しては、他のどんなＺｉｇｂｅｅクライアントとも同じように見える。Ｚｉｇｂｅｅ／ＩＰクライアント２４がＺｉｇｂｅｅネットワーク３０に参加すると、ゲートウェイ１００はＺｉｇｂｅｅ／ＩＰクライアント２４をルーティングテーブル１１０に加え、他のどんなＺｉｇｂｅｅクライアント３２とも同じようにＺｉｇｂｅｅ／ＩＰクライアント２４に対してポートを割り当てる。Ｚｉｇｂｅｅネットワーク３０内のＺｉｇｂｅｅクライアント３２は、他のどんなＺｉｇｂｅｅクライアント３２とも同じように、Ｚｉｇｂｅｅ／ＩＰクライアント２４を認識し通信することができるだろう。Ｚｉｇｂｅｅ／ＩＰクライアント２４はまた、標準Ｚｉｇｂｅｅ発見メソッドを用いても発見可能だろう。標準Ｚｉｇｂｅｅクライアント３２に対して書かれたアプリケーションはまた、図９に示される実施形態で、Ｚｉｇｂｅｅ／ＩＰクライアント２４によって用いられることが可能である。

ゲートウェイ１００は、標準Ｚｉｇｂｅｅクライアント３２と、ＩＰネットワーク２０内に存在するＩＰマルチメディアサブシステム（ＩＭＳ）クライアント４０との間での通信を促進するために用いられてもよい。ＩＭＳクライアント４０は、ＩＰネットワーク２０へと接続されたホストコンピュータ上に存在するソフトウェアアプリケーションである。ＩＭＳクライアント４０は、セッション開始プロトコル（ＳＩＰ）を実行する。Ｚｉｇｂｅｅクライアント３２上に存在するＩＭＳを認識可能なアプリケーションは、ＩＭＳメッセージとＳＩＰメッセージとの少なくとも一方を生成し、標準Ｚｉｇｂｅｅメッセージへとカプセル化されたＩＭＳメッセージとＳＩＰメッセージとの少なくとも一方をゲートウェイ１００へと送るために、Ｚｉｇｂｅｅプロトコルを用いることができるだろう。この場合、ゲートウェイ１００は単純にカプセル化されたＩＭＳメッセージとＳＩＰメッセージとの少なくとも一方を最終的な行き先へと転送してもよい。しかしながら、ＩＭＳメッセージ及びＳＩＰメッセージは概して大きく、ゲートウェイ１００とＩＰネットワークとの間の接続は、高価であり若しくは非現実的であり、又はこの双方である。それゆえ、ゲートウェイ１００とＩＰネットワーク２０との間のインタフェースを通してＩＭＳメッセージ及びＳＩＰメッセージを送ることは望ましくないかもしれない。

図１０に示される実施形態において、Ｚｉｇｂｅｅクライアント３２上に存在するＩＭＳを認識可能なアプリケーションは、ＩＰネットワーク２０に接続されたＩＭＳユーザ・エージェント・サーバ４２と通信する。ゲートウェイ１００上に存在するユーザ・エージェント・クライアント（ＵＡＣ）４４は、ＵＡＳ４２と通信するために用いられる。ＵＡＳ４２への接続を持つそれぞれのＺｉｇｂｅｅクライアント３２に対する、別々のＵＡＣ４４がインスタンス生成される。Ｚｉｇｂｅｅクライアント３２上に存在するＩＭＳを認識可能なアプリケーションは、ＩＭＳクライアント４０を遠隔制御し、ＩＭＳトランザクションに参加することができる。２００５年４月４０日に出願され、「ネットワーク化された通信デバイスのためのメディア・クライアント・アーキテクチャ(Media Client Architecture for Networked Communication Devices)」と題する米国特許出願番号１１／１１４４２７号は、アプリケーションとの遠隔通信のための、高レベルアプリケーションインタフェースを有するユーザエージェントを記述する。このユーザエージェントは、本発明においてユーザ・エージェント・サーバ４２として働きうる。この出願が、ここに参照により組み込まれる。ＩＭＳクライアント４０をＩＰネットワーク２０内に位置させることにより、ゲートウェイ１００を越える必要があるメッセージはより少なくなるだろう。さらに、Ｚｉｇｂｅｅクライアント３２上に存在するアプリケーションと、ＩＭＳクライアント４０上に存在するアプリケーションとの間で送られるメッセージは、テキストではなくバイナリ型で送られてもよく、メッセージの大きさを大きく減らすだろう。こうして、ゲートウェイ１００を通して送信されるデータは、著しく削減されることができる。

ＩＭＳクライアント４０が、ＩＭＳへの認識(aware)に欠ける工業標準のＺｉｇｂｅｅアプリケーションで通信することが望ましい場合もありうる。このような通信は、図１１に示されるようなメッセージ翻訳器５０の使用によって促進される。メッセージ翻訳器５０は、メッセージ翻訳サービスをも提供するＳＩＰプロキシサーバとして働く。メッセージ翻訳器５０は、ＩＰネットワーク２０に接続されたものとして図１１に示されているが、当業者ならメッセージ翻訳機能がゲートウェイ１００に位置するメッセージ翻訳器５０によって実現されうることを理解するだろう。

例を与えるために、ＩＭＳクライアント４０が、Home Control, Lighting profileに従って動作する１以上のＺｉｇｂｅｅ明かりセンサからの情報を集めることを望むことを仮定する。明かりセンサはＳＩＰユーザ名を割り当てられ、ＳＩＰユーザ名はＳＩＰレジスタに登録されていることが仮定される。図１２は、メッセージ翻訳器５０によって実行される典型的な手順を示す。メッセージ翻訳器５０は、ＩＭＳクライアント４０からＳＵＢＳＣＲＩＢＥメッセージを受け取る（ステップ１７０）。ＳＵＢＳＣＲＩＢＥメッセージは、Ｚｉｇｂｅｅネットワーク３０内の明かりセンサについてのＳＩＰ ＵＲＩを含む。メッセージを受信すると、メッセージ翻訳器５０はＩＭＳクライアント４０によって与えられたＳＩＰユーザ名を用いる従来の方法で、ＳＩＰレジスタからゲートウェイ１００のＩＰアドレスとポートとを取得する（ステップ１７２）。メッセージ翻訳器５０は次に、メッセージを標準Ｚｉｇｂｅｅメッセージへと変換し（ステップ１７４）、メッセージを１以上のＩＰパケットにカプセル化し（ステップ１７６）、ＩＰパケットをゲートウェイ１００へと転送する（ステップ１７８）。ゲートウェイ１００は、ＩＰパケットからカプセル化されたＺｉｇｂｅｅメッセージを抽出し、前に記述したようにカプセル化されたＺｉｇｂｅｅメッセージを明かりセンサを制御するＺｉｇｂｅｅクライアント３２へと転送する。

図１３は、ＩＰクライアント２２と通信するために、ＩＰネットワーク２０と接続されたゲートウェイプロキシ１２０を用いる実施形態を示す。ゲートウェイプロキシ１２０は、ゲートウェイ１００とＩＰネットワーク２０との間のリンクが高価か信頼できないかの少なくとも一方であり、ゲートウェイ１００との継続した接続を維持することが望ましくない又は非実用的である場合に、有用であるかもしれない。ゲートウェイプロキシ１２０はゲートウェイ１００とは物理的に離れているが、論理的にはゲートウェイ１００の一部だと考えられてもよい。この実施形態では、ＩＰクライアント２２との接続を維持する仕事は、ゲートウェイ１００からゲートウェイプロキシ１２０へと移動させられる。多重通信リンクは、ゲートウェイ１００をゲートウェイプロキシ１２０へと接続する。ゲートウェイプロキシ１２０はまた、ＺｉｇｂｅｅメッセージフォーマットとＩＭＳメッセージフォーマットとを翻訳するメッセージ翻訳器５０として働くこともできるだろう。ゲートウェイプロキシ１２０は、ＩＰネットワーク２０に接続されたサーバ上に存在するソフトウェアアプリケーションとして実装されてもよい。

ゲートウェイ１００のＩＰコントローラ１０６Ａの主要な役割は、ゲートウェイプロキシ１２０と接続し、Ｚｉｇｂｅｅクライアント３２とゲートウェイプロキシ１２０との間のメッセージを転送することである。ゲートウェイプロキシ１２０は、前に記述したようにＺｉｇｂｅｅクライアント３２にポートを割り当て、ルーティングテーブル１１０を保守する。Ｚｉｇｂｅｅクライアント３２と通信することを望むＩＰクライアント２２は、ゲートウェイプロキシ１２０に接続する。図１３に示されるようなゲートウェイプロキシ１２０の使用は、ゲートウェイ１００が少ないメモリしか有さない低電力無線デバイスに実装されることを可能にする。ゲートウェイプロキシ１２０は、より大きなメモリとより大きな電力とを有することができる。ゲートウェイプロキシ１２０はデータをバッファでき、ゲートウェイ１００とのリンクが遮断された時であってもＩＰクライアント２２とのリンクを維持できる。同様に、ゲートウェイ１００はゲートウェイプロキシ１２０とのリンクが遮断された時に、データをバッファできる。

図１４は、Ｚｉｇｂｅｅエージェント１０８を用いてＺｉｇｂｅｅクライアント３２とＩＰクライアント２２との間の通信を可能とする実施形態を示す。Ｚｉｇｂｅｅエージェント１０８は、ゲートウェイ１００上に存在する、標準Ｚｉｇｂｅｅアプリケーションプロファイルによって定義されるＺｉｇｂｅｅアプリケーションを含む。Ｚｉｇｂｅｅエージェント１０８は、ＩＰクライアント２２によって遠隔設定されることができ、ＩＰクライアント２２の指示及び制御の下、仕事を実行するためにＺｉｇｂｅｅネットワーク３０に参加することができる。Ｚｉｇｂｅｅエージェント１０８の使用は、ＩＰクライアント２２が、ＩＰネットワーク２０への認識に欠ける工業標準のＺｉｇｂｅｅアプリケーションと相互作用することを可能にする。

例として、ＩＰクライアント２２がＺｉｇｂｅｅネットワーク３０内の明かりセンサを監視することを望むことを仮定する。ＩＰクライアント２２はゲートウェイ１００と接続し、Ｚｉｇｂｅｅエージェント１０８が明かりセンサを監視するために生成されることを要求してもよい。この例ではゲートウェイ１００は、明かりセンサとのバインディングを可能とする、プロファイルＩＤとクラスタＩＤとを有するＺｉｇｂｅｅエージェント１０８を生成するだろう。Ｚｉｇｂｅｅエージェント１０８は、標準Ｚｉｇｂｅｅ明かりセンサから明かりセンサ読み取り値を受け取り、それらの読み取り値をＩＰクライアント２２へと転送してもよい。Ｚｉｇｂｅｅ明かりセンサは、どんな特別な能力も必要としない。

Ｚｉｇｂｅｅエージェント１０８を実装するために、Ｚｉｇｂｅｅコントローラ１０６Ｂは、Ｚｉｇｂｅｅエージェント１０８をインスタンス生成するためのノードマネージャ１１２を含む。ノードマネージャ１１２は、ＩＰクライアント２２と直接通信するための、ゲートウェイ上の専用のポートを割り当てられてもよい。それぞれのＺｉｇｂｅｅエージェント１０８は、ルーティングテーブル１１０に格納される一意のポートを割り当てられる。ＩＰクライアント２２は、Ｚｉｇｂｅｅエージェント１０８を生成するために、ノードマネージャ１１２に要求を送ってもよい。Ｚｉｇｂｅｅエージェント１０８がノードマネージャ１１２によってインスタンス生成される時は、Ｚｉｇｂｅｅエージェント１０８はＩＰコントローラ１０６ＡにＺｉｇｂｅｅエージェント１０８に対してポートを割り当てることと、対応するポートとともにＺｉｇｂｅｅエージェント１０８に関係するエントリをルーティングテーブル１１０に加えることとを要求する。ＩＰコントローラ１０６Ａは、ノードマネージャ１１２に割り当てられたポートを返し、ノードマネージャ１１２はＩＰクライアント２２に通知する。代わりに、ＩＰコントローラ１０６Ａは、ポートを割り当てた後にＩＰクライアント２２に対し直接メッセージを送ることもできるだろう。一度Ｚｉｇｂｅｅエージェント１０８がインスタンス生成され、ポートが割り当てられると、ＩＰクライアント２２は割り当てられたポートを用いてＺｉｇｂｅｅエージェント１０８と直接通信することができる。ゲートウェイ１００は、Ｚｉｇｂｅｅエージェント１０８とＩＰクライアント２２との間の通信を、Ｚｉｇｂｅｅクライアント３２と同じように扱う。

図１５は、ゲートウェイ１００上にＺｉｇｂｅｅエージェント１０８を確立するための典型的な手順を示す。ＩＰクライアント２２は、ノードマネージャ１１２にＺｉｇｂｅｅエージェント１０８を生成するための要求を送る（ステップａ）。要求は、生成されるエージェント１０８の型を定義するパラメータを含む。例えば、要求は標準的なＺｉｇｂｅｅアプリケーションプロファイルに対応する、標準的なプロファイルＩＤとクラスタＩＤとの少なくとも一方を含んでいてもよい。要求はまた、Ｚｉｇｂｅｅエージェント１０８がバインドされるべきである、Ｚｉｇｂｅｅネットワーク３０内の他のＺｉｇｂｅｅアプリケーションを特定してもよい。要求に応えて、ノードマネージャ１１２は要求によって明記されたようにＺｉｇｂｅｅエージェント１０８をインスタンス生成し、Ｚｉｇｂｅｅエージェント１０８とＺｉｇｂｅｅネットワーク３０内の１以上のＺｉｇｂｅｅアプリケーションとのバインディングを開始する（ステップｂ）。ノードマネージャ１１２はまた、ＩＰコントローラ１０６Ａに、ポート割り当ての要求を送る（ステップｃ）。ＩＰコントローラ１０６Ａは、新しく生成されたＺｉｇｂｅｅエージェント１０８にポートを割り当て、割り当てられたポートをノードマネージャ１１２に返す（ステップｄ）。ノードマネージャ１１２はＩＰクライアント２２に応答し、Ｚｉｇｂｅｅエージェント１０８の生成を確認し、そのＺｉｇｂｅｅエージェント１０８に対して割り当てられたポートをＩＰクライアント２２に与える（ステップｅ）。ＩＰクライアント２２及びＺｉｇｂｅｅエージェント１０８はすると、ＩＰコントローラ１０６Ａのサービスを用いて通信することが可能となる（ステップｆ）。

図１６は、前の実施形態からの要素を結合する実施形態を示す。この実施形態は、図１３に示されるゲートウェイ１００と、プロキシ１２０と、ユーザ・エージェント・サーバ（ＵＡＳ）４２とを含む。この実施形態におけるプロキシ１２０は、ＩＭＳを認識可能なＺｉｇｂｅｅクライアント３２の代わりにＵＡＳ４２との接続を確立するために用いられる、１以上のＩＭＳユーザ・エージェント・クライアント４４を含む。別々のＩＭＳユーザクライアント（ＵＡＣ）４４が、それぞれのＩＭＳを認識可能なＺｉｇｂｅｅクライアント３２について生成される。プロキシ１２０もまた、ＵＡＣ４４を有する。ゲートウェイ１００は、前に記述したように、Ｚｉｇｂｅｅエージェント１０８をインスタンス生成するためのノードマネージャ１１２を含む。ゲートウェイ１００とプロキシ１２０との双方が、どちらかの末端がデータを受信することが不可能であるか、又はゲートウェイ１００をＩＰネットワーク２０と接続するＩＰリンクが遮断された時に、データトラフィックをバッファすることが可能である。ゲートウェイ１００のこの実施形態は、ＩＭＳクライアント４０と、ＩＭＳを認識可能なＺｉｇｂｅｅクライアント３２とＩＭＳを認識可能でないＺｉｇｂｅｅクライアント３２との双方との、通信を可能にする。

図１７は、ＩＭＳクライアント４０とＩＭＳを認識可能でないＺｉｇｂｅｅクライアント３２との間の通信を確立するための典型的な手順を示す。ＩＭＳクライアント４０は、Ｚｉｇｂｅｅエージェント１０８を生成するための要求を、ノードマネージャ１１２へと送る（ステップａ）。要求は、生成されるエージェント１０８の型を定義するパラメータを含む。例えばこの要求は、標準Ｚｉｇｂｅｅアプリケーションプロファイルに対応する、標準プロファイルＩＤとクラスタＩＤとの少なくとも一方を含んでもよい。この要求はまた、Ｚｉｇｂｅｅエージェント１０８のバインド先となるべき、Ｚｉｇｂｅｅネットワーク３０内の他のＺｉｇｂｅｅアプリケーションを特定してもよい。要求に応えてノードマネージャ１１２は、要求によって明記されたようにＺｉｇｂｅｅエージェント１０８をインスタンス生成し、Ｚｉｇｂｅｅエージェント１０８とＺｉｇｂｅｅネットワーク３０内の１以上の他のＺｉｇｂｅｅアプリケーションとのバインディングを開始する（ステップｂ）。ノードマネージャ１１２はまた、ＩＰコントローラ１０６Ａに、ポート割り当ての要求を送る（ステップｃ）。ＩＰコントローラ１０６Ａは、新しく生成されたＺｉｇｂｅｅエージェント１０８にポートを割り当て、割り当てられたポートをノードマネージャ１１２に返す（ステップｄ）ノードマネージャ１１２は、プロキシ１２０に対し、新しく生成されたＺｉｇｂｅｅエージェントと組にされるＩＭＳユーザ・エージェント・クライアント４４を、生成し又は割り当てる要求を送る（ステップｅ）。プロキシは、ＩＭＳユーザ・エージェント・クライアント４４を割り当て又は生成し（ステップｆ）、ＩＭＳユーザ・エージェント・クライアント４４の確認を、トランザクションを開始したＩＭＳクライアント４０と、ノードマネージャ１１２との双方に送る（ステップｇ）。ノードマネージャ１１２は、確認をＺｉｇｂｅｅエージェント１０８へと転送する。確認は、イベント名又はイベントＩＤとＭＩＭＥ型とともに、新しいＺｉｇｂｅｅエージェントから送られる全てのＳＴＡＴＥ命令について用いられるだろう、新しいＩＭＳユーザエージェントについてのＵＲＩを含む。ＩＭＳクライアント４０はここで、プロキシ１２０からの確認において受け取られたＵＲＩ、イベントＩＤ又はイベント名、及びＭＩＭＥ型とともに、ＳＵＢＳＣＲＩＢＥ要求をＩＭＳユーザ・エージェント・サーバ４２へと送ることにより、新しいＺｉｇｂｅｅエージェントに関連するイベントにサブスクライブしてもよい（ステップｈ）。バインドされたクラスタＩＤのＺｉｇｂｅｅエージェント１０８によって受け取られた全てのＺｉｇｂｅｅメッセージは、ＩＭＳ ＳＴＡＴＥ命令メッセージ中に埋め込まれ、メッセージがＩＭＳ ＵＡ ＳＴＡＴＥメッセージにフォーマットされるプロキシ１２０に送られる。メッセージはそして、ＩＭＳユーザ・エージェント・クライアント４４及びＩＭＳユーザ・エージェント・サーバ４２を介してＩＭＳクライアント４０に転送される（ステップｉ）。他の実施形態ではＵＡＣ４４は、Ｚｉｇｂｅｅエージェント１０８から直接ＩＭＳクライアント４０へとメッセージを転送するように構成されることもできるだろう。ＩＭＳクライアント４０はまた、Ｚｉｇｂｅｅ ＭＳＧ及びＫＶＰメッセージを、ＩＭＳ ＭＳＧメソッドを用いて、Ｚｉｇｂｅｅネットワーク３０上のどんなＺｉｇｂｅｅクライアントへも送ってよい。ＺｉｇｂｅｅメッセージはＩＭＳ ＭＳＧリクエスト中にカプセル化され、ゲートウェイ１００上のＺｉｇｂｅｅエージェント１０８へと送られる。

当業者なら、Ｚｉｇｂｅｅエージェント１０８とＩＭＳクライアント４０との間の通信を確立するための上述の技術が、ＳＵＢＳＣＲＩＢＥメソッド以外の標準ＳＩＰメソッドとともに使われることもできるだろうことを、理解するだろう。

本発明はもちろん、本発明の範囲及び必須の特徴から逸脱することなく、本明細書で説明された以外の他の特定の方法で実行されてもよい。本実施形態はそれゆえ、あらゆる観点において、説明的なものであって、制限的なものではないと考えられるべきである。また、添付の請求の範囲の意図する範囲内、並びにその均等範囲内となる全ての変更は、本発明に含まれることが意図されている。

Claims (26)

1. パーソナル・エリア・ネットワーク（ＰＡＮ）（３０）とインターネット・プロトコル（ＩＰ）・ネットワーク（２０）との間でメッセージを送信する方法であって、
   前記ＰＡＮ（３０）内の１以上のＰＡＮクライアント（３２）に対して、ＩＰインタフェース（１０２）上のポートを割り当てる工程と、
   前記ＰＡＮ（３０）内の前記ＰＡＮクライアント（３２）を、前記ＰＡＮクライアント（３２）に対応するポートと関係づけるためのルーティングテーブル（１１０）を、メモリに格納する工程と、
   前記ルーティングテーブルに基づいて、前記ＰＡＮクライアント（３２）と前記ＩＰネットワーク（２０）との間でメッセージを運ぶ工程とを含むことを特徴とする工程。
2. 前記ルーティングテーブル（１１０）に基づいて前記ＰＡＮクライアント（３２）と前記ＩＰネットワーク（２０）との間でメッセージを運ぶ工程は、前記ＩＰネットワーク（２０）において発せられたメッセージを、どのポートで前記メッセージが受け取られたかに基づいて、前記ＰＡＮ（３０）内の対応するクライアント（３２）に運ぶ工程を含むことを特徴とする、請求項１に記載の方法。
3. 前記メッセージはＩＰパケットにカプセル化され、
   前記工程はさらに前記メッセージをカプセルから出す工程と、
   前記カプセルから出されたメッセージを前記クライアント（３２）へと送る工程とを含むことを特徴とする、請求項２に記載の方法。
4. 前記ルーティングテーブル（１１０）に基づいて前記ＰＡＮクライアント（３２）と前記ＩＰネットワーク（２０）との間でメッセージを運ぶ工程は、前記ＰＡＮ（３０）内の発信したクライアント（３２）から受け取ったメッセージを、前記発信したクライアントに割り当てられたポートに出力する工程を含むことを特徴とする、請求項１に記載の方法。
5. 前記メッセージをＩＰパケットにカプセル化する工程と、
   前記対応するポートに前記ＩＰパケットを出力する工程とをさらに含むことを特徴とする、請求項４に記載の方法。
6. 前記ＩＰインタフェースは、前記ＰＡＮ（３０）と前記ＩＰネットワーク（２０）との間のゲートウェイ（１００）に位置することを特徴とする、請求項１に記載の方法。
7. 前記ルーティングテーブル（１１０）は、前記ルーティングテーブル内（１１０）に、前記ＰＡＮクライアント（３２）のデバイス型を指し示す情報を含むことを特徴とする、請求項１に記載の方法。
8. パーソナル・エリア・ネットワーク（ＰＡＮ）（３０）をインターネット・プロトコル（ＩＰ）・ネットワーク（２０）に接続するためのゲートウェイ（１００）であって、
   前記ＰＡＮ（３０）に接続するためのＰＡＮインタフェース（１０４）と、
   前記ＩＰネットワーク（２０）に接続するための、１以上のポートを含むＩＰインタフェース（１０２）と、
   前記ＰＡＮ（３０）内のそれぞれのクライアント（３２）に対して、前記ＩＰインタフェース（１０２）上のポートを割り当て、前記ＰＡＮ（３０）内のＰＡＮクライアント（３２）と前記ＩＰネットワーク（２０）との間でメッセージを運ぶための、ゲートウェイコントローラ（１０６）と、
   前記ＰＡＮ（３０）内の前記クライアントを前記ＩＰインタフェース（１０２）上の対応するポートと関係づけるためのルーティング情報を、格納するためのメモリとを備えることを特徴とする、ゲートウェイ（１００）。
9. 前記ゲートウェイコントローラ（１０６）は、前記ＩＰネットワーク（２０）からのメッセージを、どのポートで前記メッセージが受け取られたかに基づいて、前記ＰＡＮ（３０）内の対応するクライアントに運ぶことを特徴とする、請求項８に記載のゲートウェイ（１００）。
10. 前記ゲートウェイコントローラ（１０６）はさらに、前記ＩＰネットワーク（２０）から受け取った前記メッセージをカプセルから出すことを特徴とする、請求項９に記載のゲートウェイ（１００）。
11. 前記ゲートウェイコントローラ（１０６）は、前記ＰＡＮ（３０）内のクライアント（３２）からのメッセージを、前記クライアント（３２）のアイデンティティに基づいて、対応するポートに出力することを特徴とする、請求項８に記載のゲートウェイ（１００）。
12. 前記ゲートウェイコントローラ（１０６）はさらに、前記メッセージをＩＰパケットにカプセル化することを特徴とする、請求項８に記載のゲートウェイ（１００）。
13. 前記ルーティングテーブル（１１０）は、前記ルーティングテーブル内（１１０）に、前記ＰＡＮクライアント（３２）のデバイス型を指し示す情報を含むことを特徴とする、請求項８に記載のゲートウェイ（１００）。
14. パーソナル・エリア・ネットワーク（ＰＡＮ）（３０）内のクライアントと通信する方法であって、
    前記ＰＡＮ（３０）内の前記クライアント（３２）と通信するために、前記ＰＡＮ（３０）上にＰＡＮエージェント（１０８）を生成する工程と、
    前記ＰＡＮ（３０）内の前記クライアント（３２）と、前記ＰＡＮエージェント（１０８）を介して通信する工程とを含むことを特徴とする方法。
15. 前記ＰＡＮ（３０）エージェントは、ゲートウェイ上に存在することを特徴とする、請求項１４に記載の方法。
16. 前記ＰＡＮは、Ｚｉｇｂｅｅネットワークであることを特徴とする、請求項１４に記載の方法。
17. インターネット・プロトコル（ＩＰ）・ネットワーク（２０）内に、前記ＰＡＮエージェント（１０８）のための存在を生成する工程をさらに含むことを特徴とする、請求項１４に記載の方法。
18. 前記ＩＰネットワーク（２０）中に前記ＰＡＮエージェント（１０８）のための存在を生成する工程は、前記ＩＰネットワーク（２０）内の前記ＰＡＮエージェント（１０８）のためのユーザエージェント（４２）への接続を生成する工程を含むことを特徴とする、請求項１７に記載の方法。
19. 前記ユーザエージェント（４２）は、ＩＰマルチメディアサブシステム（ＩＭＳ）ユーザエージェントを含むことを特徴とする、請求項１７に記載の方法。
20. 前記ＰＡＮ（３０）内の前記クライアント（３２）と前記ＰＡＮエージェント（１０８）を介して通信する前記工程は、前記ユーザエージェント（４２）と通信する工程を含むことを特徴とする、請求項１８に記載の方法。
21. パーソナル・エリア・ネットワーク（ＰＡＮ）（３０）を、インターネット・プロトコル（ＩＰ）・ネットワーク（２０）と接続するためのゲートウェイ（１００）であって、
    前記ＰＡＮ（３０）に接続するための第１のインタフェースデバイス（１４０）と、
    前記ＩＰネットワーク（２０）と接続するための第２のインタフェースデバイス（１０２）と、
    前記ＰＡＮ（３０）に接続されたクライアント（３２）と通信することが可能なＰＡＮエージェント（１０８）を生成するためのノードマネージャ（１１２）を含む、ゲートウェイコントローラ（１０６）とを備えることを特徴とする、ゲートウェイ（１００）。
22. 前記ノードマネージャ（１１２）は、前記第２のインタフェース（１０２）を通して受信されたＩＰクライアント（２０）型要求に応えて、ＰＡＮエージェント（１０８）を生成するように構成されていることを特徴とする、請求項２１に記載のゲートウェイ（１００）
23. 前記要求は、生成されるＰＡＮエージェント（１０８）の型を定義するパラメータを含むことを特徴とする、請求項２２に記載のゲートウェイ（１００）。
24. 前記ＰＡＮ（３０）はＺｉｇｂｅｅネットワークを含み、
    前記パラメータはＺｉｇｂｅｅプロファイルＩＤを含むことを特徴とする、請求項２３に記載のゲートウェイ（１００）。
25. 前記ノードマネージャ（１１２）は、前記ＩＰネットワーク内のユーザエージェント（４２）と通信するように前記ＰＡＮエージェント（１０８）を設定し、
    ＩＰクライアントは前記ユーザエージェント（４２）を介して前記ＰＡＮエージェント（１０８）と通信することを特徴とする、請求項２２に記載のゲートウェイ（１００）。
26. 前記ユーザエージェント（４２）は、ＩＭＳクライアント（４０）と通信するためのＩＰマルチメディアサブシステム（ＩＭＳ）ユーザエージェントを含むことを特徴とする、請求項２５に記載のゲートウェイ。

Images