アプリケーションプログラムのプロトコルを再構成する方法及びその装置
【課題】複数の（プロトコル）コンポーネントモジュールのうち、少なくとも１つのコンポーネントモジュールを結合して再構成されたプロトコルを実施する。
【解決手段】複数のコンポーネントモジュールのスタックが格納されたメモリを保持するステップと、アプリケーションプログラムの要求情報及びプロトコルレイヤから取得したシステム情報を分析するステップと、分析結果に基づいて、アプリケーションプログラムのための再構成されたプロトコルと再構成されたプロトコルのための運用パラメータとを含むプロトコル構成情報を決定するステップと、プロトコル構成情報に基づいて、再構成されたプロトコルを実施するのに必要である複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールとの接続関係を決定するステップとを有する。
【解決手段】複数のコンポーネントモジュールのスタックが格納されたメモリを保持するステップと、アプリケーションプログラムの要求情報及びプロトコルレイヤから取得したシステム情報を分析するステップと、分析結果に基づいて、アプリケーションプログラムのための再構成されたプロトコルと再構成されたプロトコルのための運用パラメータとを含むプロトコル構成情報を決定するステップと、プロトコル構成情報に基づいて、再構成されたプロトコルを実施するのに必要である複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールとの接続関係を決定するステップとを有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーションプログラムのプロトコルを再構成する方法及びその装置に関し、特に、複数のプロトコルコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールを結合して再構成されたプロトコルを実施するアプリケーションプログラムのプロトコルを再構成する方法及びその装置に関する。
【背景技術】
【０００２】
近年、スマートフォンなど携帯可能な個人用デジタル機器とセンサの普及により無線通信を用いる様々なアプリケーションプログラム（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ）が引き続いて増加している。
このように様々なアプリケーションプログラムは、サービス分野に応じて互いに異なるサービス品質（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ；以下、ＱｏＳ）が要求される。
【０００３】
アプリケーションプログラムの一例として、ｌａｔｅｎｃｙ、ｒｅｌｉａｂｉｌｉｔｙ（ＰＥＲ）、バッテリーなどの要求事項を有するｗｅａｒａｂｌｅ ＢＡＮ（Ｂｏｄｙ Ａｒｅａ Ｎｅｔｗｏｒｋ）分野のＥＣＧ（ＥｌｅｃｔｒｏＣａｒｄｉｏＧｒａｐｈ）、ＥＥＧ（ＥｌｅｃｔｒｏＥｎｃｅｐｈａｌｏＧｒａｐｈｙ）、ＥＭＧ（ＥｌｅｃｔｒｏＭｙｏＧｒａｐｈｙ）などのヘルスケア用のプログラムが挙げられる。
【０００４】
また、個人用デジタル機器と接続されたセンサなどは、個人用デジタル機器で駆動されるアプリケーションプログラムによってその数がリアルタイムに変わり得る。
従って、個人用デジタル機器が自身と接続されたセンサ、その他のデジタル機器及びアプリケーションプログラムが要求するサービス品質を提供することができるようリアルタイムで最適のプロトコルを支援する方法が求められているという問題がある。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
そこで、本発明は上記従来のアプリケーションプログラムにおける問題点に鑑みてなされたものであって、本発明の目的は、複数の（プロトコル）コンポーネントモジュールのうち、少なくとも１つのコンポーネントモジュールを結合して再構成されたプロトコルを実施することにある。
また、本発明の他の目的は、少なくとも１つのコンポーネントモジュールを再使用してセンサプラットフォームのメモリ使用を減少させることにある。
また、本発明の他の目的は、コンポーネントモジュールを結合して再構成されたプロトコルを実施することによって、複数のアプリケーションプログラムそれぞれのためのプロトコル開発時間を短縮させることにある。
【課題を解決するための手段】
【０００６】
上記目的を達成するためになされた本発明によるアプリケーションプログラムのためのプロトコルを再構成する方法は、アプリケーションプログラムのためのプロトコルを再構成する方法において、複数のコンポーネントモジュールのスタックが格納されたメモリを保持するステップと、前記アプリケーションプログラムの要求情報及びプロトコルレイヤから取得したシステム情報を分析するステップと、前記分析結果に基づいて、前記アプリケーションプログラムのための再構成されたプロトコルと前記再構成されたプロトコルのための運用パラメータとを含むプロトコル構成情報を決定するステップと、前記プロトコル構成情報に基づいて、前記再構成されたプロトコルを実施するのに必要である前記複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールとの接続関係を決定するステップとを有することを特徴とする。
【０００７】
前記システム情報を分析するステップは、前記アプリケーションプログラムで、前記アプリケーションプログラムの要求情報に関連するイベントが発生したか否かに基づいて、前記アプリケーションプログラムの要求情報を取得することが好ましい。
前記プロトコル構成情報を決定するステップは、複数のプロトコルそれぞれに対するＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）指標を、前記プロトコルレイヤから取得可能な少なくとも１つのパラメータと前記プロトコルの運用パラメータの関数として定義するステップと、前記関数を前記アプリケーションプログラムの要求情報に適するよう数式化するステップとをさらに含むことが好ましい。
前記プロトコル構成情報を決定するステップは、前記アプリケーションプログラムの要求情報によって表示される前記アプリケーションプログラムの要求事項を満足するために、前記再構成されたプロトコルのＱｏＳ指標を最適化させる運用パラメータを決定するステップを含むことが好ましい。
【０００８】
前記複数のプロトコルそれぞれを分析した結果を含む情報を適用することによって、複数のプロトコルと、要求情報がマッピングされた複数のプロトコルそれぞれの運用パラメータとを格納するプロトコルデータベースを保持するステップをさらに有し、前記プロトコル構成情報を決定するステップは、前記プロトコルデータベースを参照して、前記アプリケーションプログラムの要求情報に対応してマッピングされている複数のプロトコルのいずれか１つのプロトコルと、該いずれか１つのプロトコルの運用パラメータとを前記再構成されたプロトコル及び前記再構成されたプロトコルの運用パラメータとして決定するステップを含むことが好ましい。
前記少なくとも１つのコンポーネントモジュールとの接続関係を決定するステップは、前記プロトコル構成情報に基づいて前記接続関係に関連する情報を生成するステップと、前記接続関係に関連する情報を用いて前記再構成されたプロトコルを実施するステップとをさらに含むことが好ましい。
前記複数のコンポーネントモジュールに関連する情報を格納するコンポーネントライブラリーを保持するステップをさらに有することが好ましい。
【０００９】
アプリケーションプログラムのためのプロトコルを再構成する装置に接続され前記再構成されたプロトコルを実施する対象装置が前記再構成されたプロトコルを実施するために必要なコンポーネントモジュールが失われているか（ｍｉｓｓｉｎｇ）否かを判断するステップと、前記判断結果に応じて、前記対象装置から失われていると判断されるコンポーネントモジュールに関する情報を前記コンポーネントライブラリーから取得するステップとをさらに有することが好ましい。
対象装置によって使用されるプロトコルとプロトコルの運用パラメータに関する情報を格納するノードステートデータベースを保持するステップをさらに有することが好ましい。
前記ノードステートデータベース及び前記接続関係を参照して、前記プロトコル構成情報に基づき前記対象装置で前記再構成されたプロトコルを実施するために必要な情報を生成するステップと、前記対象装置で前記再構成されたプロトコルを実施するために必要な情報を前記対象装置に送信するステップとをさらに有することが好ましい。
前記対象装置で前記再構成されたプロトコルを実施するために必要な情報を符号化するステップをさらに有することが好ましい。
【００１０】
前記少なくとも１つのコンポーネントモジュールとの接続関係を決定するステップは、前記プロトコル構成情報を受信するステップと、前記プロトコル構成情報を解釈するステップとを含むことが好ましい。
前記少なくとも１つのコンポーネントモジュールとの接続関係を決定するステップは、前記少なくとも１つのコンポーネントモジュールそれぞれのアドレスを含むテーブルを用いて前記少なくとも１つのコンポーネントモジュールを接続するステップをさらに有することが好ましい。
前記少なくとも１つのコンポーネントモジュールとの接続関係を決定するステップは、前記アプリケーションプログラムのための前記再構成されたプロトコルによりアプリケーションプログラムレイヤの下位レイヤを通過するメッセージをフックする（ｈｏｏｋｉｎｇ）ステップと、前記フックしたメッセージから取得したプロトコルのＩＤに基づいて、前記少なくとも１つのコンポーネントモジュールをスイッチングするステップとを含むことが好ましい。
【００１１】
また、上記目的を達成するためになされた本発明によるアプリケーションプログラムのためのプロトコルを再構成する方法は、アプリケーションプログラムのためのプロトコルを再構成する方法において、複数のコンポーネントモジュールのスタックが格納されたメモリを保持するステップと、アプリケーションプログラムのためのプロトコルを再構成する装置に接続された対象装置から前記アプリケーションプログラムのための再構成されたプロトコルを実施するために必要な情報を受信するステップと、前記アプリケーションプログラムの再構成されたプロトコルを実施するために必要な情報に基づいて、前記アプリケーションプログラムの再構成プロトコルを構成するために必要な前記複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールとの接続関係を決定するステップとを有することを特徴とする。
【００１２】
前記アプリケーションプログラムのための再構成されたプロトコルを実施するために必要な情報は、前記アプリケーションプログラムのための再構成されたプロトコルと前記再構成されたプロトコルのための運用パラメータとを含むプロトコル構成情報、前記少なくとも１つのコンポーネントモジュールとの接続関係に関連する情報又は前記プロトコル構成情報及び前記接続関係に関連する情報の内の少なくとも１つを含むことが好ましい。
前記少なくとも１つのコンポーネントモジュールとの接続関係を決定するステップは、前記再構成されたプロトコルを実施するために必要な情報を解読するステップをさらに含むことが好ましい。
【００１３】
上記目的を達成するためになされた本発明によるコンピュータで読み出し可能な記録媒体は、上記アプリケーションプログラムのためのプロトコルを再構成する方法を実行させるためのプログラムが記録されたことを特徴とする。
【００１４】
上記目的を達成するためになされた本発明によるアプリケーションプログラムのためのプロトコルを再構成する装置は、アプリケーションプログラムのためのプロトコルを再構成する装置において、前記アプリケーションプログラムの要求情報及びプロトコルレイヤから取得されたシステム情報を分析する分析部と、前記分析結果に基づいて、前記アプリケーションプログラムのための再構成されたプロトコル及び前記再構成されたプロトコルのための運用パラメータを含むプロトコル構成情報を決定するプロトコルエンジンと、前記プロトコル構成情報により、前記再構成されたプロトコルを実施するために複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールとの接続関係を決定するプロトコル実施部と、前記複数のコンポーネントモジュールのスタックが格納されたメモリを含む再構成プロトコルスタックとを有することを特徴とする。
【００１５】
また、上記目的を達成するためになされた本発明によるアプリケーションプログラムのためのプロトコルを再構成する装置は、アプリケーションプログラムのためのプロトコルを再構成する装置において、複数のコンポーネントモジュールのスタックが格納されたメモリを含む再構成プロトコルスタックと、前記アプリケーションプログラムのためのプロトコルを再構成する装置と接続した対象装置から受信した前記アプリケーションプログラムのための再構成されたプロトコルを実施するために必要な情報に基づいて、前記アプリケーションプログラムの再構成されたプロトコルを実施するために必要な前記複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールとの接続関係を決定するプロトコル実施部とを有することを特徴とする。
【００１６】
また、上記目的を達成するためになされた本発明によるアプリケーションプログラムのためのプロトコルを再構成する方法は、プロトコルレイヤから取得されたシステム情報及びアプリケーションプログラムの要求情報に基づいて前記アプリケーションプログラムの最適プロトコルと該最適プロトコルの運用パラメータの最適値とを決定するステップと、前記アプリケーションプログラムの現在のプロトコルが前記最適プロトコルではない場合、前記アプリケーションプログラムの現在のプロトコルから失われた（ｍｉｓｓｉｎｇ）少なくとも１つのコンポーネントモジュールと前記アプリケーションプログラムの現在のプロトコルの少なくとも１つのコンポーネントモジュールとを用いて、前記最適プロトコルの前記運用パラメータの値を前記最適プロトコルの前記運用パラメータの最適値に設定して前記アプリケーションプログラムの現在のプロトコルを前記最適プロトコルに再構成するステップとを有することを特徴とする。
【００１７】
前記アプリケーションプログラムの現在のプロトコルの少なくとも１つのコンポーネントモジュールと前記アプリケーションプログラムの前記現在のプロトコルから失われた（ｍｉｓｓｉｎｇ）少なくとも１つのコンポーネントモジュールは、再構成プロトコルスタックのメモリに格納された複数のコンポーネントモジュールに含まれることが好ましい。
前記アプリケーションプログラムの前記現在のプロトコルが前記最適プロトコルであり、前記最適プロトコルの運用パラメータの現在の値が前記最適プロトコルの運用パラメータの最適値ではない場合、前記最適プロトコルの運用パラメータの値を前記運用パラメータの最適値に設定するステップをさらに有することが好ましい。
前記アプリケーションプログラムは、第１装置に接続された第２装置から前記現在のプロトコルを用いて前記第１装置に送信されたデータを処理するために前記第１装置で駆動され、前記最適プロトコルを決定するステップは、前記アプリケーションプログラムの要求情報が変更された時、又は前記第１装置に第３装置が接続された時に、実行されることが好ましい。
【発明の効果】
【００１８】
本発明に係るアプリケーションプログラムのプロトコルを再構成する方法及びその装置によれば、複数の（プロトコル）コンポーネントモジュールのうち少なくとも１つのコンポーネントモジュールを結合して再構成されたプロトコルを実施することによって、複数のセンサ、その他のデジタル機器及びアプリケーションプログラムそれぞれで要求されるサービス品質を提供することのできるプロトコルをリアルタイムで再構成することができるという効果がある。
また、少なくとも１つのコンポーネントモジュールを再使用することによって、センサプラットフォームのメモリ使用を減少させることができるという効果がある。
また、複数の（プロトコル）コンポーネントモジュールのうち、少なくとも１つのコンポーネントモジュールを結合して再構成されたプロトコルを実施することによって、複数のアプリケーションプログラムそれぞれのためのプロトコル開発時間を短縮させることができるという効果がある。
【図面の簡単な説明】
【００１９】
【図１】本発明の一実施形態に係るアプリケーションプログラムのプロトコルを再構成する装置のブロック図である。
【図２】本発明の他の実施形態に係るアプリケーションプログラムのプロトコルを再構成する装置のブロック図である。
【図３】図１に示すプロトコル再構成装置がアプリケーションプログラムのプロトコルを再構成する方法を説明するためのフローチャートである。
【図４】図２に示すプロトコル再構成装置がアプリケーションプログラムのプロトコルを再構成する方法を説明するためのフローチャートである。
【図５】本発明の一実施形態に係るアプリケーションプログラムのプロトコルを再構成する装置を含むプロトコル再構成システムにおける装置間の動作を説明するための図である。
【図６】本発明の他の実施形態に係るアプリケーションプログラムのプロトコルを再構成する装置を含むプロトコル再構成システムにおける装置間の動作を説明するための図である。
【図７】本発明の一実施形態に係るランタイムソルバーを用いてプロトコルエンジンを実施する方法を説明するための図である。
【図８】本発明の一実施形態に係るプロトコルデータベースを用いてプロトコルエンジンを実施する方法を説明するための図である。
【図９】本発明の一実施形態に係るアプリケーションプログラムのプロトコルを再構成する装置において能動モードで動作するプロトコル実施部の構成を示すブロック図である。
【図１０】図９に示す能動モードでのプロトコル実施部の動作を説明するためのフローチャートである。
【図１１】本発明の一実施形態に係るアプリケーションプログラムのプロトコルを再構成する装置がＲＦＤで動作するときのプロトコル実施部の動作を説明するための図である。
【図１２】本発明の一実施形態に係るプロトコル実施部が構成テーブルを用いて再構成されたプロトコルを実施する方法を説明するための図である。
【図１３】本発明の一実施形態に係るプロトコル実施部がメッセージフッキングを用いて再構成されたプロトコルを実施する方法を説明するための図である。
【発明を実施するための形態】
【００２０】
次に、本発明に係るアプリケーションプログラムのプロトコルを再構成する方法及びその装置を実施するための形態の具体例を図面を参照しながら説明する。
【００２１】
しかし、本発明が一実施形態によって制限されたり限定されることはない。また、各図面に提示した同一の参照符号は同一の部材を示す。
【００２２】
一般的にプロトコルは、大きくアプリケーションプログラムに特化されたプロトコルと多重−目的（ｍｕｌｔｉ−ｐｕｒｐｏｓｅ）のためのプロトコルに分類される。
アプリケーションプログラムに特化されたプロトコルでは、Ｂ−ＭＡＣ、Ｘ−ＭＡＣなどのようにセンサネットワークのために提案されたプロトコルが一例として挙げられる。
【００２３】
アプリケーションプログラムに特化されたプロトコルの特徴は、特定アプリケーションプログラムには最適に設計されるが、異質のサービス品質（ＱｏＳ）を要求するアプリケーションプログラムに対しては、その性能が急激に低下することがある。このような適応性の問題を克服するために必要な全てのプロトコルをシステムに搭載する場合、メモリの側面において、効率的ではないという問題が発生する。
【００２４】
また、多重目的のためのプロトコルは、プロファイル（ｐｒｏｆｉｌｅ）によって様々なアプリケーションプログラムを支援することができ、ＩＥＥＥ８０２．１５．４などが一例として挙げられる。
多重目的のためのプロトコルは、プロトコル自体のオーバーヘッドによって性能面において最適のプロトコルではない場合もある。
【００２５】
したがって、本発明の実施形態では、アプリケーションプログラムのリアルタイム「ｉｎ ａｎｄ ｏｕｔ」の変化に対して最適のプロトコルを決定することのできるラン−タイム構造（ｒｕｎ−ｔｉｍｅ ａｒｃｈｉｔｅｃｔｕｒｅ）を提供すると同時に、ユーザの携帯用デジタル機器に提供するアプリケーションプログラムが動的に用いられる環境でサービスの品質を満足させ得る最適のプロトコルと運用条件をリアルタイムに提供することが可能である。
【００２６】
図１は、本発明の一実施形態に係るアプリケーションプログラムのプロトコルを再構成する装置のブロック図である。
図１に示すアプリケーションプログラムのプロトコルを再構成する装置（以下、「プロトコル再構成装置」）１００は、能動的にアプリケーションプログラムのプロトコルを再構成する装置である。
【００２７】
プロトコル再構成装置１００は、
（１）アプリケーションプログラム又は周辺センサノードのための最適のプロトコルを決定し、アプリケーションプログラムのプロトコルを再構成する機能と、
（２）他のプロトコル再構成装置からの要求を受け入れて自身のプロトコルを変形させる機能の全てを行う。
プロトコル再構成装置１００で、（１）の機能はプロトコル再構成装置１００が能動モードで動作するときに行われ、（２）の機能はプロトコル再構成装置１００が受動モードで動作するときに行われる。
上述したような２種類の機能を全て含むプロトコル再構成装置１００を「Ｆｕｌｌ Ｆｕｎｃｔｉｏｎａｌ Ｐｒｏｔｏｃｏｌ Ｓｙｓｔｅｍ Ｄｅｖｉｃｅ」（以下、「ＦＦＤ」）と称する。
【００２８】
プロトコル再構成装置１００は、分析部１１０、プロトコルエンジン１３０、プロトコル実施部１５０、及び再構成プロトコルスタック１７０を含む。
分析部１１０は、アプリケーションプログラムの要求情報及びプロトコルレイヤから取得されたシステム情報を分析する。ここで、アプリケーションプログラムの要求情報は、アプリケーションプログラムのＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）リクエスト情報だけではなく、周辺センサノードの要求情報も含んでもよく、各アプリケーションプログラムが要求するＬａｔｅｎｃｙ、ＰＥＲ（Ｐａｃｋｅｔ Ｅｒｒｏｒ Ｒａｔｅ）、ｌｉｆｅｔｉｍｅなどが一例として含みうる。
【００２９】
システム情報は、チャネル状態情報、プロトコル再構成装置１００に接続したデバイス（センサノード及びその他のデジタル機器）の数字など、プロトコル再構成装置１００がＰＨＹレイヤ又はＭＡＣレイヤなどに対してプロトコルレイヤから取得する情報である。
また、分析部１１０は、取得した情報（アプリケーションプログラムの要求情報及びシステム情報）を予め設定されたフォーマットのメッセージ形式でプロトコルエンジン１３０に周期的に供給する。
【００３０】
プロトコルエンジン１３０は、分析部１１０の分析結果に基づいてアプリケーションプログラムのための再構成されたプロトコル、及び再構成されたプロトコルのための運用パラメータを含むプロトコル構成情報を決定する。
すなわち、プロトコルエンジン１３０は、アプリケーションプログラムのための最適のプロトコル（ここでは、再構成されたプロトコル）及び該当プロトコルのための運用パラメータを決定する。
運用パラメータは、プロトコル再構成装置１００が調節権限を有するパラメータである。
プロトコルエンジン１３０は、エージェント（Ａｇｅｎｔ）とソルバー（ｓｏｌｖｅｒ）から構成され、具体的な構成及び動作については、図７及び図８を参照して詳細に後述する。
【００３１】
プロトコル実施部１５０は、プロトコルエンジン１３０から受信したプロトコル構成情報により、再構成されたプロトコルを実施するために複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールの接続関係を決定する。
プロトコル実施部１５０の具体的な動作及び構成については、図９及び図１０を参照して詳細に後述する。
【００３２】
再構成プロトコルスタック（Ｒｅｃｏｎｆｉｇｕｒａｂｌｅ Ｐｒｏｔｏｃｏｌ Ｓｔａｃｋ）１７０は、複数の（プロトコル）コンポーネントモジュールのスタックが格納されたメモリを保持する。
再構成プロトコルスタック１７０は、プロトコル実施部１５０で決定された少なくとも１つの接続関係に関する情報を受信して少なくとも１つのコンポーネントモジュールの接続を行う。
（プロトコル）コンポーネントモジュールのスタックは、プロトコルのための機能はコンポーネント化させて、これを接続して必要な機能を実行できるようにする。ここで、コンポーネントモジュールは、粒度（ｇｒａｎｕｌａｒｉｔｙ）に応じて伴うオーバーヘッド（ｏｖｅｒｈｅａｄ）によるトレード−オフ（ｔｒａｄｅ−ｏｆｆ）があるため、設計者の意図により様々な形態で構成され得る。
【００３３】
センサネットワークのプロトコルは、様々なアプリケーションプログラムの特性に応じてその種類が極めて多様である。
したがって、アプリケーションプログラムごとの最適のプロトコルを構成するために全ての作業を初めから再び始めることは時間と費用面において浪費になりかねない。
したがって、本実施形態ではプロトコルの基本機能をコンポーネント化して複数のコンポーネントモジュールのうち、プロトコルを再構成するために必要なコンポーネントモジュールを最大に再使用できるようにする。
【００３４】
ＦＦＤのプロトコル再構成装置１００が、能動モードで動作するときには、分析部１１０、プロトコルエンジン１３０、プロトコル実施部１５０及び再構成プロトコルスタック１７０の全てが活性化される。
一方、ＦＦＤのプロトコル再構成装置１００が、受動モードで動作するときには、図２に示すように、プロトコル実施部１５０及び再構成プロトコルスタック１７０だけが活性化され、このときには後述するＲＦＤと同一の動作を行う。
【００３５】
図２は、本発明の他の実施形態に係るアプリケーションプログラムのプロトコルを再構成する装置のブロック図である。
図２に示すアプリケーションプログラムのプロトコルを再構成する装置（以下、「プロトコル再構成装置」）２００は、受動的にアプリケーションプログラムのプロトコルを再構成する装置である。
【００３６】
プロトコル再構成装置２００は、自身と接続した対象装置から受信した、アプリケーションプログラムのための再構成されたプロトコルを実施するために必要な情報を用いて、プロトコル再構成装置２００で再構成されたプロトコルを実施するために必要な機能のみを含んでもよい。
すなわち、プロトコル再構成装置２００は、他のプロトコル再構成装置からの要求を受け入れて、自身のプロトコルを変形させる機能のみを行い、このような機能を行うプロトコル再構成装置２００を「Ｒｅｄｕｃｅｄ Ｆｕｎｃｔｉｏｎａｌ Ｐｒｏｔｏｃｏｌ Ｓｙｓｔｅｍ Ｄｅｖｉｃｅ」（以下、「ＲＦＤ」）と称する。
【００３７】
プロトコル再構成装置２００は、プロトコル実施部２１０及び再構成プロトコルスタック２３０を含む。
プロトコル実施部２１０は、自身と接続した対象装置から受信した、アプリケーションプログラムのための再構成されたプロトコルを実施するために必要な情報に基づいて、複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールの接続関係を決定する。ここで、アプリケーションプログラムのための再構成されたプロトコルを実施するために必要な情報は、再構成プロトコルスタック２３０に格納された複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールの接続関係に関連する情報を含んでもよい。
【００３８】
対象装置は、図１に基づいて説明したように、能動的にアプリケーションプログラムのプロトコルを再構成できるプロトコル再構成装置１００、又はこれに類似する機能を有する装置であってもよい。
アプリケーションプログラムのための再構成されたプロトコルを実施するために必要な情報は、アプリケーションプログラムのための再構成されたプロトコル、再構成されたプロトコルのための運用パラメータを含むプロトコル構成情報、及び少なくとも１つのコンポーネントモジュールの接続関係に関連する情報の内の少なくとも１つを含んでもよい。
【００３９】
再構成プロトコルスタック２３０は、複数のコンポーネントモジュールのスタックが格納されたメモリを含む。
再構成プロトコルスタック２３０の動作は、図１に示す再構成プロトコルスタック１７０と同一であるため、該当部分に対する説明を参照する。
【００４０】
図３は、図１に示すプロトコル再構成装置がアプリケーションプログラムのプロトコルを再構成する方法をを説明するためのフローチャートである。
プロトコル再構成装置１００は、複数のコンポーネントモジュールのスタックが格納されたメモリを保持する（ステップＳ３０１）。
プロトコル再構成装置１００は、アプリケーションプログラムの要求情報及びプロトコルレイヤから取得したシステム情報を分析する（ステップＳ３０３）。
【００４１】
ステップＳ３０３において、プロトコル再構成装置１００は、アプリケーションプログラムで、アプリケーションプログラムの要求情報に関連するイベント（例えば、Ａｓｓｏｃｉａｔｉｏｎなど）が発生するか否かに基づいてアプリケーションプログラムの要求情報を取得してもよい。
【００４２】
プロトコル再構成装置１００は、ステップＳ３０３における分析結果に基づいてプロトコル構成情報を決定する（ステップＳ３０５）。
プロトコル構成情報は、アプリケーションプログラムのための再構成されたプロトコル及び再構成されたプロトコルのための運用パラメータを含む。
プロトコル再構成装置１００は、例えば、ランタイムソルバー（Ｒｕｎ−ｔｉｍｅ ｓｏｌｖｅｒ）又はプロトコルデータベース（Ｐｒｏｔｏｃｏｌ Ｄａｔａｂａｓｅ）を用いてプロトコル構成情報を決定してもよい。
【００４３】
プロトコル再構成装置１００がランタイムソルバーを用いてプロトコル構成情報を決定する方法は次の通りである。
プロトコル再構成装置１００は、複数のプロトコルそれぞれに対するＱｏＳ指標をプロトコルレイヤから取得可能なパラメータと運用パラメータの関数で定義する。
その後、プロトコル再構成装置は、定義された関数をアプリケーションプログラムの要求情報に対応するように数式化する。
プロトコル再構成装置１００は、アプリケーションプログラムの要求情報を満足するために再構成されたプロトコルのＱｏＳ指標を最適化させる運用パラメータを決定する。
【００４４】
また、プロトコル再構成装置１００がプロトコルデータベースをソルバーとして用いてプロトコル構成情報を決定する方法は次の通りである。
まず、プロトコル再構成装置１００は、プロトコルデータベースを保持する。
プロトコルデータベースは、ステップＳ３０３における分析結果を含む情報を複数のプロトコルそれぞれに適用して決定した再構成されたプロトコル及び再構成されたプロトコルのための運用パラメータを格納する。
【００４５】
その後、プロトコル再構成装置１００は、プロトコルデータベースを参照してアプリケーションプログラムの要求情報に対応してマッピングされているプロトコルと該当運用パラメータを再構成されたプロトコル及び運用パラメータとして決定する。
上述したランタイムソルバー又はプロトコルデータベースを用いてプロトコル構成情報を決定する方法については、図７〜図８を参照して詳細に後述する。
【００４６】
プロトコル再構成装置１００は、プロトコル構成情報により、再構成されたプロトコルを実施するために複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールの接続関係を決定する（ステップＳ３０７）。
プロトコル再構成装置１００は、自身のプロトコルを再構成するか、そうでなければ、自身と接続した対象装置のプロトコルを再構成するかに応じて動作が変わり得る。
プロトコル再構成装置１００がいずれかのプロトコルを再構成するかによって変化する動作については図９〜図１１を参照して詳細に後述する。
【００４７】
図４は、図２に示すプロトコル再構成装置がアプリケーションプログラムのプロトコルを再構成する方法をを説明するためのフローチャートである。
プロトコル再構成装置２００は、複数のコンポーネントモジュールのスタックが格納されたメモリを保持する（ステップＳ４０１）。
プロトコル再構成装置２００は、自身と接続した対象装置からアプリケーションプログラムのための再構成されたプロトコルを実施するために必要な情報を受信する（Ｓ４０３）。
【００４８】
アプリケーションプログラムのための再構成されたプロトコルを実施するために必要な情報は、アプリケーションプログラムのための再構成されたプロトコル、再構成されたプロトコルのための運用パラメータを含むプロトコル構成情報、及び少なくとも１つのコンポーネントモジュールの接続関係に関連する情報のうち少なくとも１つを含んでもよい。
ここで、アプリケーションプログラムのための再構成されたプロトコルを実施するために必要な情報が符号化された形態で受信されれば、プロトコル再構成装置２００は、該当情報を解釈した後に利用してもよい。
【００４９】
プロトコル再構成装置２００は、再構成されたプロトコルを実施するために必要な情報に基づいて複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールの接続関係を決定する（ステップＳ４０５）。
【００５０】
図５は、本発明の一実施形態に係るアプリケーションプログラムのプロトコルを再構成する装置を含むプロトコル再構成システムにおける装置間の動作を説明するための図である。
プロトコル再構成システムは、能動モードで動作するプロトコル再構成装置（例えば、ＦＦＤ）５３０と対象装置（例えば、ＲＦＤ）５５０を含む。
【００５１】
図５に示す要素間の数字（１）〜（７）は、プロトコル再構成装置の各要素間のメッセージ伝達順序を示す。
装置間の動作は次の通りである。
分析部５３１は、アプリケーションプログラム５２０から、アプリケーションプログラム又は自身と接続したセンサノードの要求情報及びプロトコルレイヤからシステム情報を取得する（１）。また、分析部５３１は、再構成プロトコルスタック５３７からネットワーク情報も取得してもよい（１）。
【００５２】
ここで、アプリケーションプログラム５２０は、プロトコル再構成装置（ＦＦＤ）５３０の内部にインストールされたアプリケーションプログラムであるか、又は、対象装置（ＲＦＤ）５５０で駆動されるアプリケーションプログラムであってもよい。
【００５３】
分析部５３１は、取得した情報を分析してその結果及び取得した情報をプロトコルエンジン５３３に提供する（２）。
プロトコルエンジン５３３は、分析部５３１における分析結果に基づいてプロトコル構成情報を決定する。
プロトコル構成情報は、アプリケーションプログラム５２０のための再構成されたプロトコル及び再構成されたプロトコルのための運用パラメータを含む。
【００５４】
プロトコルエンジン５３３は、プロトコル構成情報をプロトコル実施部５３５に提供する（３）。
プロトコル実施部５３５は、プロトコル構成情報により再構成されたプロトコルを実施するために再構成プロトコルスタック５３７に格納された複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールの接続関係を決定する。
ここで、再構成プロトコルスタック５３７は、複数のコンポーネントモジュールのスタックが格納されたメモリを保持する。
【００５５】
プロトコル実施部５３５は、少なくとも１つのコンポーネントモジュールの接続関係に関連する情報を再構成プロトコルスタック５３７に送信する（４）。
それにより、再構成プロトコルスタック５３７は、該当情報を用いて少なくとも１つのコンポーネントモジュールを接続し、これによって再構成されたプロトコルが実施される。
【００５６】
この後、再構成プロトコルスタック５３７は、自身に接続した対象装置（ＲＦＤ）５５０にアプリケーションプログラムのための再構成されたプロトコルを実施するために必要な情報を送信する（５）。
【００５７】
対象装置のプロトコル再構成装置（ＲＦＤ）５５０の再構成プロトコルスタック５５７は、プロトコル再構成装置（ＦＦＤ）５３０の再構成プロトコルスタック５３７が送信した情報（アプリケーションプログラムのための再構成されたプロトコルを実施するために必要な情報）を受信してプロトコル実施部５５５に伝達する（６）。
【００５８】
プロトコル実施部５５５は、アプリケーションプログラムのための再構成されたプロトコルを実施するために必要な情報に基づいて、複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールの接続関係を決定する。
プロトコル実施部５５５は、接続関係に関連する情報を再構成プロトコルスタック５５７に通知する（７）。
【００５９】
再構成プロトコルスタック５５７は、接続関係に関連する情報により複数のコンポーネントモジュールのうち、再構成プロトコルを実施するために必要な少なくとも１つのコンポーネントモジュールを接続して対象装置５５０で再構成プロトコルが実施されるようにする。
【００６０】
図６は、本発明の他の実施形態に係るアプリケーションプログラムのプロトコルを再構成する装置を含むプロトコル再構成システムにおける装置間の動作を説明するための図である。
図６に示すプロトコル再構成システムは、能動モードで動作するプロトコル再構成装置（例えば、ＦＦＤ）６３０と対象装置（ここでは、受動モードで動作するプロトコル再構成装置（例えば、ＦＦＤ））６５０を含む。
【００６１】
図６において、能動モードで動作するプロトコル再構成装置（ＦＦＤ）６３０の動作は、図５に示すプロトコル再構成装置（ＦＦＤ）５３０の動作と同一である。
また、受動モードで動作するプロトコル再構成装置（ＦＦＤ）６５０は、プロトコルを決定するために関与する分析部６５１とプロトコルエンジン６５３の機能が非活性化されるだけであって、残りのプロトコル実施部６５５及び再構成プロトコルエンジン６５７の動作は図５に示すプロトコル再構成装置（ＲＦＤ）５５０と同一である。
すなわち、受動モードで動作するプロトコル再構成装置（ＦＦＤ）６５０は、機能上、図５に示す対象装置５５０のＲＦＤと同一に動作する。
したがって、図６で各構成要素の動作は、図５に示す説明を参照する。
【００６２】
図７は、本発明の一実施形態に係るランタイムソルバー（ｒｕｎ−ｔｉｍｅ ｓｏｌｖｅｒ）を用いてプロトコルエンジンを実現する方法を説明するための図である。
図７においてプロトコルエンジン７３０は、エージェント７３１とランタイムソルバー７３５を含む。
【００６３】
エージェント７３１は、分析部７１０が取得した情報及び分析した情報を受信し、該当情報に基づいて周期的にランタイムソルバー７３５の動作をトリガー（ｔｒｉｇｇｅｒ）する。さらに、エージェント７３１は、ランタイムソルバー７３５の動作による結果をプロトコル実施部７５０に伝達する。
ランタイムソルバー７３５は、アプリケーションプログラムのための最適のプロトコル（ここでは、再構成されたプロトコル）が何であるかをリアルタイムに確認し、該当プロトコルのための運用パラメータを決定する。
【００６４】
ランタイムソルバー７３５は、アプリケーションプログラムのための再構成されたプロトコル、再構成されたプロトコルを実施するために必要な少なくとも１つのコンポーネントモジュール、及び再構成されたプロトコルのための運用パラメータなどを決定する。
ランタイムソルバー７３５を用いて実現したプロトコルエンジン７３０は、モデリング部７３５３とアルゴリズム部７３５６を含む。
【００６５】
モデリング部７３５３では複数のプロトコルそれぞれに対するＱｏＳ指標をプロトコルレイヤから取得可能なパラメータ（より詳しくは、分析部７１０から取得可能なパラメータと運用パラメータ）の関数で定義する。
そして、該当関数をアプリケーションプログラムの要求情報又はアプリケーションプログラムの目的に適するように数式化してモデリングする。
例えば、アプリケーションプログラムの要求情報で「ｒｅｌｉａｂｉｌｉｔｙ」と「ｄｅｌａｙ」に対する要求事項があって、ユーザがアプリケーションプログラムのエネルギーを最小化することを所望すると仮定する。ここで、プロトコルエンジン７３０（より詳しくは、モデリング部７３５３）はアプリケーションプログラムの要求情報に基づいて、数式化されたＱｏＳ指標を用いてエネルギーを最小化するための最適化の問題を数式化する。
【００６６】
図７に示すモデリング部７３５３に示す例では、プロトコル再構成装置を含む装置（又は、角度センサノード及びアプリケーションプログラム）のＱｏＳ指標がシステム情報（ＳＰ１、．．．、ＳＰｉ）、ネットワーク情報（ＮＰ１、．．．、ＮＰｊ）、再構成プロトコルスタック（図示せず）を構成する少なくとも１つのコンポーネントモジュール（ＣＯ１、．．．、ＣＯｋ）及び再構成されたプロトコルを実施するために選択された少なくとも１つのコンポーネントモジュールから得られる再構成されたプロトコルのための運用パラメータ（ＣＶ１、．．．、ＣＶｋ）の関数で数式化されることが分かる。
ここで、ＱｏＳ指標としては、Ｅｎｅｒｇｙ（Ｅｉ）、Ｒｅｌｉａｂｉｌｉｔｙ（Ｒｉ）、Ｄｅｌａｙ（Ｄｉ）などが一例として挙げられる。
【００６７】
プロトコルエンジン７３０は、上述した動作によってアプリケーションプログラムの目的によりＱｏＳ指標を最適化させる。
プロトコルエンジン７３０は、アプリケーションプログラムの要求情報、システム情報、ネットワーク情報に対する値を分析部７１０から取得した後、モデリング部７３５３によって定義された数式に入力する。
プロトコルエンジン７３０は、アプリケーションプログラムの要求情報を満足する範囲内で再構成されたプロトコルのＱｏＳ指標を最適化させる運用パラメータを決定する。
【００６８】
この工程は、アルゴリズム部７３５６によって行われる。
アルゴリズム部７３５６は、モデリング部７３５３によって数式化された最適化の問題により適切なアルゴリズムを選択、又は開発（ｄｅｖｅｌｏｐ）して、アプリケーションプログラムのプロトコル再構成装置にてこのアルゴリズムを実施する。
図７に示すように、アルゴリズム部７３５６では整数プログラミング（ｉｎｔｅｇｅｒ ｐｒｏｇｒａｍｍｉｎｇ）に対する解決方法のうち１つの分枝限定法（ｂｒａｎｃｈ ａｎｄ ｂｏｕｎｄ）アルゴリズムを用いることができる。
【００６９】
図８は、本発明の一実施形態に係るプロトコルデータベースを用いてプロトコルエンジンを実施する方法を説明するための図である。
プロトコルデータベースを用いてプロトコルエンジンを実施するときにもエージェント８３１は、図７と同様に動作してもよい。
すなわち、エージェント８３１は、分析部８１０が取得した情報を受信し、該当情報に基づいて周期的にプロトコルデータベース８３５の動作をトリガー（ｔｒｉｇｇｅｒ）する。さらに、エージェント８３１は、プロトコルデータベース８３５によって決定された結果をプロトコル実施部８５０に伝達する。
【００７０】
プロトコルエンジン８３０を実現するためにプロトコルデータベースを用いるときにも、ランタイムソルバー７３５と同様にモデリング部８３５３によってモデリングを行う。
ただし、プロトコルデータベース８３５を用いるときには、アルゴリズム部７３５６に代って外部パラメータに対する最適のプロトコルと該当プロトコルのための運用パラメータを（アルゴリズムによって）予め算出し、その結果をデータベース８３５６化することが異なる。
ここで、外部パラメータでは、オフライン上で取得可能なアプリケーションプログラムの要求情報、システム情報及びネットワーク情報などが例として挙げられる。
【００７１】
すなわち、分析部８１０が取得した情報（例えば、アプリケーションプログラムの要求情報）を受信したプロトコルエンジン８３０ではプロトコルデータベース８３５を参照して該当情報に対応してマッピングされている最適のプロトコルと該当運用パラメータを確認する。
プロトコルエンジン８３０は、確認した結果を再構成されたプロトコルと該当運用パラメータでプロトコル実施部８５０に送信する。
【００７２】
プロトコルデータベースを用いてプロトコルエンジン８３０を実現する方法は、プロトコル再構成装置の算出能力がランタイムソルバーを運用するに不都合な場合に効果的である。
また、プロトコルデータベースを用いてプロトコルエンジン８３０を実現する方法は、比較的に静的であり単純な環境により運用パラメータや再構成されたプロトコルの運用範囲が広い必要がない場合にも効果的である。
【００７３】
図９は、本発明の一実施形態に係るアプリケーションプログラムのプロトコルを再構成する装置において、能動モードで動作するプロトコル実施部の構成を示すブロック図であり、図１０は、図９の能動モードでのプロトコル実施部の動作を説明するためのフローチャートである。
プロトコル実施部９５０は、プロトコルエンジン９３０から受信したプロトコル構成情報を解釈し、プロトコル構成情報により再構成されたプロトコルをプロトコルレイヤで実施できるようにする。ここで、プロトコル構成情報は、プロトコルエンジン９３０が分析部９１０から受信した情報に基づいて決定したものである。
【００７４】
すなわち、プロトコル実施部９５０は、プロトコル構成情報により再構成されたプロトコルを実施するために、再構成プロトコルスタック９７０に含まれた複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールの接続関係を決定する。
プロトコル実施部９５０は、プロトコル再構成装置の役割により異なる動作を行う。すなわち、プロトコル再構成装置がＦＦＤの役割を行うときと、ＲＦＤの役割を行うときにプロトコル実施部９５０の構成要素及びその動作が異なる。
また、プロトコル実施部９５０は、自分のプロトコルを再構成するために必要な情報を生成するときと、自身と接続した対象装置で再構成されたプロトコルを実施するために必要な情報を生成するときの動作が異なる。
【００７５】
図９では、ＦＦＤで動作するプロトコル再構成装置９００と、ＲＦＤで動作するプロトコル再構成装置９９０の２つのプロトコル再構成装置を示している。
ここで、プロトコル再構成装置９９０は、プロトコル再構成装置９００に接続された対象装置の役割を行う。
【００７６】
ＦＦＤで動作するプロトコル再構成装置９００が自身のプロトコルを再構成する場合、プロトコル実施部９５０は、プロトコル構成情報に基づいて少なくとも１つのコンポーネントモジュールの間の接続関係に関連する情報を生成し、これによって再構成されたプロトコルが実施されるようにする。
少なくとも１つのコンポーネントモジュールの接続関係に関連する情報は、プロトコルＩＤ、コンポーネント情報、及びパラメータ値を含む。もし、プロトコル再構成装置９００が必要なコンポーネントモジュールを含んでいない場合には、少なくとも１つのコンポーネントモジュールの接続関係に関連する情報は「ＥＬＦ ｆｏｒｍａｔ」のコンポーネントモジュールのコードをさらに含んでもよい。
【００７７】
プロトコル再構成装置９００において、プロトコル実施部９５０は、実施部エージェント９５１、プロトコルアップデータ９５２、コンポーネントライブラリー９５３及びノードステートデータベース９５４を含む。また、プロトコル実施部９５０は、プロトコルパーサー９５５及びプロトコルエンコーダ９５６をさらに含んでもよい。
プロトコルパーサー９５５は、プロトコル再構成装置９００がＦＦＤで動作するときには利用されない。
プロトコルエンコーダ９５６は、プロトコル実施部９５０が再構成プロトコルスタック９７０に送信する情報（例えば、少なくとも１つのコンポーネントモジュールの接続関係に関連する情報）を符号化するときのみ用いられる。
【００７８】
実施部エージェント９５１は、プロトコルエンジン９３０から受信したプロトコル構成情報に基づいて、自身と接続した対象装置（ここでは、プロトコル再構成装置（ＲＦＤ）９９０）で再構成されたプロトコルを実施するために必要な情報を生成する。
図１０は、実施部エージェント９５１が行う動作を説明するためのフローチャートを示す。
実施部エージェント９５１が自分のプロトコルを再構成するために必要な情報を生成するときの動作はステップＳ１００１〜Ｓ１００３の工程である。
【００７９】
実施部エージェント９５１は、自身のプロトコルを再構成するか否かを判断する（ステップＳ１００１）。
ステップＳ１００１の判断結果、自身のプロトコルを再構成しなければならない必要があれば、実施部エージェント９５１はプロトコルアップデータ９５２に関連情報（ここでは、少なくとも１つのコンポーネントモジュールの接続関係に関連する情報）を送信する（ステップＳ１００３）。
少なくとも１つのコンポーネントモジュールの接続関係に関連する情報はプロトコルＩＤ（Ｐｒｏｔｏｃｏｌ ＩＤ）、少なくとも１つのコンポーネントモジュールに関する情報（Ｃｏｍｐｏｎｅｎｔｓ Ｉｎｆｏ）及びパラメータ値（Ｐａｒａｍｅｔｅｒ Ｖａｌｕｅ）であってもよい。
【００８０】
もし、再構成プロトコルスタック９７０が再構成されたプロトコルを構成するために必要な少なくとも１つのコンポーネントモジュールを含んでいなければ、実施部エージェント９５１は、プロトコルアップデータ９５２に少なくとも１つのコンポーネントモジュールのコードを送信してもよい。ここで、少なくとも１つのコンポーネントモジュールのコードは、例えば、ＥＬＦフォーマットで構成されてもよい。
プロトコルアップデータ９５２は、少なくとも１つのコンポーネントモジュールの接続関係に関連する情報を用いて再構成されたプロトコルを実施することができる。
図９に示す実線は、プロトコル実施部９５０が自身のプロトコルを再構成するときのメッセージの流れを示す。
【００８１】
ステップＳ１００１の判断結果、自身のプロトコルを再構成する必要がなければ、実施部エージェント９５１は、自身に接続した対象装置で再構成されたプロトコルを実施するためにノードステートデータベース９５４を参照する（ステップＳ１００５）。
その前に、実施部エージェント９５１は、自身と接続した対象装置（ここでは、プロトコル再構成装置９９０）が使用しているプロトコルと運用パラメータに関する情報を格納するノードステートデータベース（Ｎｏｄｅ ｓｔａｔｅ Ｄａｔａｂａｓｅ）９５４を保持する。
【００８２】
実施部エージェント９５１は、ノードステートデータベース９５４を参照してプロトコル構成情報により対象装置９９０で再構成されたプロトコルを実施するために必要な情報を生成する。実施部エージェント９５１は、生成された情報を再構成プロトコルスタック９７０によって対象装置９９０に送信する。
【００８３】
実施部エージェント９５１は、ノードステートデータベース９５４を参照して対象装置９９０が再構成されたプロトコルを実施するために必要な少なくとも１つのコンポーネントモジュールを含むか否かを判断する（ステップＳ１００７）。
ステップＳ１００７において、対象装置９９０が再構成されたプロトコルを実施するために必要な少なくとも１つのコンポーネントモジュールを含んでいないと判断されれば、実施部エージェント９５１はコンポーネントライブラリー９５３を参照する（ステップＳ１００９）。
【００８４】
コンポーネントライブラリー９５３は、再構成されたプロトコルを実施するために用いられる複数のコンポーネントモジュールに関する情報を含む。
実施部エージェント９５１は、コンポーネントライブラリー９５３を参照して必要な少なくとも１つのコンポーネントモジュールに関する情報を取得してメモリなどに記録する。ここで、少なくとも１つのコンポーネントモジュールに関する情報はＥＬＦフォーマットであってもよい。
この状態で対象装置９９０に送信する情報（すなわち、再構成されたプロトコルを実施するために必要な情報）の内容が確定される。
【００８５】
実施部エージェント９５１は、対象装置９９０に送信する情報のロバスト性（ｒｏｂｕｓｔｎｅｓｓ）のために、該当情報に対する符号化が必要であるか否かを判断する（ステップＳ１０１１）。
実施部エージェント９５１は、該当情報に対する符号化が必要であると判断されれば、プロトコルエンコーダ９５６によって該当情報に対する符号化を行う（ステップＳ１０１３）。
【００８６】
一方、ステップＳ１０１１で、もし、該当情報に対する符号化が必要ではないと判断されれば、実施部エージェント９５１は再構成プロトコルスタック９７０によって無線で該当情報を送信する（ステップＳ１０１５）。
ステップＳ１０１３において、符号化された該当情報も同様に再構成プロトコルスタック９７０によって無線で該当情報を送信する（ステップＳ１０１５）。
【００８７】
図９に示す点線は、プロトコル実施部９５０が対象装置９９０で再構成されたプロトコルを実施するための情報を生成するときのメッセージの流れを示す。
ＲＦＤで動作するプロトコル再構成装置９９０は、プロトコル実施部９９１及び再構成プロトコルスタック９９５を含む。
プロトコル実施部９９１は、情報解釈を行うプロトコルパーサー９９１１と解釈された結果を行うプロトコルアップデータ９９１３を含む。
【００８８】
ＲＦＤで動作するプロトコル再構成装置９９０のプロトコル実施部９９１は、ＦＦＤで動作するプロトコル再構成装置が受動モードで動作するときのプロトコル実施部とその構成及び動作が一致する。
したがって、以下では図１１を参照してＲＦＤで動作するプロトコル再構成装置９９０のプロトコル実施部９９１の動作について説明する。
【００８９】
図１１は、本発明の一実施形態に係るアプリケーションプログラムのプロトコルを再構成する装置がＲＦＤで動作するときのプロトコル実施部１１１０の動作を説明するための図である。
ＲＦＤで動作するプロトコル再構成装置１１００は、プロトコルパーサー１１１３とプロトコルアップデータ１１１６を含む。プロトコルパーサー１１１３は、ＦＦＤで動作するプロトコル再構成装置がプロトコルエンコーダを用いて情報を符号化した場合にのみ活性化する。
【００９０】
ＲＦＤで動作するプロトコル再構成装置１１００がＦＦＤで動作するプロトコル再構成装置から受信した情報（例えば、プロトコル再構成装置１１００でアプリケーションプログラムのための再構成されたプロトコルを実施するために必要な情報）は、下位の再構成プロトコルスタック１１３０を介してプロトコルパーサー１１１３に伝達される。
プロトコルパーサー１１１３は、該当情報を解釈してプロトコルアップデータ１１１６に送信する。
プロトコルアップデータ１１１６は、解釈された該当情報により再構成されたプロトコルをプロトコル再構成装置１１００で実施されるように複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールの接続関係を決定する。
【００９１】
プロトコルアップデータ１１１６は、上述した接続関係に関連する情報を再構成プロトコルスタック１１３０に送信し、該当情報により少なくとも１つのコンポーネントモジュールを接続する。ここで、プロトコルアップデータ１１１６が再構成されたプロトコルを実施するために再構成プロトコルスタック１１３０に送信する情報は、再構成プロトコルスタック１１３０の実現方法によって変わり得る。
【００９２】
図１２は、本発明の一実施形態に係るプロトコル実施部が構成テーブルを用いて再構成されたプロトコルを実施する方法を説明するための図である。
符号１２１０は一般的なコンポーネントモジュール構造を示し、符号１２３０は構成テーブルを用いて再構成されたプロトコルを実施することを示す。
【００９３】
符号１２３０でプロトコル実施部は、構成テーブル（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｔａｂｌｅ）１２３３を用いて少なくとも１つのコンポーネントモジュールを接続することによって、再構成されたプロトコルをリアルタイムで実施する。
ここで、構成テーブル１２３３は、再構成されたプロトコルを実施するために必要な少なくとも１つのコンポーネントモジュールそれぞれのアドレスを含む。また、構成テーブル１２３３は、再構成されたプロトコルを実施するために必要な少なくとも１つのコンポーネントモジュールにアクセスできるようにルーティングする機能も含んでもよい。
【００９４】
したがって、該当コンポーネントモジュールを呼び出す同一名の関数が数個のプロトコルに複数存在するとしても、構成テーブル１２３３は必要なコンポーネントモジュールのアドレスを直ちにアクセスすることができる。
ここで、プロトコルアップデータは、再構成プロトコルスタックに少なくとも１つのコンポーネントモジュールのＩＤを通知する。
【００９５】
図１３は、一実施形態に係るプロトコル実施部がメッセージフッキング（ｍｅｓｓａｇｅ ｈｏｏｋｉｎｇ）を用いて再構成されたプロトコルを実施する方法を説明するための図である。
図１３に示すように、アプリケーションプログラムレイヤ１３１０の下位に構成レイヤ１３２０を備える。
ここで、プロトコル実施部は、構成レイヤ１３２０によって下位のＭＡＣレイヤ１３３０に送信されるメッセージをフッキングしてプロトコルのＩＤを取得する。
【００９６】
プロトコル実施部は、フッキングしたメッセージから取得したプロトコルのＩＤに基づいて、再構成プロトコルを実施するための少なくとも１つのコンポーネントモジュールをスイッチングする。
ここで、プロトコルアップデータは、再構成プロトコルスタックに再構成プロトコルに該当するプロトコルＩＤを通知する。
【００９７】
以下は、上述した方法を用いて１台のＦＦＤに接続したＲＦＤが１台から３台に動的に変化する場合にプロトコル再構成システムの動作について説明する。
まず、ＲＦＤが１台である場合を＜実施形態１＞、ＲＦＤが３台である場合を＜実施形態２＞に分類して、各実施形態の動作を詳しく説明する。
＜実施形態１＞において、１台のＦＦＤではＴＤＭＡプロトコルを使用していると仮定する。
【００９８】
＜実施形態１＞
ＲＦＤ１は、実行中である体温測定のためのアプリケーションプログラムを実行するためにＦＦＤとの接続を試みる。
ここで、ＲＦＤ１が実行しようとするアプリケーションプログラムの要求情報は下記に示す表１の通りである。
【００９９】
【表１】
表１でＳａｍｐｌｉｎｇ ｒａｔｅは、データパケットの生成率を示し、Ｒｅｌｉａｂｉｌｉｔｙはパケット損失率（ｐａｃｋｅｔ ｌｏｓｓ ｒａｔｅ）を示す。
表１で考慮されるアプリケーションプログラムの要求情報は、Ｒｅｌｉａｂｉｌｉｔｙとｌａｔｅｎｃｙである。
【０１００】
ＦＦＤは、アプリケーションプログラムの要求情報を様々な方式によって取得してもよい。例えば、ＦＦＤで初期アプリケーションプログラムのセットアップのとき、アプリケーションプログラムに予め格納された要求情報に対するデフォルト値をアクセスしたり、ＲＦＤ１とのＡｓｓｏｃｉａｔｉｏｎ実行工程で該当情報をｉｎ−ｂａｎｄ ｓｉｇｎａｌｉｎｇのような方法によってＲＦＤから伝達されてもよい。
【０１０１】
＜実施形態１＞での分析部の動作
分析部は、プロトコルエンジンでのモデリングに用いられる全てのパラメータ値に関する情報を保持及び／又は更新する。分析部はアプリケーションプログラムの要求情報に関連するイベント（例えば、ａｓｓｏｃｉａｔｉｏｎ）の発生時にアプリケーションプログラムの要求情報を取得する。
その他にも、分析部は、必要な場合にのみＰＨＹレイヤ又はＭＡＣレイヤからパケットエラー率（ｐａｃｋｅｔ ｅｒｒｏｒ ｒａｔｅ）及び接続ノードの数などのような情報を取得する。
【０１０２】
分析部は、取得した情報を一括的あるいは選別的にプロトコルエンジンに伝達することができ、分析部が取得した情報の一括的あるいは選別的な伝達の有無はプロトコルエンジンとのインターフェースの設計時に決定される。
本実施形態では、アプリケーションプログラムの要求情報及びプロトコル再構成装置に接続したノード（装置またはセンサなど）の数に対するアップデートされた情報が発生する場合のみ分析部がプロトコルエンジンに該当値を伝達するものとする。
【０１０３】
すなわち、分析部は、アプリケーションプログラムの要求情報及びプロトコル再構成装置に接続したノード（装置またはセンサなど）の数に対するアップデートされた情報が発生する場合にＤｅｖｉｃｅ ＩＤ、Ｒｅｌｉａｂｉｌｉｔｙ ｒｅｑｕｅｓｔ、Ｌａｔｅｎｃｙ ｒｅｑｕｅｓｔ、ｎｕｍｂｅｒ ｏｆ ｎｏｄｅ形態の情報をプロトコルエンジンに送信する。
したがって、＜実施形態１＞において分析部は、ＲＦＤ１に対する要求情報をプロトコルエンジンに送信する。ここで、ＲＦＤ１に対する要求情報は、例えば、Ｄｅｖｉｃｅ ＩＤ：１、Ｒｅｌｉａｂｉｌｉｔｙ ｒｅｑｕｅｓｔ：５、Ｌａｔｅｎｃｙ ｒｅｑｕｅｓｔ：ｎ／ａ、ｎｕｍｂｅｒ ｏｆ ｎｏｄｅ：１であってもよい。
【０１０４】
＜実施形態１＞でのプロトコルエンジンの動作
分析部から情報を受信したプロトコルエンジンのエージェントは、情報を受信するときごとに実行されるイベントベースの方法、あるいは一定周期ごとにトリガーさせる周期ベースの方法などを用いてソルバーをトリガーする。
上述したように、ソルバーは複数のプロトコルごとに対するモデリングを行うモデリング部と、複数のプロトコルごとに対するモデルに対する解を取得するアルゴリズム部で構成される。
【０１０５】
本実施形態では、ＦＦＤがＸ−ＭＡＣ、Ｐｕｒｅ−ＴＤＭＡ、及びＢａｓｅ Ｐｒｏｔｏｃｏｌの３種類のプロトコルを保有していると仮定する。
ここで、Ｂａｓｅ Ｐｒｏｔｏｃｏｌは、ＲＦＤ１とＦＦＤとのａｓｓｏｃｉａｔｉｏｎのためのコントロール情報の送受信を支援するプロトコルである。
したがって、モデリング部は、実際的なデータ送信の過程を支援するプロトコルのＸ−ＭＡＣとＰｕｒｅ−ＴＤＭＡに対するモデリングを行う。
【０１０６】
Ｘ−ＭＡＣプロトコルの動作は次の通りである。
Ｘ−ＭＡＣは、データを送信しようとする送信装置（ｓｅｎｄｅｒ）がストローブ（ｓｔｒｏｂｅ）と呼ばれる小さいパケットに受信装置（ｒｅｃｅｉｖｅｒ）のアドレスを記載して送信する。
受信装置は、スリップモード（ｓｌｅｅｐ ｍｏｄｅ）から一定周期ごとに起動して自身のアドレスが記載されたストローブパケットがあるか否かをチェックする。
もし、自身のアドレスが記載されたストローブパケットがあれば、受信装置はＡＣＫパケットを送信装置に送信する。
【０１０７】
送信装置は、ＡＣＫパケットを受信すると同時に即受信装置にデータを送信する。
受信装置は、データを全て受信した後、直ちにスリップモードに入ることなく、一定時間起動して他のノードからのデータを待機する。
受信装置のこのような動作は、送信装置のストローブパケット送信を減らしてエネルギーを節減することができる。
【０１０８】
受信装置に送信するデータがあるものの、他のノードが送信していることを検出した場合に、送信装置は一定期間をバックオフ（ｂａｃｋ−ｏｆｆ）して待機する。
送信装置は、一定期間が完了すれば、直ちに受信装置にデータを送信する。
ここで、受信装置が起動している時間は最大バックオフ時間よりも大きくなければならない。
【０１０９】
Ｐｕｒｅ−ＴＤＭＡの動作は次の通りである。
Ｐｕｒｅ−ＴＤＭＡで受信装置と送信装置との間の送信順序が決定されて、送信するデータはタイムスロット（ｔｉｍｅ ｓｌｏｔ）に基づいて送信される。
そのために受信装置は、周期的にビーコン信号を送信して自身と送信装置の間の同期を合わせて割り当てられたタイムスロットを通知する。
【０１１０】
受信装置は、送信装置にデータ送信のために１つのタイムスロットを割り当て、決定したタイムスロットにのみ送信を許諾する。
このように送信のために割り当てられたタイムスロットを活性期間（ａｃｔｉｖｅ ｐｅｒｉｏｄ）という。
活性期間の後に、ノードはスリップ期間の間にスリップモードに入る。このスリップモードは、送信装置のビーコン送信時点の直前に終了する。
【０１１１】
プロトコルエンジンは、上述した２種類のプロトコルを用いて通信を行うときに発生するエネルギー及びＱｏＳ指標（ＲｅｌｉａｂｉｌｉｔｙとＬａｔｅｎｃｙ）を予測して数学的モデリングを行う。
モデリング部は、運用パラメータ及びアプリケーションプログラムの要求情報などを用いるが、このときにプロトコルの動作を理解してこれに基づいて各指標を数式化してもよい。
【０１１２】
例えば、Ｘ−ＭＡＣの場合、パケットを生成する間に必要とされるエネルギーを受信装置のスリップ周期（Ｒｓ）と他の送信装置がデータを送信しているとき、待機しなければならないバックオフ期間（Ｓｂｏ）のエネルギー関数に示してもよい。
したがって、この２つのパラメータがＸ−ＭＡＣの運用パラメータであってもよい。アプリケーションプログラムの要求情報に該当するＬａｔｅｎｃｙ及びＲｅｌｉａｂｉｌｉｔｙも受信装置のスリップ周期（Ｒｓ）及びバックオフ期間（Ｓｂｏ）の関数に示してもよい。
【０１１３】
また、ＴＤＭＡの場合、エネルギー関数は活性期間及びスリップ期間を構成する総タイムスロットの個数であるＮｆｒａｍｅの関数に表わしてもよく、ここで、Ｎｆｒａｍｅは運用パラメータであってもよい。
プロトコルエンジンは、各プロトコルごとのモデルに対して運用パラメータの最適値とそれによるエネルギー消耗を比較して最適のプロトコルを選択する。
【０１１４】
プロトコルエンジンのアルゴリズム部は、例えば、エネルギーの最小化問題をそれぞれ解決して各プロトコルの目的値を比較し、最小のエネルギー費用を有するプロトコルとそのときの運用パラメータを最適プロトコル及び運用パラメータとして決定する。
アルゴリズム部は、プロトコル問題が有している変数特性などに基づいて設計されるべきであるが、本実施形態ではプロトコルが有する運用パラメータが整数値を有すると仮定し、これに対する一般的な解を求める分枝限定法（ｂｒａｎｃｈ ａｎｄ ｂｏｕｎｄ）アルゴリズムを選択してもよい。
【０１１５】
＜実施形態１＞でのプロトコル実施部の動作：ＦＦＤ側
プロトコルエンジンのエージェントは、例えば、最適のプロトコルがＸ−ＭＡＣであり、最適の（システム）パラメータがＲｓ：９、Ｓｂｏ：１０ｍｓであることをプロトコル実施部の実施部エージェントに伝達する。
実施部エージェントは、ＦＦＤ自身のプロトコルを再構成するために取得した情報をプロトコルアップデータに伝達する。
プロトコルアップデータは、再構成されたプロトコルを実施するためにプロトコルスタックに関連情報を伝達する。
【０１１６】
例えば、プロトコルを再構成するためにメッセージフッキング方法を用いると仮定する。
プロトコル実施部のプロトコルアップデータは、まず、関数呼出（ｆｕｎｃｔｉｏｎ ｃａｌｌ）によってＸ−ＭＡＣプロトコル上の最適のパラメータのＲｓとＳｂｏを調節する該当関数に最適値を設定することを要求する。
そして、応用レイヤ（Ａｐｐｌｉｃａｔｉｏｎ Ｌａｙｅｒ）で作られたデータは、プロトコルフィールドにＸ−ＭＡＣに該当するＩＤが設定された形態のメッセージでプロトコルスタックに伝達される。プロトコル実施部のアップデータは、下位のプロトコルスタックに伝達される直前に該当メッセージをフッキングして最適のプロトコルがＸ−ＭＡＣであることを確認し、Ｘ−ＭＡＣのためのコンポーネントモジュールにスイッチングする。
【０１１７】
また、実施部エージェントは、ＲＦＤ１で再構成されたプロトコルを実施できるようにする。
実施部エージェントは、まず、現在ＲＦＤ１のプロトコルの使用状況を把握するためにノードステートデータベースを参照する。ＲＦＤ１に該当するノードステートデータベース情報は下記に示す表２の通りである。
【０１１８】
【表２】
【０１１９】
ＲＦＤ１で現在に使用中であるプロトコルがＴＤＭＡであるため、ＲＦＤ１でのプロトコル再構成が必要であると判断した実施部エージェントは、ＲＦＤ１でＸ−ＭＡＣを実施するために足りない（プロトコル）コンポーネントモジュールがないかを確認する。
ここで、ＲＦＤ１がＸ−ＭＡＣを保有しているため、Ｘ−ＭＡＣのためのコンポーネントモジュールをもってくる動作は必要としない。したがって、実施部エージェントは再構成プロトコルスタックに、例えば、（最適のプロトコル、パラメータ値）＝（Ｘ−ＭＡＣ、（９，１０））（Ｒｓ、Ｓｂｏの順）のような情報を送信する。この情報は必要に応じて符号化が可能であり、実施部エージェントは再構成プロトコルスタックによって該当情報がＲＦＤ１に無線に送信される。
【０１２０】
＜実施形態１＞でのプロトコル実施部の動作：ＲＦＤ側
ＲＦＤ１の再構成プロトコルスタックは、関連情報（例えば、Ｘ−ＭＡＣ、（９、１０））を受信してＲＦＤ１のプロトコル実施部に伝達する。
ここで、関連情報が符号化されていれば、プロトコル実施部は、プロトコルパーサーによってこれを復元してプロトコルアップデータに伝達する。
関連情報が伝達されたプロトコルアップデータの動作は、上述したＦＦＤのプロトコルアップデータの動作と同一である。
【０１２１】
＜実施形態２＞
以下は、ＲＦＤ１と通信していたＦＦＤにＲＦＤ２とＲＦＤ３が新しく接続要求をした動的な状況におけるシステム動作を説明する。
＜実施形態１＞と相当の部分が類似するため、相異する点のみを説明する。
【０１２２】
新たに接続要求したＲＦＤ２及びＲＦＤ３のアプリケーションプログラム及びその特性は下記に示す表３の通りである。
【表３】
【０１２３】
＜実施形態１＞の場合と同様に＜実施形態２＞でも分析部は３つのＲＦＤ（アプリケーションプログラム）に対するサービス品質情報と接続したセンサノードの数などのような情報をプロトコルエンジンに送信する。
【０１２４】
＜実施形態２＞でのプロトコルエンジンの動作
プロトコルエンジンは、３つの装置ＲＦＤ１、ＲＦＤ２、ＲＦＤ３のプロトコルを用いるときに消費されるエネルギーを送信装置の３つの装置のバックオフパラメータＳｂｏ１、Ｓｂｏ２、Ｓｂｏ３と受信装置であるＦＦＤのスリップ期間Ｒｓの関数に表わす。
また、プロトコルエンジンは、各装置のＱｏＳ指標も上述したパラメータに表わしてアプリケーションプログラムで要求される要求情報を満足するように数式化する。
ＴＤＭＡの場合、＜実施形態１＞と同様に、受信装置であるＦＦＤのパラメータであるＮｆｒａｍｅの関数に表わす。
【０１２５】
＜実施形態２＞でのプロトコル実施部の動作：ＦＦＤ側
プロトコルエンジンのエージェントは、最適のプロトコルがＴＤＭＡであり、最適のパラメータがＮＦｒａｍｅ：２０であることをプロトコル実施部の実施部エージェントに伝達する。
実施部エージェントは、ＦＦＤ自身のプロトコルを再構成するために取得した情報をプロトコルアップデータに伝達する。プロトコルアップデータは、再構成されたプロトコルを実施するためにプロトコルスタックに関連情報を伝達し、再構成されたプロトコルを行うように命令する。具体的な方法は＜実施形態１＞と同一である。
【０１２６】
実施部エージェントは、自身に接続した３つの装置ＲＦＤ１、ＲＦＤ２、ＲＦＤ３に対してプロトコル再構成を行う。
まず、実施部エージェントは、現在の３つの装置それぞれが用いるプロトコルを把握するためにノードステートデータベースを参照する。
【０１２７】
ノードステートデータベースは下記に示す表４のような情報を保有すると仮定する。
【表４】
【０１２８】
表４で実施部エージェントは、＜実施形態１＞と同様に、ＴＤＭＡを保有しているＲＦＤ１とＲＦＤ２には（最適プロトコル、パラメータ値）＝（ＴＤＭＡ、３０）の情報を再構成プロトコルスタックによって送信する。ここで、符号化が必要であれば、該当情報を符号化して送信してもよい。
ＲＦＤ３は、ＴＤＭＡを保有していないため、実施部エージェントは、ＴＤＭＡを実施するために必要なコンポーネントモジュールが何であるかをコンポーネントライブラリーを参照して確認する。
【０１２９】
例えば、必要なコンポーネントモジュールが３番であると仮定すると、実施部エージェントは（最適プロトコル、パラメータ値）＝（ＴＤＭＡ、３０）の情報と共に３番のコンポーネントモジュールを再構成プロトコルスタックに送信する。ここで、３番のコンポーネントモジュールはＥＬＦ形式を有し得る。
【０１３０】
＜実施形態２＞でのプロトコル実施部の動作：ＲＦＤ側
ＲＦＤ３のプロトコルスタックは、関連情報（ここでは（最適プロトコル、パラメータ値）＝（ＴＤＭＡ、３０）の情報及び３番のコンポーネントモジュール）を受信してＲＦＤ３のプロトコル実施部に伝達する。ここで、関連情報が符号化されていれば、ＲＦＤ３のプロトコル実施部はプロトコルパーサーを介して少なくとも１つのコンポーネントモジュール（ここでは、３番のモジュール）に関する情報とプロトコル構成情報を復元する。
【０１３１】
少なくとも１つのコンポーネントモジュールに関する情報に関する情報を確認すると、ＲＦＤ３のプロトコルアップデータはリンカー（Ｌｉｎｋｅｒ）に受信した３番のコンポーネントモジュールをリンクするというメッセージを送信する。
そして、リンカーは新しいＥＬＦ ｏｂｊｅｃｔをリンクし、バイナリ（ｂｉｎａｒｙ）をコードメモリからロードしてＴＤＭＡスタックを設定する。
その後、ＲＦＤ３のプロトコルアップデータは＜実施形態１＞のような方法によって（最適プロトコル、パラメータ値）＝（ＴＤＭＡ、３０）の情報を用いてＴＤＭＡプロトコルを設定する。
【０１３２】
上述した本発明の一実施形態に係るプリケーションプログラムのプロトコルを再構成する方法方法は、多様なコンピュータ手段を介して様々な処理を実行することができるプログラム命令の形態で実現され、コンピュータ読取可能な記録媒体に記録されてもよい。
コンピュータ読取可能な媒体は、プログラム命令、データファイル、データ構造などの単独又はその組み合わせたものを含んでもよい。
媒体に記録されるプログラム命令は、本発明の目的のために特別に設計されて構成されたものでもよく、コンピュータソフトウェア分野の技術を有する当業者にとって公知のものであり使用可能なものであってもよい。
【０１３３】
尚、本発明は、上述の実施形態に限られるものではない。本発明の技術的範囲から逸脱しない範囲内で多様に変更実施することが可能である。
【符号の説明】
【０１３４】
１００、２００ プロトコル再構成装置
１１０、５３１ 分析部
１３０、５３３ プロトコルエンジン
１５０、２１０、５３５、５５５ プロトコル実施部
１７０、２３０、５３７、５５７ 再構成プロトコルスタック
５２０ アプリケーションプログラム
５３０ プロトコル再構成装置（ＦＦＤ）
５５０ 対象装置（ＲＦＤ）
【技術分野】
【０００１】
本発明は、アプリケーションプログラムのプロトコルを再構成する方法及びその装置に関し、特に、複数のプロトコルコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールを結合して再構成されたプロトコルを実施するアプリケーションプログラムのプロトコルを再構成する方法及びその装置に関する。
【背景技術】
【０００２】
近年、スマートフォンなど携帯可能な個人用デジタル機器とセンサの普及により無線通信を用いる様々なアプリケーションプログラム（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ）が引き続いて増加している。
このように様々なアプリケーションプログラムは、サービス分野に応じて互いに異なるサービス品質（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ；以下、ＱｏＳ）が要求される。
【０００３】
アプリケーションプログラムの一例として、ｌａｔｅｎｃｙ、ｒｅｌｉａｂｉｌｉｔｙ（ＰＥＲ）、バッテリーなどの要求事項を有するｗｅａｒａｂｌｅ ＢＡＮ（Ｂｏｄｙ Ａｒｅａ Ｎｅｔｗｏｒｋ）分野のＥＣＧ（ＥｌｅｃｔｒｏＣａｒｄｉｏＧｒａｐｈ）、ＥＥＧ（ＥｌｅｃｔｒｏＥｎｃｅｐｈａｌｏＧｒａｐｈｙ）、ＥＭＧ（ＥｌｅｃｔｒｏＭｙｏＧｒａｐｈｙ）などのヘルスケア用のプログラムが挙げられる。
【０００４】
また、個人用デジタル機器と接続されたセンサなどは、個人用デジタル機器で駆動されるアプリケーションプログラムによってその数がリアルタイムに変わり得る。
従って、個人用デジタル機器が自身と接続されたセンサ、その他のデジタル機器及びアプリケーションプログラムが要求するサービス品質を提供することができるようリアルタイムで最適のプロトコルを支援する方法が求められているという問題がある。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
そこで、本発明は上記従来のアプリケーションプログラムにおける問題点に鑑みてなされたものであって、本発明の目的は、複数の（プロトコル）コンポーネントモジュールのうち、少なくとも１つのコンポーネントモジュールを結合して再構成されたプロトコルを実施することにある。
また、本発明の他の目的は、少なくとも１つのコンポーネントモジュールを再使用してセンサプラットフォームのメモリ使用を減少させることにある。
また、本発明の他の目的は、コンポーネントモジュールを結合して再構成されたプロトコルを実施することによって、複数のアプリケーションプログラムそれぞれのためのプロトコル開発時間を短縮させることにある。
【課題を解決するための手段】
【０００６】
上記目的を達成するためになされた本発明によるアプリケーションプログラムのためのプロトコルを再構成する方法は、アプリケーションプログラムのためのプロトコルを再構成する方法において、複数のコンポーネントモジュールのスタックが格納されたメモリを保持するステップと、前記アプリケーションプログラムの要求情報及びプロトコルレイヤから取得したシステム情報を分析するステップと、前記分析結果に基づいて、前記アプリケーションプログラムのための再構成されたプロトコルと前記再構成されたプロトコルのための運用パラメータとを含むプロトコル構成情報を決定するステップと、前記プロトコル構成情報に基づいて、前記再構成されたプロトコルを実施するのに必要である前記複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールとの接続関係を決定するステップとを有することを特徴とする。
【０００７】
前記システム情報を分析するステップは、前記アプリケーションプログラムで、前記アプリケーションプログラムの要求情報に関連するイベントが発生したか否かに基づいて、前記アプリケーションプログラムの要求情報を取得することが好ましい。
前記プロトコル構成情報を決定するステップは、複数のプロトコルそれぞれに対するＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）指標を、前記プロトコルレイヤから取得可能な少なくとも１つのパラメータと前記プロトコルの運用パラメータの関数として定義するステップと、前記関数を前記アプリケーションプログラムの要求情報に適するよう数式化するステップとをさらに含むことが好ましい。
前記プロトコル構成情報を決定するステップは、前記アプリケーションプログラムの要求情報によって表示される前記アプリケーションプログラムの要求事項を満足するために、前記再構成されたプロトコルのＱｏＳ指標を最適化させる運用パラメータを決定するステップを含むことが好ましい。
【０００８】
前記複数のプロトコルそれぞれを分析した結果を含む情報を適用することによって、複数のプロトコルと、要求情報がマッピングされた複数のプロトコルそれぞれの運用パラメータとを格納するプロトコルデータベースを保持するステップをさらに有し、前記プロトコル構成情報を決定するステップは、前記プロトコルデータベースを参照して、前記アプリケーションプログラムの要求情報に対応してマッピングされている複数のプロトコルのいずれか１つのプロトコルと、該いずれか１つのプロトコルの運用パラメータとを前記再構成されたプロトコル及び前記再構成されたプロトコルの運用パラメータとして決定するステップを含むことが好ましい。
前記少なくとも１つのコンポーネントモジュールとの接続関係を決定するステップは、前記プロトコル構成情報に基づいて前記接続関係に関連する情報を生成するステップと、前記接続関係に関連する情報を用いて前記再構成されたプロトコルを実施するステップとをさらに含むことが好ましい。
前記複数のコンポーネントモジュールに関連する情報を格納するコンポーネントライブラリーを保持するステップをさらに有することが好ましい。
【０００９】
アプリケーションプログラムのためのプロトコルを再構成する装置に接続され前記再構成されたプロトコルを実施する対象装置が前記再構成されたプロトコルを実施するために必要なコンポーネントモジュールが失われているか（ｍｉｓｓｉｎｇ）否かを判断するステップと、前記判断結果に応じて、前記対象装置から失われていると判断されるコンポーネントモジュールに関する情報を前記コンポーネントライブラリーから取得するステップとをさらに有することが好ましい。
対象装置によって使用されるプロトコルとプロトコルの運用パラメータに関する情報を格納するノードステートデータベースを保持するステップをさらに有することが好ましい。
前記ノードステートデータベース及び前記接続関係を参照して、前記プロトコル構成情報に基づき前記対象装置で前記再構成されたプロトコルを実施するために必要な情報を生成するステップと、前記対象装置で前記再構成されたプロトコルを実施するために必要な情報を前記対象装置に送信するステップとをさらに有することが好ましい。
前記対象装置で前記再構成されたプロトコルを実施するために必要な情報を符号化するステップをさらに有することが好ましい。
【００１０】
前記少なくとも１つのコンポーネントモジュールとの接続関係を決定するステップは、前記プロトコル構成情報を受信するステップと、前記プロトコル構成情報を解釈するステップとを含むことが好ましい。
前記少なくとも１つのコンポーネントモジュールとの接続関係を決定するステップは、前記少なくとも１つのコンポーネントモジュールそれぞれのアドレスを含むテーブルを用いて前記少なくとも１つのコンポーネントモジュールを接続するステップをさらに有することが好ましい。
前記少なくとも１つのコンポーネントモジュールとの接続関係を決定するステップは、前記アプリケーションプログラムのための前記再構成されたプロトコルによりアプリケーションプログラムレイヤの下位レイヤを通過するメッセージをフックする（ｈｏｏｋｉｎｇ）ステップと、前記フックしたメッセージから取得したプロトコルのＩＤに基づいて、前記少なくとも１つのコンポーネントモジュールをスイッチングするステップとを含むことが好ましい。
【００１１】
また、上記目的を達成するためになされた本発明によるアプリケーションプログラムのためのプロトコルを再構成する方法は、アプリケーションプログラムのためのプロトコルを再構成する方法において、複数のコンポーネントモジュールのスタックが格納されたメモリを保持するステップと、アプリケーションプログラムのためのプロトコルを再構成する装置に接続された対象装置から前記アプリケーションプログラムのための再構成されたプロトコルを実施するために必要な情報を受信するステップと、前記アプリケーションプログラムの再構成されたプロトコルを実施するために必要な情報に基づいて、前記アプリケーションプログラムの再構成プロトコルを構成するために必要な前記複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールとの接続関係を決定するステップとを有することを特徴とする。
【００１２】
前記アプリケーションプログラムのための再構成されたプロトコルを実施するために必要な情報は、前記アプリケーションプログラムのための再構成されたプロトコルと前記再構成されたプロトコルのための運用パラメータとを含むプロトコル構成情報、前記少なくとも１つのコンポーネントモジュールとの接続関係に関連する情報又は前記プロトコル構成情報及び前記接続関係に関連する情報の内の少なくとも１つを含むことが好ましい。
前記少なくとも１つのコンポーネントモジュールとの接続関係を決定するステップは、前記再構成されたプロトコルを実施するために必要な情報を解読するステップをさらに含むことが好ましい。
【００１３】
上記目的を達成するためになされた本発明によるコンピュータで読み出し可能な記録媒体は、上記アプリケーションプログラムのためのプロトコルを再構成する方法を実行させるためのプログラムが記録されたことを特徴とする。
【００１４】
上記目的を達成するためになされた本発明によるアプリケーションプログラムのためのプロトコルを再構成する装置は、アプリケーションプログラムのためのプロトコルを再構成する装置において、前記アプリケーションプログラムの要求情報及びプロトコルレイヤから取得されたシステム情報を分析する分析部と、前記分析結果に基づいて、前記アプリケーションプログラムのための再構成されたプロトコル及び前記再構成されたプロトコルのための運用パラメータを含むプロトコル構成情報を決定するプロトコルエンジンと、前記プロトコル構成情報により、前記再構成されたプロトコルを実施するために複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールとの接続関係を決定するプロトコル実施部と、前記複数のコンポーネントモジュールのスタックが格納されたメモリを含む再構成プロトコルスタックとを有することを特徴とする。
【００１５】
また、上記目的を達成するためになされた本発明によるアプリケーションプログラムのためのプロトコルを再構成する装置は、アプリケーションプログラムのためのプロトコルを再構成する装置において、複数のコンポーネントモジュールのスタックが格納されたメモリを含む再構成プロトコルスタックと、前記アプリケーションプログラムのためのプロトコルを再構成する装置と接続した対象装置から受信した前記アプリケーションプログラムのための再構成されたプロトコルを実施するために必要な情報に基づいて、前記アプリケーションプログラムの再構成されたプロトコルを実施するために必要な前記複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールとの接続関係を決定するプロトコル実施部とを有することを特徴とする。
【００１６】
また、上記目的を達成するためになされた本発明によるアプリケーションプログラムのためのプロトコルを再構成する方法は、プロトコルレイヤから取得されたシステム情報及びアプリケーションプログラムの要求情報に基づいて前記アプリケーションプログラムの最適プロトコルと該最適プロトコルの運用パラメータの最適値とを決定するステップと、前記アプリケーションプログラムの現在のプロトコルが前記最適プロトコルではない場合、前記アプリケーションプログラムの現在のプロトコルから失われた（ｍｉｓｓｉｎｇ）少なくとも１つのコンポーネントモジュールと前記アプリケーションプログラムの現在のプロトコルの少なくとも１つのコンポーネントモジュールとを用いて、前記最適プロトコルの前記運用パラメータの値を前記最適プロトコルの前記運用パラメータの最適値に設定して前記アプリケーションプログラムの現在のプロトコルを前記最適プロトコルに再構成するステップとを有することを特徴とする。
【００１７】
前記アプリケーションプログラムの現在のプロトコルの少なくとも１つのコンポーネントモジュールと前記アプリケーションプログラムの前記現在のプロトコルから失われた（ｍｉｓｓｉｎｇ）少なくとも１つのコンポーネントモジュールは、再構成プロトコルスタックのメモリに格納された複数のコンポーネントモジュールに含まれることが好ましい。
前記アプリケーションプログラムの前記現在のプロトコルが前記最適プロトコルであり、前記最適プロトコルの運用パラメータの現在の値が前記最適プロトコルの運用パラメータの最適値ではない場合、前記最適プロトコルの運用パラメータの値を前記運用パラメータの最適値に設定するステップをさらに有することが好ましい。
前記アプリケーションプログラムは、第１装置に接続された第２装置から前記現在のプロトコルを用いて前記第１装置に送信されたデータを処理するために前記第１装置で駆動され、前記最適プロトコルを決定するステップは、前記アプリケーションプログラムの要求情報が変更された時、又は前記第１装置に第３装置が接続された時に、実行されることが好ましい。
【発明の効果】
【００１８】
本発明に係るアプリケーションプログラムのプロトコルを再構成する方法及びその装置によれば、複数の（プロトコル）コンポーネントモジュールのうち少なくとも１つのコンポーネントモジュールを結合して再構成されたプロトコルを実施することによって、複数のセンサ、その他のデジタル機器及びアプリケーションプログラムそれぞれで要求されるサービス品質を提供することのできるプロトコルをリアルタイムで再構成することができるという効果がある。
また、少なくとも１つのコンポーネントモジュールを再使用することによって、センサプラットフォームのメモリ使用を減少させることができるという効果がある。
また、複数の（プロトコル）コンポーネントモジュールのうち、少なくとも１つのコンポーネントモジュールを結合して再構成されたプロトコルを実施することによって、複数のアプリケーションプログラムそれぞれのためのプロトコル開発時間を短縮させることができるという効果がある。
【図面の簡単な説明】
【００１９】
【図１】本発明の一実施形態に係るアプリケーションプログラムのプロトコルを再構成する装置のブロック図である。
【図２】本発明の他の実施形態に係るアプリケーションプログラムのプロトコルを再構成する装置のブロック図である。
【図３】図１に示すプロトコル再構成装置がアプリケーションプログラムのプロトコルを再構成する方法を説明するためのフローチャートである。
【図４】図２に示すプロトコル再構成装置がアプリケーションプログラムのプロトコルを再構成する方法を説明するためのフローチャートである。
【図５】本発明の一実施形態に係るアプリケーションプログラムのプロトコルを再構成する装置を含むプロトコル再構成システムにおける装置間の動作を説明するための図である。
【図６】本発明の他の実施形態に係るアプリケーションプログラムのプロトコルを再構成する装置を含むプロトコル再構成システムにおける装置間の動作を説明するための図である。
【図７】本発明の一実施形態に係るランタイムソルバーを用いてプロトコルエンジンを実施する方法を説明するための図である。
【図８】本発明の一実施形態に係るプロトコルデータベースを用いてプロトコルエンジンを実施する方法を説明するための図である。
【図９】本発明の一実施形態に係るアプリケーションプログラムのプロトコルを再構成する装置において能動モードで動作するプロトコル実施部の構成を示すブロック図である。
【図１０】図９に示す能動モードでのプロトコル実施部の動作を説明するためのフローチャートである。
【図１１】本発明の一実施形態に係るアプリケーションプログラムのプロトコルを再構成する装置がＲＦＤで動作するときのプロトコル実施部の動作を説明するための図である。
【図１２】本発明の一実施形態に係るプロトコル実施部が構成テーブルを用いて再構成されたプロトコルを実施する方法を説明するための図である。
【図１３】本発明の一実施形態に係るプロトコル実施部がメッセージフッキングを用いて再構成されたプロトコルを実施する方法を説明するための図である。
【発明を実施するための形態】
【００２０】
次に、本発明に係るアプリケーションプログラムのプロトコルを再構成する方法及びその装置を実施するための形態の具体例を図面を参照しながら説明する。
【００２１】
しかし、本発明が一実施形態によって制限されたり限定されることはない。また、各図面に提示した同一の参照符号は同一の部材を示す。
【００２２】
一般的にプロトコルは、大きくアプリケーションプログラムに特化されたプロトコルと多重−目的（ｍｕｌｔｉ−ｐｕｒｐｏｓｅ）のためのプロトコルに分類される。
アプリケーションプログラムに特化されたプロトコルでは、Ｂ−ＭＡＣ、Ｘ−ＭＡＣなどのようにセンサネットワークのために提案されたプロトコルが一例として挙げられる。
【００２３】
アプリケーションプログラムに特化されたプロトコルの特徴は、特定アプリケーションプログラムには最適に設計されるが、異質のサービス品質（ＱｏＳ）を要求するアプリケーションプログラムに対しては、その性能が急激に低下することがある。このような適応性の問題を克服するために必要な全てのプロトコルをシステムに搭載する場合、メモリの側面において、効率的ではないという問題が発生する。
【００２４】
また、多重目的のためのプロトコルは、プロファイル（ｐｒｏｆｉｌｅ）によって様々なアプリケーションプログラムを支援することができ、ＩＥＥＥ８０２．１５．４などが一例として挙げられる。
多重目的のためのプロトコルは、プロトコル自体のオーバーヘッドによって性能面において最適のプロトコルではない場合もある。
【００２５】
したがって、本発明の実施形態では、アプリケーションプログラムのリアルタイム「ｉｎ ａｎｄ ｏｕｔ」の変化に対して最適のプロトコルを決定することのできるラン−タイム構造（ｒｕｎ−ｔｉｍｅ ａｒｃｈｉｔｅｃｔｕｒｅ）を提供すると同時に、ユーザの携帯用デジタル機器に提供するアプリケーションプログラムが動的に用いられる環境でサービスの品質を満足させ得る最適のプロトコルと運用条件をリアルタイムに提供することが可能である。
【００２６】
図１は、本発明の一実施形態に係るアプリケーションプログラムのプロトコルを再構成する装置のブロック図である。
図１に示すアプリケーションプログラムのプロトコルを再構成する装置（以下、「プロトコル再構成装置」）１００は、能動的にアプリケーションプログラムのプロトコルを再構成する装置である。
【００２７】
プロトコル再構成装置１００は、
（１）アプリケーションプログラム又は周辺センサノードのための最適のプロトコルを決定し、アプリケーションプログラムのプロトコルを再構成する機能と、
（２）他のプロトコル再構成装置からの要求を受け入れて自身のプロトコルを変形させる機能の全てを行う。
プロトコル再構成装置１００で、（１）の機能はプロトコル再構成装置１００が能動モードで動作するときに行われ、（２）の機能はプロトコル再構成装置１００が受動モードで動作するときに行われる。
上述したような２種類の機能を全て含むプロトコル再構成装置１００を「Ｆｕｌｌ Ｆｕｎｃｔｉｏｎａｌ Ｐｒｏｔｏｃｏｌ Ｓｙｓｔｅｍ Ｄｅｖｉｃｅ」（以下、「ＦＦＤ」）と称する。
【００２８】
プロトコル再構成装置１００は、分析部１１０、プロトコルエンジン１３０、プロトコル実施部１５０、及び再構成プロトコルスタック１７０を含む。
分析部１１０は、アプリケーションプログラムの要求情報及びプロトコルレイヤから取得されたシステム情報を分析する。ここで、アプリケーションプログラムの要求情報は、アプリケーションプログラムのＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）リクエスト情報だけではなく、周辺センサノードの要求情報も含んでもよく、各アプリケーションプログラムが要求するＬａｔｅｎｃｙ、ＰＥＲ（Ｐａｃｋｅｔ Ｅｒｒｏｒ Ｒａｔｅ）、ｌｉｆｅｔｉｍｅなどが一例として含みうる。
【００２９】
システム情報は、チャネル状態情報、プロトコル再構成装置１００に接続したデバイス（センサノード及びその他のデジタル機器）の数字など、プロトコル再構成装置１００がＰＨＹレイヤ又はＭＡＣレイヤなどに対してプロトコルレイヤから取得する情報である。
また、分析部１１０は、取得した情報（アプリケーションプログラムの要求情報及びシステム情報）を予め設定されたフォーマットのメッセージ形式でプロトコルエンジン１３０に周期的に供給する。
【００３０】
プロトコルエンジン１３０は、分析部１１０の分析結果に基づいてアプリケーションプログラムのための再構成されたプロトコル、及び再構成されたプロトコルのための運用パラメータを含むプロトコル構成情報を決定する。
すなわち、プロトコルエンジン１３０は、アプリケーションプログラムのための最適のプロトコル（ここでは、再構成されたプロトコル）及び該当プロトコルのための運用パラメータを決定する。
運用パラメータは、プロトコル再構成装置１００が調節権限を有するパラメータである。
プロトコルエンジン１３０は、エージェント（Ａｇｅｎｔ）とソルバー（ｓｏｌｖｅｒ）から構成され、具体的な構成及び動作については、図７及び図８を参照して詳細に後述する。
【００３１】
プロトコル実施部１５０は、プロトコルエンジン１３０から受信したプロトコル構成情報により、再構成されたプロトコルを実施するために複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールの接続関係を決定する。
プロトコル実施部１５０の具体的な動作及び構成については、図９及び図１０を参照して詳細に後述する。
【００３２】
再構成プロトコルスタック（Ｒｅｃｏｎｆｉｇｕｒａｂｌｅ Ｐｒｏｔｏｃｏｌ Ｓｔａｃｋ）１７０は、複数の（プロトコル）コンポーネントモジュールのスタックが格納されたメモリを保持する。
再構成プロトコルスタック１７０は、プロトコル実施部１５０で決定された少なくとも１つの接続関係に関する情報を受信して少なくとも１つのコンポーネントモジュールの接続を行う。
（プロトコル）コンポーネントモジュールのスタックは、プロトコルのための機能はコンポーネント化させて、これを接続して必要な機能を実行できるようにする。ここで、コンポーネントモジュールは、粒度（ｇｒａｎｕｌａｒｉｔｙ）に応じて伴うオーバーヘッド（ｏｖｅｒｈｅａｄ）によるトレード−オフ（ｔｒａｄｅ−ｏｆｆ）があるため、設計者の意図により様々な形態で構成され得る。
【００３３】
センサネットワークのプロトコルは、様々なアプリケーションプログラムの特性に応じてその種類が極めて多様である。
したがって、アプリケーションプログラムごとの最適のプロトコルを構成するために全ての作業を初めから再び始めることは時間と費用面において浪費になりかねない。
したがって、本実施形態ではプロトコルの基本機能をコンポーネント化して複数のコンポーネントモジュールのうち、プロトコルを再構成するために必要なコンポーネントモジュールを最大に再使用できるようにする。
【００３４】
ＦＦＤのプロトコル再構成装置１００が、能動モードで動作するときには、分析部１１０、プロトコルエンジン１３０、プロトコル実施部１５０及び再構成プロトコルスタック１７０の全てが活性化される。
一方、ＦＦＤのプロトコル再構成装置１００が、受動モードで動作するときには、図２に示すように、プロトコル実施部１５０及び再構成プロトコルスタック１７０だけが活性化され、このときには後述するＲＦＤと同一の動作を行う。
【００３５】
図２は、本発明の他の実施形態に係るアプリケーションプログラムのプロトコルを再構成する装置のブロック図である。
図２に示すアプリケーションプログラムのプロトコルを再構成する装置（以下、「プロトコル再構成装置」）２００は、受動的にアプリケーションプログラムのプロトコルを再構成する装置である。
【００３６】
プロトコル再構成装置２００は、自身と接続した対象装置から受信した、アプリケーションプログラムのための再構成されたプロトコルを実施するために必要な情報を用いて、プロトコル再構成装置２００で再構成されたプロトコルを実施するために必要な機能のみを含んでもよい。
すなわち、プロトコル再構成装置２００は、他のプロトコル再構成装置からの要求を受け入れて、自身のプロトコルを変形させる機能のみを行い、このような機能を行うプロトコル再構成装置２００を「Ｒｅｄｕｃｅｄ Ｆｕｎｃｔｉｏｎａｌ Ｐｒｏｔｏｃｏｌ Ｓｙｓｔｅｍ Ｄｅｖｉｃｅ」（以下、「ＲＦＤ」）と称する。
【００３７】
プロトコル再構成装置２００は、プロトコル実施部２１０及び再構成プロトコルスタック２３０を含む。
プロトコル実施部２１０は、自身と接続した対象装置から受信した、アプリケーションプログラムのための再構成されたプロトコルを実施するために必要な情報に基づいて、複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールの接続関係を決定する。ここで、アプリケーションプログラムのための再構成されたプロトコルを実施するために必要な情報は、再構成プロトコルスタック２３０に格納された複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールの接続関係に関連する情報を含んでもよい。
【００３８】
対象装置は、図１に基づいて説明したように、能動的にアプリケーションプログラムのプロトコルを再構成できるプロトコル再構成装置１００、又はこれに類似する機能を有する装置であってもよい。
アプリケーションプログラムのための再構成されたプロトコルを実施するために必要な情報は、アプリケーションプログラムのための再構成されたプロトコル、再構成されたプロトコルのための運用パラメータを含むプロトコル構成情報、及び少なくとも１つのコンポーネントモジュールの接続関係に関連する情報の内の少なくとも１つを含んでもよい。
【００３９】
再構成プロトコルスタック２３０は、複数のコンポーネントモジュールのスタックが格納されたメモリを含む。
再構成プロトコルスタック２３０の動作は、図１に示す再構成プロトコルスタック１７０と同一であるため、該当部分に対する説明を参照する。
【００４０】
図３は、図１に示すプロトコル再構成装置がアプリケーションプログラムのプロトコルを再構成する方法をを説明するためのフローチャートである。
プロトコル再構成装置１００は、複数のコンポーネントモジュールのスタックが格納されたメモリを保持する（ステップＳ３０１）。
プロトコル再構成装置１００は、アプリケーションプログラムの要求情報及びプロトコルレイヤから取得したシステム情報を分析する（ステップＳ３０３）。
【００４１】
ステップＳ３０３において、プロトコル再構成装置１００は、アプリケーションプログラムで、アプリケーションプログラムの要求情報に関連するイベント（例えば、Ａｓｓｏｃｉａｔｉｏｎなど）が発生するか否かに基づいてアプリケーションプログラムの要求情報を取得してもよい。
【００４２】
プロトコル再構成装置１００は、ステップＳ３０３における分析結果に基づいてプロトコル構成情報を決定する（ステップＳ３０５）。
プロトコル構成情報は、アプリケーションプログラムのための再構成されたプロトコル及び再構成されたプロトコルのための運用パラメータを含む。
プロトコル再構成装置１００は、例えば、ランタイムソルバー（Ｒｕｎ−ｔｉｍｅ ｓｏｌｖｅｒ）又はプロトコルデータベース（Ｐｒｏｔｏｃｏｌ Ｄａｔａｂａｓｅ）を用いてプロトコル構成情報を決定してもよい。
【００４３】
プロトコル再構成装置１００がランタイムソルバーを用いてプロトコル構成情報を決定する方法は次の通りである。
プロトコル再構成装置１００は、複数のプロトコルそれぞれに対するＱｏＳ指標をプロトコルレイヤから取得可能なパラメータと運用パラメータの関数で定義する。
その後、プロトコル再構成装置は、定義された関数をアプリケーションプログラムの要求情報に対応するように数式化する。
プロトコル再構成装置１００は、アプリケーションプログラムの要求情報を満足するために再構成されたプロトコルのＱｏＳ指標を最適化させる運用パラメータを決定する。
【００４４】
また、プロトコル再構成装置１００がプロトコルデータベースをソルバーとして用いてプロトコル構成情報を決定する方法は次の通りである。
まず、プロトコル再構成装置１００は、プロトコルデータベースを保持する。
プロトコルデータベースは、ステップＳ３０３における分析結果を含む情報を複数のプロトコルそれぞれに適用して決定した再構成されたプロトコル及び再構成されたプロトコルのための運用パラメータを格納する。
【００４５】
その後、プロトコル再構成装置１００は、プロトコルデータベースを参照してアプリケーションプログラムの要求情報に対応してマッピングされているプロトコルと該当運用パラメータを再構成されたプロトコル及び運用パラメータとして決定する。
上述したランタイムソルバー又はプロトコルデータベースを用いてプロトコル構成情報を決定する方法については、図７〜図８を参照して詳細に後述する。
【００４６】
プロトコル再構成装置１００は、プロトコル構成情報により、再構成されたプロトコルを実施するために複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールの接続関係を決定する（ステップＳ３０７）。
プロトコル再構成装置１００は、自身のプロトコルを再構成するか、そうでなければ、自身と接続した対象装置のプロトコルを再構成するかに応じて動作が変わり得る。
プロトコル再構成装置１００がいずれかのプロトコルを再構成するかによって変化する動作については図９〜図１１を参照して詳細に後述する。
【００４７】
図４は、図２に示すプロトコル再構成装置がアプリケーションプログラムのプロトコルを再構成する方法をを説明するためのフローチャートである。
プロトコル再構成装置２００は、複数のコンポーネントモジュールのスタックが格納されたメモリを保持する（ステップＳ４０１）。
プロトコル再構成装置２００は、自身と接続した対象装置からアプリケーションプログラムのための再構成されたプロトコルを実施するために必要な情報を受信する（Ｓ４０３）。
【００４８】
アプリケーションプログラムのための再構成されたプロトコルを実施するために必要な情報は、アプリケーションプログラムのための再構成されたプロトコル、再構成されたプロトコルのための運用パラメータを含むプロトコル構成情報、及び少なくとも１つのコンポーネントモジュールの接続関係に関連する情報のうち少なくとも１つを含んでもよい。
ここで、アプリケーションプログラムのための再構成されたプロトコルを実施するために必要な情報が符号化された形態で受信されれば、プロトコル再構成装置２００は、該当情報を解釈した後に利用してもよい。
【００４９】
プロトコル再構成装置２００は、再構成されたプロトコルを実施するために必要な情報に基づいて複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールの接続関係を決定する（ステップＳ４０５）。
【００５０】
図５は、本発明の一実施形態に係るアプリケーションプログラムのプロトコルを再構成する装置を含むプロトコル再構成システムにおける装置間の動作を説明するための図である。
プロトコル再構成システムは、能動モードで動作するプロトコル再構成装置（例えば、ＦＦＤ）５３０と対象装置（例えば、ＲＦＤ）５５０を含む。
【００５１】
図５に示す要素間の数字（１）〜（７）は、プロトコル再構成装置の各要素間のメッセージ伝達順序を示す。
装置間の動作は次の通りである。
分析部５３１は、アプリケーションプログラム５２０から、アプリケーションプログラム又は自身と接続したセンサノードの要求情報及びプロトコルレイヤからシステム情報を取得する（１）。また、分析部５３１は、再構成プロトコルスタック５３７からネットワーク情報も取得してもよい（１）。
【００５２】
ここで、アプリケーションプログラム５２０は、プロトコル再構成装置（ＦＦＤ）５３０の内部にインストールされたアプリケーションプログラムであるか、又は、対象装置（ＲＦＤ）５５０で駆動されるアプリケーションプログラムであってもよい。
【００５３】
分析部５３１は、取得した情報を分析してその結果及び取得した情報をプロトコルエンジン５３３に提供する（２）。
プロトコルエンジン５３３は、分析部５３１における分析結果に基づいてプロトコル構成情報を決定する。
プロトコル構成情報は、アプリケーションプログラム５２０のための再構成されたプロトコル及び再構成されたプロトコルのための運用パラメータを含む。
【００５４】
プロトコルエンジン５３３は、プロトコル構成情報をプロトコル実施部５３５に提供する（３）。
プロトコル実施部５３５は、プロトコル構成情報により再構成されたプロトコルを実施するために再構成プロトコルスタック５３７に格納された複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールの接続関係を決定する。
ここで、再構成プロトコルスタック５３７は、複数のコンポーネントモジュールのスタックが格納されたメモリを保持する。
【００５５】
プロトコル実施部５３５は、少なくとも１つのコンポーネントモジュールの接続関係に関連する情報を再構成プロトコルスタック５３７に送信する（４）。
それにより、再構成プロトコルスタック５３７は、該当情報を用いて少なくとも１つのコンポーネントモジュールを接続し、これによって再構成されたプロトコルが実施される。
【００５６】
この後、再構成プロトコルスタック５３７は、自身に接続した対象装置（ＲＦＤ）５５０にアプリケーションプログラムのための再構成されたプロトコルを実施するために必要な情報を送信する（５）。
【００５７】
対象装置のプロトコル再構成装置（ＲＦＤ）５５０の再構成プロトコルスタック５５７は、プロトコル再構成装置（ＦＦＤ）５３０の再構成プロトコルスタック５３７が送信した情報（アプリケーションプログラムのための再構成されたプロトコルを実施するために必要な情報）を受信してプロトコル実施部５５５に伝達する（６）。
【００５８】
プロトコル実施部５５５は、アプリケーションプログラムのための再構成されたプロトコルを実施するために必要な情報に基づいて、複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールの接続関係を決定する。
プロトコル実施部５５５は、接続関係に関連する情報を再構成プロトコルスタック５５７に通知する（７）。
【００５９】
再構成プロトコルスタック５５７は、接続関係に関連する情報により複数のコンポーネントモジュールのうち、再構成プロトコルを実施するために必要な少なくとも１つのコンポーネントモジュールを接続して対象装置５５０で再構成プロトコルが実施されるようにする。
【００６０】
図６は、本発明の他の実施形態に係るアプリケーションプログラムのプロトコルを再構成する装置を含むプロトコル再構成システムにおける装置間の動作を説明するための図である。
図６に示すプロトコル再構成システムは、能動モードで動作するプロトコル再構成装置（例えば、ＦＦＤ）６３０と対象装置（ここでは、受動モードで動作するプロトコル再構成装置（例えば、ＦＦＤ））６５０を含む。
【００６１】
図６において、能動モードで動作するプロトコル再構成装置（ＦＦＤ）６３０の動作は、図５に示すプロトコル再構成装置（ＦＦＤ）５３０の動作と同一である。
また、受動モードで動作するプロトコル再構成装置（ＦＦＤ）６５０は、プロトコルを決定するために関与する分析部６５１とプロトコルエンジン６５３の機能が非活性化されるだけであって、残りのプロトコル実施部６５５及び再構成プロトコルエンジン６５７の動作は図５に示すプロトコル再構成装置（ＲＦＤ）５５０と同一である。
すなわち、受動モードで動作するプロトコル再構成装置（ＦＦＤ）６５０は、機能上、図５に示す対象装置５５０のＲＦＤと同一に動作する。
したがって、図６で各構成要素の動作は、図５に示す説明を参照する。
【００６２】
図７は、本発明の一実施形態に係るランタイムソルバー（ｒｕｎ−ｔｉｍｅ ｓｏｌｖｅｒ）を用いてプロトコルエンジンを実現する方法を説明するための図である。
図７においてプロトコルエンジン７３０は、エージェント７３１とランタイムソルバー７３５を含む。
【００６３】
エージェント７３１は、分析部７１０が取得した情報及び分析した情報を受信し、該当情報に基づいて周期的にランタイムソルバー７３５の動作をトリガー（ｔｒｉｇｇｅｒ）する。さらに、エージェント７３１は、ランタイムソルバー７３５の動作による結果をプロトコル実施部７５０に伝達する。
ランタイムソルバー７３５は、アプリケーションプログラムのための最適のプロトコル（ここでは、再構成されたプロトコル）が何であるかをリアルタイムに確認し、該当プロトコルのための運用パラメータを決定する。
【００６４】
ランタイムソルバー７３５は、アプリケーションプログラムのための再構成されたプロトコル、再構成されたプロトコルを実施するために必要な少なくとも１つのコンポーネントモジュール、及び再構成されたプロトコルのための運用パラメータなどを決定する。
ランタイムソルバー７３５を用いて実現したプロトコルエンジン７３０は、モデリング部７３５３とアルゴリズム部７３５６を含む。
【００６５】
モデリング部７３５３では複数のプロトコルそれぞれに対するＱｏＳ指標をプロトコルレイヤから取得可能なパラメータ（より詳しくは、分析部７１０から取得可能なパラメータと運用パラメータ）の関数で定義する。
そして、該当関数をアプリケーションプログラムの要求情報又はアプリケーションプログラムの目的に適するように数式化してモデリングする。
例えば、アプリケーションプログラムの要求情報で「ｒｅｌｉａｂｉｌｉｔｙ」と「ｄｅｌａｙ」に対する要求事項があって、ユーザがアプリケーションプログラムのエネルギーを最小化することを所望すると仮定する。ここで、プロトコルエンジン７３０（より詳しくは、モデリング部７３５３）はアプリケーションプログラムの要求情報に基づいて、数式化されたＱｏＳ指標を用いてエネルギーを最小化するための最適化の問題を数式化する。
【００６６】
図７に示すモデリング部７３５３に示す例では、プロトコル再構成装置を含む装置（又は、角度センサノード及びアプリケーションプログラム）のＱｏＳ指標がシステム情報（ＳＰ１、．．．、ＳＰｉ）、ネットワーク情報（ＮＰ１、．．．、ＮＰｊ）、再構成プロトコルスタック（図示せず）を構成する少なくとも１つのコンポーネントモジュール（ＣＯ１、．．．、ＣＯｋ）及び再構成されたプロトコルを実施するために選択された少なくとも１つのコンポーネントモジュールから得られる再構成されたプロトコルのための運用パラメータ（ＣＶ１、．．．、ＣＶｋ）の関数で数式化されることが分かる。
ここで、ＱｏＳ指標としては、Ｅｎｅｒｇｙ（Ｅｉ）、Ｒｅｌｉａｂｉｌｉｔｙ（Ｒｉ）、Ｄｅｌａｙ（Ｄｉ）などが一例として挙げられる。
【００６７】
プロトコルエンジン７３０は、上述した動作によってアプリケーションプログラムの目的によりＱｏＳ指標を最適化させる。
プロトコルエンジン７３０は、アプリケーションプログラムの要求情報、システム情報、ネットワーク情報に対する値を分析部７１０から取得した後、モデリング部７３５３によって定義された数式に入力する。
プロトコルエンジン７３０は、アプリケーションプログラムの要求情報を満足する範囲内で再構成されたプロトコルのＱｏＳ指標を最適化させる運用パラメータを決定する。
【００６８】
この工程は、アルゴリズム部７３５６によって行われる。
アルゴリズム部７３５６は、モデリング部７３５３によって数式化された最適化の問題により適切なアルゴリズムを選択、又は開発（ｄｅｖｅｌｏｐ）して、アプリケーションプログラムのプロトコル再構成装置にてこのアルゴリズムを実施する。
図７に示すように、アルゴリズム部７３５６では整数プログラミング（ｉｎｔｅｇｅｒ ｐｒｏｇｒａｍｍｉｎｇ）に対する解決方法のうち１つの分枝限定法（ｂｒａｎｃｈ ａｎｄ ｂｏｕｎｄ）アルゴリズムを用いることができる。
【００６９】
図８は、本発明の一実施形態に係るプロトコルデータベースを用いてプロトコルエンジンを実施する方法を説明するための図である。
プロトコルデータベースを用いてプロトコルエンジンを実施するときにもエージェント８３１は、図７と同様に動作してもよい。
すなわち、エージェント８３１は、分析部８１０が取得した情報を受信し、該当情報に基づいて周期的にプロトコルデータベース８３５の動作をトリガー（ｔｒｉｇｇｅｒ）する。さらに、エージェント８３１は、プロトコルデータベース８３５によって決定された結果をプロトコル実施部８５０に伝達する。
【００７０】
プロトコルエンジン８３０を実現するためにプロトコルデータベースを用いるときにも、ランタイムソルバー７３５と同様にモデリング部８３５３によってモデリングを行う。
ただし、プロトコルデータベース８３５を用いるときには、アルゴリズム部７３５６に代って外部パラメータに対する最適のプロトコルと該当プロトコルのための運用パラメータを（アルゴリズムによって）予め算出し、その結果をデータベース８３５６化することが異なる。
ここで、外部パラメータでは、オフライン上で取得可能なアプリケーションプログラムの要求情報、システム情報及びネットワーク情報などが例として挙げられる。
【００７１】
すなわち、分析部８１０が取得した情報（例えば、アプリケーションプログラムの要求情報）を受信したプロトコルエンジン８３０ではプロトコルデータベース８３５を参照して該当情報に対応してマッピングされている最適のプロトコルと該当運用パラメータを確認する。
プロトコルエンジン８３０は、確認した結果を再構成されたプロトコルと該当運用パラメータでプロトコル実施部８５０に送信する。
【００７２】
プロトコルデータベースを用いてプロトコルエンジン８３０を実現する方法は、プロトコル再構成装置の算出能力がランタイムソルバーを運用するに不都合な場合に効果的である。
また、プロトコルデータベースを用いてプロトコルエンジン８３０を実現する方法は、比較的に静的であり単純な環境により運用パラメータや再構成されたプロトコルの運用範囲が広い必要がない場合にも効果的である。
【００７３】
図９は、本発明の一実施形態に係るアプリケーションプログラムのプロトコルを再構成する装置において、能動モードで動作するプロトコル実施部の構成を示すブロック図であり、図１０は、図９の能動モードでのプロトコル実施部の動作を説明するためのフローチャートである。
プロトコル実施部９５０は、プロトコルエンジン９３０から受信したプロトコル構成情報を解釈し、プロトコル構成情報により再構成されたプロトコルをプロトコルレイヤで実施できるようにする。ここで、プロトコル構成情報は、プロトコルエンジン９３０が分析部９１０から受信した情報に基づいて決定したものである。
【００７４】
すなわち、プロトコル実施部９５０は、プロトコル構成情報により再構成されたプロトコルを実施するために、再構成プロトコルスタック９７０に含まれた複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールの接続関係を決定する。
プロトコル実施部９５０は、プロトコル再構成装置の役割により異なる動作を行う。すなわち、プロトコル再構成装置がＦＦＤの役割を行うときと、ＲＦＤの役割を行うときにプロトコル実施部９５０の構成要素及びその動作が異なる。
また、プロトコル実施部９５０は、自分のプロトコルを再構成するために必要な情報を生成するときと、自身と接続した対象装置で再構成されたプロトコルを実施するために必要な情報を生成するときの動作が異なる。
【００７５】
図９では、ＦＦＤで動作するプロトコル再構成装置９００と、ＲＦＤで動作するプロトコル再構成装置９９０の２つのプロトコル再構成装置を示している。
ここで、プロトコル再構成装置９９０は、プロトコル再構成装置９００に接続された対象装置の役割を行う。
【００７６】
ＦＦＤで動作するプロトコル再構成装置９００が自身のプロトコルを再構成する場合、プロトコル実施部９５０は、プロトコル構成情報に基づいて少なくとも１つのコンポーネントモジュールの間の接続関係に関連する情報を生成し、これによって再構成されたプロトコルが実施されるようにする。
少なくとも１つのコンポーネントモジュールの接続関係に関連する情報は、プロトコルＩＤ、コンポーネント情報、及びパラメータ値を含む。もし、プロトコル再構成装置９００が必要なコンポーネントモジュールを含んでいない場合には、少なくとも１つのコンポーネントモジュールの接続関係に関連する情報は「ＥＬＦ ｆｏｒｍａｔ」のコンポーネントモジュールのコードをさらに含んでもよい。
【００７７】
プロトコル再構成装置９００において、プロトコル実施部９５０は、実施部エージェント９５１、プロトコルアップデータ９５２、コンポーネントライブラリー９５３及びノードステートデータベース９５４を含む。また、プロトコル実施部９５０は、プロトコルパーサー９５５及びプロトコルエンコーダ９５６をさらに含んでもよい。
プロトコルパーサー９５５は、プロトコル再構成装置９００がＦＦＤで動作するときには利用されない。
プロトコルエンコーダ９５６は、プロトコル実施部９５０が再構成プロトコルスタック９７０に送信する情報（例えば、少なくとも１つのコンポーネントモジュールの接続関係に関連する情報）を符号化するときのみ用いられる。
【００７８】
実施部エージェント９５１は、プロトコルエンジン９３０から受信したプロトコル構成情報に基づいて、自身と接続した対象装置（ここでは、プロトコル再構成装置（ＲＦＤ）９９０）で再構成されたプロトコルを実施するために必要な情報を生成する。
図１０は、実施部エージェント９５１が行う動作を説明するためのフローチャートを示す。
実施部エージェント９５１が自分のプロトコルを再構成するために必要な情報を生成するときの動作はステップＳ１００１〜Ｓ１００３の工程である。
【００７９】
実施部エージェント９５１は、自身のプロトコルを再構成するか否かを判断する（ステップＳ１００１）。
ステップＳ１００１の判断結果、自身のプロトコルを再構成しなければならない必要があれば、実施部エージェント９５１はプロトコルアップデータ９５２に関連情報（ここでは、少なくとも１つのコンポーネントモジュールの接続関係に関連する情報）を送信する（ステップＳ１００３）。
少なくとも１つのコンポーネントモジュールの接続関係に関連する情報はプロトコルＩＤ（Ｐｒｏｔｏｃｏｌ ＩＤ）、少なくとも１つのコンポーネントモジュールに関する情報（Ｃｏｍｐｏｎｅｎｔｓ Ｉｎｆｏ）及びパラメータ値（Ｐａｒａｍｅｔｅｒ Ｖａｌｕｅ）であってもよい。
【００８０】
もし、再構成プロトコルスタック９７０が再構成されたプロトコルを構成するために必要な少なくとも１つのコンポーネントモジュールを含んでいなければ、実施部エージェント９５１は、プロトコルアップデータ９５２に少なくとも１つのコンポーネントモジュールのコードを送信してもよい。ここで、少なくとも１つのコンポーネントモジュールのコードは、例えば、ＥＬＦフォーマットで構成されてもよい。
プロトコルアップデータ９５２は、少なくとも１つのコンポーネントモジュールの接続関係に関連する情報を用いて再構成されたプロトコルを実施することができる。
図９に示す実線は、プロトコル実施部９５０が自身のプロトコルを再構成するときのメッセージの流れを示す。
【００８１】
ステップＳ１００１の判断結果、自身のプロトコルを再構成する必要がなければ、実施部エージェント９５１は、自身に接続した対象装置で再構成されたプロトコルを実施するためにノードステートデータベース９５４を参照する（ステップＳ１００５）。
その前に、実施部エージェント９５１は、自身と接続した対象装置（ここでは、プロトコル再構成装置９９０）が使用しているプロトコルと運用パラメータに関する情報を格納するノードステートデータベース（Ｎｏｄｅ ｓｔａｔｅ Ｄａｔａｂａｓｅ）９５４を保持する。
【００８２】
実施部エージェント９５１は、ノードステートデータベース９５４を参照してプロトコル構成情報により対象装置９９０で再構成されたプロトコルを実施するために必要な情報を生成する。実施部エージェント９５１は、生成された情報を再構成プロトコルスタック９７０によって対象装置９９０に送信する。
【００８３】
実施部エージェント９５１は、ノードステートデータベース９５４を参照して対象装置９９０が再構成されたプロトコルを実施するために必要な少なくとも１つのコンポーネントモジュールを含むか否かを判断する（ステップＳ１００７）。
ステップＳ１００７において、対象装置９９０が再構成されたプロトコルを実施するために必要な少なくとも１つのコンポーネントモジュールを含んでいないと判断されれば、実施部エージェント９５１はコンポーネントライブラリー９５３を参照する（ステップＳ１００９）。
【００８４】
コンポーネントライブラリー９５３は、再構成されたプロトコルを実施するために用いられる複数のコンポーネントモジュールに関する情報を含む。
実施部エージェント９５１は、コンポーネントライブラリー９５３を参照して必要な少なくとも１つのコンポーネントモジュールに関する情報を取得してメモリなどに記録する。ここで、少なくとも１つのコンポーネントモジュールに関する情報はＥＬＦフォーマットであってもよい。
この状態で対象装置９９０に送信する情報（すなわち、再構成されたプロトコルを実施するために必要な情報）の内容が確定される。
【００８５】
実施部エージェント９５１は、対象装置９９０に送信する情報のロバスト性（ｒｏｂｕｓｔｎｅｓｓ）のために、該当情報に対する符号化が必要であるか否かを判断する（ステップＳ１０１１）。
実施部エージェント９５１は、該当情報に対する符号化が必要であると判断されれば、プロトコルエンコーダ９５６によって該当情報に対する符号化を行う（ステップＳ１０１３）。
【００８６】
一方、ステップＳ１０１１で、もし、該当情報に対する符号化が必要ではないと判断されれば、実施部エージェント９５１は再構成プロトコルスタック９７０によって無線で該当情報を送信する（ステップＳ１０１５）。
ステップＳ１０１３において、符号化された該当情報も同様に再構成プロトコルスタック９７０によって無線で該当情報を送信する（ステップＳ１０１５）。
【００８７】
図９に示す点線は、プロトコル実施部９５０が対象装置９９０で再構成されたプロトコルを実施するための情報を生成するときのメッセージの流れを示す。
ＲＦＤで動作するプロトコル再構成装置９９０は、プロトコル実施部９９１及び再構成プロトコルスタック９９５を含む。
プロトコル実施部９９１は、情報解釈を行うプロトコルパーサー９９１１と解釈された結果を行うプロトコルアップデータ９９１３を含む。
【００８８】
ＲＦＤで動作するプロトコル再構成装置９９０のプロトコル実施部９９１は、ＦＦＤで動作するプロトコル再構成装置が受動モードで動作するときのプロトコル実施部とその構成及び動作が一致する。
したがって、以下では図１１を参照してＲＦＤで動作するプロトコル再構成装置９９０のプロトコル実施部９９１の動作について説明する。
【００８９】
図１１は、本発明の一実施形態に係るアプリケーションプログラムのプロトコルを再構成する装置がＲＦＤで動作するときのプロトコル実施部１１１０の動作を説明するための図である。
ＲＦＤで動作するプロトコル再構成装置１１００は、プロトコルパーサー１１１３とプロトコルアップデータ１１１６を含む。プロトコルパーサー１１１３は、ＦＦＤで動作するプロトコル再構成装置がプロトコルエンコーダを用いて情報を符号化した場合にのみ活性化する。
【００９０】
ＲＦＤで動作するプロトコル再構成装置１１００がＦＦＤで動作するプロトコル再構成装置から受信した情報（例えば、プロトコル再構成装置１１００でアプリケーションプログラムのための再構成されたプロトコルを実施するために必要な情報）は、下位の再構成プロトコルスタック１１３０を介してプロトコルパーサー１１１３に伝達される。
プロトコルパーサー１１１３は、該当情報を解釈してプロトコルアップデータ１１１６に送信する。
プロトコルアップデータ１１１６は、解釈された該当情報により再構成されたプロトコルをプロトコル再構成装置１１００で実施されるように複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールの接続関係を決定する。
【００９１】
プロトコルアップデータ１１１６は、上述した接続関係に関連する情報を再構成プロトコルスタック１１３０に送信し、該当情報により少なくとも１つのコンポーネントモジュールを接続する。ここで、プロトコルアップデータ１１１６が再構成されたプロトコルを実施するために再構成プロトコルスタック１１３０に送信する情報は、再構成プロトコルスタック１１３０の実現方法によって変わり得る。
【００９２】
図１２は、本発明の一実施形態に係るプロトコル実施部が構成テーブルを用いて再構成されたプロトコルを実施する方法を説明するための図である。
符号１２１０は一般的なコンポーネントモジュール構造を示し、符号１２３０は構成テーブルを用いて再構成されたプロトコルを実施することを示す。
【００９３】
符号１２３０でプロトコル実施部は、構成テーブル（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｔａｂｌｅ）１２３３を用いて少なくとも１つのコンポーネントモジュールを接続することによって、再構成されたプロトコルをリアルタイムで実施する。
ここで、構成テーブル１２３３は、再構成されたプロトコルを実施するために必要な少なくとも１つのコンポーネントモジュールそれぞれのアドレスを含む。また、構成テーブル１２３３は、再構成されたプロトコルを実施するために必要な少なくとも１つのコンポーネントモジュールにアクセスできるようにルーティングする機能も含んでもよい。
【００９４】
したがって、該当コンポーネントモジュールを呼び出す同一名の関数が数個のプロトコルに複数存在するとしても、構成テーブル１２３３は必要なコンポーネントモジュールのアドレスを直ちにアクセスすることができる。
ここで、プロトコルアップデータは、再構成プロトコルスタックに少なくとも１つのコンポーネントモジュールのＩＤを通知する。
【００９５】
図１３は、一実施形態に係るプロトコル実施部がメッセージフッキング（ｍｅｓｓａｇｅ ｈｏｏｋｉｎｇ）を用いて再構成されたプロトコルを実施する方法を説明するための図である。
図１３に示すように、アプリケーションプログラムレイヤ１３１０の下位に構成レイヤ１３２０を備える。
ここで、プロトコル実施部は、構成レイヤ１３２０によって下位のＭＡＣレイヤ１３３０に送信されるメッセージをフッキングしてプロトコルのＩＤを取得する。
【００９６】
プロトコル実施部は、フッキングしたメッセージから取得したプロトコルのＩＤに基づいて、再構成プロトコルを実施するための少なくとも１つのコンポーネントモジュールをスイッチングする。
ここで、プロトコルアップデータは、再構成プロトコルスタックに再構成プロトコルに該当するプロトコルＩＤを通知する。
【００９７】
以下は、上述した方法を用いて１台のＦＦＤに接続したＲＦＤが１台から３台に動的に変化する場合にプロトコル再構成システムの動作について説明する。
まず、ＲＦＤが１台である場合を＜実施形態１＞、ＲＦＤが３台である場合を＜実施形態２＞に分類して、各実施形態の動作を詳しく説明する。
＜実施形態１＞において、１台のＦＦＤではＴＤＭＡプロトコルを使用していると仮定する。
【００９８】
＜実施形態１＞
ＲＦＤ１は、実行中である体温測定のためのアプリケーションプログラムを実行するためにＦＦＤとの接続を試みる。
ここで、ＲＦＤ１が実行しようとするアプリケーションプログラムの要求情報は下記に示す表１の通りである。
【００９９】
【表１】
表１でＳａｍｐｌｉｎｇ ｒａｔｅは、データパケットの生成率を示し、Ｒｅｌｉａｂｉｌｉｔｙはパケット損失率（ｐａｃｋｅｔ ｌｏｓｓ ｒａｔｅ）を示す。
表１で考慮されるアプリケーションプログラムの要求情報は、Ｒｅｌｉａｂｉｌｉｔｙとｌａｔｅｎｃｙである。
【０１００】
ＦＦＤは、アプリケーションプログラムの要求情報を様々な方式によって取得してもよい。例えば、ＦＦＤで初期アプリケーションプログラムのセットアップのとき、アプリケーションプログラムに予め格納された要求情報に対するデフォルト値をアクセスしたり、ＲＦＤ１とのＡｓｓｏｃｉａｔｉｏｎ実行工程で該当情報をｉｎ−ｂａｎｄ ｓｉｇｎａｌｉｎｇのような方法によってＲＦＤから伝達されてもよい。
【０１０１】
＜実施形態１＞での分析部の動作
分析部は、プロトコルエンジンでのモデリングに用いられる全てのパラメータ値に関する情報を保持及び／又は更新する。分析部はアプリケーションプログラムの要求情報に関連するイベント（例えば、ａｓｓｏｃｉａｔｉｏｎ）の発生時にアプリケーションプログラムの要求情報を取得する。
その他にも、分析部は、必要な場合にのみＰＨＹレイヤ又はＭＡＣレイヤからパケットエラー率（ｐａｃｋｅｔ ｅｒｒｏｒ ｒａｔｅ）及び接続ノードの数などのような情報を取得する。
【０１０２】
分析部は、取得した情報を一括的あるいは選別的にプロトコルエンジンに伝達することができ、分析部が取得した情報の一括的あるいは選別的な伝達の有無はプロトコルエンジンとのインターフェースの設計時に決定される。
本実施形態では、アプリケーションプログラムの要求情報及びプロトコル再構成装置に接続したノード（装置またはセンサなど）の数に対するアップデートされた情報が発生する場合のみ分析部がプロトコルエンジンに該当値を伝達するものとする。
【０１０３】
すなわち、分析部は、アプリケーションプログラムの要求情報及びプロトコル再構成装置に接続したノード（装置またはセンサなど）の数に対するアップデートされた情報が発生する場合にＤｅｖｉｃｅ ＩＤ、Ｒｅｌｉａｂｉｌｉｔｙ ｒｅｑｕｅｓｔ、Ｌａｔｅｎｃｙ ｒｅｑｕｅｓｔ、ｎｕｍｂｅｒ ｏｆ ｎｏｄｅ形態の情報をプロトコルエンジンに送信する。
したがって、＜実施形態１＞において分析部は、ＲＦＤ１に対する要求情報をプロトコルエンジンに送信する。ここで、ＲＦＤ１に対する要求情報は、例えば、Ｄｅｖｉｃｅ ＩＤ：１、Ｒｅｌｉａｂｉｌｉｔｙ ｒｅｑｕｅｓｔ：５、Ｌａｔｅｎｃｙ ｒｅｑｕｅｓｔ：ｎ／ａ、ｎｕｍｂｅｒ ｏｆ ｎｏｄｅ：１であってもよい。
【０１０４】
＜実施形態１＞でのプロトコルエンジンの動作
分析部から情報を受信したプロトコルエンジンのエージェントは、情報を受信するときごとに実行されるイベントベースの方法、あるいは一定周期ごとにトリガーさせる周期ベースの方法などを用いてソルバーをトリガーする。
上述したように、ソルバーは複数のプロトコルごとに対するモデリングを行うモデリング部と、複数のプロトコルごとに対するモデルに対する解を取得するアルゴリズム部で構成される。
【０１０５】
本実施形態では、ＦＦＤがＸ−ＭＡＣ、Ｐｕｒｅ−ＴＤＭＡ、及びＢａｓｅ Ｐｒｏｔｏｃｏｌの３種類のプロトコルを保有していると仮定する。
ここで、Ｂａｓｅ Ｐｒｏｔｏｃｏｌは、ＲＦＤ１とＦＦＤとのａｓｓｏｃｉａｔｉｏｎのためのコントロール情報の送受信を支援するプロトコルである。
したがって、モデリング部は、実際的なデータ送信の過程を支援するプロトコルのＸ−ＭＡＣとＰｕｒｅ−ＴＤＭＡに対するモデリングを行う。
【０１０６】
Ｘ−ＭＡＣプロトコルの動作は次の通りである。
Ｘ−ＭＡＣは、データを送信しようとする送信装置（ｓｅｎｄｅｒ）がストローブ（ｓｔｒｏｂｅ）と呼ばれる小さいパケットに受信装置（ｒｅｃｅｉｖｅｒ）のアドレスを記載して送信する。
受信装置は、スリップモード（ｓｌｅｅｐ ｍｏｄｅ）から一定周期ごとに起動して自身のアドレスが記載されたストローブパケットがあるか否かをチェックする。
もし、自身のアドレスが記載されたストローブパケットがあれば、受信装置はＡＣＫパケットを送信装置に送信する。
【０１０７】
送信装置は、ＡＣＫパケットを受信すると同時に即受信装置にデータを送信する。
受信装置は、データを全て受信した後、直ちにスリップモードに入ることなく、一定時間起動して他のノードからのデータを待機する。
受信装置のこのような動作は、送信装置のストローブパケット送信を減らしてエネルギーを節減することができる。
【０１０８】
受信装置に送信するデータがあるものの、他のノードが送信していることを検出した場合に、送信装置は一定期間をバックオフ（ｂａｃｋ−ｏｆｆ）して待機する。
送信装置は、一定期間が完了すれば、直ちに受信装置にデータを送信する。
ここで、受信装置が起動している時間は最大バックオフ時間よりも大きくなければならない。
【０１０９】
Ｐｕｒｅ−ＴＤＭＡの動作は次の通りである。
Ｐｕｒｅ−ＴＤＭＡで受信装置と送信装置との間の送信順序が決定されて、送信するデータはタイムスロット（ｔｉｍｅ ｓｌｏｔ）に基づいて送信される。
そのために受信装置は、周期的にビーコン信号を送信して自身と送信装置の間の同期を合わせて割り当てられたタイムスロットを通知する。
【０１１０】
受信装置は、送信装置にデータ送信のために１つのタイムスロットを割り当て、決定したタイムスロットにのみ送信を許諾する。
このように送信のために割り当てられたタイムスロットを活性期間（ａｃｔｉｖｅ ｐｅｒｉｏｄ）という。
活性期間の後に、ノードはスリップ期間の間にスリップモードに入る。このスリップモードは、送信装置のビーコン送信時点の直前に終了する。
【０１１１】
プロトコルエンジンは、上述した２種類のプロトコルを用いて通信を行うときに発生するエネルギー及びＱｏＳ指標（ＲｅｌｉａｂｉｌｉｔｙとＬａｔｅｎｃｙ）を予測して数学的モデリングを行う。
モデリング部は、運用パラメータ及びアプリケーションプログラムの要求情報などを用いるが、このときにプロトコルの動作を理解してこれに基づいて各指標を数式化してもよい。
【０１１２】
例えば、Ｘ−ＭＡＣの場合、パケットを生成する間に必要とされるエネルギーを受信装置のスリップ周期（Ｒｓ）と他の送信装置がデータを送信しているとき、待機しなければならないバックオフ期間（Ｓｂｏ）のエネルギー関数に示してもよい。
したがって、この２つのパラメータがＸ−ＭＡＣの運用パラメータであってもよい。アプリケーションプログラムの要求情報に該当するＬａｔｅｎｃｙ及びＲｅｌｉａｂｉｌｉｔｙも受信装置のスリップ周期（Ｒｓ）及びバックオフ期間（Ｓｂｏ）の関数に示してもよい。
【０１１３】
また、ＴＤＭＡの場合、エネルギー関数は活性期間及びスリップ期間を構成する総タイムスロットの個数であるＮｆｒａｍｅの関数に表わしてもよく、ここで、Ｎｆｒａｍｅは運用パラメータであってもよい。
プロトコルエンジンは、各プロトコルごとのモデルに対して運用パラメータの最適値とそれによるエネルギー消耗を比較して最適のプロトコルを選択する。
【０１１４】
プロトコルエンジンのアルゴリズム部は、例えば、エネルギーの最小化問題をそれぞれ解決して各プロトコルの目的値を比較し、最小のエネルギー費用を有するプロトコルとそのときの運用パラメータを最適プロトコル及び運用パラメータとして決定する。
アルゴリズム部は、プロトコル問題が有している変数特性などに基づいて設計されるべきであるが、本実施形態ではプロトコルが有する運用パラメータが整数値を有すると仮定し、これに対する一般的な解を求める分枝限定法（ｂｒａｎｃｈ ａｎｄ ｂｏｕｎｄ）アルゴリズムを選択してもよい。
【０１１５】
＜実施形態１＞でのプロトコル実施部の動作：ＦＦＤ側
プロトコルエンジンのエージェントは、例えば、最適のプロトコルがＸ−ＭＡＣであり、最適の（システム）パラメータがＲｓ：９、Ｓｂｏ：１０ｍｓであることをプロトコル実施部の実施部エージェントに伝達する。
実施部エージェントは、ＦＦＤ自身のプロトコルを再構成するために取得した情報をプロトコルアップデータに伝達する。
プロトコルアップデータは、再構成されたプロトコルを実施するためにプロトコルスタックに関連情報を伝達する。
【０１１６】
例えば、プロトコルを再構成するためにメッセージフッキング方法を用いると仮定する。
プロトコル実施部のプロトコルアップデータは、まず、関数呼出（ｆｕｎｃｔｉｏｎ ｃａｌｌ）によってＸ−ＭＡＣプロトコル上の最適のパラメータのＲｓとＳｂｏを調節する該当関数に最適値を設定することを要求する。
そして、応用レイヤ（Ａｐｐｌｉｃａｔｉｏｎ Ｌａｙｅｒ）で作られたデータは、プロトコルフィールドにＸ−ＭＡＣに該当するＩＤが設定された形態のメッセージでプロトコルスタックに伝達される。プロトコル実施部のアップデータは、下位のプロトコルスタックに伝達される直前に該当メッセージをフッキングして最適のプロトコルがＸ−ＭＡＣであることを確認し、Ｘ−ＭＡＣのためのコンポーネントモジュールにスイッチングする。
【０１１７】
また、実施部エージェントは、ＲＦＤ１で再構成されたプロトコルを実施できるようにする。
実施部エージェントは、まず、現在ＲＦＤ１のプロトコルの使用状況を把握するためにノードステートデータベースを参照する。ＲＦＤ１に該当するノードステートデータベース情報は下記に示す表２の通りである。
【０１１８】
【表２】
【０１１９】
ＲＦＤ１で現在に使用中であるプロトコルがＴＤＭＡであるため、ＲＦＤ１でのプロトコル再構成が必要であると判断した実施部エージェントは、ＲＦＤ１でＸ−ＭＡＣを実施するために足りない（プロトコル）コンポーネントモジュールがないかを確認する。
ここで、ＲＦＤ１がＸ−ＭＡＣを保有しているため、Ｘ−ＭＡＣのためのコンポーネントモジュールをもってくる動作は必要としない。したがって、実施部エージェントは再構成プロトコルスタックに、例えば、（最適のプロトコル、パラメータ値）＝（Ｘ−ＭＡＣ、（９，１０））（Ｒｓ、Ｓｂｏの順）のような情報を送信する。この情報は必要に応じて符号化が可能であり、実施部エージェントは再構成プロトコルスタックによって該当情報がＲＦＤ１に無線に送信される。
【０１２０】
＜実施形態１＞でのプロトコル実施部の動作：ＲＦＤ側
ＲＦＤ１の再構成プロトコルスタックは、関連情報（例えば、Ｘ−ＭＡＣ、（９、１０））を受信してＲＦＤ１のプロトコル実施部に伝達する。
ここで、関連情報が符号化されていれば、プロトコル実施部は、プロトコルパーサーによってこれを復元してプロトコルアップデータに伝達する。
関連情報が伝達されたプロトコルアップデータの動作は、上述したＦＦＤのプロトコルアップデータの動作と同一である。
【０１２１】
＜実施形態２＞
以下は、ＲＦＤ１と通信していたＦＦＤにＲＦＤ２とＲＦＤ３が新しく接続要求をした動的な状況におけるシステム動作を説明する。
＜実施形態１＞と相当の部分が類似するため、相異する点のみを説明する。
【０１２２】
新たに接続要求したＲＦＤ２及びＲＦＤ３のアプリケーションプログラム及びその特性は下記に示す表３の通りである。
【表３】
【０１２３】
＜実施形態１＞の場合と同様に＜実施形態２＞でも分析部は３つのＲＦＤ（アプリケーションプログラム）に対するサービス品質情報と接続したセンサノードの数などのような情報をプロトコルエンジンに送信する。
【０１２４】
＜実施形態２＞でのプロトコルエンジンの動作
プロトコルエンジンは、３つの装置ＲＦＤ１、ＲＦＤ２、ＲＦＤ３のプロトコルを用いるときに消費されるエネルギーを送信装置の３つの装置のバックオフパラメータＳｂｏ１、Ｓｂｏ２、Ｓｂｏ３と受信装置であるＦＦＤのスリップ期間Ｒｓの関数に表わす。
また、プロトコルエンジンは、各装置のＱｏＳ指標も上述したパラメータに表わしてアプリケーションプログラムで要求される要求情報を満足するように数式化する。
ＴＤＭＡの場合、＜実施形態１＞と同様に、受信装置であるＦＦＤのパラメータであるＮｆｒａｍｅの関数に表わす。
【０１２５】
＜実施形態２＞でのプロトコル実施部の動作：ＦＦＤ側
プロトコルエンジンのエージェントは、最適のプロトコルがＴＤＭＡであり、最適のパラメータがＮＦｒａｍｅ：２０であることをプロトコル実施部の実施部エージェントに伝達する。
実施部エージェントは、ＦＦＤ自身のプロトコルを再構成するために取得した情報をプロトコルアップデータに伝達する。プロトコルアップデータは、再構成されたプロトコルを実施するためにプロトコルスタックに関連情報を伝達し、再構成されたプロトコルを行うように命令する。具体的な方法は＜実施形態１＞と同一である。
【０１２６】
実施部エージェントは、自身に接続した３つの装置ＲＦＤ１、ＲＦＤ２、ＲＦＤ３に対してプロトコル再構成を行う。
まず、実施部エージェントは、現在の３つの装置それぞれが用いるプロトコルを把握するためにノードステートデータベースを参照する。
【０１２７】
ノードステートデータベースは下記に示す表４のような情報を保有すると仮定する。
【表４】
【０１２８】
表４で実施部エージェントは、＜実施形態１＞と同様に、ＴＤＭＡを保有しているＲＦＤ１とＲＦＤ２には（最適プロトコル、パラメータ値）＝（ＴＤＭＡ、３０）の情報を再構成プロトコルスタックによって送信する。ここで、符号化が必要であれば、該当情報を符号化して送信してもよい。
ＲＦＤ３は、ＴＤＭＡを保有していないため、実施部エージェントは、ＴＤＭＡを実施するために必要なコンポーネントモジュールが何であるかをコンポーネントライブラリーを参照して確認する。
【０１２９】
例えば、必要なコンポーネントモジュールが３番であると仮定すると、実施部エージェントは（最適プロトコル、パラメータ値）＝（ＴＤＭＡ、３０）の情報と共に３番のコンポーネントモジュールを再構成プロトコルスタックに送信する。ここで、３番のコンポーネントモジュールはＥＬＦ形式を有し得る。
【０１３０】
＜実施形態２＞でのプロトコル実施部の動作：ＲＦＤ側
ＲＦＤ３のプロトコルスタックは、関連情報（ここでは（最適プロトコル、パラメータ値）＝（ＴＤＭＡ、３０）の情報及び３番のコンポーネントモジュール）を受信してＲＦＤ３のプロトコル実施部に伝達する。ここで、関連情報が符号化されていれば、ＲＦＤ３のプロトコル実施部はプロトコルパーサーを介して少なくとも１つのコンポーネントモジュール（ここでは、３番のモジュール）に関する情報とプロトコル構成情報を復元する。
【０１３１】
少なくとも１つのコンポーネントモジュールに関する情報に関する情報を確認すると、ＲＦＤ３のプロトコルアップデータはリンカー（Ｌｉｎｋｅｒ）に受信した３番のコンポーネントモジュールをリンクするというメッセージを送信する。
そして、リンカーは新しいＥＬＦ ｏｂｊｅｃｔをリンクし、バイナリ（ｂｉｎａｒｙ）をコードメモリからロードしてＴＤＭＡスタックを設定する。
その後、ＲＦＤ３のプロトコルアップデータは＜実施形態１＞のような方法によって（最適プロトコル、パラメータ値）＝（ＴＤＭＡ、３０）の情報を用いてＴＤＭＡプロトコルを設定する。
【０１３２】
上述した本発明の一実施形態に係るプリケーションプログラムのプロトコルを再構成する方法方法は、多様なコンピュータ手段を介して様々な処理を実行することができるプログラム命令の形態で実現され、コンピュータ読取可能な記録媒体に記録されてもよい。
コンピュータ読取可能な媒体は、プログラム命令、データファイル、データ構造などの単独又はその組み合わせたものを含んでもよい。
媒体に記録されるプログラム命令は、本発明の目的のために特別に設計されて構成されたものでもよく、コンピュータソフトウェア分野の技術を有する当業者にとって公知のものであり使用可能なものであってもよい。
【０１３３】
尚、本発明は、上述の実施形態に限られるものではない。本発明の技術的範囲から逸脱しない範囲内で多様に変更実施することが可能である。
【符号の説明】
【０１３４】
１００、２００ プロトコル再構成装置
１１０、５３１ 分析部
１３０、５３３ プロトコルエンジン
１５０、２１０、５３５、５５５ プロトコル実施部
１７０、２３０、５３７、５５７ 再構成プロトコルスタック
５２０ アプリケーションプログラム
５３０ プロトコル再構成装置（ＦＦＤ）
５５０ 対象装置（ＲＦＤ）
【特許請求の範囲】
【請求項１】
アプリケーションプログラムのためのプロトコルを再構成する方法において、
複数のコンポーネントモジュールのスタックが格納されたメモリを保持するステップと、
前記アプリケーションプログラムの要求情報及びプロトコルレイヤから取得したシステム情報を分析するステップと、
前記分析結果に基づいて、前記アプリケーションプログラムのための再構成されたプロトコルと前記再構成されたプロトコルのための運用パラメータとを含むプロトコル構成情報を決定するステップと、
前記プロトコル構成情報に基づいて、前記再構成されたプロトコルを実施するのに必要である前記複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールとの接続関係を決定するステップとを有することを特徴とするアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項２】
前記システム情報を分析するステップは、前記アプリケーションプログラムで、前記アプリケーションプログラムの要求情報に関連するイベントが発生したか否かに基づいて、前記アプリケーションプログラムの要求情報を取得することを特徴とする請求項１に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項３】
前記プロトコル構成情報を決定するステップは、複数のプロトコルそれぞれに対するＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）指標を、前記プロトコルレイヤから取得可能な少なくとも１つのパラメータと前記プロトコルの運用パラメータの関数として定義するステップと、
前記関数を前記アプリケーションプログラムの要求情報に適するよう数式化するステップとをさらに含むことを特徴とする請求項１に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項４】
前記プロトコル構成情報を決定するステップは、前記アプリケーションプログラムの要求情報によって表示される前記アプリケーションプログラムの要求事項を満足するために、前記再構成されたプロトコルのＱｏＳ指標を最適化させる運用パラメータを決定するステップを含むことを特徴とする請求項１に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項５】
前記複数のプロトコルそれぞれを分析した結果を含む情報を適用することによって、複数のプロトコルと、要求情報がマッピングされた複数のプロトコルそれぞれの運用パラメータとを格納するプロトコルデータベースを保持するステップをさらに有し、
前記プロトコル構成情報を決定するステップは、前記プロトコルデータベースを参照して、前記アプリケーションプログラムの要求情報に対応してマッピングされている複数のプロトコルのいずれか１つのプロトコルと、該いずれか１つのプロトコルの運用パラメータとを前記再構成されたプロトコル及び前記再構成されたプロトコルの運用パラメータとして決定するステップを含むことを特徴とする請求項１に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項６】
前記少なくとも１つのコンポーネントモジュールとの接続関係を決定するステップは、前記プロトコル構成情報に基づいて前記接続関係に関連する情報を生成するステップと、
前記接続関係に関連する情報を用いて前記再構成されたプロトコルを実施するステップとをさらに含むことを特徴とする請求項１に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項７】
前記複数のコンポーネントモジュールに関連する情報を格納するコンポーネントライブラリーを保持するステップをさらに有することを特徴とする請求項６に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項８】
アプリケーションプログラムのためのプロトコルを再構成する装置に接続され前記再構成されたプロトコルを実施する対象装置が前記再構成されたプロトコルを実施するために必要なコンポーネントモジュールが失われているか（ｍｉｓｓｉｎｇ）否かを判断するステップと、
前記判断結果に応じて、前記対象装置から失われていると判断されるコンポーネントモジュールに関する情報を前記コンポーネントライブラリーから取得するステップとをさらに有することを特徴とする請求項７に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項９】
対象装置によって使用されるプロトコルとプロトコルの運用パラメータに関する情報を格納するノードステートデータベースを保持するステップをさらに有することを特徴とする請求項１に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項１０】
前記ノードステートデータベース及び前記接続関係を参照して、前記プロトコル構成情報に基づき前記対象装置で前記再構成されたプロトコルを実施するために必要な情報を生成するステップと、
前記対象装置で前記再構成されたプロトコルを実施するために必要な情報を前記対象装置に送信するステップとをさらに有することを特徴とする請求項９に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項１１】
前記対象装置で前記再構成されたプロトコルを実施するために必要な情報を符号化するステップをさらに有することを特徴とする請求項１０に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項１２】
前記少なくとも１つのコンポーネントモジュールとの接続関係を決定するステップは、前記プロトコル構成情報を受信するステップと、
前記プロトコル構成情報を解釈するステップとを含むことを特徴とする請求項１に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項１３】
前記少なくとも１つのコンポーネントモジュールとの接続関係を決定するステップは、前記少なくとも１つのコンポーネントモジュールそれぞれのアドレスを含むテーブルを用いて前記少なくとも１つのコンポーネントモジュールを接続するステップをさらに有することを特徴とする請求項１に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項１４】
前記少なくとも１つのコンポーネントモジュールとの接続関係を決定するステップは、前記アプリケーションプログラムのための前記再構成されたプロトコルによりアプリケーションプログラムレイヤの下位レイヤを通過するメッセージをフックする（ｈｏｏｋｉｎｇ）ステップと、
前記フックしたメッセージから取得したプロトコルのＩＤに基づいて、前記少なくとも１つのコンポーネントモジュールをスイッチングするステップとを含むことを特徴とする請求項１に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項１５】
アプリケーションプログラムのためのプロトコルを再構成する方法において、
複数のコンポーネントモジュールのスタックが格納されたメモリを保持するステップと、
アプリケーションプログラムのためのプロトコルを再構成する装置に接続された対象装置から前記アプリケーションプログラムのための再構成されたプロトコルを実施するために必要な情報を受信するステップと、
前記アプリケーションプログラムの再構成されたプロトコルを実施するために必要な情報に基づいて、前記アプリケーションプログラムの再構成プロトコルを構成するために必要な前記複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールとの接続関係を決定するステップとを有することを特徴とするアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項１６】
前記アプリケーションプログラムのための再構成されたプロトコルを実施するために必要な情報は、前記アプリケーションプログラムのための再構成されたプロトコルと前記再構成されたプロトコルのための運用パラメータとを含むプロトコル構成情報、前記少なくとも１つのコンポーネントモジュールとの接続関係に関連する情報又は前記プロトコル構成情報及び前記接続関係に関連する情報の内の少なくとも１つを含むことを特徴とする請求項１５に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項１７】
前記少なくとも１つのコンポーネントモジュールとの接続関係を決定するステップは、前記再構成されたプロトコルを実施するために必要な情報を解読するステップをさらに含むことを特徴とする請求項１５に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項１８】
請求項１乃至１７のいずれか１項に記載のアプリケーションプログラムのためのプロトコルを再構成する方法を実行させるためのプログラムが記録されたことを特徴とするコンピュータで読み出し可能な記録媒体。
【請求項１９】
アプリケーションプログラムのためのプロトコルを再構成する装置において、
前記アプリケーションプログラムの要求情報及びプロトコルレイヤから取得されたシステム情報を分析する分析部と、
前記分析結果に基づいて、前記アプリケーションプログラムのための再構成されたプロトコル及び前記再構成されたプロトコルのための運用パラメータを含むプロトコル構成情報を決定するプロトコルエンジンと、
前記プロトコル構成情報により、前記再構成されたプロトコルを実施するために複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールとの接続関係を決定するプロトコル実施部と、
前記複数のコンポーネントモジュールのスタックが格納されたメモリを含む再構成プロトコルスタックとを有することを特徴とするアプリケーションプログラムのためのプロトコルを再構成する装置。
【請求項２０】
アプリケーションプログラムのためのプロトコルを再構成する装置において、
複数のコンポーネントモジュールのスタックが格納されたメモリを含む再構成プロトコルスタックと、
前記アプリケーションプログラムのためのプロトコルを再構成する装置と接続した対象装置から受信した前記アプリケーションプログラムのための再構成されたプロトコルを実施するために必要な情報に基づいて、前記アプリケーションプログラムの再構成されたプロトコルを実施するために必要な前記複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールとの接続関係を決定するプロトコル実施部とを有することを特徴とするアプリケーションプログラムのためのプロトコルを再構成する装置。
【請求項２１】
プロトコルレイヤから取得されたシステム情報及びアプリケーションプログラムの要求情報に基づいて前記アプリケーションプログラムの最適プロトコルと該最適プロトコルの運用パラメータの最適値とを決定するステップと、
前記アプリケーションプログラムの現在のプロトコルが前記最適プロトコルではない場合、
前記アプリケーションプログラムの現在のプロトコルから失われた（ｍｉｓｓｉｎｇ）少なくとも１つのコンポーネントモジュールと前記アプリケーションプログラムの現在のプロトコルの少なくとも１つのコンポーネントモジュールとを用いて、前記最適プロトコルの前記運用パラメータの値を前記最適プロトコルの前記運用パラメータの最適値に設定して前記アプリケーションプログラムの現在のプロトコルを前記最適プロトコルに再構成するステップとを有することを特徴とするアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項２２】
前記アプリケーションプログラムの現在のプロトコルの少なくとも１つのコンポーネントモジュールと前記アプリケーションプログラムの前記現在のプロトコルから失われた（ｍｉｓｓｉｎｇ）少なくとも１つのコンポーネントモジュールは、再構成プロトコルスタックのメモリに格納された複数のコンポーネントモジュールに含まれることを特徴とする請求項２１に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項２３】
前記アプリケーションプログラムの前記現在のプロトコルが前記最適プロトコルであり、前記最適プロトコルの運用パラメータの現在の値が前記最適プロトコルの運用パラメータの最適値ではない場合、
前記最適プロトコルの運用パラメータの値を前記運用パラメータの最適値に設定するステップをさらに有することを特徴とする請求項２１に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項２４】
前記アプリケーションプログラムは、第１装置に接続された第２装置から前記現在のプロトコルを用いて前記第１装置に送信されたデータを処理するために前記第１装置で駆動され、
前記最適プロトコルを決定するステップは、前記アプリケーションプログラムの要求情報が変更された時、又は前記第１装置に第３装置が接続された時に、実行されることを特徴とする請求項２１に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項１】
アプリケーションプログラムのためのプロトコルを再構成する方法において、
複数のコンポーネントモジュールのスタックが格納されたメモリを保持するステップと、
前記アプリケーションプログラムの要求情報及びプロトコルレイヤから取得したシステム情報を分析するステップと、
前記分析結果に基づいて、前記アプリケーションプログラムのための再構成されたプロトコルと前記再構成されたプロトコルのための運用パラメータとを含むプロトコル構成情報を決定するステップと、
前記プロトコル構成情報に基づいて、前記再構成されたプロトコルを実施するのに必要である前記複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールとの接続関係を決定するステップとを有することを特徴とするアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項２】
前記システム情報を分析するステップは、前記アプリケーションプログラムで、前記アプリケーションプログラムの要求情報に関連するイベントが発生したか否かに基づいて、前記アプリケーションプログラムの要求情報を取得することを特徴とする請求項１に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項３】
前記プロトコル構成情報を決定するステップは、複数のプロトコルそれぞれに対するＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）指標を、前記プロトコルレイヤから取得可能な少なくとも１つのパラメータと前記プロトコルの運用パラメータの関数として定義するステップと、
前記関数を前記アプリケーションプログラムの要求情報に適するよう数式化するステップとをさらに含むことを特徴とする請求項１に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項４】
前記プロトコル構成情報を決定するステップは、前記アプリケーションプログラムの要求情報によって表示される前記アプリケーションプログラムの要求事項を満足するために、前記再構成されたプロトコルのＱｏＳ指標を最適化させる運用パラメータを決定するステップを含むことを特徴とする請求項１に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項５】
前記複数のプロトコルそれぞれを分析した結果を含む情報を適用することによって、複数のプロトコルと、要求情報がマッピングされた複数のプロトコルそれぞれの運用パラメータとを格納するプロトコルデータベースを保持するステップをさらに有し、
前記プロトコル構成情報を決定するステップは、前記プロトコルデータベースを参照して、前記アプリケーションプログラムの要求情報に対応してマッピングされている複数のプロトコルのいずれか１つのプロトコルと、該いずれか１つのプロトコルの運用パラメータとを前記再構成されたプロトコル及び前記再構成されたプロトコルの運用パラメータとして決定するステップを含むことを特徴とする請求項１に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項６】
前記少なくとも１つのコンポーネントモジュールとの接続関係を決定するステップは、前記プロトコル構成情報に基づいて前記接続関係に関連する情報を生成するステップと、
前記接続関係に関連する情報を用いて前記再構成されたプロトコルを実施するステップとをさらに含むことを特徴とする請求項１に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項７】
前記複数のコンポーネントモジュールに関連する情報を格納するコンポーネントライブラリーを保持するステップをさらに有することを特徴とする請求項６に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項８】
アプリケーションプログラムのためのプロトコルを再構成する装置に接続され前記再構成されたプロトコルを実施する対象装置が前記再構成されたプロトコルを実施するために必要なコンポーネントモジュールが失われているか（ｍｉｓｓｉｎｇ）否かを判断するステップと、
前記判断結果に応じて、前記対象装置から失われていると判断されるコンポーネントモジュールに関する情報を前記コンポーネントライブラリーから取得するステップとをさらに有することを特徴とする請求項７に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項９】
対象装置によって使用されるプロトコルとプロトコルの運用パラメータに関する情報を格納するノードステートデータベースを保持するステップをさらに有することを特徴とする請求項１に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項１０】
前記ノードステートデータベース及び前記接続関係を参照して、前記プロトコル構成情報に基づき前記対象装置で前記再構成されたプロトコルを実施するために必要な情報を生成するステップと、
前記対象装置で前記再構成されたプロトコルを実施するために必要な情報を前記対象装置に送信するステップとをさらに有することを特徴とする請求項９に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項１１】
前記対象装置で前記再構成されたプロトコルを実施するために必要な情報を符号化するステップをさらに有することを特徴とする請求項１０に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項１２】
前記少なくとも１つのコンポーネントモジュールとの接続関係を決定するステップは、前記プロトコル構成情報を受信するステップと、
前記プロトコル構成情報を解釈するステップとを含むことを特徴とする請求項１に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項１３】
前記少なくとも１つのコンポーネントモジュールとの接続関係を決定するステップは、前記少なくとも１つのコンポーネントモジュールそれぞれのアドレスを含むテーブルを用いて前記少なくとも１つのコンポーネントモジュールを接続するステップをさらに有することを特徴とする請求項１に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項１４】
前記少なくとも１つのコンポーネントモジュールとの接続関係を決定するステップは、前記アプリケーションプログラムのための前記再構成されたプロトコルによりアプリケーションプログラムレイヤの下位レイヤを通過するメッセージをフックする（ｈｏｏｋｉｎｇ）ステップと、
前記フックしたメッセージから取得したプロトコルのＩＤに基づいて、前記少なくとも１つのコンポーネントモジュールをスイッチングするステップとを含むことを特徴とする請求項１に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項１５】
アプリケーションプログラムのためのプロトコルを再構成する方法において、
複数のコンポーネントモジュールのスタックが格納されたメモリを保持するステップと、
アプリケーションプログラムのためのプロトコルを再構成する装置に接続された対象装置から前記アプリケーションプログラムのための再構成されたプロトコルを実施するために必要な情報を受信するステップと、
前記アプリケーションプログラムの再構成されたプロトコルを実施するために必要な情報に基づいて、前記アプリケーションプログラムの再構成プロトコルを構成するために必要な前記複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールとの接続関係を決定するステップとを有することを特徴とするアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項１６】
前記アプリケーションプログラムのための再構成されたプロトコルを実施するために必要な情報は、前記アプリケーションプログラムのための再構成されたプロトコルと前記再構成されたプロトコルのための運用パラメータとを含むプロトコル構成情報、前記少なくとも１つのコンポーネントモジュールとの接続関係に関連する情報又は前記プロトコル構成情報及び前記接続関係に関連する情報の内の少なくとも１つを含むことを特徴とする請求項１５に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項１７】
前記少なくとも１つのコンポーネントモジュールとの接続関係を決定するステップは、前記再構成されたプロトコルを実施するために必要な情報を解読するステップをさらに含むことを特徴とする請求項１５に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項１８】
請求項１乃至１７のいずれか１項に記載のアプリケーションプログラムのためのプロトコルを再構成する方法を実行させるためのプログラムが記録されたことを特徴とするコンピュータで読み出し可能な記録媒体。
【請求項１９】
アプリケーションプログラムのためのプロトコルを再構成する装置において、
前記アプリケーションプログラムの要求情報及びプロトコルレイヤから取得されたシステム情報を分析する分析部と、
前記分析結果に基づいて、前記アプリケーションプログラムのための再構成されたプロトコル及び前記再構成されたプロトコルのための運用パラメータを含むプロトコル構成情報を決定するプロトコルエンジンと、
前記プロトコル構成情報により、前記再構成されたプロトコルを実施するために複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールとの接続関係を決定するプロトコル実施部と、
前記複数のコンポーネントモジュールのスタックが格納されたメモリを含む再構成プロトコルスタックとを有することを特徴とするアプリケーションプログラムのためのプロトコルを再構成する装置。
【請求項２０】
アプリケーションプログラムのためのプロトコルを再構成する装置において、
複数のコンポーネントモジュールのスタックが格納されたメモリを含む再構成プロトコルスタックと、
前記アプリケーションプログラムのためのプロトコルを再構成する装置と接続した対象装置から受信した前記アプリケーションプログラムのための再構成されたプロトコルを実施するために必要な情報に基づいて、前記アプリケーションプログラムの再構成されたプロトコルを実施するために必要な前記複数のコンポーネントモジュールの内の少なくとも１つのコンポーネントモジュールとの接続関係を決定するプロトコル実施部とを有することを特徴とするアプリケーションプログラムのためのプロトコルを再構成する装置。
【請求項２１】
プロトコルレイヤから取得されたシステム情報及びアプリケーションプログラムの要求情報に基づいて前記アプリケーションプログラムの最適プロトコルと該最適プロトコルの運用パラメータの最適値とを決定するステップと、
前記アプリケーションプログラムの現在のプロトコルが前記最適プロトコルではない場合、
前記アプリケーションプログラムの現在のプロトコルから失われた（ｍｉｓｓｉｎｇ）少なくとも１つのコンポーネントモジュールと前記アプリケーションプログラムの現在のプロトコルの少なくとも１つのコンポーネントモジュールとを用いて、前記最適プロトコルの前記運用パラメータの値を前記最適プロトコルの前記運用パラメータの最適値に設定して前記アプリケーションプログラムの現在のプロトコルを前記最適プロトコルに再構成するステップとを有することを特徴とするアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項２２】
前記アプリケーションプログラムの現在のプロトコルの少なくとも１つのコンポーネントモジュールと前記アプリケーションプログラムの前記現在のプロトコルから失われた（ｍｉｓｓｉｎｇ）少なくとも１つのコンポーネントモジュールは、再構成プロトコルスタックのメモリに格納された複数のコンポーネントモジュールに含まれることを特徴とする請求項２１に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項２３】
前記アプリケーションプログラムの前記現在のプロトコルが前記最適プロトコルであり、前記最適プロトコルの運用パラメータの現在の値が前記最適プロトコルの運用パラメータの最適値ではない場合、
前記最適プロトコルの運用パラメータの値を前記運用パラメータの最適値に設定するステップをさらに有することを特徴とする請求項２１に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【請求項２４】
前記アプリケーションプログラムは、第１装置に接続された第２装置から前記現在のプロトコルを用いて前記第１装置に送信されたデータを処理するために前記第１装置で駆動され、
前記最適プロトコルを決定するステップは、前記アプリケーションプログラムの要求情報が変更された時、又は前記第１装置に第３装置が接続された時に、実行されることを特徴とする請求項２１に記載のアプリケーションプログラムのためのプロトコルを再構成する方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公開番号】特開２０１３−７３６２９（Ｐ２０１３−７３６２９Ａ）
【公開日】平成２５年４月２２日（２０１３．４．２２）
【国際特許分類】
【出願番号】特願２０１２−２１２７９６（Ｐ２０１２−２１２７９６）
【出願日】平成２４年９月２６日（２０１２．９．２６）
【出願人】（３９００１９８３９）三星電子株式会社 (8,520)
【氏名又は名称原語表記】Ｓａｍｓｕｎｇ Ｅｌｅｃｔｒｏｎｉｃｓ Ｃｏ．，Ｌｔｄ．
【住所又は居所原語表記】１２９，Ｓａｍｓｕｎｇ−ｒｏ，Ｙｅｏｎｇｔｏｎｇ−ｇｕ，Ｓｕｗｏｎ−ｓｉ，Ｇｙｅｏｎｇｇｉ−ｄｏ，Ｒｅｐｕｂｌｉｃ ｏｆ Ｋｏｒｅａ
【Ｆターム（参考）】
【公開日】平成２５年４月２２日（２０１３．４．２２）
【国際特許分類】
【出願日】平成２４年９月２６日（２０１２．９．２６）
【出願人】（３９００１９８３９）三星電子株式会社 (8,520)
【氏名又は名称原語表記】Ｓａｍｓｕｎｇ Ｅｌｅｃｔｒｏｎｉｃｓ Ｃｏ．，Ｌｔｄ．
【住所又は居所原語表記】１２９，Ｓａｍｓｕｎｇ−ｒｏ，Ｙｅｏｎｇｔｏｎｇ−ｇｕ，Ｓｕｗｏｎ−ｓｉ，Ｇｙｅｏｎｇｇｉ−ｄｏ，Ｒｅｐｕｂｌｉｃ ｏｆ Ｋｏｒｅａ
【Ｆターム（参考）】
[ Back to top ]