(57)【特許請求の範囲】
【請求項１】
複数ノードの備わる通信ネットワークを制御するための通信制御システムであって、
各ノードに備わり、ノードに関する情報を管理する知識ベース部と、
各ノードに備わり、ノード間で制御情報を送受信する制御情報送受信部と、
各ノードに備わり、各レイヤに共通の形式で表された自ノード内の各レイヤからの制御情報を交換するレイヤ間協調部と、
各ノードに備わり、前記レイヤ間協調部からの制御情報を取得し、当該制御情報の内容に応じてノードを指定して当該制御情報を前記制御情報送受信部へ出力するか又は前記知識ベース部へ出力するとともに、前記制御情報送受信部の受信した他のノードからの制御情報を取得し、当該制御情報の内容に応じてレイヤを指定して前記レイヤ間協調部へ出力するか又は前記知識ベース部へ出力するとともに、前記知識ベース部からの制御情報を取得し、レイヤを指定して前記レイヤ間協調部へ出力するか又はノードを指定して当該制御情報を前記制御情報送受信部へ出力するノード間協調部と、
を備え、
いずれかのノードの前記知識ベース部は、全ノードについてのノードに関する情報を提供する知識ベースサーバとして機能し、
前記ノード間協調部は、
前記制御情報として、自ノード内のいずれかのレイヤから、他ノード内の対象とするレイヤの情報の取得を要求するＩＮ−ＩＳプリミティブが前記レイヤ間協調部を介して入力されると、該ＩＮ−ＩＳプリミティブを前記知識ベース部に出力し、前記知識ベース部に該ＩＮ−ＩＳプリミティブを前記知識ベースサーバへの問い合わせ形式に変換させ、該変換されたＩＮ−ＩＳプリミティブを前記制御情報送受信部を介して前記知識ベースサーバを有するノードへ送信し、
前記知識ベースサーバを有するノードから、前記ＩＮ−ＩＳプリミティブに対する応答を前記制御情報送受信部を介して受信すると、該受信した応答を前記レイヤ間協調部を介して前記ＩＮ−ＩＳプリミティブの要求元のレイヤに出力する
ことを特徴とする通信制御システム。
【請求項２】
前記ノード間協調部は、
前記制御情報として、他ノード内のいずれかのレイヤから、自ノード内の対象とするレイヤで発生したイベントの通知を要求するＩＮ−ＥＳプリミティブを前記制御情報送受信部を介して受信すると、該受信した前記ＩＮ−ＥＳプリミティブに対応する要求を登録し、
登録されている前記要求に一致するイベントが発生すると、当該要求の送信元に向けた応答用の制御情報を生成し、前記制御情報送受信部を介して前記ＩＮ−ＥＳプリミティブの要求元のノードに送信する
ことを特徴とする請求項１に記載の通信制御システム。
【請求項３】
複数ノードの備わる通信ネットワークを制御するための通信制御方法であって、
各ノードは、ノードに関する情報を管理する知識ベース部と、ノード間で制御情報を送受信する制御情報送受信部と、レイヤ間協調部と、ノード間協調部とを備え、
前記レイヤ間協調部が、各レイヤに共通の形式で表された自ノード内の各レイヤからの制御情報を交換するレイヤ間協調手順と、
前記ノード間協調部が、前記レイヤ間協調部からの制御情報を取得し、当該制御情報の内容に応じてノードを指定して当該制御情報を前記制御情報送受信部へ出力するか又は前記知識ベース部へ出力するとともに、前記制御情報送受信部の受信した他のノードからの制御情報を取得し、当該制御情報の内容に応じてレイヤを指定して前記レイヤ間協調部へ出力するか又は前記知識ベース部へ出力するとともに、前記知識ベース部からの制御情報を取得し、レイヤを指定して前記レイヤ間協調部へ出力するか又はノードを指定して当該制御情報を前記制御情報送受信部へ出力するノード間協調手順と、
を順に有し、
いずれかのノードの前記知識ベース部は、全ノードについてのノードに関する情報を提供する知識ベースサーバとして機能し、
前記ノード間協調手順では、前記ノード間協調部が、
前記制御情報として、自ノード内のいずれかのレイヤから、他ノード内の対象とするレイヤの情報の取得を要求するＩＮ−ＩＳプリミティブが前記レイヤ間協調部を介して入力されると、該ＩＮ−ＩＳプリミティブを前記知識ベース部に出力し、前記知識ベース部に該ＩＮ−ＩＳプリミティブを前記知識ベースサーバへの問い合わせ形式に変換させ、該変換されたＩＮ−ＩＳプリミティブを前記制御情報送受信部を介して前記知識ベースサーバを有するノードへ送信し、
前記知識ベースサーバを有するノードから、前記ＩＮ−ＩＳプリミティブに対する応答を前記制御情報送受信部を介して受信すると、該受信した応答を前記レイヤ間協調部を介して前記ＩＮ−ＩＳプリミティブの要求元のレイヤに出力する
ことを特徴とする通信制御方法。
【請求項４】
前記ノード間協調手順では、前記ノード間協調部が、
前記制御情報として、他ノード内のいずれかのレイヤから、自ノード内の対象とするレイヤで発生したイベントの通知を要求するＩＮ−ＥＳプリミティブを前記制御情報送受信部を介して受信すると、該受信した前記ＩＮ−ＥＳプリミティブに対応する要求を登録し、
登録されている前記要求に一致するイベントが発生すると、当該要求の送信元に向けた応答用の制御情報を生成し、前記制御情報送受信部を介して前記ＩＮ−ＥＳプリミティブの要求元のノードに送信する
ことを特徴とする請求項３に記載の通信制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ノード間での制御情報を利用した通信制御システム及び通信制御方法に関する。
【背景技術】
【０００２】
（ノード内クロスレイヤ協調アーキテクチャ：ＣＥＡＬ）
慶應義塾大学理工学部情報工学科の寺岡研究室ではノード内におけるレイヤ間協調アーキテクチャとしてＣＥＡＬ（Ｃｒｏｓｓ  ｌａｙｅｒ  ｉｎｆｏｒｍａｔｉｏｎ  Ｅｘｃｈａｎｇｅ  ｂｅｔｗｅｅｎ  Ａｒｂｉｔｒａｒｙ  Ｌａｙｅｒｓ）を提案している（例えば、非特許文献１参照。）。図５にＣＥＡＬのアーキテクチャを示す。図において、ＰＥ１１はＩＳＯ（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ  Ｏｒｇａｎｉｚａｔｉｏｎ）のＯＳＩ（Ｏｐｅｎ  Ｓｙｓｔｅｍｓ  Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）のモデルで定義されているＰｒｏｔｏｃｏｌ  Ｅｎｔｉｔｙであり、プロトコルを解釈実行する実体である。ＰＥ１１は各レイヤに存在し、異なるレイヤのＰＥ１１間のデータ交換はレイヤの境界に存在するＳＡＰ（Ｓｅｒｖｉｃｅ  Ａｃｃｅｓｓ  Ｐｏｉｎｔ）１７を介して行われる。これに対し、ＣＥＡＬではＡＥ１２（Ａｂｓｔｒａｃｔ  Ｅｎｔｉｔｙ）とＩＬＳ（Ｉｎｔｅｒ−Ｌａｙｅｒ  Ｓｙｓｔｅｍ）１３を導入している。ＡＥ１２はＰＥ１１ごとに設けられ、ＰＥ１１がもつプロトコル依存あるいはデバイス依存の制御情報を、プロトコルやデバイスに依存しない制御情報に変換する。そしてこの制御情報はＩＬＳ１３を介して任意のレイヤ間で交換される。
【０００３】
ＣＥＡＬは元々ネットワークレイヤ（Ｌ３）がリンクレイヤ（Ｌ２）の情報を利用して高速ハンドオーバを実現することを目的として設計されており、図６に示す９種類のＬ２プリミティブを定義している。図６においてＩＳはＩｎｆｏｒｍａｔｉｏｎ  Ｓｅｒｖｉｃｅであり、リンクレイヤの情報を得るためのプリミティブである。ＥＳはＥｖｅｎｔ  Ｓｅｒｖｉｃｅであり、リンクレイヤで発生したイベントを非同期に得るためのプリミティブである。ＣＳはＣｏｍｍａｎｄ  Ｓｅｒｖｉｃｅであり、リンクレイヤの動作を指示するプリミティブである。
【０００４】
各プリミティブは図７に示すシーケンスで動作する。ＩＳの場合は、（ｎ＋ｍ）レイヤは（ｎ）レイヤにＲｅｑｕｅｓｔ（ｒｅｑ）を送信し、（ｎ）レイヤはＲｅｑｕｅｓｔへの応答として（ｎ＋ｍ）レイヤにＣｏｎｆｉｒｍ（ｃｏｎｆ）を返す。たとえばネットワークレイヤ（Ｌ３）がＬ２−ＰｏＡＬｉｓｔを使用する場合を考える。Ｌ３はＬ２−ＰｏＡＬｉｓｔ．ｒｅｑをＬ２に送信すると、Ｌ２はアクセスポイントのリストを格納したＬ２−ＰｏＡＬｉｓｔ．ｃｏｎｆをＬ３に返す。
【０００５】
ＥＳの場合は、（ｎ＋ｍ）レイヤは（ｎ）レイヤにＲｅｑｕｅｓｔを送信し、受信したいイベントの種類などを登録する。（ｎ＋ｍ）レイヤはその応答としてＣｏｎｆｉｒｍを（ｎ＋ｍ）レイヤに返す。（ｎ）レイヤでイベントが発生すると（ｎ）レイヤはＩｎｄｉｃａｔｉｏｎ（ｉｎｄ）を（ｎ＋ｍ）レイヤに送信する。（ｎ＋ｍ）レイヤはＩｎｄｉｃａｔｉｏｎの応答として（ｎ）レイヤにＲｅｓｐｏｎｓｅ（ｒｅｓ）を返す。最後のＲｅｓｐｏｎｓｅは省略可能とする。たとえばＬ３がＬ２−ＬｉｎｋＵｐを使用する場合を考える。Ｌ３はＬ２−ＬｉｎｋＵｐ．ｒｅｑをＬ２に送信すると、Ｌ２はこの要求を記録してＬ２−ＬｉｎｋＵｐ．ｃｏｎｆをＬ３に返す。そしてＬ２でリンクが実際に使用可能になると、Ｌ２はＬ２−ＬｉｎｋＵｐ．ｉｎｄをＬ３に送信する。Ｌ３はＬ２にＬ２−ＬｉｎｋＵｐ．ｒｅｓを返してもよい。
【０００６】
ＣＳの場合は、（ｎ＋ｍ）レイヤはＲｅｑｕｅｓｔを（ｎ）レイヤに送信する。（ｎ）レイヤはその応答としてＣｏｎｆｉｒｍを（ｎ＋ｍ）レイヤに返す。たとえばＬ３がＬ２−ＬｉｎｋＣｏｎｎｅｃｔを使用する場合を考える。Ｌ３はＬ２−ＬｉｎｋＣｏｎｎｅｃｔ．ｒｅｑをＬ２に送信する。Ｌ２はその応答としてＬ２−ＬｉｎｋＣｏｎｎｅｃｔ．ｃｏｎｆをＬ３に返し、その後指示された動作を実行する。
【０００７】
（ネットワークレイヤでの高速ハンドオーバ）
図８にＣＥＡＬによる高速ハンドオーバの実行手順を示す（例えば、非特許文献２参照。）。まずＬ３とＬ２はＬ２−ＬｉｎｋＳｔａｔｕｓＣｈａｎｇｅｄ．ｒｅｑ／ｃｏｎｆおよびＬ２−ＬｉｎｋＵｐ．ｒｅｑ／ｃｏｎｆの交換を済ませておく（Ｓ３０１〜Ｓ３０４）。やがてリンクのシグナルレベルが閾値よりも低くなるとＬ２はＬ３にＬ２−ＬｉｎｋＳｔａｔｕｓＣｈａｎｇｅｄ．ｉｎｄを送信する（Ｓ３０５）。Ｌ３はＬ２−ＰｏＡＬｉｓｔ．ｒｅｑ／ｃｏｎｆにより使用可能なアクセスポイントのリストを得る（Ｓ３０６〜Ｓ３０７）。そしてＬ３は最適なアクセスポイントを選択し、Ｌ２にＬ２−ＬｉｎｋＣｏｎｎｅｃｔ．ｒｅｑを送信してハンドオーバ実行を指示する（Ｓ３０８〜Ｓ３０９）。その後Ｌ２がハンドオーバを完了すると、Ｌ２−ＬｉｎｋＵｐ．ｉｎｄがＬ３に送信される（Ｓ３１０）。その後Ｌ３はシグナリング処理を行い、ハンドオーバが完了する。
【０００８】
（ＳＣＴＰの高速フェイルオーバ）
ＳＣＴＰ（Ｓｔｒｅａｍ  Ｃｏｎｔｒｏｌ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｐｒｏｔｏｃｏｌ）はＴＣＰの後継プロトコルとしてＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）で標準化されたプロトコルである。ＴＣＰのコネクションに相当するものをＳＣＴＰではアソシエーションと呼ぶ。ＳＣＴＰの１つのアソシエーション内には複数のパスを持つことができる。パスとはＴＣＰのコネクションに相当するものと言える。そしてアソシエーション内の１つのパスをプライマリパスとして通信に使用し、他のパスをセカンダリパスとして障害対策のために未使用としておく。プライマリパスに障害が発生するとセカンダリパスの１つをプライマリパスとすることにより、通信を継続させることができる。この動作をフェイルオーバと呼ぶ。しかしＳＣＴＰの仕様ではパス障害をタイムアウトで検出することになっており、障害が発生してからＳＣＴＰがそれを検出するまでには３０秒以上の時間を要する。
【０００９】
ＣＥＡＬに基づくレイヤ間協調を利用することにより、高速にフェイルオーバを実行することができる（例えば、非特許文献３を参照。）。
まず、図６に示すリンクレイヤ（Ｌ２）プリミティブに加えて図９に示すネットワークレイヤ（Ｌ３）プリミティブを定義した。図１０において、Ｈｏｓｔ−Ａは２つのネットワークインタフェース、Ｌ２−１とＬ２−２、を持ち、最初はＬ２−１をプライマリパスに割り当ててＨｏｓｔ−Ｂと通信している。するとＬ２−１のリンクに障害が発生し、これを検知したＬ２−１はＬ３（すなわちＩＰ）にＬ２−ＬｉｎｋＤｏｗｎ．ｉｎｄを送信する（Ｓ４０１）。するとＬ３はＬ４（すなわちＳＣＴＰ）にＬ３−ＲｅａｃｈａｂｉｌｉｔｙＬｏｓｔ．ｉｎｄを送信する（Ｓ４０２）。Ｌ４は代替経路を知るため、Ｌ３にＬ３−Ｒｏｕｔｅ．ｒｅｑを送信する（Ｓ４０３）。Ｌ３はセカンダリパスとなっているＬ２−２とＬ２−ＬｉｎｋＳｔａｔｕｓ．ｒｅｑ／ｃｏｎｆを交換し、Ｌ２−２の状態を知る（Ｓ４０４）。この結果、Ｌ３はＨｏｓｔ−Ｂに到達するにはＬ２−２を使用すれば良いことが分かるので、Ｌ３はこの情報を格納したＬ３−Ｒｏｕｔｅ．ｃｏｎｆをＬ４に返す（Ｓ４０５）。Ｌ４はＬ２−２のパスをプライマリパスにすることを決定し、これをＨｏｓｔ−ＢのＬ４（すなわちＳＣＴＰ）に通知する。
【００１０】
（ＩＥＥＥ  ８０２．２１）
ＩＥＥＥ  ８０２．２１（例えば、非特許文献４を参照。）はクロスレイヤ協調を利用して異種無線技術（たとえばＷｉＦｉやＷｉＭＡＸなど）間でのスムーズなハンドオーバの実現を目的としたＭｅｄｉａ  Ｉｎｄｅｐｅｎｄｅｎｔ  Ｈａｎｄｏｖｅｒ  Ｆｕｎｃｔｉｏｎ（ＭＩＨＦ）を定義している。ＩＥＥＥ  ８０２．２１の参照モデルを図１１に示す。ＭＩＨＦは前述のＣＥＡＬと同様にＥＳ、ＣＳ及びＩＳを提供する。ＭＩＨＦはＭＩＨ  ＬＩＮＫ  ＳＡＰを介してリンクレイヤと制御情報を交換し、ＭＩＨ  ＳＡＰを介して上位レイヤプロトコルにリンクレイヤ情報を受け渡す。さらにＭＩＨＦはＭＩＨ  ＮＥＴ  ＳＡＰを介して他ノードのＭＩＨＦと制御情報を交換する。
【００１１】
ＭＩＨＦのＩＳではインフォメーションサーバから次のような情報を得ることができるとしているが、インフォメーションサーバの詳細は本規格の範囲外としている。
・利用可能な無線ネットワークのリスト（ＩＥＥＥ８０２．１１／１６／２２及びＧＳＭ（登録商標）等）
・リンクレイヤの情報（近隣のマップ）
・上位レイヤのサービス（ＩＳＰ及びＭＭＳ等）
【先行技術文献】
【非特許文献】
【００１２】
【非特許文献１】Ｆ．  Ｔｅｒａｏｋａ，  Ｋ．  Ｇｏｇｏ，  Ｋ．  Ｍｉｔｓｕｙａ，  Ｒ．  Ｓｈｉｂｕｉ，  ａｎｄ  Ｋ．  Ｍｉｔａｎｉ．  Ｕｎｉｆｉｅｄ  Ｌａｙｅｒ  ２（Ｌ２）Ａｂｓｔｒａｃｔｉｏｎｓ  ｆｏｒ  Ｌａｙｅｒ  ３（Ｌ３）−Ｄｒｉｖｅｎ  Ｆａｓｔ  Ｈａｎｄｏｖｅｒ，  Ｍａｙ  ２００８．  ＲＦＣ  ５１８４http://www.rfc-editor.org/rfc/rfc5184.txt
【非特許文献２】Ｋ．  Ｇｏｇｏ，  Ｒ．  Ｓｈｉｂｕｉ，  ａｎｄ  Ｆ．  Ｔｅｒａｏｋａ．  Ａｎ  Ｌ３−Ｄｒｉｖｅｎ  Ｆａｓｔ  Ｈａｎｄｏｖｅｒ  Ｍｅｃｈａｎｉｓｍ  ｉｎ  ＩＰｖ６  Ｍｏｂｉｌｉｔｙ．  Ｉｎ  Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ＳＡＩＮＴ  ２００６，  Ｊａｎｕａｒｙ  ２００６http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1581358
【非特許文献３】Ｙ．  Ｈａｎ  ａｎｄ  Ｆ．  Ｔｅｒａｏｋａ．  ＳＣＴＰｆｘ：  Ａ  Ｆａｓｔ  Ｆａｉｌｏｖｅｒ  Ｍｅｃｈａｎｉｓｍ  Ｂａｓｅｄ  ｏｎ  Ｃｒｏｓｓ−Ｌａｙｅｒ  Ａｒｃｈｉｔｅｃｔｕｒｅ  ｉｎ  ＳＣＴＰ  Ｍｕｌｔｉｈｏ−ｍｉｎｇ．  Ｉｎ  Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ＡＩＮＴＥＣ  ２００８，  Ｎｏｖｅｍｂｅｒ  ２００８http://dl.acm.org/citation.cfm?id=1503370.1503399&coll=DL&dl=GUIDE&CFID=63195011&CFTOKEN=44527594
【非特許文献４】ＩＥＥＥ．  ＩＥＥＥ  Ｓｔａｎｄａｒｄ  ｆｏｒ  Ｌｏｃａｌ  ａｎｄ  ｍｅｔｒｏｐｏｌｉｔａｎ  ａｒｅａ  ｎｅｔｗｏｒｋｓ  −  Ｐａｒｔ２１：  Ｍｅｄｉａ  Ｉｎｄｅｐｅｎｄｅｎｔ  Ｈａｎｄｏｖｅｒ  Ｓｅｒｖｉｃｅｓ，  Ｊａｎｕａｒｙ  ２００９．  ＩＥＥＥ  Ｓｔｄ  ８０２．２１−２００８ｈｔｔｐ：／／ｉｅｅｅｘｐｌｏｒｅ．ｏｒｇ／ｘｐｌ／ｍｏｓｔＲｅｃｅｎｔＩｓｓｕｅ．ｊｓｐ？ｐｕｎｕｍｂｅｒ＝４７６９３６３
【発明の概要】
【発明が解決しようとする課題】
【００１３】
既存技術には次のような課題がある。
・ＩＥＥＥ  ８０２．２１は高速ハンドオーバを目的としており、汎用的なクロスレイヤアーキテクチャとはなっていない。
・ＩＥＥＥ  ８０２．２１はインフォメーションサーバを利用してさまざま情報をノードが取得することを想定しているが、インフォメーションサーバの詳細は規格の範囲外となっている。
・ＣＥＡＬは汎用的なクロスレイヤアーキテクチャだが、ノード内部での制御情報交換しか考慮していない。
【００１４】
そこで、本発明は、各ノードの各レイヤから収集した情報を提供可能な汎用的なクロスレイヤ協調アーキテクチャの提供を目的とする。
【課題を解決するための手段】
【００１５】
本発明に係る通信制御システムは、
複数ノードの備わる通信ネットワークを制御するための通信制御システムであって、
各ノードに備わり、ノードに関する情報を管理する知識ベース部と、
各ノードに備わり、ノード間で制御情報を送受信する制御情報送受信部と、
各ノードに備わり、各レイヤに共通の形式で表された自ノード内の各レイヤからの制御情報を交換するレイヤ間協調部と、
各ノードに備わり、前記レイヤ間協調部からの制御情報を取得し、当該制御情報の内容に応じてノードを指定して当該制御情報を前記制御情報送受信部へ出力するか又は前記知識ベース部へ出力するとともに、前記制御情報送受信部の受信した他のノードからの制御情報を取得し、当該制御情報の内容に応じてレイヤを指定して前記レイヤ間協調部へ出力するか又は前記知識ベース部へ出力するとともに、前記知識ベース部からの制御情報を取得し、レイヤを指定して前記レイヤ間協調部へ出力するか又はノードを指定して当該制御情報を前記制御情報送受信部へ出力するノード間協調部と、
を備え、
いずれかのノードの前記知識ベース部は、全ノードについてのノードに関する情報を提供する知識ベースサーバとして機能し、
前記ノード間協調部は、
前記制御情報として、自ノード内のいずれかのレイヤから、他ノード内の対象とするレイヤの情報の取得を要求するＩＮ−ＩＳプリミティブが前記レイヤ間協調部を介して入力されると、該ＩＮ−ＩＳプリミティブを前記知識ベース部に出力し、前記知識ベース部に該ＩＮ−ＩＳプリミティブを前記知識ベースサーバへの問い合わせ形式に変換させ、該変換されたＩＮ−ＩＳプリミティブを前記制御情報送受信部を介して前記知識ベースサーバを有するノードへ送信し、
前記知識ベースサーバを有するノードから、前記ＩＮ−ＩＳプリミティブに対する応答を前記制御情報送受信部を介して受信すると、該受信した応答を前記レイヤ間協調部を介して前記ＩＮ−ＩＳプリミティブの要求元のレイヤに出力することを特徴とする。
【００１６】
本発明に係る通信制御システムでは、前記ノード間協調部は、前記制御情報として、他ノード内のいずれかのレイヤから、自ノード内の対象とするレイヤで発生したイベントの通知を要求するＩＮ−ＥＳプリミティブを前記制御情報送受信部を介して受信すると、該受信した前記ＩＮ−ＥＳプリミティブに対応する要求を登録し、登録されている前記要求に一致するイベントが発生すると、当該要求の送信元に向けた応答用の制御情報を生成し、前記制御情報送受信部を介して前記ＩＮ−ＥＳプリミティブの要求元のノードに送信してもよい。
【００１７】
本発明に係る通信制御方法は、
複数ノードの備わる通信ネットワークを制御するための通信制御方法であって、
各ノードは、ノードに関する情報を管理する知識ベース部と、ノード間で制御情報を送受信する制御情報送受信部と、レイヤ間協調部と、ノード間協調部とを備え、
前記レイヤ間協調部が、各レイヤに共通の形式で表された自ノード内の各レイヤからの制御情報を交換するレイヤ間協調手順と、
前記ノード間協調部が、前記レイヤ間協調部からの制御情報を取得し、当該制御情報の内容に応じてノードを指定して当該制御情報を前記制御情報送受信部へ出力するか又は前記知識ベース部へ出力するとともに、前記制御情報送受信部の受信した他のノードからの制御情報を取得し、当該制御情報の内容に応じてレイヤを指定して前記レイヤ間協調部へ出力するか又は前記知識ベース部へ出力するとともに、前記知識ベース部からの制御情報を取得し、レイヤを指定して前記レイヤ間協調部へ出力するか又はノードを指定して当該制御情報を前記制御情報送受信部へ出力するノード間協調手順と、
を順に有し、
いずれかのノードの前記知識ベース部は、全ノードについてのノードに関する情報を提供する知識ベースサーバとして機能し、
前記ノード間協調手順では、前記ノード間協調部が、
前記制御情報として、自ノード内のいずれかのレイヤから、他ノード内の対象とするレイヤの情報の取得を要求するＩＮ−ＩＳプリミティブが前記レイヤ間協調部を介して入力されると、該ＩＮ−ＩＳプリミティブを前記知識ベース部に出力し、前記知識ベース部に該ＩＮ−ＩＳプリミティブを前記知識ベースサーバへの問い合わせ形式に変換させ、該変換されたＩＮ−ＩＳプリミティブを前記制御情報送受信部を介して前記知識ベースサーバを有するノードへ送信し、
前記知識ベースサーバを有するノードから、前記ＩＮ−ＩＳプリミティブに対する応答を前記制御情報送受信部を介して受信すると、該受信した応答を前記レイヤ間協調部を介して前記ＩＮ−ＩＳプリミティブの要求元のレイヤに出力する
ことを特徴とする。
【００１８】
本発明に係る通信制御方法では、前記ノード間協調手順では、前記ノード間協調部が、前記制御情報として、他ノード内のいずれかのレイヤから、自ノード内の対象とするレイヤで発生したイベントの通知を要求するＩＮ−ＥＳプリミティブを前記制御情報送受信部を介して受信すると、該受信した前記ＩＮ−ＥＳプリミティブに対応する要求を登録し、登録されている前記要求に一致するイベントが発生すると、当該要求の送信元に向けた応答用の制御情報を生成し、前記制御情報送受信部を介して前記ＩＮ−ＥＳプリミティブの要求元のノードに送信してもよい。
【発明の効果】
【００１９】
本発明によれば、各ノードの各レイヤから収集した情報を提供可能な汎用的なクロスレイヤ協調アーキテクチャを提供することができる。
【図面の簡単な説明】
【００２０】
【図１】本実施形態に係る通信制御システムの一例を示す。
【図２】本実施形態に係るＬ２プリミティブの一例を示す。
【図３】本実施形態に係るＬ３プリミティブの一例を示す。
【図４】ハンドオーバによって帯域が減少する場合の一例を示す。
【図５】ＣＥＡＬアーキテクチャの一例を示す。
【図６】ＣＥＡＬのＬ２プリミティブの一例を示す。
【図７】ＣＥＡＬのインタラクションモデルを示す。
【図８】ＣＥＡＬによる高速ハンドオーバの処理手順
【図９】ＣＥＡＬのＬ３プリミティブの一例を示す。
【図１０】ＣＥＡＬによるＳＣＴＰの高速フェイルオーバ手順の一例を示す。
【図１１】ＩＥＥＥ  ８０２．２１の参照モデルの一例を示す。
【発明を実施するための形態】
【００２１】
添付の図面を参照して本発明の実施形態を説明する。以下に説明する実施形態は本発明の実施の例であり、本発明は、以下の実施形態に制限されるものではない。なお、本明細書及び図面において符号が同じ構成要素は、相互に同一のものを示すものとする。
【００２２】
（実施形態１）
図１に、本実施形態に係る通信制御システムの一例を示す。本実施形態に係る通信制御システムは、複数のノード１０の備わる通信ネットワークを制御するための通信制御システムである。本実施形態では、一例として、通信ネットワークが４つのノード１０を備える場合を示し、さらに、ノード１０のうちの第１のノード１０が、（ｎ−ｍ）レイヤから（ｎ＋２）レイヤまでを有する例について示した。
【００２３】
図２に提案方式におけるリンクレイヤ（Ｌ２）のプリミティブを、図３にネットワークレイヤ（Ｌ３）のプリミティブを示す。ＩＳはＩｎｆｏｒｍａｔｉｏｎ  Ｓｅｒｖｉｃｅであり、対象とするレイヤの情報を取得するためのプリミティブである。ＥＳはＥｖｅｎｔ  Ｓｅｒｖｉｃｅであり、対象とするレイヤで発生したイベントを非同期に受信するためのプリミティブである。ＣＳはＣｏｍｍａｎｄ  Ｓｅｒｖｉｃｅであり、対象とするレイヤの動作を指示するためのプリミティブである。また、ＩＮ−ＩＳはノード間クロスレイヤ協調でのＩｎｆｏｒｍａｔｉｏｎ  Ｓｅｒｖｉｃｅを、ＩＮ−ＥＳはノード間クロスレイヤ協調でのＥｖｅｎｔ  Ｓｅｒｖｉｃｅを表す。
【００２４】
ノード１０はエンドホストやルータなどのノードを表す。ノード１０のうちの第１のノードはノード１０間でのクロスレイヤ協調を実行しようとするノードである。先行技術のＣＥＡＬと同様に、ノード内部にはレイヤごとにプロトコルを処理する実体であるＰＥ（Ｐｒｏｔｏｃｏｌ  Ｅｎｔｉｔｙ）１１と、プロトコルやデバイス依存の制御情報をプロトコルやデバイスに非依存の制御情報に変換するＡＥ（Ａｂｓｔｒａｃｔ  Ｅｎｔｉｔｙ）１２が対になっている。
【００２５】
各ノード１０は、知識ベース部としてのＫＢ（Ｋｎｏｗｌｅｄｇｅ  Ｂａｓｅ）クライアント１６と、制御情報送受信部としてのＬ３制御プレーン１５と、レイヤ間協調部としてのＩＬＳ１３と、ノード間協調部としてのＩＮＳ（Ｉｎｔｅｒ−Ｎｏｄｅ  Ｓｙｓｔｅｍ）１４と、を備える。各ノードのＬ３制御プレーン１５は、互いにプリミティブなどの各種制御情報を送受信する。ＩＬＳ１３は、各レイヤに共通の形式で表された自ノード内の各レイヤからの制御情報を交換する。ＩＮＳ１４は、ＩＬＳ１３、ＫＢクライアント１６又はＬ３制御プレーン１５のいずれかから制御情報を取得し、制御情報の内容に応じて、当該制御情報を、ＩＬＳ１３、ＫＢクライアント１６又はＬ３制御プレーン１５のいずれかへ出力する。
【００２６】
ＫＢクライアント１６は、ＩＮ−ＩＳプリミティブを処理するために用いられる。いずれかのノード１０のＫＢクライアント１６は、全ノード１０についてのノードに関する情報を格納するＫＢ（Ｋｎｏｗｌｅｄｇｅ  Ｂａｓｅ）サーバとして機能する。例えば、第４のノード１０のように、ネットワーク内の選ばれたノードはＫＢサーバの役割を果たす。
【００２７】
本実施形態に係る通信制御方法は、レイヤ間協調手順と、ノード間協調手順と、を順に有する。
レイヤ間協調手順では、各ノードにおけるＡＥ１２を用いて、各レイヤから出力された制御情報を、各レイヤに共通の形式で表された制御情報に変換し、ＩＬＳ１３へ出力する。
ノード間協調手順では、各ノードにおけるＩＮＳ１４を用いて、ＩＬＳ１３からの制御情報を、当該制御情報の内容に応じて、他ノード１０に送信するか又はＫＢクライアント１６へ問い合わせる。
【００２８】
ノード内のクロスレイヤ協調の場合は、レイヤ間協調手順の後に、ＣＥＡＬと同様にＡＥ１２によって変換された制御情報がＩＬＳ（Ｉｎｔｅｒ−Ｌａｙｅｒ  Ｓｙｓｔｅｍ）１３を介して交換される。例えば、破線で示すように、（ｎ−ｍ）レイヤのＡＥ１２と（ｎ）レイヤのＡＥ１２は、ＩＬＳ１３を介して制御情報を交換する。
【００２９】
ＩＮ−ＥＳの場合、ノード間協調手順において、プリミティブは、実線で示すように、ＩＬＳ１３からＩＮＳ１４に渡され、さらにＬ３制御プレーン１５を介してノード１０間で転送され、各ノード１０にＩＮ−ＥＳの要求を登録していく。例えば、第１のノード１０のプリミティブが、実線で示すように、Ｌ３制御プレーン１５を介して第２のノード１０及び第３のノード１０に転送され、登録される。
【００３０】
ＩＮ−ＥＳの要求が登録されたノード１０で対象となるイベントが発生すると、ＩＮ−ＥＳの要求が登録された経路を逆にたどってＩＮ−ＥＳを要求したＡＥ１２にイベント発生が通知される。例えば、第３のノード１０のあるレイヤでイベントが発生した場合、要求時の経路である実線で示される経路をたどって第１のノード１０の（ｎ＋１）レイヤのＡＥ１２へ通知される。
【００３１】
ＩＮ−ＩＳの場合、ノード間協調手順において、プリミティブはＩＬＳ１３からＩＮＳ１４に渡され、さらにＫＢクライアント１６に渡される。ＫＢクライアント１６はＩＮ−ＩＳプリミティブを解釈して知識ベース問い合わせ形式に変換し、これをＬ３制御プレーン１５を介して該当するＫＢサーバへ転送する。例えば、２点鎖線で示すように、第１のノード１０の（ｎ＋２）レイヤからのプリミティブがＫＢクライアント１６に渡され、ＫＢクライアント１６からのプリミティブが第１のノード１０のＬ３制御プレーン１５から第４のノード１０のＬ３制御プレーン１５へ送信される。第４のノード１０のＫＢクライアント１６が第１のノード１０のＫＢクライアント１６からの問い合わせに応答し、第４のノード１０のＬ３制御プレーン１５から第１のノード１０のＬ３制御プレーン１５へ応答が送信される。
【００３２】
以上説明したように、本実施形態に係る発明は、汎用的なクロスレイヤ協調アーキテクチャとするため、ＰＥ１１に対してＡＥ１２を導入して制御情報をプロトコルやデバイスに依存しない形式に変換し、ＩＬＳ１３を介して任意のレイヤ間で制御情報を交換する。本実施形態に係る発明は、ノード間のクロスレイヤ協調を可能にするため、ＩＮＳ１４とＬ３制御プレーン１５を導入した。また、各ノード１０から収集した生データからより高度な加工した情報を提供するため、ＫＢサーバを導入した。また、各ノード１０にはＫＢサーバに問い合わせるためにＫＢクライアント１６を導入した。
【００３３】
（Ｌ３−ＰａｔｈＳｔａｔＣｈａｎｇｅｄの実行例）
第１のノード１０内の（ｎ＋１）レイヤにおけるＰＥ１１は、あるノード（例えば第ｎのノード）との通信中に経路（パス）が切断した場合は即座にこのイベントを知りたいとする。（ｎ＋１）レイヤにおけるＰＥ１１はまずＬ３−ＰａｔｈＳｔａｔＣｈａｎｇｅｄ．ｒｅｑを（ｎ＋１）レイヤにおけるＡＥ１２を介してＩＬＳ１３に発行する。このとき、引数としてパスの終点アドレス（この例では第ｎノードのアドレス）と知りたいパス状態の種類（この例ではパスの切断）を指定する。ＩＬＳ１３はこのＬ３−ＰａｔｈＳｔａｔ．Ｃｈａｎｇｅｄ．ｒｅｑの終点アドレスが別ノードであることを判別し、Ｌ３−ＰａｔｈＳｔａｔＣｈａｎｇｅｄ．ｒｅｑをＩＮＳ１４に渡す。ＩＮＳ４１はＬ３−ＰａｔｈＳｔａｔＣｈａｎｇｅｄ．ｒｅｑを第ｎのノード１０に向けて送信する。Ｌ３−ＰａｔｈＳｔａｔＣｈａｎｇｅｄ．ｒｅｑは第１のノード１０のＬ３制御プレーン１５を介して第２のノード、第３のノード、・・・と第ｎのノードに向かって転送されていく。各ノード１０では転送の際、Ｌ３制御プレーン１５とＩＮＳ１４にこの要求が登録される。第ｎのノード１０がＬ３−ＰａｔｈＳｔａｔＣｈａｎｇｅｄ．ｒｅｑを受信すると、第ｎのノード１０におけるＩＮＳ１４がＬ３−ＰａｔｈＣｈａｎｇｅｄ．ｃｏｎｆを生成し、第１のノード１０に返送する。Ｌ３−ＰａｔｈＣｈａｎｇｅｄ．ｃｏｎｆはＬ３−ＰａｔｈＣｈａｎｇｅｄ．ｒｅｑが転送された経路の逆をたどって第１のノード１０のＬ３制御プレーン１５に到達し、最終的には（ｎ＋１）レイヤにおけるＰＥ１１に到達する。
【００３４】
第３のノード１０は第１のノード１０が送信したＬ３−ＰａｔｈＳｔａｔＣｈａｎｇｅｄ．ｒｅｑを中継したノードとし、自ノードが接続しているリンクに障害を検知したとする。第３のノード１０内ではＬ２がＬ２−ＬｉｎｋＳｔａｔＣｈａｎｇｅｄ．ｉｎｄを生成し、ＩＬＳ１３に通知する。
【００３５】
第３のノード１０のＩＬＳ１３はさらにこれをＩＮＳ１４に通知する。第３のノード１０のＩＮＳ１４には第１のノード１０が発行したＬ３−ＰａｔｈＳｔａｔＣｈａｎｇｅｄ．ｒｅｑが登録されているため、ＩＮＳ１４はＬ３−ＰａｔｈＳｔａｔＣｈａｎｇｅｄ．ｉｎｄを生成し、Ｌ３制御プレーン１５を介してこれを第１のノード１０に向けて送信する。Ｌ３−ＰａｔｈＳｔａｔＣｈａｎｇｅｄ．ｉｎｄは第２のノード１０を経て第１のノード１０のＬ３制御プレーン１５に到達する。そしてＩＮＳ１４、ＩＬＳ１３および（ｎ＋１）レイヤのＡＥ１２を介して（ｎ＋１）レイヤのＰＥ１１に通知される。
【００３６】
本提案手法では通信経路上のリンク障害をエンドノードが素早く検知することが可能となり、このような場合でも素早くフェイルオーバを実行することができるようになる。
【００３７】
（Ｌ３−ＰａｔｈＳｔａｔの実行例）
第１のノード１０の（ｎ＋２）レイヤのＰＥ１１は、あるノード（第ｎのノード１０）への経路の中で、帯域が１Ｍｂｐｓ、遅延が２０ｍｓ以下の経路を知りたいとする。ＰＥ１１はまずＡＥ１２を介してＬ３−ＰａｔｈＳｔａｔ．ｒｅｑをＩＬＳ１３に発行する。このとき引数として終点アドレス（この例の場合は第ｎのノード１０のアドレス）および取得したい情報（この例の場合は経路とその条件である帯域１Ｍｂｐｓと遅延２０ｍｓ）を指定する。ＩＬＳ１３はこのＬ３−ＰａｔｈＳｔａｔの終点アドレスが他ノードであることを判別し、Ｌ３−ＰａｔｈＳｔａｔ．ｒｅｑをＩＮＳ１４に渡す。ＩＮＳ１４はさらにこれをＫＢクライアント１６に渡す。ＫＢクライアント１６はＬ３−ＰａｔｈＳｔａｔ．ｒｅｑの内容を知識ベース問い合わせ言語に変換し、第４のノード１０に存在するＫＢサーバに向けて知識ベース問い合わせを送信する。この知識ベース問い合わせは第２のノード１０を経て第４のノード１０上のＫＢサーバに到達する。ＫＢサーバは知識ベース問い合わせへの回答を生成し、第１のノード１０上のＫＢクライアント１６に送信する。
【００３８】
ここで、ＫＢサーバは、各ノード１０に関する情報を格納する。各ノード１０に関する情報は、各ノードの各レイヤにおける通信状態であり、例えば、ノード間の接続情報（トポロジー）、各リンクの最大帯域、各リンクの遅延、各リンクで使用されている帯域である。このため、ＫＢクライアント１６を用いてＫＢサーバに問い合わせることで、各ノードから収集した生データからより高度な加工した情報を提供することが可能になる。
【００３９】
以上述べたように、提案手法では、ＫＢクライアント１６及びＫＢサーバを利用することにより、エンドノードは帯域と遅延などの条件を満たす経路といった加工したデータを取得できるようになる。
【００４０】
（実施形態２）
本実施形態では、図４に示すように、列車９５に移動ルータ９１が設置され、ＷｉＦｉや３Ｇ無線技術などでインターネットに接続する場合を考える。移動ルータ９１は車内にはＷｉＦｉによるＬＡＮを提供し、車内の携帯機器９４は移動ルータ９１を介してインターネットに接続する。列車９５の移動により、移動ルータ９１はハンドオーバしながら通信を継続する。たとえば移動ルータ９１がＷｉＦｉアクセスルータ９２のエリアから３Ｇアクセスルータ９３のエリアにハンドオーバする際、ハンドオーバの前後で利用可能帯域が大きく減少する。このとき、携帯機器９４のＴＣＰ（トランスポートレイヤ（Ｌ４））は利用可能帯域が大きく減少したことに気づかないため、ハンドオーバ前の状況での輻輳制御を行うため、無線リンクが輻輳してしまい、多くのパケットロスが発生することが考えられる。
【００４１】
本実施形態では、移動ルータ９１には車内ＬＡＮの情報を管理するＫＢサーバが設置されているとする。車内の携帯機器９４のＴＣＰはＬ３−ＰａｔｈＳｔａｔＣｈａｎｇｅｄ．ｒｅｑを発行することにより、通信経路の状態変化を取得して最適な輻輳制御を目指すとする。この要求は携帯機器９４のＫＢクライアント１６から移動ルータ９１のＫＢサーバに通知され、ＫＢサーバに登録される。一方、移動ルータ９１のネットワークレイヤ（Ｌ３）はノード内のクロスレイヤ協調によりハンドオーバを予測し、その事象をＫＢサーバに登録する。
【００４２】
ＫＢサーバはハンドオーバによって利用可能帯域が大きく減少することを検知し、ハンドオーバ終了後直ちに登録されているＬ３−ＰａｔｈＳｔａｔＣｈａｎｇｅｄ．ｒｅｑに対してＬ３−ＰａｔｈＳｔａｔＣｈａｎｇｅｄ．ｉｎｄを生成し、携帯機器９４に通知する。携帯機器９４のＬ３制御プレーン１５がＬ３−ＰａｔｈＳｔａｔＣｈａｎｇｅｄ．ｉｎｄを受信すると、携帯機器９４のＩＮＳ１４及びＩＬＳ１３がこれをＴＣＰに知らせる。ＴＣＰは利用可能帯域が大きく減少したことを知り、それに合わせた輻輳制御を行うことにより無線リンクの輻輳を回避し、結果としてパケットロスを回避することができる。
【産業上の利用可能性】
【００４３】
本発明は情報通信産業に適用することができる。
【符号の説明】
【００４４】
１０：ノード
１１：ＰＥ
１２：ＡＥ
１３：ＩＬＳ
１４：ＩＮＳ
１５：Ｌ３制御プレーン
１６：ＫＢクライアント
１７：ＳＡＰ
９１：移動ルータ
９２：ＷｉＦｉアクセスルータ
９３：３Ｇアクセスルータ
９４：携帯機器
９５：列車
９６：通信相手
【図１】
0005845133.tif 000002
【図２】
0005845133.tif 000003
【図３】
0005845133.tif 000004
【図４】
0005845133.tif 000005
【図５】
0005845133.tif 000006
【図６】
0005845133.tif 000007
【図７】
0005845133.tif 000008
【図８】
0005845133.tif 000009
【図９】
0005845133.tif 000010
【図１０】
0005845133.tif 000011
【図１１】
0005845133.tif 000012