(57)【要約】【課題】本方法は、通信ネットワークにおいて、第１のアプリケーション層プロトコルを第２のアプリケーション層プロトコルに変換する。【解決手段】アプリケーションノードにおいて上記第１のアプリケーション層プロトコルの要求が要求ノードから受信される。当該要求は変換ノードへ送信され、そのメッセージを上記第２のアプリケーション層プロトコルに変換する。変換された要求は次に、当該変換ノードから上記アプリケーションノードに返送される。すると、上記アプリケーションノードは上記要求に対する応答を構成することができ、この応答もまた、当該アプリケーションノードが上記要求ノードに応答する前に上記変換ノードによって変換される。【選択図】        図２
2004164569.tif 000002
【特許請求の範囲】
【請求項１】
通信ネットワークにおいて第１のアプリケーション層プロトコルを第２のアプリケーション層プロトコルに変換する方法であって、
アプリケーションノードにおいて前記第１のアプリケーション層プロトコルの要求を要求ノードから受信するステップと、
前記要求を変換ノードへ送信してそのメッセージを前記第２のアプリケーション層プロトコルに変換するステップと、
前記アプリケーションノードにおいて前記第２のアプリケーション層プロトコルの前記要求を前記変換ノードから受信するステップと
を含む通信ネットワークにおいて第１のアプリケーション層プロトコルを第２のアプリケーション層プロトコルに変換する方法。
【請求項２】
前記第２のアプリケーション層プロトコルの応答を送信し、各プロトコルについて変換ノードのアドレスを処理ノードのテーブルに格納するステップと、
前記第１のアプリケーション層プロトコルの前記応答を前記変換ノードから受信するステップと、
前記要求に対して前記要求ノードへ前記第２のアプリケーション層プロトコルの前記応答を送信するステップと
をさらに含む請求項１記載の通信ネットワークにおいて第１のアプリケーション層プロトコルを第２のアプリケーション層プロトコルに変換する方法。
【請求項３】
各項目がプロトコル名と、関連する変換ノードのアドレスである、テーブルを前記アプリケーションノードに格納するステップ
をさらに含む請求項１記載の通信ネットワークにおいて第１のアプリケーション層プロトコルを第２のアプリケーション層プロトコルに変換する方法。
【請求項４】
各プロトコル名について複数の対応する変換ノードの複数のアドレスが格納される
請求項３記載の通信ネットワークにおいて第１のアプリケーション層プロトコルを第２のアプリケーション層プロトコルに変換する方法。
【請求項５】
前記複数のアドレスの各々は、関連する利用可能性のビットを有する
請求項４記載の通信ネットワークにおいて第１のアプリケーション層プロトコルを第２のアプリケーション層プロトコルに変換する方法。
【請求項６】
前記テーブルは、前記アプリケーションノードのＩ／Ｏポートを経由して受信した情報から構成される
請求項３記載の通信ネットワークにおいて第１のアプリケーション層プロトコルを第２のアプリケーション層プロトコルに変換する方法。
【請求項７】
前記テーブルは、前記通信ネットワークを経由して受信した情報から構成される
請求項３記載の通信ネットワークにおいて第１のアプリケーション層プロトコルを第２のアプリケーション層プロトコルに変換する方法。
【請求項８】
前記テーブルは、前記アプリケーションノードのプロトコルマネージャによって構成される
請求項３記載の通信ネットワークにおいて第１のアプリケーション層プロトコルを第２のアプリケーション層プロトコルに変換する方法。
【請求項９】
前記アプリケーションノードにおける受信するステップと送信するステップとは、プロトコルディスパッチャによって行われる
請求項１記載の通信ネットワークにおいて第１のアプリケーション層プロトコルを第２のアプリケーション層プロトコルに変換する方法。
【請求項１０】
前記アプリケーションノードは、デバイス固有のプロセスを備える
請求項１記載の通信ネットワークにおいて第１のアプリケーション層プロトコルを第２のアプリケーション層プロトコルに変換する方法。
【請求項１１】
通信ネットワークにおいて第１のアプリケーション層プロトコルを第２のアプリケーション層プロトコルに変換するシステムであって、
前記第１のアプリケーション層プロトコルの要求を送信するように構成される要求ノードと、
前記要求を受信し、前記要求を転送するように構成されるアプリケーションノードと、
前記要求を前記第１のアプリケーション層プロトコルから前記第２のアプリケーション層プロトコルに変換し、前記変換した要求を前記アプリケーションノードへ送信するように構成される変換ノードと
を備える通信ネットワークにおいて第１のアプリケーション層プロトコルを第２のアプリケーション層プロトコルに変換するシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、包括的にはデータ通信システムに関し、特に、異なるタイプのアプリケーションプロトコル間でのプロトコル変換に関する。
【０００２】
【従来の技術】
オープンなユビキタスコンピュータシステムおよびマルチベンダーに対する需要が高まるのに伴い、通信システムには様々なタイプの接続様式が必要となる。例えば、１つのＬＡＮ（ｌｏｃａｌ  ａｒｅａ  ｎｅｔｗｏｒｋ）のノードを他のＬＡＮのノードに、インターネット、または有線および無線の電話網などのＷＡＮ（ｗｉｄｅ  ａｒｅａ  ｎｅｔｗｏｒｋ）を経由して接続する必要がある。この構成において、ノードは、サーバコンピュータ、ワークステーション、ＰＣ、ポータブルコンピュータ、ウェアラブルコンピュータ、携帯情報端末（ＰＤＡ）、特殊デバイス（例えばセンサおよび産業機器のコントローラ）、および周辺機器（例えばプリンタ、ファイルシステムなど）である可能性がある。
【０００３】
通信ネットワークが進化を続けるに従い、様々なノードおよびネットワークコンポーネント（例えばブリッジ、ルータ、およびゲートウェイ）が用いるプロトコル、ならびにノードも進化を続ける。
【０００４】
ブリッジは通常、様々なネットワーク間の物理リンクを提供する。ルータは、プロトコルモデルのネットワーク層までを処理してネットワーク内でどのタイプの通信デバイスが接続されているのかを認識し、かつ宛先ノードに必要な情報を送信することによって、ネットワーク間の接続を提供する。プロトコルモデルの全ての層、すなわちアプリケーション層までを処理可能なゲートウェイは、ＬＡＮの外部プロトコルと内部プロトコルを変換する。ゲートウェイは、アプリケーション層までの層を処理するプロトコル変換システムであるため、これを設計するのには手間がかかり長い時間を要する可能性がある。
【０００５】
様々なプロトコルモデル、例えば開放型システム間相互接続（ＩＳＯ）モデル、および図４に示すＴＣＰ／ＩＰモデル４００が既知である。一般に、モデルは、アプリケーション層４０１と、ネットワーク層４０２とを含む。ネットワーク層４０２は、トランスポート層（ＴＣＰ、ＵＤＰ）、インターネット層（ＩＰ、ＩＣＭＰ）、ネットワークインタフェース層（ＡＲＰ、ＲＡＲＰ）、およびハードウェア層（Ｅｔｈｅｒｎｅｔ、ＮＩＣ）を含み得る。アプリケーション層４０１は、ＦＴＰ、ＴＥＬＮＥＴ、Ｅ−ｍａｉｌ、ＳＮＭＰ、ＳＯＡＰ、ｕＰｎＰ、ｈｔｔｐ、およびデバイス固有の各層を含み得る。
【０００６】
図１は、典型的な従来技術のネットワーク構成１００を示す。この構成は、外部ノード１０１と、ＷＡＮ１１０（例えばインターネット）と、ゲートウェイ１２０と、ＬＡＮ１３０と、内部ノード１０２とを含む。第１のプロトコル１１１はゲートウェイ１２０の「外側」で用いられ、第２のプロトコル１３１はゲートウェイの「内側」で用いられる。したがって、ゲートウェイ１２０はプロトコル変換器１２１を備える。
【０００７】
通常、ゲートウェイ１２０は内部ノード１０２を外部ノード１０１から「隠す」。これは安全上の理由による意図的なものである。したがって、外部ノードは、内部ノードのアドレスを見つけることができない。その代わりに、外部ノードは、ゲートウェイによって提供されるプロキシアドレスを持っており、このプロキシアドレスを介して内部ノードと間接的にのみ通信することができる。当然、ゲートウェイが万一機能しなくなると、外部ノードとの通信も同様に機能しなくなる。さらに、この構成は、ゲートウェイ１２０において複数のプロトコルのための多くの異なる変換器を統合することを難しくする。（特開平１１−３２８０８０号公報）
【０００８】
【発明が解決しようとする課題】
ユビキタスネットワーク環境では、いずれのノードもネットワーク中の任意の他のノードと、ゲートウェイを経て、またはゲートウェイを経ずに通信可能であることが望まれる。また、多くの標準的なアプリケーションプロトコル層４０１、例えばＳＯＡＰ、ｕＰｎＰ、およびｈｔｔｐが用いられる。これらはすべて、ネットワーク層４０２よりも上位層での処理を必要とする。しかしながら、小規模な特殊ノード、例えばリモートセンサや産業用コントローラでは、記憶能力および処理能力が限られている。これにより、ノードにおける必要なプロトコルスタックをすべて「小さなメモリフットプリント」で実施することが難しくなる。さらに、これらのデバイスは、ゲートウェイを経ずとも他のノードと通信可能であることが望まれる。したがって、従来技術の問題を軽減することのできるプロトコル変換方法が必要とされている。
【０００９】
【課題を解決するための手段】
本方法は、通信ネットワークにおいて、第１のアプリケーション層プロトコルを第２のアプリケーション層プロトコルに変換する。アプリケーションノードにおいて上記第１のアプリケーション層プロトコルの要求が要求ノードから受信される。当該要求は変換ノードへ送信され、そのメッセージを上記第２のアプリケーション層プロトコルに変換する。変換された要求は次に、当該変換ノードから上記アプリケーションノードに返送される。
【００１０】
すると、上記アプリケーションノードは上記要求に対する応答を構成することができ、この応答もまた、当該アプリケーションノードが上記要求ノードに応答する前に上記変換ノードによって変換される。
【００１１】
【発明の実施の形態】
システム構造
図２は、本発明による、アプリケーションプロトコル層の分散型変換を用いるネットワーク構成２００を示す。ネットワーク２００は、要求ノード２０１と、変換ノード２０２と、アプリケーションノード２０３とを接続する。各ノードは、一意の関連ネットワーク（ＩＰ）アドレスを有する。アプリケーションノード２０３はメモリを備えて、以下で詳述する変換テーブルを格納する。テーブル３００は、要求ノードのアドレス２３１および変換ノードのアドレス２３２を含む。
【００１２】
アプリケーションノード２０３はまた、プロトコルディスパッチャ２２５およびプロトコルマネージャ２３０と、デバイス固有のプロセスすなわちアプリケーション２２０とを備える。この例において、アプリケーションノードは例えば、要求ノード２０１による要求に応答して温度測定値を提供する温度センサである。
【００１３】
システム動作
要求および応答は、以下で詳述するアプリケーション層プロトコル２１１および２１２を用いて通信される。例えば、要求ノードはプロトコル２１１しか処理できず、アプリケーションノードはプロトコル２１２しか処理できない可能性がある。全てのノードは、共通のネットワークプロトコル層を用いる。したがって、変換ノードが２つのプロトコル間の変換を行う。
【００１４】
したがって、プロトコルディスパッチャが、テーブル３００を用いて要求ノード２０１からアプリケーションノード２０３への要求メッセージを変換ノード２０２へ転送する。変換ノード２０２は、メッセージをプロトコル２１１からプロトコル２１２に変換し、変換したメッセージをアプリケーションノードへ返送する。アプリケーションノードは応答メッセージを変換ノードへ送信し、このメッセージを、変換ノードにおいて変換し、アプリケーションノードに返送し、アプリケーションノードにおいて要求ノード２０１へ転送することができる。変換ノードは要求ノード２０１のアドレスを知る必要がないことに留意されたい。変換ノードは常に、メッセージを受信したのと全く同じノードに、変換したメッセージを送信する。
【００１５】
変換テーブル
図３は、表構造３００を詳細に示す。このテーブルは、プロトコルマネージャ２３０によって構成および維持される。各プロトコル名３０１について、変換ノードのアドレス３０２と、要求ノードのアドレス３０３とが格納される。要求ノードのアドレスは要求に対する応答が提供されるまで一時的にのみ格納されることに留意されたい。要求に対する応答が提供された時点で、異なるノードからの要求を処理することができる。
【００１６】
プロトコルディスパッチャ２２５は、受信メッセージのプロトコルを調べ、プロトコルテーブル３００中で同一プロトコルを検索する。ディスパッチャは、このプロトコルを見つけたものの、要求元（ｒｅｑｕｅｓｔｅｒ：リクエスタ）がテーブルにない場合、受信メッセージをプロトコル変換器へ、当該変換器のアドレスを用いて転送し、要求ノードのアドレスを将来の応答のためにテーブル３００に記録する。
【００１７】
受信メッセージのプロトコルがアプリケーションノードによって用いられるプロトコルと同じである場合、アプリケーションノード自体がメッセージを処理することができる。受信メッセージが変換器からのものである場合、ディスパッチャは受信メッセージを、対応する要求ノードアドレスを有するノードへ転送する。
【００１８】
代替的な実施形態では、どの１つのプロトコルにも複数の変換ノードを用いることができる。複数のアドレスがあるプロトコルＣを参照されたい。この場合、タイムアウトエラーの場合に備えて、タイマを用いて別の変換器に切り換えることができる。変換器が利用可能でない場合、ビット３１０を設定することができる。このビットは、所定時間後に、または変換器が再び利用可能となったことを知らせてくるとリセットされ得る。
【００１９】
テーブル３００は、アプリケーションノード２０３のＩ／Ｏポート２４０を経て送られる情報によりプロトコルマネージャ２３０がローカルで構成することができる。テーブル３００はまた、メモリカードからロードするか、あるいは有線または無線リンクを用いてネットワーク２１０を経由してロードすることもできる。この場合、プロトコルサーバ２５０がプロトコルまたは変換器のアドレスを格納することができる。その場合、変換器を設計する際に、変換器をプロトコルサーバ２５０に登録して、アプリケーション層プロトコル変換の完全な分散型ソリューションを提供することができる。
【００２０】
【発明の効果】
本発明を用いれば、アプリケーションノードは、ネットワーク中の考え得る各プロトコルについて処理モジュールを有する必要がない。その代わりに、アプリケーションノードは、異なるプロトコル同士を変換する変換ノードのアドレスを格納する。したがって、適切な変換ノードのアドレスをアプリケーションノードに提供することによって、アプリケーションノードは新規のプロトコル変換を行うことができる。アプリケーションノード自体をアップグレードする必要はない。さらに本発明は、ノード同士が、従来技術の場合のようにゲートウェイを経ることなく互いに通信することを可能にする。上述のように、分散型プロトコル変換器は、ネットワーク２１０中の任意の好都合な場所に配置することができる。
【００２１】
本発明を好ましい実施形態の例示により記載してきたが、本発明の精神および範囲内で様々な他の適応形態および変更形態を行うことができることが理解される。したがって、併記の特許請求項の目的は、本発明の真の精神および範囲に含まれるかかる変形および変更形態をすべて網羅することである。
【図面の簡単な説明】
【図１】従来技術によるアプリケーション層プロトコル変換のブロック図である。
【図２】本発明に係る分散型アプリケーション層プロトコル変換のブロック図である。
【図３】アプリケーション層プロトコル変換テーブルのブロック図である。
【図４】本発明が用いるプロトコルスタックのブロック図である。
【図１】
2004164569.tif 000003
【図２】
2004164569.tif 000004
【図３】
2004164569.tif 000005
【図４】
2004164569.tif 000006
【外国語明細書】
2004164569.tif 000007
2004164569.tif 000008
2004164569.tif 000009
2004164569.tif 000010
2004164569.tif 000011
2004164569.tif 000012
2004164569.tif 000013
2004164569.tif 000014
2004164569.tif 000015
2004164569.tif 000016
2004164569.tif 000017
2004164569.tif 000018
2004164569.tif 000019
2004164569.tif 000020