ZIGBEE/IPゲートウェイ
【課題】パーソナル・エリア・ネットワーク(PAN)と、インターネット・プロトコル(IP)ネットワークとの間の通信を可能にする。
【解決手段】ゲートウェイコントローラ106は、PAN内の1以上のクライアント32に対してIPインタフェース上のポートを割り当て、パーソナル・エリア・ネットワーク内のクライアント32を対応するポートと関係づけるためのルーティングテーブル110をメモリに格納し、ルーティングテーブル110に基づいてパーソナル・エリア・ネットワーク・クライアント32とIPネットワーク内のIPクライアント22との間でメッセージを運ぶ。他の実施形態においては、ゲートウェイ100はゲートウェイプロキシと協力して働いてもよい。
【解決手段】ゲートウェイコントローラ106は、PAN内の1以上のクライアント32に対してIPインタフェース上のポートを割り当て、パーソナル・エリア・ネットワーク内のクライアント32を対応するポートと関係づけるためのルーティングテーブル110をメモリに格納し、ルーティングテーブル110に基づいてパーソナル・エリア・ネットワーク・クライアント32とIPネットワーク内のIPクライアント22との間でメッセージを運ぶ。他の実施形態においては、ゲートウェイ100はゲートウェイプロキシと協力して働いてもよい。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、概してパーソナル・エリア・ネットワーク(PAN)に関し、より詳しくはパーソナル・エリア・ネットワークをIPベースのネットワークに接続する方法に関する。
【背景技術】
【0002】
Zigbee(登録商標)は、低電力、低データレート、低コストの適用例のための、無線ネットワーク規格である。Zigbeeは、電池で動くデバイスからデータがまれに低いレートで送信されるような、自動化、制御、監視及び感知のアプリケーションに対してとても適している。Zigbeeプロトコルは、電気電子学会(IEEE)802.15.4規格に基づいている。このIEEE規格は、制限された電力、CPU及びメモリ資源を有する小デバイスのための、短距離、低電力、低データレート無線インタフェースを定める。
【0003】
Zigbeeは広い産業の支持を有するオープン規格である。オープン規格であるために、様々な製造者によって作られたZigbeeデバイスは協同して動作するだろう。Zigbeeプロトコルは、デバイスが容易に追加され、既存のネットワークから容易に取り除かれうる、アドホックなネットワーキングを可能とする。これらの理由のために、Zigbeeテクノロジはマシン・ツー・マシン(M2M)アプリケーションのための主要な技術の1つとして現れることが期待されている。
【0004】
Zigbeeテクノロジの最大の能力を実現するためには、パーソナル・エリア・ネットワークに存在するZigbeeデバイスがIPネットワークに接続された他のデバイスと通信することを可能とすることが必要だろう。
【発明の概要】
【課題を解決するための手段】
【0005】
本発明は、Zigbeeパーソナル・エリア・ネットワークのような多様なネットワークと、IPネットワークとの間の通信に関する。ゲートウェイは、IPネットワークに接続するための第1のインタフェースデバイスと、Zigbeeネットワークと接続するための第2のインタフェースデバイスと、ゲートウェイコントローラとを含む。ゲートウェイコントローラは、IPネットワークとZigbeeネットワークとの間のメッセージをルーティングする。
【0006】
ある実施形態においては、ゲートウェイコントローラは、Zigbeeネットワーク内のクライアントに対してIPインタフェースデバイス上のポートを割り当てる。ゲートウェイコントローラは、割り当てられたポートを対応するZigbeeクライアントに関係づけるルーティングテーブルを保守する。ルーティングテーブルは例えば、Zigbeeクライアントについてのネットワークアドレスと、対応するポートとを含んでもよい。ゲートウェイに、IPネットワークからメッセージが到着すると、メッセージがどのポートに到着したかが、対応するZigbeeクライアントのネットワークアドレスを調べるために用いられる。逆に、Zigbeeクライアントからのメッセージは、発信したZigbeeクライアントのネットワークアドレスに基づいて対応するポートへと出力される。
【0007】
ある実施形態においては、ゲートウェイはZigbeeクライアントにポートを割り当て、ルーティングテーブルを保守する、ゲートウェイプロキシと協力して動作してもよい。
【0008】
他の実施形態においては、ゲートウェイコントローラは、IPクライアントからの要求に応答するZigbeeエージェントを生成することができる、ノードマネージャを含む。Zigbeeエージェントは、要求するIPクライアントのために、Zigbeeネットワークに関するプレゼンスを提供してもよい。Zigbeeエージェントは、Zigbeeクライアントにとって、他のどんなZigbeeアプリケーションのようにも見える。Zigbeeエージェントは、IPクライアントによって遠隔制御及び遠隔操作されることができる。
【図面の簡単な説明】
【0009】
【図1】IPネットワーク及びZigbeeパーソナル・エリア・ネットワークを含む、典型的な通信ネットワークを示す。
【図2】Zigbeeパーソナル・エリア・ネットワークとIPネットワークとの間のゲートウェイの典型例を示す。
【図3】標準Zigbeeプロトコルスタックを示す。
【図4】Zigbeeパーソナル・エリア・ネットワークとIPネットワークとの間のゲートウェイの、実装例を示す。
【図5】典型的なゲートウェイと通信するためのメッセージフォーマットを示す。
【図6】ゲートウェイによって用いられるルーティングテーブルの典型例を示す。
【図7】ゲートウェイを確立するための手順を示す。
【図7A】IPクライアントからのメッセージをゲートウェイへと送るための手順を示す。
【図8】Zigbeeパーソナル・エリア・ネットワークとIPネットワークとの間のゲートウェイの、実装例を示す。
【図9】Zigbeeパーソナル・エリア・ネットワークとIPネットワークとの間のゲートウェイの、実装例を示す。
【図10】IPネットワーク及びZigbeeパーソナル・エリア・ネットワークを含む、典型的な通信ネットワークを示す。
【図11】IPネットワーク及びZigbeeパーソナル・エリア・ネットワークを含む、典型的な通信ネットワークを示す。
【図12】IMSメッセージをZigbeeメッセージへと翻訳する手順を示す。
【図13】IPネットワーク及びZigbeeパーソナル・エリア・ネットワークを含む、典型的な通信ネットワークを示す。
【図14】Zigbeeパーソナル・エリア・ネットワークとIPネットワークとの間のゲートウェイの、実装例を示す。
【図15】Zigbeeエージェントをゲートウェイ上に生成するための手順を示す。
【図16】IPネットワーク及びZigbeeパーソナル・エリア・ネットワークを含む、典型的な通信ネットワークを示す。
【図17】Zigbeeエージェントを、ゲートウェイ上に生成するための手順を示す。
【図18】シリアル通信のためのメッセージフォーマットを示す。
【発明を実施するための形態】
【0010】
ここで図面を参照すると、本発明に従う通信ネットワーク10の典型的な実施形態が、図1に示される。通信ネットワーク10は、IPクライアント22が属するIPネットワーク20と、1以上のZigbeeクライアントを備えるZigbeeネットワーク30とを含む。Zigbee規格は、パーソナル・エリア・ネットワーク(PAN)のためのプロトコルを詳細に示し、感知、自動化及び制御アプリケーションのためによく適合する。本発明はしかしながら、他の形のPANとともに用いられてもよく、Zigbeeネットワークに限られるものではない。ゲートウェイ100はZigbeeネットワーク30をIPネットワーク20に接続し、IPネットワーク20に存在するIPクライアント22がZigbeeネットワーク30のZigbeeクライアント32と通信することを可能にする。Zigbeeクライアント32は、明かり、センサ等のデバイスを制御するために用いられうる。
【0011】
図2は、一例としてのゲートウェイ100を示す。ゲートウェイ100は、IPネットワーク20と接続するためのIPインタフェースデバイス102と、Zigbeeネットワーク30と接続するためのZigbeeインタフェースデバイス104と、ゲートウェイコントローラ106とを含む。IPインタフェースデバイス102は例えば、イーサネット(登録商標)アダプタ、IEEE802.11.x無線インタフェースアダプタ、又はセルラ送受信器を含んでいてもよい。Zigbeeインタフェースデバイスは、IEEE802.15.4無線インタフェースアダプタを含んでいてもよい。ゲートウェイコントローラ106は、IPインタフェースデバイス102を制御するためのIPコントローラ106Aと、Zigbeeインタフェースデバイス104を制御するためのZigbeeコントローラ106Bとを含む。ゲートウェイコントローラ106は、動作に必要とされるデータとアプリケーションとを格納するための内部又は外部の関連するメモリを備える、1以上のプログラム可能なプロセッサにおけるソフトウェアとして実装されてもよい。
【0012】
Zigbee規格は、限られた電力、CPU及びメモリ資源を有する小デバイスのための短距離、低電力、低データレート無線インタフェースを規定する、電気電子学会(IEEE)802.15.4規格に基づいている。Zigbee規格は、Zigbeeクライアント32間のネットワーキングを可能とする、ネットワーク及びアプリケーションレベルのプロトコルのセットを含む。Zigbeeクライアント32は、Zigbeeネットワーク30内のノードを含む。コーディネイタ、ルータ、及びエンドデバイスの3種類のノードが存在する。様々なノードは、スタートポロジ、ツリートポロジ、又はメッシュトポロジによって相互に接続されていてもよい。ネットワークトポロジにかかわらず、それぞれのZigbeeネットワーク30は1つの(そして1つだけの)コーディネイタを含む。コーディネイタは、他のノードが参加できるZigbeeネットワーク30を構成し、管理する責任を持つ。いくつかの実施形態においてはコーディネイタはまた、Zigbeeネットワーク30の様々なノード間でのメッセージのルーティングのためのバインディングテーブルを保守してもよい。
【0013】
ツリー又はメッシュトポロジを用いるZigbeeネットワーク30は、少なくとも1つのルータの存在を必要とする。ルータは、Zigbeeネットワーク30内の1つのノードから他のノードへのメッセージを転送し、子ノードが接続することを可能とする。ルータは、Zigbeeネットワーク30に参加するエンドデバイスにとってのローカルなコーディネイタとして働く。エンドデバイスは典型的には、特定のタスクを実行する1以上のアプリケーションをホストする。例えばエンドデバイスは、データを収集及び報告し、並びに家庭内の明かりのようなホームデバイスを制御するためのアプリケーションを有してもよい。
【0014】
Zigbeeネットワーク30内では、それぞれのノードは一意のアドレスによって特定される。Zigbeeネットワーク30は、2つのアドレス指定機構を採用する。それぞれのノードは、ロングアドレス及びショートアドレスを持つ。IEEEアドレス又はMACアドレスとも呼ばれるロングアドレスは、IEEEによって割り当てられた、ノードを一意に特定する64ビットアドレスである。ネットワークアドレスとも呼ばれるショートアドレスは、Zigbeeネットワーク30のノードをネットワークコーディネイタに対して特定する、16ビットアドレスである。ネットワークアドレスは、ノードがZigbeeネットワーク30に参加する時に、コーディネイタ又はルータによって割り当てられる。
【0015】
ノードは、1以上のユーザアプリケーションをホストしてもよい。例えば、ネットワーク30内に温度及び湿度を監視するための1つのアプリケーションが存在してもよい。このようなアプリケーションは、ノード上のエンドポイントと呼ばれる。これらのアプリケーションは、Zigbeeネットワーク30の内部又は外部の他のアプリケーションと、メッセージを送受信してもよい。
【0016】
ノードに到着したメッセージを適切なアプリケーションに向けるために、それぞれのエンドポイントはエンドポイントアドレスによって特定される。エンドポイントアドレスは、IPアドレスにおけるポートに類似している。クライアント32は、1から240まで番号付けされる、最大240のアプリケーション又はエンドポイントを有してもよい。エンドポイント255は、ブロードキャスト・エンドポイント・アドレスである。エンドポイント255に向けられたメッセージは、ノード上の全てのアプリケーションに配達されるだろう。
【0017】
アプリケーションは、アプリケーションオブジェクトとしてモデル化される。アプリケーションプロファイルは、関連する又は相補的なアプリケーションオブジェクトの間の相互作用(interaction)を定義する。アプリケーションプロファイルは、パブリックであってもプライベートであってもよい。パブリック・アプリケーション・プロファイルは、異なるベンダからのデバイスが協同作業することを可能とする。プライベート・アプリケーション・プロファイルはプロプライエタリな(独占的な)ものである。Zigbeeアライアンスは、多くのパブリックプロファイルを提供する。このようなパブリックプラファイルの1つが、Home Control, Lighting Profile(家庭制御、明かりプロファイル)であり、これは家庭環境における明かりレベルを感知及び制御することに焦点を合わせている。このプロファイルは、Light Sensor Monochromatic(明かりセンサ・単色光)、Switch Remote Control(スイッチ遠隔制御)、Switching Load Controller(ロードコントローラのスイッチ)、及びDimmer Remote Control(薄暗さ遠隔制御)を含む多くのデバイスを定義する。
【0018】
アプリケーションオブジェクトは、オブジェクト属性及びクラスタを介して、他のアプリケーションオブジェクトと通信する。オブジェクト属性は、アプリケーションオブジェクト間で通信される、データアイテムである。それぞれの属性は、自身の一意な識別子を有する。Zigbee規格は、オブジェクト属性についてのデータ型のセットを定義する。属性のグルーピングはクラスタを含み、クラスタもまた自身の一意の識別子を有する。クラスタ内の属性には、必須のものもあれば任意のものもある。それぞれのクラスタは、216個までの属性を含むことができる。入力クラスタは、他のアプリケーションオブジェクトによって送られることができる属性からなる。例えば、センサを監視するためのアプリケーションオブジェクトは、センサの読み取りの間の時間間隔を制御する「report time(報告時間)」と呼ばれる属性を有してもよい。出力クラスタは、他のアプリケーションオブジェクトにデータを供給する属性を含む。相補的な入力クラスタと出力クラスタとを備えるアプリケーションオブジェクトは、他のアプリケーションオブジェクトと通信することができる。
【0019】
アプリケーションオブジェクトは、バインディングとして知られているプロセスを介して通信を開始することができる。バインディングは、アプリケーションオブジェクト間の論理的なリンクを生成する。バインディング機構(binding mechanism)は、情報を生成するアプリケーションを、その情報を使用するアプリケーションと結びつける。情報は、クラスタとして交換される。2つのアプリケーションオブジェクトが結びつけられるためには、それらは相補的な入力クラスタと出力クラスタとを持たなければならない。2つのアプリケーションオブジェクトが結びつくと、1つのアプリケーションオブジェクトの出力クラスタは、他のアプリケーションオブジェクトの入力クラスタと接続される。2つのアプリケーションオブジェクト間のバインディングは、クラスタが生成されたアプリケーションオブジェクトのネットワークアドレス及びエンドポイント(ソース)、クラスタを消費するアプリケーションオブジェクトのネットワークアドレス及びエンドポイント(デスティネーション)、並びにそれらの間で送られるクラスタについてのクラスタIDによって特定される。結びつけられたアプリケーションオブジェクトは、MSG及びKVPメッセージサービスを用いてメッセージを送受信できる。
【0020】
バインディング情報が格納されている場所に応じて、ソースからデスティネーションへのクラスタ情報の伝送は、直接的又は間接的である。直接アドレッシングでは、情報を送ったノードが、デスティネーション・アプリケーションオブジェクトが存在するノードについてのネットワークアドレスを決定し、そのデスティネーションアドレスをメッセージに挿入する。異なったノードで複数のアプリケーションオブジェクトがメッセージを受け取る場合、メッセージは複製され、少なくとも1つのデスティネーション・アプリケーションオブジェクトが存在するそれぞれのノードに、複製が送られる。間接アドレッシングでは、出力クラスタはコーディネイタに送られる。コーディネイタは、バインディングテーブルを保守している。コーディネイタは送信ノードのソースアドレスとクラスタIDとに基づいて、デスティネーションノードを決定する。コーディネイタは、コーディネイタのバインディングテーブルにおいて、ソースクラスタとアプリケーションアドレスとを含むの全てのエントリを見つけ、それぞれの受信ノードに向けたメッセージを生成する。それぞれのメッセージについて、コーディネイタはメッセージ中にバインディングテーブルからのデスティネーションアドレスを挿入する。
【0021】
Zigbee規格は、ネットワーク内のZigbeeクライアント32が、他のクライアント32のアドレス及び能力(capability)を発見することを可能にする発見機構(discovery mechanism)を含む。デバイス発見は、Zigbeeクライアント32が、ネットワーク上の他のクライアントのネットワークアドレスを発見するためにネットワーク30に問い合わせる(query)ことを可能とする。サービス発見は、Zigbeeクライアント32が他のZigbeeクライアント32の能力に関する情報を要求することを可能にする。サービス情報は記述子として格納され、Zigbeeクライアント32のデバイス型及び能力のような情報、並びにZigbeeクライアント32上で動作しているアプリケーションの型に関する情報を含んでもよい。Zigbeeクライアント32に格納される、3つの必須な記述子と2つの任意的な記述子とが存在する。必須な記述子は、ノード記述子、ノード電力記述子、及び単純記述子である。任意的な記述子は、複合記述子及びユーザ記述子と呼ばれる。それぞれのZigbeeクライアント32について、ただ1つのノード記述子及びノード電力記述子が存在する。エンドポイントに属するそれぞれのアプリケーションについて、単純記述子が存在し、複合記述子とユーザ記述子との少なくとも一方が存在することも可能である。
【0022】
ノード記述子は、Zigbeeクライアント32の型(すなわち、コーディネイタ、ルータ、又はエンドデバイス)及び能力を記述する。Zigbeeクライアント32の能力又はノードの能力とは、使用されている周波数帯及び最大バッファサイズのような属性である。出力記述子は、どのようにクライアント32が電力を供給されているかに関する情報を含む。このような情報は、電力モード(すなわちデバイスが常に電源が入っているか、又は定期的に起動するか)、利用可能な電源、現在使用されている電源及び現在の電源レベルを含んでもよい。単純記述子は、Zigbeeクライアント32のエンドポイントに属しているアプリケーションに関する情報を含む。この情報は、アプリケーションが存在するエンドポイントアドレス、アプリケーションが実装するアプリケーションプロファイル、及びサポートされている入力クラスタ及び出力クラスタのリストを含む。単純記述子はまた、対応する複合記述子及びユーザ記述子が存在するか否かを示す。
【0023】
図3は、電気電子学会(IEEE)802.15.4無線通信規格上に構築された、Zigbeeプロトコルスタックを示す。IEEE規格は、無線チャネルを介する通信のための短距離無線インタフェースを規定する。IEEE規格は、プロトコルスタックの物理層及び媒体アクセス制御(MAC)層についての仕様を含む。Zigbee規格は、ユーザアプリケーションをサポートするための、ネットワーク層及びアプリケーション層のプロトコル(本明細書では、まとめてZigbeeスタック又はZigbeeプロトコルと呼ばれる)のセットを定義する。ネットワーク層は、ネットワークに参加し、及びネットワークから抜けるための、並びにメッセージを適切な行き先に送るための機構を定義する。ネットワーク層はまた、デバイス発見及びサービス発見のための機構も提供する。これらの機構は、Zigbeeノードがネットワーク内の他のノードを発見し、そのようなノードの能力を発見することを可能にする。ネットワーク層はまた、Zigbeeネットワークの形成を管理し、ネットワークに参加するデバイスにアドレスを割り当てる。
【0024】
アプリケーション層は、アプリケーションフレームワーク(AF)、アプリケーション・サポート・サブレイヤー(APS)、及びZigbeeデバイスオブジェクトを含む。アプリケーションフレームワークは、アプリケーションとAPSとの間のインタフェースを提供する。APSは、アプリケーションオブジェクト間の論理的な結合を生成する、バインディング機構を実装する。メッセージがZigbeeクライアント32に到着した時、APSが適切なアプリケーションにメッセージを配達する責任を持つ。Zigbeeデバイスオブジェクト(ZDO)は、デバイスのZigbeeノード型(例えば、コーディネイタ、ルータ、又はエンドデバイス)を表す。Zigbeeデバイスオブジェクトはまた、Zigbeeネットワーク30上でのデバイス発見及びサービス発見を開始する。
【0025】
Zigbeeプロトコルは、同一のZigbeeネットワーク30内の2以上のZigbeeクライアント32が、互いに通信することを可能にする。しかしながら、Zigbeeプロトコルは、Zigbeeクライアント32が、IPネットワーク20内のIPクライアント22と通信することを可能にする機構を提供しない。本発明は、このような通信を促進する、ゲートウェイ機能を提供する。
【0026】
図4は、本発明の一実施形態に従う、一例としてのゲートウェイ100を示す。ゲートウェイ100は、ZigbeeスタックとTCP/IPスタックの双方を含む。Zigbeeスタックは、IEEE802.15.4インタフェース上に実装された従来のZigbeeスタックである。TCP/IPスタックもまた、ゲートウェイ100がIPネットワーク20内のIPクライアント22と通信することを可能にする。ゲートウェイ100がZigbeeスタックを実装するために、ゲートウェイ100はZigbeeネットワーク30に参加することができ、他のZigbeeクライアント32と通信することができる。Zigbeeクライアント32にとっては、ゲートウェイ100は他のどんなZigbeeクライアント32にも見え、ゲートウェイ100はZigbee規格に従って働く。Zigbeeクライアント32上に存在し、ゲートウェイコントローラ106と同じプロファイルIDを共有するアプリケーションは、通常のZigbeeメッセージを用いてゲートウエイ100と通信できる。
【0027】
Zigbeeクライアント32上に存在するアプリケーションは、ゲートウェイ100と通信するために標準的なMSG又はKVPメッセージを用いてもよい。Zigbeeクライアント32とゲートウェイ100との間の通信のために、1つのCID(例えばCID=1)がデータメッセージ(送られ又は受け取られるデータ)のために用いられる。第2のCID(例えばCID=2)は、制御メッセージのために用いられる。Zigbeeクライアント32がデータを送ることを望む時、Zigbeeクライアント32はMSG又はKVPメッセージを、「1」に等しく設定されたCIDとともに、ゲートウェイ100に送る。データフィールドは、送信されるデータを含む。同様に、ゲートウェイ100はIPクライアント22からZigbeeクライアント32へとデータを転送するために、CID=1を用いる。Zigbeeクライアント及びゲートウェイは、制御メッセージを送るためにCID=2を用いてもよい。代わりに、アプリケーション層メッセージは、図5に示される標準Zigbeeメッセージにカプセル化されることもできる。アプリケーション層メッセージについてのメッセージフォーマットは、メッセージ型フィールド、1以上のメッセージパラメータフィールド、及びデータフィールドを含む。メッセージ型フィールドは、メッセージの型を示す。メッセージパラメータフィールドは、メッセージ型について必要とされるパラメータを与える。データフィールドはメッセージデータを含む。
【0028】
ゲートウェイ100は、IPネットワーク20との接続を保守し、Zigbeeクライアント32とIPネットワーク20内のIPクライアント22との間のメッセージを運ぶことに責任を持つ。ゲートウェイ100は、IPネットワーク20内のIPクライアント22と、Zigbeeネットワーク30内のZigbeeクライアント32との間の論理関係を保守する。これらの論理関係は、例えばゲートウェイ100のメモリ中に格納された、ルーティングテーブル110において保守される。ゲートウェイ100は、それぞれのZigbeeクライアント32に、ゲートウェイIPアドレスにおいて一意なIPポートを割り当てる。それぞれのZigbeeクライアント32について、ルーティングテーブル110はMACアドレス又はショートアドレスと、対応するポート番号とを格納する。メッセージがゲートウエイ100に到着すると、ゲートウェイ100はメッセージをどこへ転送するかを決定するためにルーティングテーブル110を用いる。IPネットワーク20から特定のポートに到着したデータは、ルーティングテーブル110中で対応するMACアドレス又はショートアドレスによって特定されるZigbeeクライアント32へ送られる。同様に、Zigbeeネットワーク30内のZigbeeクライアント32からメッセージがゲートウェイ100に到着すると、ゲートウェイ100は発信ノードのMACアドレス又はショートアドレスを確認し、ルーティングテーブル中で特定される対応するポートへとデータを出力する。
【0029】
図6は、ルーティングテーブル110の実装例を示す。ルーティングテーブル110は5つのフィールド:存在、状態、クライアントID、ポート及び型を含む。クライアントIDフィールドは、Zigbeeネットワーク30内の特定のZigbeeクライアント32を特定する。このフィールドは、例えばZigbeeクライアント32のMACアドレス又はショートアドレスを含んでいてもよい。ポートフィールドは、Zigbeeクライアント32に割り当てられたポートについてのポート番号を含む。型フィールドは、Zigbeeクライアント32のデバイス型を示す。デバイス型は、Zigbeeクライアント32によって制御されるデバイスの型を示す。例えば、Zigbeeクライアント32は複数のデバイスを制御してもよく、それゆえ2以上のデバイス型を有してもよい。この場合、Zigbeeクライアント32はルーティングテーブル110中に2以上のエントリを有してもよい。IPクライアント22は、Zigbeeクライアント32のリストを、特定されたデバイス型と対応するポート番号とともに取得するために、ゲートウェイ100に問い合わせを送ってもよい。クライアントIDフィールド、ポートフィールド及び型フィールドは、通常は永続的なものであり、ゲートウェイ100が確立された時に用意される。
【0030】
存在フィールド及び状態フィールドは、Zigbeeクライアント32に関する状態情報を含む。存在フィールドは、ノードがゲートウェイ100によって検出されるか否かを示す。このフィールドはノードが検出された時にはTRUEに設定されてもよく、そうでなければFALSEに設定されてもよい。状態フィールドは現在のポートの状態を示す。IPクライアント22がポートに接続されている時には、状態は「接続(connected)」であり、そうでなければ「切断(disconnected)」である。
【0031】
ゲートウェイ100を構成するための典型的な手順が、図7に示されている。まず、ゲートウェイ100はZigbeeネットワーク30を確立し、又はZigbeeネットワーク30に参加する(ブロック150)。ゲートウェイ100は、Zigbeeコーディネイタとして、又はZigbeeルータとして働いてもよい。Zigbeeネットワーク30を確立し又はZigbeeネットワーク30に参加した後で、ゲートウェイ100はデバイス発見及びサービス発見手順を開始する(ブロック152)。ゲートウェイ100は、Zigbeeネットワーク30によって表される全てのデバイス及び能力への完全なアクセスを提供してもよいし、又はこれらのデバイス及び能力のうち限られた一群に対するアクセスを提供してもよい。デバイス発見及びサービス発見についての手順は、Zigbeeプロトコルによって詳細に示される。デバイス発見及びサービス発見手順に続けて、ゲートウェイ100はそれぞれのZigbeeクライアント32にポートを割り当て(ブロック154)、ルーティングテーブル110を構築する(ブロック156)。一度ゲートウェイ100が使用できるようになると、ゲートウェイ100は新しいデバイス32及び新しいサービスについてZigbeeネットワーク30に定期的に問い合わせ、ルーティングテーブル110を更新をしてもよい。ネットワークから欠落したデバイス32は削除されてもよい。
【0032】
一度ゲートウェイ100が動作すると、IPクライアント22はZigbeeクライアント32との通信を確立することができる。また、Zigbeeクライアント32はIPクライアント22との通信を開始してもよい。
【0033】
図7Aは、Zigbeeネットワーク30内のZigbeeクライアント32に接続するための、IPクライアント22によって実行される典型的な手順を示す。この例では、Zigbeeネットワーク30内に存在するZigbeeクライアント32についての事前の知識を、IPクライアント22は持っていないことを仮定する。しかしながら、事前の準備又は事前の通信によって、IPクライアント22はZigbeeクライアント32についての事前の知識を持っていることもありうることが、理解されるだろう。IPクライアント22は、特定のデバイス型に一致するZigbeeクライアント32のリストについて、ゲートウェイ100に問い合わせる(ブロック160)。例えば、家庭の明かりを制御するためのIPクライアント22は、明かりを制御するZigbeeクライアント32(例えば、デバイス型=明かり(LIGHT))について、ゲートウェイ100に問い合わせてもよい。ゲートウェイ100は、適合するデバイスのリストを含む、問い合わせへの応答を送る。応答は、明かりの型及び位置に関する情報を含んでもよい。応答を受け取った後で(ブロック162)、IPクライアント22は明かりを制御するZigbeeクライアント32に関連する1以上のポートへの接続を開くことができる(ブロック164)。接続要求がゲートウェイ100で受信されると、対応するポートの状態を「切断」から「接続」へと変更するために、ゲートウェイ100はルーティングテーブル110を更新する。IPクライアント22はそして、Zigbeeクライアント32にメッセージを送る(ブロック166)。メッセージ又はデータが「接続」状態を有するポートに到着すると、ゲートウェイ100はメッセージ又はデータを対応するクライアント32に転送する。対応するクライアント32は、ルーティングテーブル110中に格納されたMACアドレス又はショートアドレスによって特定される。一度IPクライアント22とZigbeeクライアント32との間で接続が確立されると、Zigbeeクライアント32はまたIPクライアント22へとメッセージ及びデータを送り返すことができる。Zigbeeクライアント32の観点からは、ゲートウェイ100はメッセージ又はデータの発信者であり、到着点である。Zigbeeクライアント32はまた、Zigbeeゲートウェイ100に対してメッセージを送ってもよい。ゲートウェイ100がZigbeeクライアント32からメッセージを受け取ると、メッセージはZigbeeクライアント32のソースアドレスに対応するポートへと、もしポートが接続状態にあれば、出力される。ポートが接続状態ではなければ、ポートがアクティブではないことを示すために、NAKが発信Zigbeeクライアントへと送られる。
【0034】
図8は、ZigbeeスタックとTCPスタックとが異なるプロセッサにおいて実装される、ゲートウェイ100の代わりの実施形態を示す。この実施形態では、IPインタフェースデバイス102とZigbeeインタフェースデバイス104とは、それぞれ別々のプロセッサを含む。IPインタフェースコントローラ106AはIPインタフェースデバイス102上に存在し、Zigbeeコントローラ106BはZigbeeインタフェースデバイス104上に存在する。Zigbeeスタックは、Zigbeeインタフェースデバイス104で終結し、一方TCPスタックはIPインタフェースデバイス102で終結する。IPインタフェースデバイス102及びZigbeeインタフェースデバイス104は、IPコントローラ106AとZigbeeコントローラ106Bとの間の通信を可能とするシリアルバスによって接続される。前に記述されたルーティングテーブル110は、IPコントローラ106Aによって保守される。
【0035】
IPコントローラ106AとZigbeeコントローラ106Bとの間でデータを運ぶために、単純なシリアル通信プロトコルが用いられる。IPコントローラ106AとZigbeeコントローラ106Bとの間でのメッセージを運ぶための、一例としてのメッセージフォーマットが、図18に示される。このメッセージフォーマットは、メッセージ型フィールド、1以上のメッセージパラメータフィールド、及びデータフィールドを含む。メッセージ型フィールドは、メッセージの型を示す。メッセージパラメータフィールドは、メッセージ型について要求されるパラメータを与える。データフィールドは、メッセージデータを含む。
【0036】
典型的なメッセージ型は、SEND、CONNECT/DISCONNECT、ACK/NACKを含む。メッセージデータを運ぶために、SENDメッセージがIPコントローラ106AとZigbeeコントローラ106Bとの間で送られる。CONNECT/DISCONNECTメッセージは、特定のIPクライアント22への接続を開き又は切るために、Zigbeeコントローラ106BからIPコントローラ106Aへと送られる。ACK/NACKメッセージは、SEND又はCONNECT/DISCONNECTメッセージに応答するために用いられる。他のメッセージもまた、定義されうる。
【0037】
メッセージパラメータは、メッセージ型に応じて変化しうる。例えば、SENDメッセージについてのメッセージパラメータフィールドは、ADDRESS要素とDATA TYPE要素とを含んでもよい。ADDRESSエレメントは、発信又は着信Zigbeeクライアント32のMACアドレスを含んでいてもよい。Zigbeeネットワーク30からIPネットワーク20へと進む伝送のために、このフィールドは発信Zigbeeクライアント32のMACアドレス又はショートアドレスを含んでいるかもしれない。以下で記述されるように、ゲートウェイ100はこのアドレスを、データが出力される適切なポートを決定するために用いてもよい。IPネットワークからZigbeeネットワーク30への通信のために、ADDRESSエレメントは着信Zigbeeクライアント32のMACアドレス又はショートアドレスを含んでいてもよい。DATA TYPE要素は、送信されるデータの型、例えばテキスト、オーディオ、ビデオ、バイナリ等を示すために用いられてもよい。
【0038】
図9は、Zigbee/IPクライアント24がIPネットワーク20内に存在することを可能にするゲートウェイを示す。Zigbee/IPクライアント24は、ZigbeeスタックをIPスタック上に実装するデバイスである。ZIgbee/IPクライアント24は、標準Zigbeeプロトコルを用いて、Zigbeeネットワーク30内のZigbeeクライアント32と通信できる。図4に示される実施形態とは対照的に、ゲートウェイ100はZigbeeスタックを終結させない。代わりにゲートウェイ100は、Zigbeeクライアント32から発信されたZigbeeメッセージ(Zigbeeヘッダを含む)を、IPネットワーク20上でZigbee/IPクライアント24へと運ぶためのIPパケットにカプセル化する。Zigbee/IPクライアント24は、受信されたIPパケット中のカプセル化されたZigbeeメッセージをカプセルから出す(decapsulate)ための、ZigbeeスタックとTCP/IP層との間のアダプテーション層(ADL)を含む。反対方向においては、ADLはZigbeeメッセージをカプセル化し、ゲートウェイ100がZigbeeメッセージをカプセルから出す。ZigbeeスタックがZigbee/IPクライアント24によって実装されるために、一度ゲートウェイ100との接続を確立しZigbeeネットワーク30に参加すると、Zigbee/IPクライアント24はZigbeeネットワーク30に対しては、他のどんなZigbeeクライアントとも同じように見える。Zigbee/IPクライアント24がZigbeeネットワーク30に参加すると、ゲートウェイ100はZigbee/IPクライアント24をルーティングテーブル110に加え、他のどんなZigbeeクライアント32とも同じようにZigbee/IPクライアント24に対してポートを割り当てる。Zigbeeネットワーク30内のZigbeeクライアント32は、他のどんなZigbeeクライアント32とも同じように、Zigbee/IPクライアント24を認識し通信することができるだろう。Zigbee/IPクライアント24はまた、標準Zigbee発見メソッドを用いても発見可能だろう。標準Zigbeeクライアント32に対して書かれたアプリケーションはまた、図9に示される実施形態で、Zigbee/IPクライアント24によって用いられることが可能である。
【0039】
ゲートウェイ100は、標準Zigbeeクライアント32と、IPネットワーク20内に存在するIPマルチメディアサブシステム(IMS)クライアント40との間での通信を促進するために用いられてもよい。IMSクライアント40は、IPネットワーク20へと接続されたホストコンピュータ上に存在するソフトウェアアプリケーションである。IMSクライアント40は、セッション開始プロトコル(SIP)を実行する。Zigbeeクライアント32上に存在するIMSを認識可能なアプリケーションは、IMSメッセージとSIPメッセージとの少なくとも一方を生成し、標準Zigbeeメッセージへとカプセル化されたIMSメッセージとSIPメッセージとの少なくとも一方をゲートウェイ100へと送るために、Zigbeeプロトコルを用いることができるだろう。この場合、ゲートウェイ100は単純にカプセル化されたIMSメッセージとSIPメッセージとの少なくとも一方を最終的な行き先へと転送してもよい。しかしながら、IMSメッセージ及びSIPメッセージは概して大きく、ゲートウェイ100とIPネットワークとの間の接続は、高価であり若しくは非現実的であり、又はこの双方である。それゆえ、ゲートウェイ100とIPネットワーク20との間のインタフェースを通してIMSメッセージ及びSIPメッセージを送ることは望ましくないかもしれない。
【0040】
図10に示される実施形態において、Zigbeeクライアント32上に存在するIMSを認識可能なアプリケーションは、IPネットワーク20に接続されたIMSユーザ・エージェント・サーバ42と通信する。ゲートウェイ100上に存在するユーザ・エージェント・クライアント(UAC)44は、UAS42と通信するために用いられる。UAS42への接続を持つそれぞれのZigbeeクライアント32に対する、別々のUAC44がインスタンス生成される。Zigbeeクライアント32上に存在するIMSを認識可能なアプリケーションは、IMSクライアント40を遠隔制御し、IMSトランザクションに参加することができる。2005年4月40日に出願され、「ネットワーク化された通信デバイスのためのメディア・クライアント・アーキテクチャ(Media Client Architecture for Networked Communication Devices)」と題する米国特許出願番号11/114427号は、アプリケーションとの遠隔通信のための、高レベルアプリケーションインタフェースを有するユーザエージェントを記述する。このユーザエージェントは、本発明においてユーザ・エージェント・サーバ42として働きうる。この出願が、ここに参照により組み込まれる。IMSクライアント40をIPネットワーク20内に位置させることにより、ゲートウェイ100を越える必要があるメッセージはより少なくなるだろう。さらに、Zigbeeクライアント32上に存在するアプリケーションと、IMSクライアント40上に存在するアプリケーションとの間で送られるメッセージは、テキストではなくバイナリ型で送られてもよく、メッセージの大きさを大きく減らすだろう。こうして、ゲートウェイ100を通して送信されるデータは、著しく削減されることができる。
【0041】
IMSクライアント40が、IMSへの認識(aware)に欠ける工業標準のZigbeeアプリケーションで通信することが望ましい場合もありうる。このような通信は、図11に示されるようなメッセージ翻訳器50の使用によって促進される。メッセージ翻訳器50は、メッセージ翻訳サービスをも提供するSIPプロキシサーバとして働く。メッセージ翻訳器50は、IPネットワーク20に接続されたものとして図11に示されているが、当業者ならメッセージ翻訳機能がゲートウェイ100に位置するメッセージ翻訳器50によって実現されうることを理解するだろう。
【0042】
例を与えるために、IMSクライアント40が、Home Control, Lighting profileに従って動作する1以上のZigbee明かりセンサからの情報を集めることを望むことを仮定する。明かりセンサはSIPユーザ名を割り当てられ、SIPユーザ名はSIPレジスタに登録されていることが仮定される。図12は、メッセージ翻訳器50によって実行される典型的な手順を示す。メッセージ翻訳器50は、IMSクライアント40からSUBSCRIBEメッセージを受け取る(ステップ170)。SUBSCRIBEメッセージは、Zigbeeネットワーク30内の明かりセンサについてのSIP URIを含む。メッセージを受信すると、メッセージ翻訳器50はIMSクライアント40によって与えられたSIPユーザ名を用いる従来の方法で、SIPレジスタからゲートウェイ100のIPアドレスとポートとを取得する(ステップ172)。メッセージ翻訳器50は次に、メッセージを標準Zigbeeメッセージへと変換し(ステップ174)、メッセージを1以上のIPパケットにカプセル化し(ステップ176)、IPパケットをゲートウェイ100へと転送する(ステップ178)。ゲートウェイ100は、IPパケットからカプセル化されたZigbeeメッセージを抽出し、前に記述したようにカプセル化されたZigbeeメッセージを明かりセンサを制御するZigbeeクライアント32へと転送する。
【0043】
図13は、IPクライアント22と通信するために、IPネットワーク20と接続されたゲートウェイプロキシ120を用いる実施形態を示す。ゲートウェイプロキシ120は、ゲートウェイ100とIPネットワーク20との間のリンクが高価か信頼できないかの少なくとも一方であり、ゲートウェイ100との継続した接続を維持することが望ましくない又は非実用的である場合に、有用であるかもしれない。ゲートウェイプロキシ120はゲートウェイ100とは物理的に離れているが、論理的にはゲートウェイ100の一部だと考えられてもよい。この実施形態では、IPクライアント22との接続を維持する仕事は、ゲートウェイ100からゲートウェイプロキシ120へと移動させられる。多重通信リンクは、ゲートウェイ100をゲートウェイプロキシ120へと接続する。ゲートウェイプロキシ120はまた、ZigbeeメッセージフォーマットとIMSメッセージフォーマットとを翻訳するメッセージ翻訳器50として働くこともできるだろう。ゲートウェイプロキシ120は、IPネットワーク20に接続されたサーバ上に存在するソフトウェアアプリケーションとして実装されてもよい。
【0044】
ゲートウェイ100のIPコントローラ106Aの主要な役割は、ゲートウェイプロキシ120と接続し、Zigbeeクライアント32とゲートウェイプロキシ120との間のメッセージを転送することである。ゲートウェイプロキシ120は、前に記述したようにZigbeeクライアント32にポートを割り当て、ルーティングテーブル110を保守する。Zigbeeクライアント32と通信することを望むIPクライアント22は、ゲートウェイプロキシ120に接続する。図13に示されるようなゲートウェイプロキシ120の使用は、ゲートウェイ100が少ないメモリしか有さない低電力無線デバイスに実装されることを可能にする。ゲートウェイプロキシ120は、より大きなメモリとより大きな電力とを有することができる。ゲートウェイプロキシ120はデータをバッファでき、ゲートウェイ100とのリンクが遮断された時であってもIPクライアント22とのリンクを維持できる。同様に、ゲートウェイ100はゲートウェイプロキシ120とのリンクが遮断された時に、データをバッファできる。
【0045】
図14は、Zigbeeエージェント108を用いてZigbeeクライアント32とIPクライアント22との間の通信を可能とする実施形態を示す。Zigbeeエージェント108は、ゲートウェイ100上に存在する、標準Zigbeeアプリケーションプロファイルによって定義されるZigbeeアプリケーションを含む。Zigbeeエージェント108は、IPクライアント22によって遠隔設定されることができ、IPクライアント22の指示及び制御の下、仕事を実行するためにZigbeeネットワーク30に参加することができる。Zigbeeエージェント108の使用は、IPクライアント22が、IPネットワーク20への認識に欠ける工業標準のZigbeeアプリケーションと相互作用することを可能にする。
【0046】
例として、IPクライアント22がZigbeeネットワーク30内の明かりセンサを監視することを望むことを仮定する。IPクライアント22はゲートウェイ100と接続し、Zigbeeエージェント108が明かりセンサを監視するために生成されることを要求してもよい。この例ではゲートウェイ100は、明かりセンサとのバインディングを可能とする、プロファイルIDとクラスタIDとを有するZigbeeエージェント108を生成するだろう。Zigbeeエージェント108は、標準Zigbee明かりセンサから明かりセンサ読み取り値を受け取り、それらの読み取り値をIPクライアント22へと転送してもよい。Zigbee明かりセンサは、どんな特別な能力も必要としない。
【0047】
Zigbeeエージェント108を実装するために、Zigbeeコントローラ106Bは、Zigbeeエージェント108をインスタンス生成するためのノードマネージャ112を含む。ノードマネージャ112は、IPクライアント22と直接通信するための、ゲートウェイ上の専用のポートを割り当てられてもよい。それぞれのZigbeeエージェント108は、ルーティングテーブル110に格納される一意のポートを割り当てられる。IPクライアント22は、Zigbeeエージェント108を生成するために、ノードマネージャ112に要求を送ってもよい。Zigbeeエージェント108がノードマネージャ112によってインスタンス生成される時は、Zigbeeエージェント108はIPコントローラ106AにZigbeeエージェント108に対してポートを割り当てることと、対応するポートとともにZigbeeエージェント108に関係するエントリをルーティングテーブル110に加えることとを要求する。IPコントローラ106Aは、ノードマネージャ112に割り当てられたポートを返し、ノードマネージャ112はIPクライアント22に通知する。代わりに、IPコントローラ106Aは、ポートを割り当てた後にIPクライアント22に対し直接メッセージを送ることもできるだろう。一度Zigbeeエージェント108がインスタンス生成され、ポートが割り当てられると、IPクライアント22は割り当てられたポートを用いてZigbeeエージェント108と直接通信することができる。ゲートウェイ100は、Zigbeeエージェント108とIPクライアント22との間の通信を、Zigbeeクライアント32と同じように扱う。
【0048】
図15は、ゲートウェイ100上にZigbeeエージェント108を確立するための典型的な手順を示す。IPクライアント22は、ノードマネージャ112にZigbeeエージェント108を生成するための要求を送る(ステップa)。要求は、生成されるエージェント108の型を定義するパラメータを含む。例えば、要求は標準的なZigbeeアプリケーションプロファイルに対応する、標準的なプロファイルIDとクラスタIDとの少なくとも一方を含んでいてもよい。要求はまた、Zigbeeエージェント108がバインドされるべきである、Zigbeeネットワーク30内の他のZigbeeアプリケーションを特定してもよい。要求に応えて、ノードマネージャ112は要求によって明記されたようにZigbeeエージェント108をインスタンス生成し、Zigbeeエージェント108とZigbeeネットワーク30内の1以上のZigbeeアプリケーションとのバインディングを開始する(ステップb)。ノードマネージャ112はまた、IPコントローラ106Aに、ポート割り当ての要求を送る(ステップc)。IPコントローラ106Aは、新しく生成されたZigbeeエージェント108にポートを割り当て、割り当てられたポートをノードマネージャ112に返す(ステップd)。ノードマネージャ112はIPクライアント22に応答し、Zigbeeエージェント108の生成を確認し、そのZigbeeエージェント108に対して割り当てられたポートをIPクライアント22に与える(ステップe)。IPクライアント22及びZigbeeエージェント108はすると、IPコントローラ106Aのサービスを用いて通信することが可能となる(ステップf)。
【0049】
図16は、前の実施形態からの要素を結合する実施形態を示す。この実施形態は、図13に示されるゲートウェイ100と、プロキシ120と、ユーザ・エージェント・サーバ(UAS)42とを含む。この実施形態におけるプロキシ120は、IMSを認識可能なZigbeeクライアント32の代わりにUAS42との接続を確立するために用いられる、1以上のIMSユーザ・エージェント・クライアント44を含む。別々のIMSユーザクライアント(UAC)44が、それぞれのIMSを認識可能なZigbeeクライアント32について生成される。プロキシ120もまた、UAC44を有する。ゲートウェイ100は、前に記述したように、Zigbeeエージェント108をインスタンス生成するためのノードマネージャ112を含む。ゲートウェイ100とプロキシ120との双方が、どちらかの末端がデータを受信することが不可能であるか、又はゲートウェイ100をIPネットワーク20と接続するIPリンクが遮断された時に、データトラフィックをバッファすることが可能である。ゲートウェイ100のこの実施形態は、IMSクライアント40と、IMSを認識可能なZigbeeクライアント32とIMSを認識可能でないZigbeeクライアント32との双方との、通信を可能にする。
【0050】
図17は、IMSクライアント40とIMSを認識可能でないZigbeeクライアント32との間の通信を確立するための典型的な手順を示す。IMSクライアント40は、Zigbeeエージェント108を生成するための要求を、ノードマネージャ112へと送る(ステップa)。要求は、生成されるエージェント108の型を定義するパラメータを含む。例えばこの要求は、標準Zigbeeアプリケーションプロファイルに対応する、標準プロファイルIDとクラスタIDとの少なくとも一方を含んでもよい。この要求はまた、Zigbeeエージェント108のバインド先となるべき、Zigbeeネットワーク30内の他のZigbeeアプリケーションを特定してもよい。要求に応えてノードマネージャ112は、要求によって明記されたようにZigbeeエージェント108をインスタンス生成し、Zigbeeエージェント108とZigbeeネットワーク30内の1以上の他のZigbeeアプリケーションとのバインディングを開始する(ステップb)。ノードマネージャ112はまた、IPコントローラ106Aに、ポート割り当ての要求を送る(ステップc)。IPコントローラ106Aは、新しく生成されたZigbeeエージェント108にポートを割り当て、割り当てられたポートをノードマネージャ112に返す(ステップd)ノードマネージャ112は、プロキシ120に対し、新しく生成されたZigbeeエージェントと組にされるIMSユーザ・エージェント・クライアント44を、生成し又は割り当てる要求を送る(ステップe)。プロキシは、IMSユーザ・エージェント・クライアント44を割り当て又は生成し(ステップf)、IMSユーザ・エージェント・クライアント44の確認を、トランザクションを開始したIMSクライアント40と、ノードマネージャ112との双方に送る(ステップg)。ノードマネージャ112は、確認をZigbeeエージェント108へと転送する。確認は、イベント名又はイベントIDとMIME型とともに、新しいZigbeeエージェントから送られる全てのSTATE命令について用いられるだろう、新しいIMSユーザエージェントについてのURIを含む。IMSクライアント40はここで、プロキシ120からの確認において受け取られたURI、イベントID又はイベント名、及びMIME型とともに、SUBSCRIBE要求をIMSユーザ・エージェント・サーバ42へと送ることにより、新しいZigbeeエージェントに関連するイベントにサブスクライブしてもよい(ステップh)。バインドされたクラスタIDのZigbeeエージェント108によって受け取られた全てのZigbeeメッセージは、IMS STATE命令メッセージ中に埋め込まれ、メッセージがIMS UA STATEメッセージにフォーマットされるプロキシ120に送られる。メッセージはそして、IMSユーザ・エージェント・クライアント44及びIMSユーザ・エージェント・サーバ42を介してIMSクライアント40に転送される(ステップi)。他の実施形態ではUAC44は、Zigbeeエージェント108から直接IMSクライアント40へとメッセージを転送するように構成されることもできるだろう。IMSクライアント40はまた、Zigbee MSG及びKVPメッセージを、IMS MSGメソッドを用いて、Zigbeeネットワーク30上のどんなZigbeeクライアントへも送ってよい。ZigbeeメッセージはIMS MSGリクエスト中にカプセル化され、ゲートウェイ100上のZigbeeエージェント108へと送られる。
【0051】
当業者なら、Zigbeeエージェント108とIMSクライアント40との間の通信を確立するための上述の技術が、SUBSCRIBEメソッド以外の標準SIPメソッドとともに使われることもできるだろうことを、理解するだろう。
【0052】
本発明はもちろん、本発明の範囲及び必須の特徴から逸脱することなく、本明細書で説明された以外の他の特定の方法で実行されてもよい。本実施形態はそれゆえ、あらゆる観点において、説明的なものであって、制限的なものではないと考えられるべきである。また、添付の請求の範囲の意図する範囲内、並びにその均等範囲内となる全ての変更は、本発明に含まれることが意図されている。
【技術分野】
【0001】
本発明は、概してパーソナル・エリア・ネットワーク(PAN)に関し、より詳しくはパーソナル・エリア・ネットワークをIPベースのネットワークに接続する方法に関する。
【背景技術】
【0002】
Zigbee(登録商標)は、低電力、低データレート、低コストの適用例のための、無線ネットワーク規格である。Zigbeeは、電池で動くデバイスからデータがまれに低いレートで送信されるような、自動化、制御、監視及び感知のアプリケーションに対してとても適している。Zigbeeプロトコルは、電気電子学会(IEEE)802.15.4規格に基づいている。このIEEE規格は、制限された電力、CPU及びメモリ資源を有する小デバイスのための、短距離、低電力、低データレート無線インタフェースを定める。
【0003】
Zigbeeは広い産業の支持を有するオープン規格である。オープン規格であるために、様々な製造者によって作られたZigbeeデバイスは協同して動作するだろう。Zigbeeプロトコルは、デバイスが容易に追加され、既存のネットワークから容易に取り除かれうる、アドホックなネットワーキングを可能とする。これらの理由のために、Zigbeeテクノロジはマシン・ツー・マシン(M2M)アプリケーションのための主要な技術の1つとして現れることが期待されている。
【0004】
Zigbeeテクノロジの最大の能力を実現するためには、パーソナル・エリア・ネットワークに存在するZigbeeデバイスがIPネットワークに接続された他のデバイスと通信することを可能とすることが必要だろう。
【発明の概要】
【課題を解決するための手段】
【0005】
本発明は、Zigbeeパーソナル・エリア・ネットワークのような多様なネットワークと、IPネットワークとの間の通信に関する。ゲートウェイは、IPネットワークに接続するための第1のインタフェースデバイスと、Zigbeeネットワークと接続するための第2のインタフェースデバイスと、ゲートウェイコントローラとを含む。ゲートウェイコントローラは、IPネットワークとZigbeeネットワークとの間のメッセージをルーティングする。
【0006】
ある実施形態においては、ゲートウェイコントローラは、Zigbeeネットワーク内のクライアントに対してIPインタフェースデバイス上のポートを割り当てる。ゲートウェイコントローラは、割り当てられたポートを対応するZigbeeクライアントに関係づけるルーティングテーブルを保守する。ルーティングテーブルは例えば、Zigbeeクライアントについてのネットワークアドレスと、対応するポートとを含んでもよい。ゲートウェイに、IPネットワークからメッセージが到着すると、メッセージがどのポートに到着したかが、対応するZigbeeクライアントのネットワークアドレスを調べるために用いられる。逆に、Zigbeeクライアントからのメッセージは、発信したZigbeeクライアントのネットワークアドレスに基づいて対応するポートへと出力される。
【0007】
ある実施形態においては、ゲートウェイはZigbeeクライアントにポートを割り当て、ルーティングテーブルを保守する、ゲートウェイプロキシと協力して動作してもよい。
【0008】
他の実施形態においては、ゲートウェイコントローラは、IPクライアントからの要求に応答するZigbeeエージェントを生成することができる、ノードマネージャを含む。Zigbeeエージェントは、要求するIPクライアントのために、Zigbeeネットワークに関するプレゼンスを提供してもよい。Zigbeeエージェントは、Zigbeeクライアントにとって、他のどんなZigbeeアプリケーションのようにも見える。Zigbeeエージェントは、IPクライアントによって遠隔制御及び遠隔操作されることができる。
【図面の簡単な説明】
【0009】
【図1】IPネットワーク及びZigbeeパーソナル・エリア・ネットワークを含む、典型的な通信ネットワークを示す。
【図2】Zigbeeパーソナル・エリア・ネットワークとIPネットワークとの間のゲートウェイの典型例を示す。
【図3】標準Zigbeeプロトコルスタックを示す。
【図4】Zigbeeパーソナル・エリア・ネットワークとIPネットワークとの間のゲートウェイの、実装例を示す。
【図5】典型的なゲートウェイと通信するためのメッセージフォーマットを示す。
【図6】ゲートウェイによって用いられるルーティングテーブルの典型例を示す。
【図7】ゲートウェイを確立するための手順を示す。
【図7A】IPクライアントからのメッセージをゲートウェイへと送るための手順を示す。
【図8】Zigbeeパーソナル・エリア・ネットワークとIPネットワークとの間のゲートウェイの、実装例を示す。
【図9】Zigbeeパーソナル・エリア・ネットワークとIPネットワークとの間のゲートウェイの、実装例を示す。
【図10】IPネットワーク及びZigbeeパーソナル・エリア・ネットワークを含む、典型的な通信ネットワークを示す。
【図11】IPネットワーク及びZigbeeパーソナル・エリア・ネットワークを含む、典型的な通信ネットワークを示す。
【図12】IMSメッセージをZigbeeメッセージへと翻訳する手順を示す。
【図13】IPネットワーク及びZigbeeパーソナル・エリア・ネットワークを含む、典型的な通信ネットワークを示す。
【図14】Zigbeeパーソナル・エリア・ネットワークとIPネットワークとの間のゲートウェイの、実装例を示す。
【図15】Zigbeeエージェントをゲートウェイ上に生成するための手順を示す。
【図16】IPネットワーク及びZigbeeパーソナル・エリア・ネットワークを含む、典型的な通信ネットワークを示す。
【図17】Zigbeeエージェントを、ゲートウェイ上に生成するための手順を示す。
【図18】シリアル通信のためのメッセージフォーマットを示す。
【発明を実施するための形態】
【0010】
ここで図面を参照すると、本発明に従う通信ネットワーク10の典型的な実施形態が、図1に示される。通信ネットワーク10は、IPクライアント22が属するIPネットワーク20と、1以上のZigbeeクライアントを備えるZigbeeネットワーク30とを含む。Zigbee規格は、パーソナル・エリア・ネットワーク(PAN)のためのプロトコルを詳細に示し、感知、自動化及び制御アプリケーションのためによく適合する。本発明はしかしながら、他の形のPANとともに用いられてもよく、Zigbeeネットワークに限られるものではない。ゲートウェイ100はZigbeeネットワーク30をIPネットワーク20に接続し、IPネットワーク20に存在するIPクライアント22がZigbeeネットワーク30のZigbeeクライアント32と通信することを可能にする。Zigbeeクライアント32は、明かり、センサ等のデバイスを制御するために用いられうる。
【0011】
図2は、一例としてのゲートウェイ100を示す。ゲートウェイ100は、IPネットワーク20と接続するためのIPインタフェースデバイス102と、Zigbeeネットワーク30と接続するためのZigbeeインタフェースデバイス104と、ゲートウェイコントローラ106とを含む。IPインタフェースデバイス102は例えば、イーサネット(登録商標)アダプタ、IEEE802.11.x無線インタフェースアダプタ、又はセルラ送受信器を含んでいてもよい。Zigbeeインタフェースデバイスは、IEEE802.15.4無線インタフェースアダプタを含んでいてもよい。ゲートウェイコントローラ106は、IPインタフェースデバイス102を制御するためのIPコントローラ106Aと、Zigbeeインタフェースデバイス104を制御するためのZigbeeコントローラ106Bとを含む。ゲートウェイコントローラ106は、動作に必要とされるデータとアプリケーションとを格納するための内部又は外部の関連するメモリを備える、1以上のプログラム可能なプロセッサにおけるソフトウェアとして実装されてもよい。
【0012】
Zigbee規格は、限られた電力、CPU及びメモリ資源を有する小デバイスのための短距離、低電力、低データレート無線インタフェースを規定する、電気電子学会(IEEE)802.15.4規格に基づいている。Zigbee規格は、Zigbeeクライアント32間のネットワーキングを可能とする、ネットワーク及びアプリケーションレベルのプロトコルのセットを含む。Zigbeeクライアント32は、Zigbeeネットワーク30内のノードを含む。コーディネイタ、ルータ、及びエンドデバイスの3種類のノードが存在する。様々なノードは、スタートポロジ、ツリートポロジ、又はメッシュトポロジによって相互に接続されていてもよい。ネットワークトポロジにかかわらず、それぞれのZigbeeネットワーク30は1つの(そして1つだけの)コーディネイタを含む。コーディネイタは、他のノードが参加できるZigbeeネットワーク30を構成し、管理する責任を持つ。いくつかの実施形態においてはコーディネイタはまた、Zigbeeネットワーク30の様々なノード間でのメッセージのルーティングのためのバインディングテーブルを保守してもよい。
【0013】
ツリー又はメッシュトポロジを用いるZigbeeネットワーク30は、少なくとも1つのルータの存在を必要とする。ルータは、Zigbeeネットワーク30内の1つのノードから他のノードへのメッセージを転送し、子ノードが接続することを可能とする。ルータは、Zigbeeネットワーク30に参加するエンドデバイスにとってのローカルなコーディネイタとして働く。エンドデバイスは典型的には、特定のタスクを実行する1以上のアプリケーションをホストする。例えばエンドデバイスは、データを収集及び報告し、並びに家庭内の明かりのようなホームデバイスを制御するためのアプリケーションを有してもよい。
【0014】
Zigbeeネットワーク30内では、それぞれのノードは一意のアドレスによって特定される。Zigbeeネットワーク30は、2つのアドレス指定機構を採用する。それぞれのノードは、ロングアドレス及びショートアドレスを持つ。IEEEアドレス又はMACアドレスとも呼ばれるロングアドレスは、IEEEによって割り当てられた、ノードを一意に特定する64ビットアドレスである。ネットワークアドレスとも呼ばれるショートアドレスは、Zigbeeネットワーク30のノードをネットワークコーディネイタに対して特定する、16ビットアドレスである。ネットワークアドレスは、ノードがZigbeeネットワーク30に参加する時に、コーディネイタ又はルータによって割り当てられる。
【0015】
ノードは、1以上のユーザアプリケーションをホストしてもよい。例えば、ネットワーク30内に温度及び湿度を監視するための1つのアプリケーションが存在してもよい。このようなアプリケーションは、ノード上のエンドポイントと呼ばれる。これらのアプリケーションは、Zigbeeネットワーク30の内部又は外部の他のアプリケーションと、メッセージを送受信してもよい。
【0016】
ノードに到着したメッセージを適切なアプリケーションに向けるために、それぞれのエンドポイントはエンドポイントアドレスによって特定される。エンドポイントアドレスは、IPアドレスにおけるポートに類似している。クライアント32は、1から240まで番号付けされる、最大240のアプリケーション又はエンドポイントを有してもよい。エンドポイント255は、ブロードキャスト・エンドポイント・アドレスである。エンドポイント255に向けられたメッセージは、ノード上の全てのアプリケーションに配達されるだろう。
【0017】
アプリケーションは、アプリケーションオブジェクトとしてモデル化される。アプリケーションプロファイルは、関連する又は相補的なアプリケーションオブジェクトの間の相互作用(interaction)を定義する。アプリケーションプロファイルは、パブリックであってもプライベートであってもよい。パブリック・アプリケーション・プロファイルは、異なるベンダからのデバイスが協同作業することを可能とする。プライベート・アプリケーション・プロファイルはプロプライエタリな(独占的な)ものである。Zigbeeアライアンスは、多くのパブリックプロファイルを提供する。このようなパブリックプラファイルの1つが、Home Control, Lighting Profile(家庭制御、明かりプロファイル)であり、これは家庭環境における明かりレベルを感知及び制御することに焦点を合わせている。このプロファイルは、Light Sensor Monochromatic(明かりセンサ・単色光)、Switch Remote Control(スイッチ遠隔制御)、Switching Load Controller(ロードコントローラのスイッチ)、及びDimmer Remote Control(薄暗さ遠隔制御)を含む多くのデバイスを定義する。
【0018】
アプリケーションオブジェクトは、オブジェクト属性及びクラスタを介して、他のアプリケーションオブジェクトと通信する。オブジェクト属性は、アプリケーションオブジェクト間で通信される、データアイテムである。それぞれの属性は、自身の一意な識別子を有する。Zigbee規格は、オブジェクト属性についてのデータ型のセットを定義する。属性のグルーピングはクラスタを含み、クラスタもまた自身の一意の識別子を有する。クラスタ内の属性には、必須のものもあれば任意のものもある。それぞれのクラスタは、216個までの属性を含むことができる。入力クラスタは、他のアプリケーションオブジェクトによって送られることができる属性からなる。例えば、センサを監視するためのアプリケーションオブジェクトは、センサの読み取りの間の時間間隔を制御する「report time(報告時間)」と呼ばれる属性を有してもよい。出力クラスタは、他のアプリケーションオブジェクトにデータを供給する属性を含む。相補的な入力クラスタと出力クラスタとを備えるアプリケーションオブジェクトは、他のアプリケーションオブジェクトと通信することができる。
【0019】
アプリケーションオブジェクトは、バインディングとして知られているプロセスを介して通信を開始することができる。バインディングは、アプリケーションオブジェクト間の論理的なリンクを生成する。バインディング機構(binding mechanism)は、情報を生成するアプリケーションを、その情報を使用するアプリケーションと結びつける。情報は、クラスタとして交換される。2つのアプリケーションオブジェクトが結びつけられるためには、それらは相補的な入力クラスタと出力クラスタとを持たなければならない。2つのアプリケーションオブジェクトが結びつくと、1つのアプリケーションオブジェクトの出力クラスタは、他のアプリケーションオブジェクトの入力クラスタと接続される。2つのアプリケーションオブジェクト間のバインディングは、クラスタが生成されたアプリケーションオブジェクトのネットワークアドレス及びエンドポイント(ソース)、クラスタを消費するアプリケーションオブジェクトのネットワークアドレス及びエンドポイント(デスティネーション)、並びにそれらの間で送られるクラスタについてのクラスタIDによって特定される。結びつけられたアプリケーションオブジェクトは、MSG及びKVPメッセージサービスを用いてメッセージを送受信できる。
【0020】
バインディング情報が格納されている場所に応じて、ソースからデスティネーションへのクラスタ情報の伝送は、直接的又は間接的である。直接アドレッシングでは、情報を送ったノードが、デスティネーション・アプリケーションオブジェクトが存在するノードについてのネットワークアドレスを決定し、そのデスティネーションアドレスをメッセージに挿入する。異なったノードで複数のアプリケーションオブジェクトがメッセージを受け取る場合、メッセージは複製され、少なくとも1つのデスティネーション・アプリケーションオブジェクトが存在するそれぞれのノードに、複製が送られる。間接アドレッシングでは、出力クラスタはコーディネイタに送られる。コーディネイタは、バインディングテーブルを保守している。コーディネイタは送信ノードのソースアドレスとクラスタIDとに基づいて、デスティネーションノードを決定する。コーディネイタは、コーディネイタのバインディングテーブルにおいて、ソースクラスタとアプリケーションアドレスとを含むの全てのエントリを見つけ、それぞれの受信ノードに向けたメッセージを生成する。それぞれのメッセージについて、コーディネイタはメッセージ中にバインディングテーブルからのデスティネーションアドレスを挿入する。
【0021】
Zigbee規格は、ネットワーク内のZigbeeクライアント32が、他のクライアント32のアドレス及び能力(capability)を発見することを可能にする発見機構(discovery mechanism)を含む。デバイス発見は、Zigbeeクライアント32が、ネットワーク上の他のクライアントのネットワークアドレスを発見するためにネットワーク30に問い合わせる(query)ことを可能とする。サービス発見は、Zigbeeクライアント32が他のZigbeeクライアント32の能力に関する情報を要求することを可能にする。サービス情報は記述子として格納され、Zigbeeクライアント32のデバイス型及び能力のような情報、並びにZigbeeクライアント32上で動作しているアプリケーションの型に関する情報を含んでもよい。Zigbeeクライアント32に格納される、3つの必須な記述子と2つの任意的な記述子とが存在する。必須な記述子は、ノード記述子、ノード電力記述子、及び単純記述子である。任意的な記述子は、複合記述子及びユーザ記述子と呼ばれる。それぞれのZigbeeクライアント32について、ただ1つのノード記述子及びノード電力記述子が存在する。エンドポイントに属するそれぞれのアプリケーションについて、単純記述子が存在し、複合記述子とユーザ記述子との少なくとも一方が存在することも可能である。
【0022】
ノード記述子は、Zigbeeクライアント32の型(すなわち、コーディネイタ、ルータ、又はエンドデバイス)及び能力を記述する。Zigbeeクライアント32の能力又はノードの能力とは、使用されている周波数帯及び最大バッファサイズのような属性である。出力記述子は、どのようにクライアント32が電力を供給されているかに関する情報を含む。このような情報は、電力モード(すなわちデバイスが常に電源が入っているか、又は定期的に起動するか)、利用可能な電源、現在使用されている電源及び現在の電源レベルを含んでもよい。単純記述子は、Zigbeeクライアント32のエンドポイントに属しているアプリケーションに関する情報を含む。この情報は、アプリケーションが存在するエンドポイントアドレス、アプリケーションが実装するアプリケーションプロファイル、及びサポートされている入力クラスタ及び出力クラスタのリストを含む。単純記述子はまた、対応する複合記述子及びユーザ記述子が存在するか否かを示す。
【0023】
図3は、電気電子学会(IEEE)802.15.4無線通信規格上に構築された、Zigbeeプロトコルスタックを示す。IEEE規格は、無線チャネルを介する通信のための短距離無線インタフェースを規定する。IEEE規格は、プロトコルスタックの物理層及び媒体アクセス制御(MAC)層についての仕様を含む。Zigbee規格は、ユーザアプリケーションをサポートするための、ネットワーク層及びアプリケーション層のプロトコル(本明細書では、まとめてZigbeeスタック又はZigbeeプロトコルと呼ばれる)のセットを定義する。ネットワーク層は、ネットワークに参加し、及びネットワークから抜けるための、並びにメッセージを適切な行き先に送るための機構を定義する。ネットワーク層はまた、デバイス発見及びサービス発見のための機構も提供する。これらの機構は、Zigbeeノードがネットワーク内の他のノードを発見し、そのようなノードの能力を発見することを可能にする。ネットワーク層はまた、Zigbeeネットワークの形成を管理し、ネットワークに参加するデバイスにアドレスを割り当てる。
【0024】
アプリケーション層は、アプリケーションフレームワーク(AF)、アプリケーション・サポート・サブレイヤー(APS)、及びZigbeeデバイスオブジェクトを含む。アプリケーションフレームワークは、アプリケーションとAPSとの間のインタフェースを提供する。APSは、アプリケーションオブジェクト間の論理的な結合を生成する、バインディング機構を実装する。メッセージがZigbeeクライアント32に到着した時、APSが適切なアプリケーションにメッセージを配達する責任を持つ。Zigbeeデバイスオブジェクト(ZDO)は、デバイスのZigbeeノード型(例えば、コーディネイタ、ルータ、又はエンドデバイス)を表す。Zigbeeデバイスオブジェクトはまた、Zigbeeネットワーク30上でのデバイス発見及びサービス発見を開始する。
【0025】
Zigbeeプロトコルは、同一のZigbeeネットワーク30内の2以上のZigbeeクライアント32が、互いに通信することを可能にする。しかしながら、Zigbeeプロトコルは、Zigbeeクライアント32が、IPネットワーク20内のIPクライアント22と通信することを可能にする機構を提供しない。本発明は、このような通信を促進する、ゲートウェイ機能を提供する。
【0026】
図4は、本発明の一実施形態に従う、一例としてのゲートウェイ100を示す。ゲートウェイ100は、ZigbeeスタックとTCP/IPスタックの双方を含む。Zigbeeスタックは、IEEE802.15.4インタフェース上に実装された従来のZigbeeスタックである。TCP/IPスタックもまた、ゲートウェイ100がIPネットワーク20内のIPクライアント22と通信することを可能にする。ゲートウェイ100がZigbeeスタックを実装するために、ゲートウェイ100はZigbeeネットワーク30に参加することができ、他のZigbeeクライアント32と通信することができる。Zigbeeクライアント32にとっては、ゲートウェイ100は他のどんなZigbeeクライアント32にも見え、ゲートウェイ100はZigbee規格に従って働く。Zigbeeクライアント32上に存在し、ゲートウェイコントローラ106と同じプロファイルIDを共有するアプリケーションは、通常のZigbeeメッセージを用いてゲートウエイ100と通信できる。
【0027】
Zigbeeクライアント32上に存在するアプリケーションは、ゲートウェイ100と通信するために標準的なMSG又はKVPメッセージを用いてもよい。Zigbeeクライアント32とゲートウェイ100との間の通信のために、1つのCID(例えばCID=1)がデータメッセージ(送られ又は受け取られるデータ)のために用いられる。第2のCID(例えばCID=2)は、制御メッセージのために用いられる。Zigbeeクライアント32がデータを送ることを望む時、Zigbeeクライアント32はMSG又はKVPメッセージを、「1」に等しく設定されたCIDとともに、ゲートウェイ100に送る。データフィールドは、送信されるデータを含む。同様に、ゲートウェイ100はIPクライアント22からZigbeeクライアント32へとデータを転送するために、CID=1を用いる。Zigbeeクライアント及びゲートウェイは、制御メッセージを送るためにCID=2を用いてもよい。代わりに、アプリケーション層メッセージは、図5に示される標準Zigbeeメッセージにカプセル化されることもできる。アプリケーション層メッセージについてのメッセージフォーマットは、メッセージ型フィールド、1以上のメッセージパラメータフィールド、及びデータフィールドを含む。メッセージ型フィールドは、メッセージの型を示す。メッセージパラメータフィールドは、メッセージ型について必要とされるパラメータを与える。データフィールドはメッセージデータを含む。
【0028】
ゲートウェイ100は、IPネットワーク20との接続を保守し、Zigbeeクライアント32とIPネットワーク20内のIPクライアント22との間のメッセージを運ぶことに責任を持つ。ゲートウェイ100は、IPネットワーク20内のIPクライアント22と、Zigbeeネットワーク30内のZigbeeクライアント32との間の論理関係を保守する。これらの論理関係は、例えばゲートウェイ100のメモリ中に格納された、ルーティングテーブル110において保守される。ゲートウェイ100は、それぞれのZigbeeクライアント32に、ゲートウェイIPアドレスにおいて一意なIPポートを割り当てる。それぞれのZigbeeクライアント32について、ルーティングテーブル110はMACアドレス又はショートアドレスと、対応するポート番号とを格納する。メッセージがゲートウエイ100に到着すると、ゲートウェイ100はメッセージをどこへ転送するかを決定するためにルーティングテーブル110を用いる。IPネットワーク20から特定のポートに到着したデータは、ルーティングテーブル110中で対応するMACアドレス又はショートアドレスによって特定されるZigbeeクライアント32へ送られる。同様に、Zigbeeネットワーク30内のZigbeeクライアント32からメッセージがゲートウェイ100に到着すると、ゲートウェイ100は発信ノードのMACアドレス又はショートアドレスを確認し、ルーティングテーブル中で特定される対応するポートへとデータを出力する。
【0029】
図6は、ルーティングテーブル110の実装例を示す。ルーティングテーブル110は5つのフィールド:存在、状態、クライアントID、ポート及び型を含む。クライアントIDフィールドは、Zigbeeネットワーク30内の特定のZigbeeクライアント32を特定する。このフィールドは、例えばZigbeeクライアント32のMACアドレス又はショートアドレスを含んでいてもよい。ポートフィールドは、Zigbeeクライアント32に割り当てられたポートについてのポート番号を含む。型フィールドは、Zigbeeクライアント32のデバイス型を示す。デバイス型は、Zigbeeクライアント32によって制御されるデバイスの型を示す。例えば、Zigbeeクライアント32は複数のデバイスを制御してもよく、それゆえ2以上のデバイス型を有してもよい。この場合、Zigbeeクライアント32はルーティングテーブル110中に2以上のエントリを有してもよい。IPクライアント22は、Zigbeeクライアント32のリストを、特定されたデバイス型と対応するポート番号とともに取得するために、ゲートウェイ100に問い合わせを送ってもよい。クライアントIDフィールド、ポートフィールド及び型フィールドは、通常は永続的なものであり、ゲートウェイ100が確立された時に用意される。
【0030】
存在フィールド及び状態フィールドは、Zigbeeクライアント32に関する状態情報を含む。存在フィールドは、ノードがゲートウェイ100によって検出されるか否かを示す。このフィールドはノードが検出された時にはTRUEに設定されてもよく、そうでなければFALSEに設定されてもよい。状態フィールドは現在のポートの状態を示す。IPクライアント22がポートに接続されている時には、状態は「接続(connected)」であり、そうでなければ「切断(disconnected)」である。
【0031】
ゲートウェイ100を構成するための典型的な手順が、図7に示されている。まず、ゲートウェイ100はZigbeeネットワーク30を確立し、又はZigbeeネットワーク30に参加する(ブロック150)。ゲートウェイ100は、Zigbeeコーディネイタとして、又はZigbeeルータとして働いてもよい。Zigbeeネットワーク30を確立し又はZigbeeネットワーク30に参加した後で、ゲートウェイ100はデバイス発見及びサービス発見手順を開始する(ブロック152)。ゲートウェイ100は、Zigbeeネットワーク30によって表される全てのデバイス及び能力への完全なアクセスを提供してもよいし、又はこれらのデバイス及び能力のうち限られた一群に対するアクセスを提供してもよい。デバイス発見及びサービス発見についての手順は、Zigbeeプロトコルによって詳細に示される。デバイス発見及びサービス発見手順に続けて、ゲートウェイ100はそれぞれのZigbeeクライアント32にポートを割り当て(ブロック154)、ルーティングテーブル110を構築する(ブロック156)。一度ゲートウェイ100が使用できるようになると、ゲートウェイ100は新しいデバイス32及び新しいサービスについてZigbeeネットワーク30に定期的に問い合わせ、ルーティングテーブル110を更新をしてもよい。ネットワークから欠落したデバイス32は削除されてもよい。
【0032】
一度ゲートウェイ100が動作すると、IPクライアント22はZigbeeクライアント32との通信を確立することができる。また、Zigbeeクライアント32はIPクライアント22との通信を開始してもよい。
【0033】
図7Aは、Zigbeeネットワーク30内のZigbeeクライアント32に接続するための、IPクライアント22によって実行される典型的な手順を示す。この例では、Zigbeeネットワーク30内に存在するZigbeeクライアント32についての事前の知識を、IPクライアント22は持っていないことを仮定する。しかしながら、事前の準備又は事前の通信によって、IPクライアント22はZigbeeクライアント32についての事前の知識を持っていることもありうることが、理解されるだろう。IPクライアント22は、特定のデバイス型に一致するZigbeeクライアント32のリストについて、ゲートウェイ100に問い合わせる(ブロック160)。例えば、家庭の明かりを制御するためのIPクライアント22は、明かりを制御するZigbeeクライアント32(例えば、デバイス型=明かり(LIGHT))について、ゲートウェイ100に問い合わせてもよい。ゲートウェイ100は、適合するデバイスのリストを含む、問い合わせへの応答を送る。応答は、明かりの型及び位置に関する情報を含んでもよい。応答を受け取った後で(ブロック162)、IPクライアント22は明かりを制御するZigbeeクライアント32に関連する1以上のポートへの接続を開くことができる(ブロック164)。接続要求がゲートウェイ100で受信されると、対応するポートの状態を「切断」から「接続」へと変更するために、ゲートウェイ100はルーティングテーブル110を更新する。IPクライアント22はそして、Zigbeeクライアント32にメッセージを送る(ブロック166)。メッセージ又はデータが「接続」状態を有するポートに到着すると、ゲートウェイ100はメッセージ又はデータを対応するクライアント32に転送する。対応するクライアント32は、ルーティングテーブル110中に格納されたMACアドレス又はショートアドレスによって特定される。一度IPクライアント22とZigbeeクライアント32との間で接続が確立されると、Zigbeeクライアント32はまたIPクライアント22へとメッセージ及びデータを送り返すことができる。Zigbeeクライアント32の観点からは、ゲートウェイ100はメッセージ又はデータの発信者であり、到着点である。Zigbeeクライアント32はまた、Zigbeeゲートウェイ100に対してメッセージを送ってもよい。ゲートウェイ100がZigbeeクライアント32からメッセージを受け取ると、メッセージはZigbeeクライアント32のソースアドレスに対応するポートへと、もしポートが接続状態にあれば、出力される。ポートが接続状態ではなければ、ポートがアクティブではないことを示すために、NAKが発信Zigbeeクライアントへと送られる。
【0034】
図8は、ZigbeeスタックとTCPスタックとが異なるプロセッサにおいて実装される、ゲートウェイ100の代わりの実施形態を示す。この実施形態では、IPインタフェースデバイス102とZigbeeインタフェースデバイス104とは、それぞれ別々のプロセッサを含む。IPインタフェースコントローラ106AはIPインタフェースデバイス102上に存在し、Zigbeeコントローラ106BはZigbeeインタフェースデバイス104上に存在する。Zigbeeスタックは、Zigbeeインタフェースデバイス104で終結し、一方TCPスタックはIPインタフェースデバイス102で終結する。IPインタフェースデバイス102及びZigbeeインタフェースデバイス104は、IPコントローラ106AとZigbeeコントローラ106Bとの間の通信を可能とするシリアルバスによって接続される。前に記述されたルーティングテーブル110は、IPコントローラ106Aによって保守される。
【0035】
IPコントローラ106AとZigbeeコントローラ106Bとの間でデータを運ぶために、単純なシリアル通信プロトコルが用いられる。IPコントローラ106AとZigbeeコントローラ106Bとの間でのメッセージを運ぶための、一例としてのメッセージフォーマットが、図18に示される。このメッセージフォーマットは、メッセージ型フィールド、1以上のメッセージパラメータフィールド、及びデータフィールドを含む。メッセージ型フィールドは、メッセージの型を示す。メッセージパラメータフィールドは、メッセージ型について要求されるパラメータを与える。データフィールドは、メッセージデータを含む。
【0036】
典型的なメッセージ型は、SEND、CONNECT/DISCONNECT、ACK/NACKを含む。メッセージデータを運ぶために、SENDメッセージがIPコントローラ106AとZigbeeコントローラ106Bとの間で送られる。CONNECT/DISCONNECTメッセージは、特定のIPクライアント22への接続を開き又は切るために、Zigbeeコントローラ106BからIPコントローラ106Aへと送られる。ACK/NACKメッセージは、SEND又はCONNECT/DISCONNECTメッセージに応答するために用いられる。他のメッセージもまた、定義されうる。
【0037】
メッセージパラメータは、メッセージ型に応じて変化しうる。例えば、SENDメッセージについてのメッセージパラメータフィールドは、ADDRESS要素とDATA TYPE要素とを含んでもよい。ADDRESSエレメントは、発信又は着信Zigbeeクライアント32のMACアドレスを含んでいてもよい。Zigbeeネットワーク30からIPネットワーク20へと進む伝送のために、このフィールドは発信Zigbeeクライアント32のMACアドレス又はショートアドレスを含んでいるかもしれない。以下で記述されるように、ゲートウェイ100はこのアドレスを、データが出力される適切なポートを決定するために用いてもよい。IPネットワークからZigbeeネットワーク30への通信のために、ADDRESSエレメントは着信Zigbeeクライアント32のMACアドレス又はショートアドレスを含んでいてもよい。DATA TYPE要素は、送信されるデータの型、例えばテキスト、オーディオ、ビデオ、バイナリ等を示すために用いられてもよい。
【0038】
図9は、Zigbee/IPクライアント24がIPネットワーク20内に存在することを可能にするゲートウェイを示す。Zigbee/IPクライアント24は、ZigbeeスタックをIPスタック上に実装するデバイスである。ZIgbee/IPクライアント24は、標準Zigbeeプロトコルを用いて、Zigbeeネットワーク30内のZigbeeクライアント32と通信できる。図4に示される実施形態とは対照的に、ゲートウェイ100はZigbeeスタックを終結させない。代わりにゲートウェイ100は、Zigbeeクライアント32から発信されたZigbeeメッセージ(Zigbeeヘッダを含む)を、IPネットワーク20上でZigbee/IPクライアント24へと運ぶためのIPパケットにカプセル化する。Zigbee/IPクライアント24は、受信されたIPパケット中のカプセル化されたZigbeeメッセージをカプセルから出す(decapsulate)ための、ZigbeeスタックとTCP/IP層との間のアダプテーション層(ADL)を含む。反対方向においては、ADLはZigbeeメッセージをカプセル化し、ゲートウェイ100がZigbeeメッセージをカプセルから出す。ZigbeeスタックがZigbee/IPクライアント24によって実装されるために、一度ゲートウェイ100との接続を確立しZigbeeネットワーク30に参加すると、Zigbee/IPクライアント24はZigbeeネットワーク30に対しては、他のどんなZigbeeクライアントとも同じように見える。Zigbee/IPクライアント24がZigbeeネットワーク30に参加すると、ゲートウェイ100はZigbee/IPクライアント24をルーティングテーブル110に加え、他のどんなZigbeeクライアント32とも同じようにZigbee/IPクライアント24に対してポートを割り当てる。Zigbeeネットワーク30内のZigbeeクライアント32は、他のどんなZigbeeクライアント32とも同じように、Zigbee/IPクライアント24を認識し通信することができるだろう。Zigbee/IPクライアント24はまた、標準Zigbee発見メソッドを用いても発見可能だろう。標準Zigbeeクライアント32に対して書かれたアプリケーションはまた、図9に示される実施形態で、Zigbee/IPクライアント24によって用いられることが可能である。
【0039】
ゲートウェイ100は、標準Zigbeeクライアント32と、IPネットワーク20内に存在するIPマルチメディアサブシステム(IMS)クライアント40との間での通信を促進するために用いられてもよい。IMSクライアント40は、IPネットワーク20へと接続されたホストコンピュータ上に存在するソフトウェアアプリケーションである。IMSクライアント40は、セッション開始プロトコル(SIP)を実行する。Zigbeeクライアント32上に存在するIMSを認識可能なアプリケーションは、IMSメッセージとSIPメッセージとの少なくとも一方を生成し、標準Zigbeeメッセージへとカプセル化されたIMSメッセージとSIPメッセージとの少なくとも一方をゲートウェイ100へと送るために、Zigbeeプロトコルを用いることができるだろう。この場合、ゲートウェイ100は単純にカプセル化されたIMSメッセージとSIPメッセージとの少なくとも一方を最終的な行き先へと転送してもよい。しかしながら、IMSメッセージ及びSIPメッセージは概して大きく、ゲートウェイ100とIPネットワークとの間の接続は、高価であり若しくは非現実的であり、又はこの双方である。それゆえ、ゲートウェイ100とIPネットワーク20との間のインタフェースを通してIMSメッセージ及びSIPメッセージを送ることは望ましくないかもしれない。
【0040】
図10に示される実施形態において、Zigbeeクライアント32上に存在するIMSを認識可能なアプリケーションは、IPネットワーク20に接続されたIMSユーザ・エージェント・サーバ42と通信する。ゲートウェイ100上に存在するユーザ・エージェント・クライアント(UAC)44は、UAS42と通信するために用いられる。UAS42への接続を持つそれぞれのZigbeeクライアント32に対する、別々のUAC44がインスタンス生成される。Zigbeeクライアント32上に存在するIMSを認識可能なアプリケーションは、IMSクライアント40を遠隔制御し、IMSトランザクションに参加することができる。2005年4月40日に出願され、「ネットワーク化された通信デバイスのためのメディア・クライアント・アーキテクチャ(Media Client Architecture for Networked Communication Devices)」と題する米国特許出願番号11/114427号は、アプリケーションとの遠隔通信のための、高レベルアプリケーションインタフェースを有するユーザエージェントを記述する。このユーザエージェントは、本発明においてユーザ・エージェント・サーバ42として働きうる。この出願が、ここに参照により組み込まれる。IMSクライアント40をIPネットワーク20内に位置させることにより、ゲートウェイ100を越える必要があるメッセージはより少なくなるだろう。さらに、Zigbeeクライアント32上に存在するアプリケーションと、IMSクライアント40上に存在するアプリケーションとの間で送られるメッセージは、テキストではなくバイナリ型で送られてもよく、メッセージの大きさを大きく減らすだろう。こうして、ゲートウェイ100を通して送信されるデータは、著しく削減されることができる。
【0041】
IMSクライアント40が、IMSへの認識(aware)に欠ける工業標準のZigbeeアプリケーションで通信することが望ましい場合もありうる。このような通信は、図11に示されるようなメッセージ翻訳器50の使用によって促進される。メッセージ翻訳器50は、メッセージ翻訳サービスをも提供するSIPプロキシサーバとして働く。メッセージ翻訳器50は、IPネットワーク20に接続されたものとして図11に示されているが、当業者ならメッセージ翻訳機能がゲートウェイ100に位置するメッセージ翻訳器50によって実現されうることを理解するだろう。
【0042】
例を与えるために、IMSクライアント40が、Home Control, Lighting profileに従って動作する1以上のZigbee明かりセンサからの情報を集めることを望むことを仮定する。明かりセンサはSIPユーザ名を割り当てられ、SIPユーザ名はSIPレジスタに登録されていることが仮定される。図12は、メッセージ翻訳器50によって実行される典型的な手順を示す。メッセージ翻訳器50は、IMSクライアント40からSUBSCRIBEメッセージを受け取る(ステップ170)。SUBSCRIBEメッセージは、Zigbeeネットワーク30内の明かりセンサについてのSIP URIを含む。メッセージを受信すると、メッセージ翻訳器50はIMSクライアント40によって与えられたSIPユーザ名を用いる従来の方法で、SIPレジスタからゲートウェイ100のIPアドレスとポートとを取得する(ステップ172)。メッセージ翻訳器50は次に、メッセージを標準Zigbeeメッセージへと変換し(ステップ174)、メッセージを1以上のIPパケットにカプセル化し(ステップ176)、IPパケットをゲートウェイ100へと転送する(ステップ178)。ゲートウェイ100は、IPパケットからカプセル化されたZigbeeメッセージを抽出し、前に記述したようにカプセル化されたZigbeeメッセージを明かりセンサを制御するZigbeeクライアント32へと転送する。
【0043】
図13は、IPクライアント22と通信するために、IPネットワーク20と接続されたゲートウェイプロキシ120を用いる実施形態を示す。ゲートウェイプロキシ120は、ゲートウェイ100とIPネットワーク20との間のリンクが高価か信頼できないかの少なくとも一方であり、ゲートウェイ100との継続した接続を維持することが望ましくない又は非実用的である場合に、有用であるかもしれない。ゲートウェイプロキシ120はゲートウェイ100とは物理的に離れているが、論理的にはゲートウェイ100の一部だと考えられてもよい。この実施形態では、IPクライアント22との接続を維持する仕事は、ゲートウェイ100からゲートウェイプロキシ120へと移動させられる。多重通信リンクは、ゲートウェイ100をゲートウェイプロキシ120へと接続する。ゲートウェイプロキシ120はまた、ZigbeeメッセージフォーマットとIMSメッセージフォーマットとを翻訳するメッセージ翻訳器50として働くこともできるだろう。ゲートウェイプロキシ120は、IPネットワーク20に接続されたサーバ上に存在するソフトウェアアプリケーションとして実装されてもよい。
【0044】
ゲートウェイ100のIPコントローラ106Aの主要な役割は、ゲートウェイプロキシ120と接続し、Zigbeeクライアント32とゲートウェイプロキシ120との間のメッセージを転送することである。ゲートウェイプロキシ120は、前に記述したようにZigbeeクライアント32にポートを割り当て、ルーティングテーブル110を保守する。Zigbeeクライアント32と通信することを望むIPクライアント22は、ゲートウェイプロキシ120に接続する。図13に示されるようなゲートウェイプロキシ120の使用は、ゲートウェイ100が少ないメモリしか有さない低電力無線デバイスに実装されることを可能にする。ゲートウェイプロキシ120は、より大きなメモリとより大きな電力とを有することができる。ゲートウェイプロキシ120はデータをバッファでき、ゲートウェイ100とのリンクが遮断された時であってもIPクライアント22とのリンクを維持できる。同様に、ゲートウェイ100はゲートウェイプロキシ120とのリンクが遮断された時に、データをバッファできる。
【0045】
図14は、Zigbeeエージェント108を用いてZigbeeクライアント32とIPクライアント22との間の通信を可能とする実施形態を示す。Zigbeeエージェント108は、ゲートウェイ100上に存在する、標準Zigbeeアプリケーションプロファイルによって定義されるZigbeeアプリケーションを含む。Zigbeeエージェント108は、IPクライアント22によって遠隔設定されることができ、IPクライアント22の指示及び制御の下、仕事を実行するためにZigbeeネットワーク30に参加することができる。Zigbeeエージェント108の使用は、IPクライアント22が、IPネットワーク20への認識に欠ける工業標準のZigbeeアプリケーションと相互作用することを可能にする。
【0046】
例として、IPクライアント22がZigbeeネットワーク30内の明かりセンサを監視することを望むことを仮定する。IPクライアント22はゲートウェイ100と接続し、Zigbeeエージェント108が明かりセンサを監視するために生成されることを要求してもよい。この例ではゲートウェイ100は、明かりセンサとのバインディングを可能とする、プロファイルIDとクラスタIDとを有するZigbeeエージェント108を生成するだろう。Zigbeeエージェント108は、標準Zigbee明かりセンサから明かりセンサ読み取り値を受け取り、それらの読み取り値をIPクライアント22へと転送してもよい。Zigbee明かりセンサは、どんな特別な能力も必要としない。
【0047】
Zigbeeエージェント108を実装するために、Zigbeeコントローラ106Bは、Zigbeeエージェント108をインスタンス生成するためのノードマネージャ112を含む。ノードマネージャ112は、IPクライアント22と直接通信するための、ゲートウェイ上の専用のポートを割り当てられてもよい。それぞれのZigbeeエージェント108は、ルーティングテーブル110に格納される一意のポートを割り当てられる。IPクライアント22は、Zigbeeエージェント108を生成するために、ノードマネージャ112に要求を送ってもよい。Zigbeeエージェント108がノードマネージャ112によってインスタンス生成される時は、Zigbeeエージェント108はIPコントローラ106AにZigbeeエージェント108に対してポートを割り当てることと、対応するポートとともにZigbeeエージェント108に関係するエントリをルーティングテーブル110に加えることとを要求する。IPコントローラ106Aは、ノードマネージャ112に割り当てられたポートを返し、ノードマネージャ112はIPクライアント22に通知する。代わりに、IPコントローラ106Aは、ポートを割り当てた後にIPクライアント22に対し直接メッセージを送ることもできるだろう。一度Zigbeeエージェント108がインスタンス生成され、ポートが割り当てられると、IPクライアント22は割り当てられたポートを用いてZigbeeエージェント108と直接通信することができる。ゲートウェイ100は、Zigbeeエージェント108とIPクライアント22との間の通信を、Zigbeeクライアント32と同じように扱う。
【0048】
図15は、ゲートウェイ100上にZigbeeエージェント108を確立するための典型的な手順を示す。IPクライアント22は、ノードマネージャ112にZigbeeエージェント108を生成するための要求を送る(ステップa)。要求は、生成されるエージェント108の型を定義するパラメータを含む。例えば、要求は標準的なZigbeeアプリケーションプロファイルに対応する、標準的なプロファイルIDとクラスタIDとの少なくとも一方を含んでいてもよい。要求はまた、Zigbeeエージェント108がバインドされるべきである、Zigbeeネットワーク30内の他のZigbeeアプリケーションを特定してもよい。要求に応えて、ノードマネージャ112は要求によって明記されたようにZigbeeエージェント108をインスタンス生成し、Zigbeeエージェント108とZigbeeネットワーク30内の1以上のZigbeeアプリケーションとのバインディングを開始する(ステップb)。ノードマネージャ112はまた、IPコントローラ106Aに、ポート割り当ての要求を送る(ステップc)。IPコントローラ106Aは、新しく生成されたZigbeeエージェント108にポートを割り当て、割り当てられたポートをノードマネージャ112に返す(ステップd)。ノードマネージャ112はIPクライアント22に応答し、Zigbeeエージェント108の生成を確認し、そのZigbeeエージェント108に対して割り当てられたポートをIPクライアント22に与える(ステップe)。IPクライアント22及びZigbeeエージェント108はすると、IPコントローラ106Aのサービスを用いて通信することが可能となる(ステップf)。
【0049】
図16は、前の実施形態からの要素を結合する実施形態を示す。この実施形態は、図13に示されるゲートウェイ100と、プロキシ120と、ユーザ・エージェント・サーバ(UAS)42とを含む。この実施形態におけるプロキシ120は、IMSを認識可能なZigbeeクライアント32の代わりにUAS42との接続を確立するために用いられる、1以上のIMSユーザ・エージェント・クライアント44を含む。別々のIMSユーザクライアント(UAC)44が、それぞれのIMSを認識可能なZigbeeクライアント32について生成される。プロキシ120もまた、UAC44を有する。ゲートウェイ100は、前に記述したように、Zigbeeエージェント108をインスタンス生成するためのノードマネージャ112を含む。ゲートウェイ100とプロキシ120との双方が、どちらかの末端がデータを受信することが不可能であるか、又はゲートウェイ100をIPネットワーク20と接続するIPリンクが遮断された時に、データトラフィックをバッファすることが可能である。ゲートウェイ100のこの実施形態は、IMSクライアント40と、IMSを認識可能なZigbeeクライアント32とIMSを認識可能でないZigbeeクライアント32との双方との、通信を可能にする。
【0050】
図17は、IMSクライアント40とIMSを認識可能でないZigbeeクライアント32との間の通信を確立するための典型的な手順を示す。IMSクライアント40は、Zigbeeエージェント108を生成するための要求を、ノードマネージャ112へと送る(ステップa)。要求は、生成されるエージェント108の型を定義するパラメータを含む。例えばこの要求は、標準Zigbeeアプリケーションプロファイルに対応する、標準プロファイルIDとクラスタIDとの少なくとも一方を含んでもよい。この要求はまた、Zigbeeエージェント108のバインド先となるべき、Zigbeeネットワーク30内の他のZigbeeアプリケーションを特定してもよい。要求に応えてノードマネージャ112は、要求によって明記されたようにZigbeeエージェント108をインスタンス生成し、Zigbeeエージェント108とZigbeeネットワーク30内の1以上の他のZigbeeアプリケーションとのバインディングを開始する(ステップb)。ノードマネージャ112はまた、IPコントローラ106Aに、ポート割り当ての要求を送る(ステップc)。IPコントローラ106Aは、新しく生成されたZigbeeエージェント108にポートを割り当て、割り当てられたポートをノードマネージャ112に返す(ステップd)ノードマネージャ112は、プロキシ120に対し、新しく生成されたZigbeeエージェントと組にされるIMSユーザ・エージェント・クライアント44を、生成し又は割り当てる要求を送る(ステップe)。プロキシは、IMSユーザ・エージェント・クライアント44を割り当て又は生成し(ステップf)、IMSユーザ・エージェント・クライアント44の確認を、トランザクションを開始したIMSクライアント40と、ノードマネージャ112との双方に送る(ステップg)。ノードマネージャ112は、確認をZigbeeエージェント108へと転送する。確認は、イベント名又はイベントIDとMIME型とともに、新しいZigbeeエージェントから送られる全てのSTATE命令について用いられるだろう、新しいIMSユーザエージェントについてのURIを含む。IMSクライアント40はここで、プロキシ120からの確認において受け取られたURI、イベントID又はイベント名、及びMIME型とともに、SUBSCRIBE要求をIMSユーザ・エージェント・サーバ42へと送ることにより、新しいZigbeeエージェントに関連するイベントにサブスクライブしてもよい(ステップh)。バインドされたクラスタIDのZigbeeエージェント108によって受け取られた全てのZigbeeメッセージは、IMS STATE命令メッセージ中に埋め込まれ、メッセージがIMS UA STATEメッセージにフォーマットされるプロキシ120に送られる。メッセージはそして、IMSユーザ・エージェント・クライアント44及びIMSユーザ・エージェント・サーバ42を介してIMSクライアント40に転送される(ステップi)。他の実施形態ではUAC44は、Zigbeeエージェント108から直接IMSクライアント40へとメッセージを転送するように構成されることもできるだろう。IMSクライアント40はまた、Zigbee MSG及びKVPメッセージを、IMS MSGメソッドを用いて、Zigbeeネットワーク30上のどんなZigbeeクライアントへも送ってよい。ZigbeeメッセージはIMS MSGリクエスト中にカプセル化され、ゲートウェイ100上のZigbeeエージェント108へと送られる。
【0051】
当業者なら、Zigbeeエージェント108とIMSクライアント40との間の通信を確立するための上述の技術が、SUBSCRIBEメソッド以外の標準SIPメソッドとともに使われることもできるだろうことを、理解するだろう。
【0052】
本発明はもちろん、本発明の範囲及び必須の特徴から逸脱することなく、本明細書で説明された以外の他の特定の方法で実行されてもよい。本実施形態はそれゆえ、あらゆる観点において、説明的なものであって、制限的なものではないと考えられるべきである。また、添付の請求の範囲の意図する範囲内、並びにその均等範囲内となる全ての変更は、本発明に含まれることが意図されている。
【特許請求の範囲】
【請求項1】
パーソナル・エリア・ネットワーク(PAN)(30)とインターネット・プロトコル(IP)・ネットワーク(20)との間でメッセージを送信する方法であって、
前記PAN(30)内の1以上のPANクライアント(32)に対して、IPインタフェース(102)上のポートを割り当てる工程と、
前記PAN(30)内の前記PANクライアント(32)を、前記PANクライアント(32)に対応するポートと関係づけるためのルーティングテーブル(110)を、メモリに格納する工程と、
前記ルーティングテーブルに基づいて、前記PANクライアント(32)と前記IPネットワーク(20)との間でメッセージを運ぶ工程とを含むことを特徴とする方法。
【請求項2】
前記ルーティングテーブル(110)に基づいて前記PANクライアント(32)と前記IPネットワーク(20)との間でメッセージを運ぶ工程は、前記IPネットワーク(20)において発せられたメッセージを、どのポートで前記メッセージが受け取られたかに基づいて、前記PAN(30)内の対応するクライアント(32)に運ぶ工程を含むことを特徴とする、請求項1に記載の方法。
【請求項3】
前記メッセージはIPパケットにカプセル化され、
前記工程はさらに前記メッセージをカプセルから出す工程と、
前記カプセルから出されたメッセージを前記クライアント(32)へと送る工程とを含むことを特徴とする、請求項2に記載の方法。
【請求項4】
前記ルーティングテーブル(110)に基づいて前記PANクライアント(32)と前記IPネットワーク(20)との間でメッセージを運ぶ工程は、前記PAN(30)内の発信したクライアント(32)から受け取ったメッセージを、前記発信したクライアントに割り当てられたポートに出力する工程を含むことを特徴とする、請求項1に記載の方法。
【請求項5】
前記メッセージをIPパケットにカプセル化する工程と、
前記対応するポートに前記IPパケットを出力する工程とをさらに含むことを特徴とする、請求項4に記載の方法。
【請求項6】
前記IPインタフェースは、前記PAN(30)と前記IPネットワーク(20)との間のゲートウェイ(100)に位置することを特徴とする、請求項1に記載の方法。
【請求項7】
前記ルーティングテーブル(110)は、前記ルーティングテーブル内(110)に、前記PANクライアント(32)のデバイス型を指し示す情報を含むことを特徴とする、請求項1に記載の方法。
【請求項8】
パーソナル・エリア・ネットワーク(PAN)(30)をインターネット・プロトコル(IP)・ネットワーク(20)に接続するためのゲートウェイ(100)であって、
前記PAN(30)に接続するためのPANインタフェース(104)と、
前記IPネットワーク(20)に接続するための、1以上のポートを含むIPインタフェース(102)と、
前記PAN(30)内のそれぞれのクライアント(32)に対して、前記IPインタフェース(102)上のポートを割り当て、前記PAN(30)内のPANクライアント(32)と前記IPネットワーク(20)との間でメッセージを運ぶための、ゲートウェイコントローラ(106)と、
前記PAN(30)内の前記クライアントを前記IPインタフェース(102)上の対応するポートと関係づけるためのルーティング情報を、格納するためのメモリとを備えることを特徴とする、ゲートウェイ(100)。
【請求項9】
前記ゲートウェイコントローラ(106)は、前記IPネットワーク(20)からのメッセージを、どのポートで前記メッセージが受け取られたかに基づいて、前記PAN(30)内の対応するクライアントに運ぶことを特徴とする、請求項8に記載のゲートウェイ(100)。
【請求項10】
前記ゲートウェイコントローラ(106)はさらに、前記IPネットワーク(20)から受け取った前記メッセージをカプセルから出すことを特徴とする、請求項9に記載のゲートウェイ(100)。
【請求項11】
前記ゲートウェイコントローラ(106)は、前記PAN(30)内のクライアント(32)からのメッセージを、前記クライアント(32)のアイデンティティに基づいて、対応するポートに出力することを特徴とする、請求項8に記載のゲートウェイ(100)。
【請求項12】
前記ゲートウェイコントローラ(106)はさらに、前記メッセージをIPパケットにカプセル化することを特徴とする、請求項8に記載のゲートウェイ(100)。
【請求項13】
前記ルーティングテーブル(110)は、前記ルーティングテーブル内(110)に、前記PANクライアント(32)のデバイス型を指し示す情報を含むことを特徴とする、請求項8に記載のゲートウェイ(100)。
【請求項14】
パーソナル・エリア・ネットワーク(PAN)(30)内のクライアントと通信する方法であって、
前記PAN(30)内の前記クライアント(32)と通信するために、前記PAN(30)上にPANエージェント(108)を生成する工程と、
前記PAN(30)内の前記クライアント(32)と、前記PANエージェント(108)を介して通信する工程とを含むことを特徴とする方法。
【請求項15】
前記PAN(30)エージェントは、ゲートウェイ上に存在することを特徴とする、請求項14に記載の方法。
【請求項16】
前記PANは、Zigbeeネットワークであることを特徴とする、請求項14に記載の方法。
【請求項17】
インターネット・プロトコル(IP)・ネットワーク(20)内に、前記PANエージェント(108)のための存在を生成する工程をさらに含むことを特徴とする、請求項14に記載の方法。
【請求項18】
前記IPネットワーク(20)中に前記PANエージェント(108)のための存在を生成する工程は、前記IPネットワーク(20)内の前記PANエージェント(108)のためのユーザエージェント(42)への接続を生成する工程を含むことを特徴とする、請求項17に記載の方法。
【請求項19】
前記ユーザエージェント(42)は、IPマルチメディアサブシステム(IMS)ユーザエージェントを含むことを特徴とする、請求項17に記載の方法。
【請求項20】
前記PAN(30)内の前記クライアント(32)と前記PANエージェント(108)を介して通信する前記工程は、前記ユーザエージェント(42)と通信する工程を含むことを特徴とする、請求項18に記載の方法。
【請求項21】
パーソナル・エリア・ネットワーク(PAN)(30)を、インターネット・プロトコル(IP)・ネットワーク(20)と接続するためのゲートウェイ(100)であって、
前記PAN(30)に接続するための第1のインタフェースデバイス(140)と、
前記IPネットワーク(20)と接続するための第2のインタフェースデバイス(102)と、
前記PAN(30)に接続されたクライアント(32)と通信することが可能なPANエージェント(108)を生成するためのノードマネージャ(112)を含む、ゲートウェイコントローラ(106)とを備えることを特徴とする、ゲートウェイ(100)。
【請求項22】
前記ノードマネージャ(112)は、前記第2のインタフェース(102)を通して受信されたIPクライアント(20)型要求に応えて、PANエージェント(108)を生成するように構成されていることを特徴とする、請求項21に記載のゲートウェイ(100)
【請求項23】
前記要求は、生成されるPANエージェント(108)の型を定義するパラメータを含むことを特徴とする、請求項22に記載のゲートウェイ(100)。
【請求項24】
前記PAN(30)はZigbeeネットワークを含み、
前記パラメータはZigbeeプロファイルIDを含むことを特徴とする、請求項23に記載のゲートウェイ(100)。
【請求項25】
前記ノードマネージャ(112)は、前記IPネットワーク内のユーザエージェント(42)と通信するように前記PANエージェント(108)を設定し、
IPクライアントは前記ユーザエージェント(42)を介して前記PANエージェント(108)と通信することを特徴とする、請求項22に記載のゲートウェイ(100)。
【請求項26】
前記ユーザエージェント(42)は、IMSクライアント(40)と通信するためのIPマルチメディアサブシステム(IMS)ユーザエージェントを含むことを特徴とする、請求項25に記載のゲートウェイ。
【請求項1】
パーソナル・エリア・ネットワーク(PAN)(30)とインターネット・プロトコル(IP)・ネットワーク(20)との間でメッセージを送信する方法であって、
前記PAN(30)内の1以上のPANクライアント(32)に対して、IPインタフェース(102)上のポートを割り当てる工程と、
前記PAN(30)内の前記PANクライアント(32)を、前記PANクライアント(32)に対応するポートと関係づけるためのルーティングテーブル(110)を、メモリに格納する工程と、
前記ルーティングテーブルに基づいて、前記PANクライアント(32)と前記IPネットワーク(20)との間でメッセージを運ぶ工程とを含むことを特徴とする方法。
【請求項2】
前記ルーティングテーブル(110)に基づいて前記PANクライアント(32)と前記IPネットワーク(20)との間でメッセージを運ぶ工程は、前記IPネットワーク(20)において発せられたメッセージを、どのポートで前記メッセージが受け取られたかに基づいて、前記PAN(30)内の対応するクライアント(32)に運ぶ工程を含むことを特徴とする、請求項1に記載の方法。
【請求項3】
前記メッセージはIPパケットにカプセル化され、
前記工程はさらに前記メッセージをカプセルから出す工程と、
前記カプセルから出されたメッセージを前記クライアント(32)へと送る工程とを含むことを特徴とする、請求項2に記載の方法。
【請求項4】
前記ルーティングテーブル(110)に基づいて前記PANクライアント(32)と前記IPネットワーク(20)との間でメッセージを運ぶ工程は、前記PAN(30)内の発信したクライアント(32)から受け取ったメッセージを、前記発信したクライアントに割り当てられたポートに出力する工程を含むことを特徴とする、請求項1に記載の方法。
【請求項5】
前記メッセージをIPパケットにカプセル化する工程と、
前記対応するポートに前記IPパケットを出力する工程とをさらに含むことを特徴とする、請求項4に記載の方法。
【請求項6】
前記IPインタフェースは、前記PAN(30)と前記IPネットワーク(20)との間のゲートウェイ(100)に位置することを特徴とする、請求項1に記載の方法。
【請求項7】
前記ルーティングテーブル(110)は、前記ルーティングテーブル内(110)に、前記PANクライアント(32)のデバイス型を指し示す情報を含むことを特徴とする、請求項1に記載の方法。
【請求項8】
パーソナル・エリア・ネットワーク(PAN)(30)をインターネット・プロトコル(IP)・ネットワーク(20)に接続するためのゲートウェイ(100)であって、
前記PAN(30)に接続するためのPANインタフェース(104)と、
前記IPネットワーク(20)に接続するための、1以上のポートを含むIPインタフェース(102)と、
前記PAN(30)内のそれぞれのクライアント(32)に対して、前記IPインタフェース(102)上のポートを割り当て、前記PAN(30)内のPANクライアント(32)と前記IPネットワーク(20)との間でメッセージを運ぶための、ゲートウェイコントローラ(106)と、
前記PAN(30)内の前記クライアントを前記IPインタフェース(102)上の対応するポートと関係づけるためのルーティング情報を、格納するためのメモリとを備えることを特徴とする、ゲートウェイ(100)。
【請求項9】
前記ゲートウェイコントローラ(106)は、前記IPネットワーク(20)からのメッセージを、どのポートで前記メッセージが受け取られたかに基づいて、前記PAN(30)内の対応するクライアントに運ぶことを特徴とする、請求項8に記載のゲートウェイ(100)。
【請求項10】
前記ゲートウェイコントローラ(106)はさらに、前記IPネットワーク(20)から受け取った前記メッセージをカプセルから出すことを特徴とする、請求項9に記載のゲートウェイ(100)。
【請求項11】
前記ゲートウェイコントローラ(106)は、前記PAN(30)内のクライアント(32)からのメッセージを、前記クライアント(32)のアイデンティティに基づいて、対応するポートに出力することを特徴とする、請求項8に記載のゲートウェイ(100)。
【請求項12】
前記ゲートウェイコントローラ(106)はさらに、前記メッセージをIPパケットにカプセル化することを特徴とする、請求項8に記載のゲートウェイ(100)。
【請求項13】
前記ルーティングテーブル(110)は、前記ルーティングテーブル内(110)に、前記PANクライアント(32)のデバイス型を指し示す情報を含むことを特徴とする、請求項8に記載のゲートウェイ(100)。
【請求項14】
パーソナル・エリア・ネットワーク(PAN)(30)内のクライアントと通信する方法であって、
前記PAN(30)内の前記クライアント(32)と通信するために、前記PAN(30)上にPANエージェント(108)を生成する工程と、
前記PAN(30)内の前記クライアント(32)と、前記PANエージェント(108)を介して通信する工程とを含むことを特徴とする方法。
【請求項15】
前記PAN(30)エージェントは、ゲートウェイ上に存在することを特徴とする、請求項14に記載の方法。
【請求項16】
前記PANは、Zigbeeネットワークであることを特徴とする、請求項14に記載の方法。
【請求項17】
インターネット・プロトコル(IP)・ネットワーク(20)内に、前記PANエージェント(108)のための存在を生成する工程をさらに含むことを特徴とする、請求項14に記載の方法。
【請求項18】
前記IPネットワーク(20)中に前記PANエージェント(108)のための存在を生成する工程は、前記IPネットワーク(20)内の前記PANエージェント(108)のためのユーザエージェント(42)への接続を生成する工程を含むことを特徴とする、請求項17に記載の方法。
【請求項19】
前記ユーザエージェント(42)は、IPマルチメディアサブシステム(IMS)ユーザエージェントを含むことを特徴とする、請求項17に記載の方法。
【請求項20】
前記PAN(30)内の前記クライアント(32)と前記PANエージェント(108)を介して通信する前記工程は、前記ユーザエージェント(42)と通信する工程を含むことを特徴とする、請求項18に記載の方法。
【請求項21】
パーソナル・エリア・ネットワーク(PAN)(30)を、インターネット・プロトコル(IP)・ネットワーク(20)と接続するためのゲートウェイ(100)であって、
前記PAN(30)に接続するための第1のインタフェースデバイス(140)と、
前記IPネットワーク(20)と接続するための第2のインタフェースデバイス(102)と、
前記PAN(30)に接続されたクライアント(32)と通信することが可能なPANエージェント(108)を生成するためのノードマネージャ(112)を含む、ゲートウェイコントローラ(106)とを備えることを特徴とする、ゲートウェイ(100)。
【請求項22】
前記ノードマネージャ(112)は、前記第2のインタフェース(102)を通して受信されたIPクライアント(20)型要求に応えて、PANエージェント(108)を生成するように構成されていることを特徴とする、請求項21に記載のゲートウェイ(100)
【請求項23】
前記要求は、生成されるPANエージェント(108)の型を定義するパラメータを含むことを特徴とする、請求項22に記載のゲートウェイ(100)。
【請求項24】
前記PAN(30)はZigbeeネットワークを含み、
前記パラメータはZigbeeプロファイルIDを含むことを特徴とする、請求項23に記載のゲートウェイ(100)。
【請求項25】
前記ノードマネージャ(112)は、前記IPネットワーク内のユーザエージェント(42)と通信するように前記PANエージェント(108)を設定し、
IPクライアントは前記ユーザエージェント(42)を介して前記PANエージェント(108)と通信することを特徴とする、請求項22に記載のゲートウェイ(100)。
【請求項26】
前記ユーザエージェント(42)は、IMSクライアント(40)と通信するためのIPマルチメディアサブシステム(IMS)ユーザエージェントを含むことを特徴とする、請求項25に記載のゲートウェイ。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図7A】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図7A】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【公開番号】特開2011−229180(P2011−229180A)
【公開日】平成23年11月10日(2011.11.10)
【国際特許分類】
【外国語出願】
【出願番号】特願2011−146282(P2011−146282)
【出願日】平成23年6月30日(2011.6.30)
【分割の表示】特願2009−526770(P2009−526770)の分割
【原出願日】平成19年3月28日(2007.3.28)
【出願人】(502087507)ソニー エリクソン モバイル コミュニケーションズ, エービー (823)
【Fターム(参考)】
【公開日】平成23年11月10日(2011.11.10)
【国際特許分類】
【出願番号】特願2011−146282(P2011−146282)
【出願日】平成23年6月30日(2011.6.30)
【分割の表示】特願2009−526770(P2009−526770)の分割
【原出願日】平成19年3月28日(2007.3.28)
【出願人】(502087507)ソニー エリクソン モバイル コミュニケーションズ, エービー (823)
【Fターム(参考)】
[ Back to top ]