パーソナルエリアネットワークPAN30とインターネットプロトコルIPネットワーク20との間でメッセージを送信する方法であって、前記PAN30内の1以上のPANクライアント32に対して、IPインタフェース102上のポートを割り当てる工程と、前記PAN30内の前記PANクライアント32を、前記PANクライアント32に対応するポートと関係づけるためのルーティングテーブル110を、メモリに格納する工程と、前記ルーティングテーブルに基づいて、前記PANクライアント32と前記IPネットワーク20との間でメッセージを運ぶ工程とを含むことを特徴とする方法。前記ルーティングテーブル110に基づいて前記PANクライアント32と前記IPネットワーク20との間でメッセージを運ぶ工程は、前記IPネットワーク20において発せられたメッセージを、どのポートで前記メッセージが受け取られたかに基づいて、前記PAN30内の対応するクライアント32に運ぶ工程を含むことを特徴とする、請求項1に記載の方法。前記メッセージはIPパケットにカプセル化され、前記工程はさらに前記メッセージをカプセルから出す工程と、前記カプセルから出されたメッセージを前記クライアント32へと送る工程とを含むことを特徴とする、請求項2に記載の方法。前記ルーティングテーブル110に基づいて前記PANクライアント32と前記IPネットワーク20との間でメッセージを運ぶ工程は、前記PAN30内の発信したクライアント32から受け取ったメッセージを、前記発信したクライアントに割り当てられたポートに出力する工程を含むことを特徴とする、請求項1に記載の方法。前記メッセージをIPパケットにカプセル化する工程と、前記対応するポートに前記IPパケットを出力する工程とをさらに含むことを特徴とする、請求項4に記載の方法。前記IPインタフェースは、前記PAN30と前記IPネットワーク20との間のゲートウェイ100に位置することを特徴とする、請求項1に記載の方法。前記ルーティングテーブル110は、前記ルーティングテーブル内110に、前記PANクライアント32のデバイス型を指し示す情報を含むことを特徴とする、請求項1に記載の方法。パーソナルエリアネットワークPAN30をインターネットプロトコルIPネットワーク20に接続するためのゲートウェイ100であって、前記PAN30に接続するためのPANインタフェース104と、前記IPネットワーク20に接続するための、1以上のポートを含むIPインタフェース102と、前記PAN30内のそれぞれのクライアント32に対して、前記IPインタフェース102上のポートを割り当て、前記PAN30内のPANクライアント32と前記IPネットワーク20との間でメッセージを運ぶための、ゲートウェイコントローラ106と、前記PAN30内の前記クライアントを前記IPインタフェース102上の対応するポートと関係づけるためのルーティング情報を、格納するためのメモリとを備えることを特徴とする、ゲートウェイ100。前記ゲートウェイコントローラ106は、前記IPネットワーク20からのメッセージを、どのポートで前記メッセージが受け取られたかに基づいて、前記PAN30内の対応するクライアントに運ぶことを特徴とする、請求項8に記載のゲートウェイ100。前記ゲートウェイコントローラ106はさらに、前記IPネットワーク20から受け取った前記メッセージをカプセルから出すことを特徴とする、請求項9に記載のゲートウェイ100。前記ゲートウェイコントローラ106は、前記PAN30内のクライアント32からのメッセージを、前記クライアント32のアイデンティティに基づいて、対応するポートに出力することを特徴とする、請求項8に記載のゲートウェイ100。前記ゲートウェイコントローラ106はさらに、前記メッセージをIPパケットにカプセル化することを特徴とする、請求項8に記載のゲートウェイ100。前記ルーティングテーブル110は、前記ルーティングテーブル内110に、前記PANクライアント32のデバイス型を指し示す情報を含むことを特徴とする、請求項8に記載のゲートウェイ100。パーソナルエリアネットワークPAN30内のクライアントと通信する方法であって、前記PAN30内の前記クライアント32と通信するために、前記PAN30上にPANエージェント108を生成する工程と、前記PAN30内の前記クライアント32と、前記PANエージェント108を介して通信する工程とを含むことを特徴とする方法。前記PAN30エージェントは、ゲートウェイ上に存在することを特徴とする、請求項14に記載の方法。前記PANは、Zigbeeネットワークであることを特徴とする、請求項14に記載の方法。インターネットプロトコルIPネットワーク20内に、前記PANエージェント108のための存在を生成する工程をさらに含むことを特徴とする、請求項14に記載の方法。前記IPネットワーク20中に前記PANエージェント108のための存在を生成する工程は、前記IPネットワーク20内の前記PANエージェント108のためのユーザエージェント42への接続を生成する工程を含むことを特徴とする、請求項17に記載の方法。前記ユーザエージェント42は、IPマルチメディアサブシステムIMSユーザエージェントを含むことを特徴とする、請求項17に記載の方法。前記PAN30内の前記クライアント32と前記PANエージェント108を介して通信する前記工程は、前記ユーザエージェント42と通信する工程を含むことを特徴とする、請求項18に記載の方法。パーソナルエリアネットワークPAN30を、インターネットプロトコルIPネットワーク20と接続するためのゲートウェイ100であって、前記PAN30に接続するための第1のインタフェースデバイス140と、前記IPネットワーク20と接続するための第2のインタフェースデバイス102と、前記PAN30に接続されたクライアント32と通信することが可能なPANエージェント108を生成するためのノードマネージャ112を含む、ゲートウェイコントローラ106とを備えることを特徴とする、ゲートウェイ100。前記ノードマネージャ112は、前記第2のインタフェース102を通して受信されたIPクライアント20型要求に応えて、PANエージェント108を生成するように構成されていることを特徴とする、請求項21に記載のゲートウェイ100前記要求は、生成されるPANエージェント108の型を定義するパラメータを含むことを特徴とする、請求項22に記載のゲートウェイ100。前記PAN30はZigbeeネットワークを含み、前記パラメータはZigbeeプロファイルIDを含むことを特徴とする、請求項23に記載のゲートウェイ100。前記ノードマネージャ112は、前記IPネットワーク内のユーザエージェント42と通信するように前記PANエージェント108を設定し、IPクライアントは前記ユーザエージェント42を介して前記PANエージェント108と通信することを特徴とする、請求項22に記載のゲートウェイ100。前記ユーザエージェント42は、IMSクライアント40と通信するためのIPマルチメディアサブシステムIMSユーザエージェントを含むことを特徴とする、請求項25に記載のゲートウェイ。本発明は、Zigbeeパーソナルエリアネットワークのような多様なネットワークと、IPネットワークとの間の通信に関する。ゲートウェイは、IPネットワークに接続するための第1のインタフェースデバイスと、Zigbeeネットワークと接続するための第2のインタフェースデバイスと、ゲートウェイコントローラとを含む。ゲートウェイコントローラは、IPネットワークとZigbeeネットワークとの間のメッセージをルーティングする。ある実施形態においては、ゲートウェイコントローラは、Zigbeeネットワーク内のクライアントに対してIPインタフェースデバイス上のポートを割り当てる。ゲートウェイコントローラは、割り当てられたポートを対応するZigbeeクライアントに関係づけるルーティングテーブルを保守する。ルーティングテーブルは例えば、Zigbeeクライアントについてのネットワークアドレスと、対応するポートとを含んでもよい。ゲートウェイに、IPネットワークからメッセージが到着すると、メッセージがどのポートに到着したかが、対応するZigbeeクライアントのネットワークアドレスを調べるために用いられる。逆に、Zigbeeクライアントからのメッセージは、発信したZigbeeクライアントのネットワークアドレスに基づいて対応するポートへと出力される。ある実施形態においては、ゲートウェイはZigbeeクライアントにポートを割り当て、ルーティングテーブルを保守する、ゲートウェイプロキシと協力して動作してもよい。他の実施形態においては、ゲートウェイコントローラは、IPクライアントからの要求に応答するZigbeeエージェントを生成することができる、ノードマネージャを含む。Zigbeeエージェントは、要求するIPクライアントのために、Zigbeeネットワークに関するプレゼンスを提供してもよい。Zigbeeエージェントは、Zigbeeクライアントにとって、他のどんなZigbeeアプリケーションのようにも見える。Zigbeeエージェントは、IPクライアントによって遠隔制御及び遠隔操作されることができる。ここで図面を参照すると、本発明に従う通信ネットワーク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は、明かり、センサ等のデバイスを制御するために用いられうる。図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以上のプログラム可能なプロセッサにおけるソフトウェアとして実装されてもよい。Zigbee規格は、限られた電力、CPU及びメモリ資源を有する小デバイスのための短距離、低電力、低データレート無線インタフェースを規定する、電気電子学会IEEE802.15.4規格に基づいている。Zigbee規格は、Zigbeeクライアント32間のネットワーキングを可能とする、ネットワーク及びアプリケーションレベルのプロトコルのセットを含む。Zigbeeクライアント32は、Zigbeeネットワーク30内のノードを含む。コーディネイタ、ルータ、及びエンドデバイスの3種類のノードが存在する。様々なノードは、スタートポロジ、ツリートポロジ、又はメッシュトポロジによって相互に接続されていてもよい。ネットワークトポロジにかかわらず、それぞれのZigbeeネットワーク30は1つのそして1つだけのコーディネイタを含む。コーディネイタは、他のノードが参加できるZigbeeネットワーク30を構成し、管理する責任を持つ。いくつかの実施形態においてはコーディネイタはまた、Zigbeeネットワーク30の様々なノード間でのメッセージのルーティングのためのバインディングテーブルを保守してもよい。ツリー又はメッシュトポロジを用いるZigbeeネットワーク30は、少なくとも1つのルータの存在を必要とする。ルータは、Zigbeeネットワーク30内の1つのノードから他のノードへのメッセージを転送し、子ノードが接続することを可能とする。ルータは、Zigbeeネットワーク30に参加するエンドデバイスにとってのローカルなコーディネイタとして働く。エンドデバイスは典型的には、特定のタスクを実行する1以上のアプリケーションをホストする。例えばエンドデバイスは、データを収集及び報告し、並びに家庭内の明かりのようなホームデバイスを制御するためのアプリケーションを有してもよい。Zigbeeネットワーク30内では、それぞれのノードは一意のアドレスによって特定される。Zigbeeネットワーク30は、2つのアドレス指定機構を採用する。それぞれのノードは、ロングアドレス及びショートアドレスを持つ。IEEEアドレス又はMACアドレスとも呼ばれるロングアドレスは、IEEEによって割り当てられた、ノードを一意に特定する64ビットアドレスである。ネットワークアドレスとも呼ばれるショートアドレスは、Zigbeeネットワーク30のノードをネットワークコーディネイタに対して特定する、16ビットアドレスである。ネットワークアドレスは、ノードがZigbeeネットワーク30に参加する時に、コーディネイタ又はルータによって割り当てられる。ノードは、1以上のユーザアプリケーションをホストしてもよい。例えば、ネットワーク30内に温度及び湿度を監視するための1つのアプリケーションが存在してもよい。このようなアプリケーションは、ノード上のエンドポイントと呼ばれる。これらのアプリケーションは、Zigbeeネットワーク30の内部又は外部の他のアプリケーションと、メッセージを送受信してもよい。ノードに到着したメッセージを適切なアプリケーションに向けるために、それぞれのエンドポイントはエンドポイントアドレスによって特定される。エンドポイントアドレスは、IPアドレスにおけるポートに類似している。クライアント32は、1から240まで番号付けされる、最大240のアプリケーション又はエンドポイントを有してもよい。エンドポイント255は、ブロードキャストエンドポイントアドレスである。エンドポイント255に向けられたメッセージは、ノード上の全てのアプリケーションに配達されるだろう。アプリケーションは、アプリケーションオブジェクトとしてモデル化される。アプリケーションプロファイルは、関連する又は相補的なアプリケーションオブジェクトの間の相互作用を定義する。アプリケーションプロファイルは、パブリックであってもプライベートであってもよい。パブリックアプリケーションプロファイルは、異なるベンダからのデバイスが協同作業することを可能とする。プライベートアプリケーションプロファイルはプロプライエタリな独占的なものである。Zigbeeアライアンスは、多くのパブリックプロファイルを提供する。このようなパブリックプラファイルの1つが、HomeControlLightingProfile家庭制御、明かりプロファイルであり、これは家庭環境における明かりレベルを感知及び制御することに焦点を合わせている。このプロファイルは、LightSensorMonochromatic明かりセンサ単色光、SwitchRemoteControlスイッチ遠隔制御、SwitchingLoadControllerロードコントローラのスイッチ、及びDimmerRemoteControl薄暗さ遠隔制御を含む多くのデバイスを定義する。アプリケーションオブジェクトは、オブジェクト属性及びクラスタを介して、他のアプリケーションオブジェクトと通信する。オブジェクト属性は、アプリケーションオブジェクト間で通信される、データアイテムである。それぞれの属性は、自身の一意な識別子を有する。Zigbee規格は、オブジェクト属性についてのデータ型のセットを定義する。属性のグルーピングはクラスタを含み、クラスタもまた自身の一意の識別子を有する。クラスタ内の属性には、必須のものもあれば任意のものもある。それぞれのクラスタは、216個までの属性を含むことができる。入力クラスタは、他のアプリケーションオブジェクトによって送られることができる属性からなる。例えば、センサを監視するためのアプリケーションオブジェクトは、センサの読み取りの間の時間間隔を制御するreporttime報告時間と呼ばれる属性を有してもよい。出力クラスタは、他のアプリケーションオブジェクトにデータを供給する属性を含む。相補的な入力クラスタと出力クラスタとを備えるアプリケーションオブジェクトは、他のアプリケーションオブジェクトと通信することができる。アプリケーションオブジェクトは、バインディングとして知られているプロセスを介して通信を開始することができる。バインディングは、アプリケーションオブジェクト間の論理的なリンクを生成する。バインディング機構は、情報を生成するアプリケーションを、その情報を使用するアプリケーションと結びつける。情報は、クラスタとして交換される。2つのアプリケーションオブジェクトが結びつけられるためには、それらは相補的な入力クラスタと出力クラスタとを持たなければならない。2つのアプリケーションオブジェクトが結びつくと、1つのアプリケーションオブジェクトの出力クラスタは、他のアプリケーションオブジェクトの入力クラスタと接続される。2つのアプリケーションオブジェクト間のバインディングは、クラスタが生成されたアプリケーションオブジェクトのネットワークアドレス及びエンドポイントソース、クラスタを消費するアプリケーションオブジェクトのネットワークアドレス及びエンドポイントデスティネーション、並びにそれらの間で送られるクラスタについてのクラスタIDによって特定される。結びつけられたアプリケーションオブジェクトは、MSG及びKVPメッセージサービスを用いてメッセージを送受信できる。バインディング情報が格納されている場所に応じて、ソースからデスティネーションへのクラスタ情報の伝送は、直接的又は間接的である。直接アドレッシングでは、情報を送ったノードが、デスティネーションアプリケーションオブジェクトが存在するノードについてのネットワークアドレスを決定し、そのデスティネーションアドレスをメッセージに挿入する。異なったノードで複数のアプリケーションオブジェクトがメッセージを受け取る場合、メッセージは複製され、少なくとも1つのデスティネーションアプリケーションオブジェクトが存在するそれぞれのノードに、複製が送られる。間接アドレッシングでは、出力クラスタはコーディネイタに送られる。コーディネイタは、バインディングテーブルを保守している。コーディネイタは送信ノードのソースアドレスとクラスタIDとに基づいて、デスティネーションノードを決定する。コーディネイタは、コーディネイタのバインディングテーブルにおいて、ソースクラスタとアプリケーションアドレスとを含むの全てのエントリを見つけ、それぞれの受信ノードに向けたメッセージを生成する。それぞれのメッセージについて、コーディネイタはメッセージ中にバインディングテーブルからのデスティネーションアドレスを挿入する。Zigbee規格は、ネットワーク内のZigbeeクライアント32が、他のクライアント32のアドレス及び能力を発見することを可能にする発見機構を含む。デバイス発見は、Zigbeeクライアント32が、ネットワーク上の他のクライアントのネットワークアドレスを発見するためにネットワーク30に問い合わせることを可能とする。サービス発見は、Zigbeeクライアント32が他のZigbeeクライアント32の能力に関する情報を要求することを可能にする。サービス情報は記述子として格納され、Zigbeeクライアント32のデバイス型及び能力のような情報、並びにZigbeeクライアント32上で動作しているアプリケーションの型に関する情報を含んでもよい。Zigbeeクライアント32に格納される、3つの必須な記述子と2つの任意的な記述子とが存在する。必須な記述子は、ノード記述子、ノード電力記述子、及び単純記述子である。任意的な記述子は、複合記述子及びユーザ記述子と呼ばれる。それぞれのZigbeeクライアント32について、ただ1つのノード記述子及びノード電力記述子が存在する。エンドポイントに属するそれぞれのアプリケーションについて、単純記述子が存在し、複合記述子とユーザ記述子との少なくとも一方が存在することも可能である。ノード記述子は、Zigbeeクライアント32の型すなわち、コーディネイタ、ルータ、又はエンドデバイス及び能力を記述する。Zigbeeクライアント32の能力又はノードの能力とは、使用されている周波数帯及び最大バッファサイズのような属性である。出力記述子は、どのようにクライアント32が電力を供給されているかに関する情報を含む。このような情報は、電力モードすなわちデバイスが常に電源が入っているか、又は定期的に起動するか、利用可能な電源、現在使用されている電源及び現在の電源レベルを含んでもよい。単純記述子は、Zigbeeクライアント32のエンドポイントに属しているアプリケーションに関する情報を含む。この情報は、アプリケーションが存在するエンドポイントアドレス、アプリケーションが実装するアプリケーションプロファイル、及びサポートされている入力クラスタ及び出力クラスタのリストを含む。単純記述子はまた、対応する複合記述子及びユーザ記述子が存在するか否かを示す。図3は、電気電子学会IEEE802.15.4無線通信規格上に構築された、Zigbeeプロトコルスタックを示す。IEEE規格は、無線チャネルを介する通信のための短距離無線インタフェースを規定する。IEEE規格は、プロトコルスタックの物理層及び媒体アクセス制御MAC層についての仕様を含む。Zigbee規格は、ユーザアプリケーションをサポートするための、ネットワーク層及びアプリケーション層のプロトコル本明細書では、まとめてZigbeeスタック又はZigbeeプロトコルと呼ばれるのセットを定義する。ネットワーク層は、ネットワークに参加し、及びネットワークから抜けるための、並びにメッセージを適切な行き先に送るための機構を定義する。ネットワーク層はまた、デバイス発見及びサービス発見のための機構も提供する。これらの機構は、Zigbeeノードがネットワーク内の他のノードを発見し、そのようなノードの能力を発見することを可能にする。ネットワーク層はまた、Zigbeeネットワークの形成を管理し、ネットワークに参加するデバイスにアドレスを割り当てる。アプリケーション層は、アプリケーションフレームワークAF、アプリケーションサポートサブレイヤーAPS、及びZigbeeデバイスオブジェクトを含む。アプリケーションフレームワークは、アプリケーションとAPSとの間のインタフェースを提供する。APSは、アプリケーションオブジェクト間の論理的な結合を生成する、バインディング機構を実装する。メッセージがZigbeeクライアント32に到着した時、APSが適切なアプリケーションにメッセージを配達する責任を持つ。ZigbeeデバイスオブジェクトZDOは、デバイスのZigbeeノード型例えば、コーディネイタ、ルータ、又はエンドデバイスを表す。Zigbeeデバイスオブジェクトはまた、Zigbeeネットワーク30上でのデバイス発見及びサービス発見を開始する。Zigbeeプロトコルは、同一のZigbeeネットワーク30内の2以上のZigbeeクライアント32が、互いに通信することを可能にする。しかしながら、Zigbeeプロトコルは、Zigbeeクライアント32が、IPネットワーク20内のIPクライアント22と通信することを可能にする機構を提供しない。本発明は、このような通信を促進する、ゲートウェイ機能を提供する。図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と通信できる。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以上のメッセージパラメータフィールド、及びデータフィールドを含む。メッセージ型フィールドは、メッセージの型を示す。メッセージパラメータフィールドは、メッセージ型について必要とされるパラメータを与える。データフィールドはメッセージデータを含む。ゲートウェイ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アドレス又はショートアドレスを確認し、ルーティングテーブル中で特定される対応するポートへとデータを出力する。図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が確立された時に用意される。存在フィールド及び状態フィールドは、Zigbeeクライアント32に関する状態情報を含む。存在フィールドは、ノードがゲートウェイ100によって検出されるか否かを示す。このフィールドはノードが検出された時にはTRUEに設定されてもよく、そうでなければFALSEに設定されてもよい。状態フィールドは現在のポートの状態を示す。IPクライアント22がポートに接続されている時には、状態は接続であり、そうでなければ切断である。ゲートウェイ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は削除されてもよい。一度ゲートウェイ100が動作すると、IPクライアント22はZigbeeクライアント32との通信を確立することができる。また、Zigbeeクライアント32はIPクライアント22との通信を開始してもよい。図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例えば、デバイス型=明かりについて、ゲートウェイ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クライアントへと送られる。図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によって保守される。IPコントローラ106AとZigbeeコントローラ106Bとの間でデータを運ぶために、単純なシリアル通信プロトコルが用いられる。IPコントローラ106AとZigbeeコントローラ106Bとの間でのメッセージを運ぶための、一例としてのメッセージフォーマットが、図18に示される。このメッセージフォーマットは、メッセージ型フィールド、1以上のメッセージパラメータフィールド、及びデータフィールドを含む。メッセージ型フィールドは、メッセージの型を示す。メッセージパラメータフィールドは、メッセージ型について要求されるパラメータを与える。データフィールドは、メッセージデータを含む。典型的なメッセージ型は、SEND、CONNECT/DISCONNECT、ACK/NACKを含む。メッセージデータを運ぶために、SENDメッセージがIPコントローラ106AとZigbeeコントローラ106Bとの間で送られる。CONNECT/DISCONNECTメッセージは、特定のIPクライアント22への接続を開き又は切るために、Zigbeeコントローラ106BからIPコントローラ106Aへと送られる。ACK/NACKメッセージは、SEND又はCONNECT/DISCONNECTメッセージに応答するために用いられる。他のメッセージもまた、定義されうる。メッセージパラメータは、メッセージ型に応じて変化しうる。例えば、SENDメッセージについてのメッセージパラメータフィールドは、ADDRESS要素とDATATYPE要素とを含んでもよい。ADDRESSエレメントは、発信又は着信Zigbeeクライアント32のMACアドレスを含んでいてもよい。Zigbeeネットワーク30からIPネットワーク20へと進む伝送のために、このフィールドは発信Zigbeeクライアント32のMACアドレス又はショートアドレスを含んでいるかもしれない。以下で記述されるように、ゲートウェイ100はこのアドレスを、データが出力される適切なポートを決定するために用いてもよい。IPネットワークからZigbeeネットワーク30への通信のために、ADDRESSエレメントは着信Zigbeeクライアント32のMACアドレス又はショートアドレスを含んでいてもよい。DATATYPE要素は、送信されるデータの型、例えばテキスト、オーディオ、ビデオ、バイナリ等を示すために用いられてもよい。図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メッセージをカプセルから出すための、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によって用いられることが可能である。ゲートウェイ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メッセージを送ることは望ましくないかもしれない。図10に示される実施形態において、Zigbeeクライアント32上に存在するIMSを認識可能なアプリケーションは、IPネットワーク20に接続されたIMSユーザエージェントサーバ42と通信する。ゲートウェイ100上に存在するユーザエージェントクライアントUAC44は、UAS42と通信するために用いられる。UAS42への接続を持つそれぞれのZigbeeクライアント32に対する、別々のUAC44がインスタンス生成される。Zigbeeクライアント32上に存在するIMSを認識可能なアプリケーションは、IMSクライアント40を遠隔制御し、IMSトランザクションに参加することができる。2005年4月40日に出願され、ネットワーク化された通信デバイスのためのメディアクライアントアーキテクチャと題する米国特許出願番号11/114427号は、アプリケーションとの遠隔通信のための、高レベルアプリケーションインタフェースを有するユーザエージェントを記述する。このユーザエージェントは、本発明においてユーザエージェントサーバ42として働きうる。この出願が、ここに参照により組み込まれる。IMSクライアント40をIPネットワーク20内に位置させることにより、ゲートウェイ100を越える必要があるメッセージはより少なくなるだろう。さらに、Zigbeeクライアント32上に存在するアプリケーションと、IMSクライアント40上に存在するアプリケーションとの間で送られるメッセージは、テキストではなくバイナリ型で送られてもよく、メッセージの大きさを大きく減らすだろう。こうして、ゲートウェイ100を通して送信されるデータは、著しく削減されることができる。IMSクライアント40が、IMSへの認識に欠ける工業標準のZigbeeアプリケーションで通信することが望ましい場合もありうる。このような通信は、図11に示されるようなメッセージ翻訳器50の使用によって促進される。メッセージ翻訳器50は、メッセージ翻訳サービスをも提供するSIPプロキシサーバとして働く。メッセージ翻訳器50は、IPネットワーク20に接続されたものとして図11に示されているが、当業者ならメッセージ翻訳機能がゲートウェイ100に位置するメッセージ翻訳器50によって実現されうることを理解するだろう。例を与えるために、IMSクライアント40が、HomeControlLightingprofileに従って動作する1以上のZigbee明かりセンサからの情報を集めることを望むことを仮定する。明かりセンサはSIPユーザ名を割り当てられ、SIPユーザ名はSIPレジスタに登録されていることが仮定される。図12は、メッセージ翻訳器50によって実行される典型的な手順を示す。メッセージ翻訳器50は、IMSクライアント40からSUBSCRIBEメッセージを受け取るステップ170。SUBSCRIBEメッセージは、Zigbeeネットワーク30内の明かりセンサについてのSIPURIを含む。メッセージを受信すると、メッセージ翻訳器50はIMSクライアント40によって与えられたSIPユーザ名を用いる従来の方法で、SIPレジスタからゲートウェイ100のIPアドレスとポートとを取得するステップ172。メッセージ翻訳器50は次に、メッセージを標準Zigbeeメッセージへと変換しステップ174、メッセージを1以上のIPパケットにカプセル化しステップ176、IPパケットをゲートウェイ100へと転送するステップ178。ゲートウェイ100は、IPパケットからカプセル化されたZigbeeメッセージを抽出し、前に記述したようにカプセル化されたZigbeeメッセージを明かりセンサを制御するZigbeeクライアント32へと転送する。図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に接続されたサーバ上に存在するソフトウェアアプリケーションとして実装されてもよい。ゲートウェイ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とのリンクが遮断された時に、データをバッファできる。図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アプリケーションと相互作用することを可能にする。例として、IPクライアント22がZigbeeネットワーク30内の明かりセンサを監視することを望むことを仮定する。IPクライアント22はゲートウェイ100と接続し、Zigbeeエージェント108が明かりセンサを監視するために生成されることを要求してもよい。この例ではゲートウェイ100は、明かりセンサとのバインディングを可能とする、プロファイルIDとクラスタIDとを有するZigbeeエージェント108を生成するだろう。Zigbeeエージェント108は、標準Zigbee明かりセンサから明かりセンサ読み取り値を受け取り、それらの読み取り値をIPクライアント22へと転送してもよい。Zigbee明かりセンサは、どんな特別な能力も必要としない。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と同じように扱う。図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。図16は、前の実施形態からの要素を結合する実施形態を示す。この実施形態は、図13に示されるゲートウェイ100と、プロキシ120と、ユーザエージェントサーバUAS42とを含む。この実施形態におけるプロキシ120は、IMSを認識可能なZigbeeクライアント32の代わりにUAS42との接続を確立するために用いられる、1以上のIMSユーザエージェントクライアント44を含む。別々のIMSユーザクライアントUAC44が、それぞれのIMSを認識可能なZigbeeクライアント32について生成される。プロキシ120もまた、UAC44を有する。ゲートウェイ100は、前に記述したように、Zigbeeエージェント108をインスタンス生成するためのノードマネージャ112を含む。ゲートウェイ100とプロキシ120との双方が、どちらかの末端がデータを受信することが不可能であるか、又はゲートウェイ100をIPネットワーク20と接続するIPリンクが遮断された時に、データトラフィックをバッファすることが可能である。ゲートウェイ100のこの実施形態は、IMSクライアント40と、IMSを認識可能なZigbeeクライアント32とIMSを認識可能でないZigbeeクライアント32との双方との、通信を可能にする。図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メッセージは、IMSSTATE命令メッセージ中に埋め込まれ、メッセージがIMSUASTATEメッセージにフォーマットされるプロキシ120に送られる。メッセージはそして、IMSユーザエージェントクライアント44及びIMSユーザエージェントサーバ42を介してIMSクライアント40に転送されるステップi。他の実施形態ではUAC44は、Zigbeeエージェント108から直接IMSクライアント40へとメッセージを転送するように構成されることもできるだろう。IMSクライアント40はまた、ZigbeeMSG及びKVPメッセージを、IMSMSGメソッドを用いて、Zigbeeネットワーク30上のどんなZigbeeクライアントへも送ってよい。ZigbeeメッセージはIMSMSGリクエスト中にカプセル化され、ゲートウェイ100上のZigbeeエージェント108へと送られる。当業者なら、Zigbeeエージェント108とIMSクライアント40との間の通信を確立するための上述の技術が、SUBSCRIBEメソッド以外の標準SIPメソッドとともに使われることもできるだろうことを、理解するだろう。本発明はもちろん、本発明の範囲及び必須の特徴から逸脱することなく、本明細書で説明された以外の他の特定の方法で実行されてもよい。本実施形態はそれゆえ、あらゆる観点において、説明的なものであって、制限的なものではないと考えられるべきである。また、添付の請求の範囲の意図する範囲内、並びにその均等範囲内となる全ての変更は、本発明に含まれることが意図されている。