JP2011135422A - 通信システムおよび通信制御装置 - Google Patents

Abstract

【課題】
通信品質要求の厳しい傾向にあるミッションクリティカルな通信サービスに対しても柔軟に信頼性が高い通信経路を確保する。
【解決手段】
端末61,62とアプリケーションサーバ71,72間の有線区間の単一経路内，あるいは，無線区間の単一経路内で通信サービスに要求される通信品質を満たすように経路を制御するだけでなく，モバイルアプリケーション基盤サーバ1と仮想ネットワーク調停サーバ4により、有線区間の複数の経路間，あるいは，無線区間の複数の経路間で前記要求通信品質を満たすように経路選択を実行し，かつそれを動的に実行する。
【選択図】図２

Description

本発明は情報通信システム、特に端末とサーバ間の要求通信品質、経路の通信特性の変化に対応する通信制御技術に関する。

昨今の世界的なインターネット及びインターネット接続サービスの普及により，通信ネットワークが社会インフラとして必須となってきた。こうした通信ネットワークを活用した様々なサービスは，今後もますます普及し，さらに高信頼通信を必要とするミッションクリティカルなケースも含め新たなサービスが次々に創出されていくと考えられる。また，こうした新たなサービスにおいては，携帯電話に代表されるモバイル無線端末が必ず使われる。したがって，有線のみならず無線も含んだアクセス網と有線のコア網から構成される広範囲な通信ネットワークにおいて，サービス毎に必要となる通信品質を確保して高信頼な通信を実現することが大きな課題の１つとなる。

現状の通信ネットワークでは，所謂ベストエフォートの品質で端末毎に通信経路が提供される場合が多く，複数の端末（またはユーザ）間，あるいは複数種類のサービス間では，ほとんど区別が無く，通信経路上のリソース不足により，通信利用が不可能となる場合が多い。音声や映像のストリーム送信などの特定のサービスに限定的な利用においては，データのカテゴリ別優先度に基づいた送信制御を実現している場合もあるが，あくまでも端末（またはユーザ）毎にベストエフォートによる通信を前提としており，同時接続ユーザ数や，他のユーザの利用状況に応じて，通信が切断されてしまうような不安定な通信状況となる。

従来技術として，通信ネットワークの通信品質を制御する手段は既にいくつか存在している。例えば，特許文献１や特許文献２がある。

特許文献１は，始点ノードから終点ノードまでの経路計算において，始点ノードから終点ノードまでの遅延制約値を満たし，かつリンクコストが最も小さい経路（最短経路）を探索して，設定する発明である。ただし，本公知例では，端末単位に考慮されてない。また，本公知例では，動的な経路計算を想定していない。すなわち，本公知例は，通信キャリアが自社の有線のネットワークインフラにおいて，静的に通信路の品質を予め設定することを前提としており，かつ，静的な通信品質の設定で十分な比較的安定した有線ネットワークを前提としていると推測できる。

特許文献２は，インターネットテレビやインターネットラジオなどのコンテンツを高速・高品質で受信する際に，無線アクセスネットワークおよび有線ネットワークの帯域設定を連動させ，コンテンツデータ毎にコンテンツに応じた必要にして十分な帯域を確保する方法を開示している。また，帯域が確保できない場合に動的にコンテンツのデータ配信レートを変更する概念を開示している。しかし，無線アクセスネットワーク及び有線ネットワークのいずれにおいても複数の経路を前提としておらず，単一の無線経路と単一の有線経路内での通信品質制御についてのみ開示しており，複数経路間での経路の切替を想定していない。

特開2008-048114号公報 特開2004-274700号公報

上述の従来技術においては，例えば，ヘテロ型の無線ネットワーク環境において，端末の移動に伴う電波環境に応じて，利用する無線ネットワークを携帯電話網から無線ＬＡＮへ切替えたり，併せて有線ネットワーク側も連動させて複数の有線ネットワークの経路から通信特性が適切となる経路に切替えたりすることは実現できていない。

本発明の課題は，上記のような仕組みを実現して，通信品質要求の厳しい傾向にあるミッションクリティカルな通信サービスに対しても柔軟に信頼性が高い通信経路を確保することである。

すなわち，ある通信端末が通信ネットワークを介してあるアプリケーションサーバに接続してサービスを享受しようとした場合に，通信特性の異なる複数の経路を含む有線区間と通信特性の異なる複数の経路を含む無線区間を含む通信ネットワーク環境下において，通信端末とアプリケーションサーバとの間で要求する要求通信品質に対して，特許文献２のように有線区間の単一経路内，あるいは，無線区間の単一経路内で前記要求通信品質を満たすように経路を制御するだけでなく，有線区間の複数の経路間，あるいは，無線区間の複数の経路間で前記要求通信品質を満たすように経路選択を制御することである。

さらに，上述の要求通信品質の変更や，前記経路の通信特性の変化に対して，動的に経路選択を制御することも本発明の課題である。

上記の課題を達成するため、本発明においては、複数の経路を有する無線通信区間と複数の経路を有する有線通信区間とに接続された通信制御装置、あるいはそれを利用する通信システムにおいて、通信制御装置を、無線通信区間の複数の経路と，有線通信区間の複数の経路の通信特性を取得する手段を備え，無線通信区間に接続された端末と有線通信区間に接続されたサーバとの間でデータ通信要求があった場合に、無線通信区間と有線通信区間とによる通信特性が，データ通信要求で指定された通信品質を満たす（例えば，通信時間の総和が指定した遅延時間以下となる，通信帯域の最小値が指定したデータレート以上となる）ように、無線通信区間の複数の経路及び有線通信区間の複数の経路の中からそれぞれ経路を選択し，該選択した経路を通信端末およびサーバへ通知する構成とする。

また、経路の特性変化に基づく動的な経路の再選択のため、通信制御装置を，選択された適切な経路を，データ通信要求毎（ある端末と，あるサーバと，その間で実現するアプリケーションとの組合せ毎）にそのデータ通信要求と共に，保持し，管理する手段と，選択された無線通信区間の通信特性（状況）と選択された有線通信区間の通信特性とを予め指定された頻度で取得する手段とを備え，個々のデータ通信要求の単位で利用している無線側経路，あるいは有線側経路，あるいは両方の経路において通信特性の変化（劣化あるいは改善）を検知した場合に，無線通信区間の複数の経路及び有線通信区間の複数の経路の中からそれぞれ適切な経路を再選択する構成とする。

更に、要求変化に基づく動的な経路の再選択のための通信制御装置を、データ通信要求は，少なくとも端末のＩＤ，サーバのＩＤ，および通信品質の値からなり，データ通信要求に含まれる通信品質の値に変化があった場合に，無線通信区間の複数の経路及び有線通信区間の複数の経路の中から，それぞれ適切な経路を動的に再選択する構成とする。

また更に、通信制御装置を、データ通信要求の要求値が上り通信と下り通信で異なる場合には，適切な経路を上り通信と下り通信で個別に選択し，維持管理する構成とする。

なお、通信品質，あるいは，通信特性は，遅延時間及び／あるいは通信帯域である。

本発明によれば、端末毎，あるいは，アプリケーションサービス毎に，端末とアプリケーションサーバとの間で要求する通信品質やその変更，さらに経路の通信特性の変化に対して，ロバストで高信頼な通信ネットワークを提供できる。例えば，従来であればネットワークの通信特性の変化に伴い接続が切断してしまった状況でも，切断しにくくなって，より長い時間継続してサービスを利用できるようになったり，全く切断せずに継続してサービスを利用できるようになったりする。

本発明の第１の実施例のシステムの全体概念を示す図である。 第１の実施例に係る、システム構成図を示す図である。 第１の実施例に係る、モバイルアプリケーション基盤サーバのハードウェア構成の一例を示す図である。 第１の実施例に係る、モバイルアプリケーション基盤サーバが保持するテーブルの一例を示す図である。 第１の実施例に係る、モバイルアプリケーション基盤サーバが保持するテーブルの他の例を示す図である。 第１の実施例に係る、通信状況収集の手順を説明するシーケンス図である。 第１の実施例に係る、要求通信品質を満たすリンク確立の手順（１）を説明するシーケンス図である。 第１の実施例に係る、要求通信品質を満たすリンク確立の手順（２）を説明するシーケンス図である。 第１の実施例に係る、要求通信品質を満たすリンク確立の手順（３）を説明するシーケンス図である。 第１の実施例に係る、要求通信品質を満たすリンク確立の手順（４）を説明するシーケンス図である。 第１の実施例に係る、要求通信品質を満たすリンク確立の手順（５）を説明するシーケンス図である。 第１の実施例に係る、要求通信品質を満たさずにリンク確立の手順（６）を説明するシーケンス図である。 第１の実施例に係る、通信特性が変化した場合にリンクを維持する手順を説明するシーケンス図である。 第１の実施例に係る、モバイルアプリケーション基盤サーバの通信状況収集におけるフローチャート図である。 第１の実施例に係る、モバイルアプリケーション基盤サーバにおいて，アプリケーションからの要求に対して，リンク確立をするためのフローチャート図である。 第１の実施例に係る、通信特性の変化に対して，リンク確立をするためのフローチャート図である。 第１の実施例に係る、モバイルアプリケーション基盤サーバにおいて，調停処理のフローチャート図である。

以下、本発明の代表的な実施例を図面に従い説明する。

図１に，第１の実施例によるシステムの全体概念を示す。ここでは同図の(a)のアプリケーションの視点（アプリ視点），同図の(b)の仮想ネットワーク（仮想Network: NW）視点，同図の(c)の物理ネットワーク（物理NW）視点の３つの視点から本実施例によるシステムを概説する。

第１の(a)アプリ視点では，端末側のアプリケーションプロセスAP1とアプリケーションサーバ側のアプリケーションプロセスAP2との間において，ある通信品質(最大許容遅延時間が100ms，最大許容ジッタが10ms，最低必要帯域が10Mbps等で指定)で通信セッションを張りたいという要求を示している。本実施例によるシステムは，この通信品質の要求を満足するように，使用する仮想ネットワーク(仮想NW)や無線アクセスネットワーク(Radio Access Network: RAN)を調停する。

第２の(b)仮想NW視点では，アプリ視点で示した要求を元に，モバイルアプリケーション基盤サーバ1（または通信制御装置）が主導して，端末側のAP1とサーバ側のAP2との間の通信品質の調整を行う様子を示している。モバイルアプリケーション基盤サーバ1は，各RAN1,RAN2から収集する無線品質情報や無線リソース使用状況の情報と，仮想NW調停サーバ4を介して収集する各仮想ネットワーク5のリンク情報とを元に，アプリケーションが要求する通信品質を確保できるよう調停を行う。この結果，調停がうまくいけば最終的にAP1−AP2間において要求される通信品質での通信が可能となるが，要求する通信品質の調整ができなかった場合には，例えば端末側のAP1とサーバ側のAP2がネゴシエーションを行い，アプリケーションとしての要求品質自体を低くすることで接続性を確保することになる。

最後に(c)物理NW視点では，アプリケーションの通信セッションのためのIPレベルでのEnd-to-Endのネットワークのつながりを示している。端末は，RAN1もしくはRAN2の無線アクセスネットワークを用い，それぞれのRANを終端するゲートウェイ(Gateway: GW)を介して仮想ネットワーク網に接続し，その先のアプリケーションサーバ70とのやり取りを行う。ここで，GW同士はモバイルネットワークゲートウェイ(Mobile Network Gateway: MN-GW)2を介して接続される。

以上のように，端末で要求される通信品質を確保し(高品質)，確保できない場合でも最低限の接続性を保つ(高信頼性)点が本発明によるシステムの特長となる。

図２に実環境を想定した第１の実施例のシステム構成図の一例を示す。本構成においては，RAN側の情報を集約して主にRANを調整するモバイルアプリケーション基盤サーバ1と，仮想NW側の情報を集約し複数の仮想NWを主に調整する仮想NW調停サーバ4が互いに連携しながら，アプリケーション（端末A61,端末B62あるいはアプリケーションサーバA71,アプリケーションサーバB72）で要求される通信品質を満たすEnd-to-Endの通信リンクを確立する。

まず初めに無線側の説明を行う。RAN3としてはRAN1 31とRAN2 32の2つのサブシステムが利用でき，端末61あるいは62は２つのRANを切り替えてもしくは同時に２つのRANを利用できる機能を有するとする。各RANはそれぞれのGW311,321で終端され，各GW同士は上述の通りMN-GW2に接続され，MN-GW2によってRANの切り替えが可能な構成となっている。モバイルアプリケーション基盤サーバは各GWからRAN内の情報を集約する。一方で仮想NW側は，仮想NW調停サーバ4が，仮想NW5内の仮想化対応ルータ51の接続を切り替える機能を持ち，随時複数の仮想NWリンクを確保し管理している。

端末A61からアプリケーションサーバA71への接続要求がモバイルアプリケーション基盤サーバ1に届くと，モバイルアプリケーション基盤サーバ1と仮想NW調停サーバ4間はそれぞれのRANや仮想NWの情報を元に要求に見合う組合せを決めるために調停を行う。使用する仮想NWリンクやRANが決定すると，仮想NW調停サーバ4は使用する仮想NWリンクに切り替えを行い，また，モバイルアプリケーション基盤サーバ1はMN−GW2にRAN切り替えの指示を出しRANの切り替えが行われ，最終的に端末-アプリケーションサーバ間での通信が行われる。

また，使用しているRANや仮想NWの品質が劣化した場合にも，再度モバイルアプリケーション基盤サーバ1−仮想NW調停サーバ4間で調停を行い，RAN内の通信品質の改善，RAN間の切り替え，仮想NWリンク内の通信品質の改善，仮想NW内のリンクの切り替えにより，アプリケーションより本来要求されていた通信品質を確保するように動作する。万が一，上記調停によっても要求された品質を実現できない場合には，端末内のAP1とアプリケーションサーバ内のAP2のアプリケーションプロセス同士が直接やり取りを行い，アプリケーションが要求する通信品質を下げる。これにより，最初に要求された品質での通信はできないが，通信品質の劣化による接続の切断等は防ぐことが可能であり，最低限の接続性は確保される。

以下，より具体的に本実施例のシステムの構成を説明する。

まず，本実施例におけるシステムの主要な通信制御装置であるモバイルアプリケーション基盤サーバ1の一構成について説明する。

図３は，モバイルアプリケーション基盤サーバ通信制御装置1の一例のハードウェア構成図を示している。ハードウェアとしては，図に示すように少なくとも，中央処理部（Central Processing Unit: CPU）11，リードオンリメモリ（Read Only Memory: ROM）12、ランダムアクセスメモリ(Random Access Memory: RAM)13，ハードディスクドライブ(Hard Disk Drive: HDD)14，ネットワークインタフェース(Network Interface: NIF）15、あるいはネットワークインタフェースカード(Network Interface Card: NIC)を含み，市販の一般的なサーバ（例えば，日立製作所製アドバンストサーバHA8000シリーズ）で実装可能である。

また，モバイルアプリケーション基盤サーバ１は，RAM13，あるいは，HDD14にソフトウェアプログラム及びデータを保持し，ソフトウェアプログラムの実行により適宜データを参照しながら所望の処理を行う。処理の詳細については後述する。なお，図３に示す通り，保持する主なデータには，無線ネットワーク(NW）通信状況テーブル131，有線ネットワーク(NW）通信状況テーブル132，アプリケーション管理テーブル133の３種類がある。

図４及び図５は，それぞれモバイルアプリケーション基盤サーバ1が保持する３種類のテーブルの具体例を示す。

図４の（ａ）は無線NW通信状況テーブル131、図４の（ｂ）は有線NW通信状況テーブル132、図４の（ｃ）はアプリケーション管理テーブル133の例をそれぞれ示している。

図４の（ａ）の無線NW通信状況テーブル131は，モバイルアプリケーション基盤サーバが管理対象とする無線アクセスネットワーク（RAN）の通信状況を保持するテーブルである。図では３つのRAN(RAN#1,RAN#2,RAN#3)の通信状況に関して，各RANを利用した場合の帯域幅（”Band Width”），遅延時間（”Delay”）の例を示している。これらの値は，例えば，ある特定の時間（例えば１０秒間）での平均値とすればよいし，あるいはほぼ保障できる値としてもよい。また，同テーブルの“アプリ識別(Identifier: ID)”は各RANをどのアプリケーションが使用しているかを保持しており，図では，”AP#1”が”RAN#1”を使用しており，”RAN#2”と”RAN#3”は使用しているアプリケーションがない場合の例を示している。このテーブルの値は，モバイルアプリケーション基盤サーバが各RANのゲートウェイに問合せた結果によって更新される。

図４の（ｂ）の有線NW通信状況テーブル132は，モバイルアプリケーション基盤サーバが管理対象とする有線ネットワークの通信状況を保持するテーブルである。図では３つの仮想ネットワーク（VN#1,VN#2,VN#3）の通信状況に関して，各仮想ネットワークを利用した場合の帯域幅（”Band Width”），遅延時間（”Delay”）の例を示している。これらの値は，例えば，ある特定の時間（無線ネットワークも変動が少なく安定していることから，例えば１分間）での平均値とすればよいし，あるいはほぼ保障できる値としてもよい。また，同テーブルの“アプリ識別ID”は各仮想ネットワークをどのアプリケーションが使用しているかを保持しており，図では，”AP#1”が”VN#1”を使用しており，”VN#2”と”VN#3”は使用しているアプリケーションがない場合の例を示している。このテーブルの値は，モバイルアプリケーション基盤サーバが仮想ネットワーク調停サーバに問合せた結果によって更新される。

図４の（ｃ）のアプリケーション管理テーブル133は，モバイルアプリケーション基盤サーバが管理しているアプリケーションの状況を保持するテーブルである。図では，アプリケーション”AP#1”が”192.168.121.14/24”で識別される端末と”192.168.100.10/24”で識別されるサーバとの間で通信しており，そのアプリケーションが要求する帯域幅が”10Mbps”，要求する遅延時間が”120msec”であり，さらに割当てられ使用している無線アクセスネットワークが”RAN#1”，使用している仮想ネットワークが”VN#1”であることを示している。このテーブルの値は，アプリケーション基盤サーバがアプリケーションの経路を調停して割当てる経路が更新されると同時に更新される。

図５は，図４の各テーブルの別な例を示している。特に，図５の（ａ）無線NW通信状況テーブル131において，その通信状況を示す指標について，最大値，最小値，平均，標準偏差の組合せで保持する例を示している。これは，一般的には有線ネットワークよりも無線ネットワークの方が通信状況は不安定であり，指標を増やすことにより通信状況が不安定ながらもより適切な経路が割り当てられるようになる。一方，図５の（ｂ）有線NW通信状況テーブル132では，平均値，最大値，最小値のいずれかで十分である。図５の（ｃ）は，テーブルの構造は図４の（ｃ）と同一であり，例示している値が異なるだけである。

次に，本実施例のシステム全体の動作を多様な場合のシーケンス例に沿って説明する。動作シーケンスは大きく３種類に分類でき，通信状況収集シーケンス，要求通信品質リンク確立シーケンス，通信品質劣化回復シーケンスがある。
一種類目のシーケンスは，定期的に実行される通信状況収集シーケンスである。図６に通信状況収集シーケンス図の一例を示す。図６に例示している通り，モバイルアプリケーション基盤サーバ1が主導してシーケンスが進行され，各RAN3内のGW311,321(以下、300で代表する)に通信状況問合せメッセージ601を送信し，通信状況返答602を受け取り、GW300で集約される各RAN内の各種無線通信情報（帯域、遅延時間等）をRAN毎に取得したり，仮想ネットワーク調停サーバ4に通信状況問合せメッセージ604を送信し，通信状況返答605を受け取り、仮想ネットワーク調停サーバ4で集約される各仮想ネットワーク5の通信状態を取得したりして，取得した情報に基づいてネットワーク状況を保持する前述した無線ＮＷ通信状況テーブル131や有線ＮＷ通信状況テーブル132の保持データで変化があったデータの更新603や更新606を行う。

なお，図では，モバイルアプリケーション基盤サーバから各RAN内GW300への通信状況問合せメッセージ及び通信状況返答メッセージはそれぞれ１本の矢印で表現しているが，実際のメッセージ送信はRANの数だけ実行される。また，無線側（RAN側）からの情報収集の周期と，有線側（仮想NW側）からの情報収集の周期は別々に設定できるものとする。図６では，それぞれx[ms]と、y[ms]と例示している。

本実施例の二種類目のシーケンスは，要求通信品質リンク確立シーケンスである。端末とアプリケーションサーバが連携してアプリケーションサービスが最初起動されEnd-to-Endの通信セッションの確立要求が発生した場合，あるいは，アプリケーションサービス利用中に，通信品質の要求が変更になった場合，実行されるシーケンスである。本実施例においては、このシーケンスに従って端末とアプリケーションサーバ間の品質を保証したリンクが確立される。

アプリケーションが要求する通信品質が決定すると，モバイルアプリケーション基盤サーバ1は，通信状況テーブル(図４あるいは図５)を参照してRAN及び仮想NWのリンクの組み合わせ候補を決定する。選択した組み合わせ候補が要求通信品質を満足する場合には，その組み合わせにて使用NWの通知，接続の処理を行う。満たす組み合わせがない場合は，仮に決定した仮想NWやRANの改善を依頼して要求する通信品質を満足するリンクを確立するか，仮想NW間あるいはRAN間を跨って改善を依頼して要求する通信品質を満足するリンクを確立する。

すなわち，２種類目のシーケンスは，要求を満たすリンクの組み合わせがあるかないか，ない場合にはどの部分で吸収するかにより，次に示す6つのケースがある。
・ 候補リンク，または，既存リンク利用のままで調停必要なし
・ 仮想NW内で吸収可能
・ 仮想NW間で吸収可能
・ RAN内で吸収可能
・ RAN間で吸収可能
・ 仮想NW，RANともに吸収不可能で，アプリ側が品質を譲歩
以下，図７〜図１２に上記6つのケースの動作シーケンス詳細を示す。

図７に調停の必要がない場合のシーケンス図を示す。なお，本ケースの前提として，モバイル端末60とアプリケーションサーバ（アプリサーバ）70の間の通信経路は無線アクセスネットワークRAN#1と仮想ネットワークVN#1を介して既に確立されており，無線アクセスネットワークRAN#1は通信帯域幅（BW）2Mbps以上かつ通信遅延(Delay)が150msec以下の通信品質で提供され，仮想ネットワークVN#1は通信帯域幅(BW)2Mbps以上かつ通信遅延(Delay)が80msec以下の通信品質で提供されているものとする。

このシーケンスでは，まずモバイル端末60でユーザの操作などによりサービスレベル、アプリケーション（QoSアプリ）AP#1のプログラムが起動701される。すると次に，モバイル端末60あるいはアプリケーションAP#1のプログラムでは，アプリケーションサーバ70との通信に対して新たに要求する通信品質を決定する。ここで，通信品質の決定は，サーバと調整することなくモバイル端末自身が予め保持している情報（固定プロファイル）に基づいて決定702しても良いし，図中に破線で示しているように通信相手となるアプリケーションサーバ70と通信して情報交換することによって必要な通信品質を決定703してもよい。

通信品質が決定すると，次にモバイル端末60がモバイルアプリケーション基盤サーバ1に通信品質要求メッセージ704を送る。なお，アプリケーションサーバ70が決定した通信品質を把握している場合には，アプリケーションサーバ70が通信品質要求メッセージをモバイルアプリケーション基盤サーバ1に送信してもよい。この通信品質要求メッセージ704には，通信相手の情報と，通信帯域幅，通信遅延などの指標による要求する通信品質の情報を含んでおり，ここでは通信品質として，”通信帯域幅(BW)が2Mbps以上”かつ”通信遅延(Delay)が300msec以下”を要求しているとする。また，必ずしも一つのアプリケーションサーバとは限らず、通信相手は複数あっても良い。

モバイルアプリケーション基盤サーバ1は，保持している無線NW通信状況テーブル131及び有線NW通信状況テーブル132を参照し，受け取った通信品質要求メッセージに含まれる通信品質の経路に関して，調停及び経路の再配分の要否判定705を行う。本ケースは，通信帯域はRAN#1の値とVN#1の値で小さい方2Mbpsで提供可能であり，通信遅延はRAN#1の値とVN#1の値との和300msecで提供可能であり，テーブル内の組合せで既に要求を満たしていると判定し，調停及び経路の再配分は不要のため実行しない。

次に，モバイルアプリケーション基盤サーバ1は，保持しているアプリ管理テーブル133に，新規で開始されるアプリケーションの関連情報を追加してテーブルを更新706する。さらに，モバイルアプリケーション基盤サーバ1は，モバイルネットワークゲートウェイ（MN-GW）2に対して，モバイル端末60とアプリケーションサーバ70との間でアプリケーションAP#1が使用するネットワークの情報（”RAN#1”と”VN#1”）を通知707する。MN-GW2は，受信した情報を元に，ルーティングテーブルの対応する値を更新708し，モバイルアプリケーション基盤サーバ1に更新完了（”OK”）の通知709を返信する。

次に，モバイルアプリケーション基盤サーバ1は，アプリケーションサーバ70に対して，モバイル端末60と今回のアプリケーションAP#1を実行する場合に仮想ネットワーク”VN#1”を使うように通知710する。アプリケーションサーバ70は，受信した情報を元に今回のアプリケーションAP#1が使う仮想ネットワーク”VN#1”を設定711し，設定完了（”OK”）の通知712を返信する。

最後に，アプリケーション基盤サーバ1は，通信品質の要求元であるアプリ端末60に，確保できた通信経路に関して，使用する無線アクセスネットワーク(“RAN#1”)と使用できる通信品質(通信帯域幅が2Mbps以上，かつ，通信遅延が(150msec以下+80msec以下=)230msec以下)を返信713する。モバイル端末60は，要求した通信品質が確保できたことを確認し，このアプリケーションAP#1で使用する無線アクセスネットワーク(“RAM#1”)を設定714した上で，アプリケーションサーバ70とのアプリケーション通信715を開始し，MN-GW2のルーティングを経由して、アプリケーションAP#1によるサービスを享受する。

図８に仮想NW内で吸収可能な場合のシーケンス図の一例を示す。なお，本ケースの前提として，モバイル端末60とアプリケーションサーバ（アプリサーバ）70の間の通信経路は無線アクセスネットワークRAN#1と仮想ネットワークVN#1を介して既に確立されており，無線アクセスネットワークRAN#1は通信帯域幅（BW）2Mbps以上かつ通信遅延(Delay)が150msec以下の通信品質で提供され，仮想ネットワークVN#1は通信帯域幅(BW)2Mbps以上かつ通信遅延(Delay)が80msec以下の通信品質で提供されているものとする。以下の説明において、図７のシーケンスとの差分のある部分についてのみ、数番を使って説明し、差分のない部分は数番を省略して説明する。図９以下においても同様である。

このシーケンスでは，まずモバイル端末60でユーザの操作などによりアプリケーション（QoSアプリ）プログラムが起動される。すると次に，モバイル端末60あるいはアプリケーションプログラムでは，アプリケーションサーバ70との通信に対して新たに要求する通信品質を決定する。ここで，通信品質の決定は，モバイル端末自身が予め保持している情報に基づいて決定しても良いし，図中に破線で示しているように通信相手となるアプリケーションサーバ70と通信して情報交換することによって必要な通信品質を決定してもよい。通信品質が決定すると，次にモバイル端末60がモバイルアプリケーション基盤サーバ1に通信品質要求メッセージを送る。なお，アプリケーションサーバ70が決定した通信品質を把握している場合には，アプリケーションサーバ70が通信品質要求メッセージをモバイルアプリケーション基盤サーバに送信してもよい。この通信品質要求メッセージには，通信相手の情報と，通信帯域幅，通信遅延などの指標による要求する通信品質の情報を含んでおり，ここでは通信品質として，”通信帯域幅(BW)が2Mbps以上”かつ”通信遅延(Delay)が200msec以下”を要求しているとする。また，通信相手は複数あっても良い。

モバイルアプリケーション基盤サーバ1は，保持している無線ＮＷ通信状況テーブル131及び有線ＮＷ通信状況テーブルを参照し，受け取った通信品質要求メッセージに含まれる通信品質の経路に関して，調停及び経路の再配分の要否判定を行う。本ケースの場合は，通信帯域幅はRAN#1の値とVN#1の値で小さい方は2Mbpsであり要求を満たすが，通信遅延はRAN#1の値とVN#1の値との和230msecとなり要求を満たせない判定801される。したがって，モバイルアプリケーション基盤サーバ1は，調停及び経路の再配分処理への移行が必要となる。このときモバイルアプリケーション基盤サーバ1は，仮想ネットワーク調停サーバ4に対して，利用中であるVN#1の通信帯域幅は維持したまま，通信遅延を80msec以下から50msec以下に変更するための通信品質要求メッセージ802を送信する。

仮想ネットワーク調停サーバ4は，その通信品質メッセージを受信すると，VN#1を形成している装置を制御し，通信遅延の改善、すなわち調整803を試みる。本ケースでは，50msecへの改善が可能で、調整が成功した場合を表しており，仮想ネットワーク調停サーバ4は，変更完了(“OK”)の通知を変更後の通信品質（通信帯域幅が2Mbps以上，かつ，通信遅延が50msec以下）と共に返信804する。

次に，モバイルアプリケーション基盤サーバ1は，仮想ネットワーク調停サーバ4からの通信品質変更完了の通知を受けて調停成功の判定805を行い，保持しているアプリ管理テーブル133に，新規で開始されるアプリケーション情報を追加、更新806する。さらに，モバイルアプリケーション基盤サーバ1は，モバイルネットワークゲートウェイ2に対して，モバイル端末60とアプリケーションサーバ70との間のアプリケーションが使用するネットワークの情報（”RAN#1”と”VN#1”）を通知807する。

MN-GW2は，受信した情報を元に，ルーティングテーブルの対応する値を更新し，モバイルアプリケーション基盤サーバ1に更新完了（”OK”）の通知を返信する。次に，モバイルアプリケーション基盤サーバ1は，アプリケーションサーバ70に対して，モバイル端末60と今回のアプリケーションAP#1を実行する場合に仮想ネットワーク”VN#1”を使うように通知する。アプリケーションサーバ70は，受信した情報を元に今回のアプリケーションが使う仮想ネットワーク”VN#1”を設定し，設定完了（”OK”）の通知を返信する。最後に，アプリケーション基盤サーバ1は，通信品質の要求元であるアプリ端末60に，確保できた通信経路に関して，使用する無線アクセスネットワーク(“RAN#1”)と，使用できる通信品質(通信帯域幅が2Mbps以上，かつ，通信遅延が(150msec以下+50msec以下=)200msec以下)を返信する。モバイル端末60は，要求した通信品質が確保できたことを確認し，このアプリケーションAP#1で使用する無線アクセスネットワーク(“RAM#1”)を設定した上で，アプリケーションサーバ70との通信を開始する。

図９に仮想NWを切り替えることにより仮想NW間で吸収可能な場合のシーケンス図を示す。なお，本ケースの前提として，モバイル端末60とアプリケーションサーバ（アプリサーバ）70の間の通信経路は無線アクセスネットワークRAN#1と仮想ネットワークVN#1を介して既に確立されており，無線アクセスネットワークRAN#1は通信帯域幅（BW）2Mbps以上かつ通信遅延(Delay)が150msec以下の通信品質で提供され，仮想ネットワークVN#1は通信帯域幅(BW)2Mbps以上かつ通信遅延(Delay)が80msec以下の通信品質で提供されているものとする。

このシーケンスでは，まずモバイル端末60でユーザの操作などによりアプリケーション（QoSアプリ）プログラムが起動される。すると次に，モバイル端末60あるいはアプリケーションプログラムでは，アプリケーションサーバ70との通信に対して新たに要求する通信品質を決定する。ここで，通信品質の決定は，モバイル端末自身が予め保持している情報に基づいて決定しても良いし，図中に破線で示しているように通信相手となるアプリケーションサーバ70と通信して情報交換することによって必要な通信品質を決定してもよい。通信品質が決定すると，次にモバイル端末60がモバイルアプリケーション基盤サーバ1に通信品質要求メッセージを送る。なお，アプリケーションサーバ70が決定した通信品質を把握している場合には，アプリケーションサーバ70が通信品質要求メッセージをモバイルアプリケーション基盤サーバに送信してもよい。この通信品質要求メッセージには，通信相手の情報と，通信帯域幅，通信遅延などの指標による要求する通信品質の情報を含んでおり，ここでは通信品質として，”通信帯域幅(BW)が2Mbps以上”かつ”通信遅延(Delay)が200msec以下”を要求しているとする。また，通信相手は複数あっても良い。

モバイルアプリケーション基盤サーバ1は，保持している無線NW通信状況テーブル131及び有線NW通信状況テーブル132を参照し，受け取った通信品質要求メッセージに含まれる通信品質の経路に関して，調停及び経路の再配分の要否判定を行う。本ケースは，通信帯域幅はRAN#1の値とVN#1の値で小さい方は2Mbpsであり要求を満たすが，通信遅延はRAN#1の値とVN#1の値との和230msecとなり要求を満たせない判定901される。したがって，モバイルアプリケーション基盤サーバ1は，調停及び経路の再配分処理への移行が必要となる。

このときモバイルアプリケーション基盤サーバ1は，仮想ネットワーク調停サーバ4に対して，利用中であるVN#1の通信帯域幅(2Mbps以上)は維持したまま，通信遅延を80msec以下から50msec以下に変更するための通信品質要求メッセージを送信902する。仮想ネットワーク調停サーバ4は，その通信品質メッセージを受信すると，VN#1を形成している装置を制御し，通信遅延の改善調整903を試みる。

本ケースでは，VN#1の通信遅延50msecへの改善が不可能であり、調停が失敗した場合を表しており，仮想ネットワーク調停サーバ4は，変更失敗(“NG”)の通知904を、変更されていない通信品質（通信帯域幅が2Mbps以上，かつ，通信遅延が80msec以下）と共に返信する。

次に，モバイルアプリケーション基盤サーバ1は，配分判定905により他の仮想ネットワーク#2に経路変更することを試み，仮想ネットワーク調停サーバ4に対して，別の仮想ネットワークVN#2を使用して通信帯域幅2Mbps以上，かつ，通信遅延50msec以下を要求するための通信品質要求メッセージを送信906する。仮想ネットワーク調停サーバ4は，その通信品質要求メッセージを受信すると，VN#2での調整907を試みる。

本ケースでは，その調整が成功した場合を想定しており，仮想ネットワーク調停サーバ4は，モバイルアプリケーション基盤サーバ1に対して，VN#2での調停成功(“OK”)の通知と共に提供できる通信品質（通信帯域幅が2Mbps以上であり，かつ，通信遅延が50msec以下）を返信している。

次に，モバイルアプリケーション基盤サーバ1は，仮想ネットワーク調停サーバ4からの通信品質調停成功の通知を受けて，保持しているアプリ管理テーブル133に，新規で開始されるアプリケーション情報を追加する。さらに，モバイルアプリケーション基盤サーバ1は，モバイルネットワークゲートウェイ2に対して，モバイル端末60とアプリケーションサーバ70との間のアプリケーションが使用するネットワークの情報（”RAN#1”と”VN#2”）を通知する。

MN-GW2は，受信した情報を元に，ルーティングテーブルの対応する値を更新し，モバイルアプリケーション基盤サーバ1に更新完了（”OK”）の通知を返信する。

次に，モバイルアプリケーション基盤サーバ1は，アプリケーションサーバ70に対して，モバイル端末60と今回のアプリケーションAP#1を実行する場合に仮想ネットワーク”VN#2”を使うように通知する。アプリケーションサーバ70は，受信した情報を元に今回のアプリケーションが使う仮想ネットワーク”VN#2”を設定し，設定完了（”OK”）の通知を返信する。

最後に，アプリケーション基盤サーバ1は，通信品質の要求元であるアプリ端末60に，確保できた通信経路に関して，使用する無線アクセスネットワーク(“RAN#1”)と，使用できる通信品質(通信帯域幅が2Mbps以上，かつ，通信遅延が(150msec以下+50msec以下=)200msec以下)を返信する。モバイル端末60は，要求した通信品質が確保できたことを確認し，このアプリケーションAP#1で使用する無線アクセスネットワーク(“RAM#1”)を設定した上で，アプリケーションサーバ70との通信を開始する。なお，このとき，モバイル端末60は，どの仮想ネットワークを使用しているか（"VN#1”か”VN#2”か）を知る必要はなく，さらにモバイルネットワークゲートウェイ2とアプリケーションサーバ70の間で使用する仮想ネットワークが変更されたことも知る必要はない。

図１０に仮想NW側で調整できずにRAN内で吸収可能な場合のシーケンス図を示す。なお，本ケースの前提として，モバイル端末60とアプリケーションサーバ（アプリサーバ）70の間の通信経路は無線アクセスネットワークRAN#1と仮想ネットワークVN#1を介して既に確立されており，無線アクセスネットワークRAN#1は通信帯域幅（BW）2Mbps以上かつ通信遅延(Delay)が150msec以下の通信品質で提供され，仮想ネットワークVN#1は通信帯域幅(BW)2Mbps以上かつ通信遅延(Delay)が80msec以下の通信品質で提供されているものとする。

このシーケンスでは，まずモバイル端末60でユーザの操作などによりアプリケーション（QoSアプリ）プログラムが起動される。すると次に，モバイル端末60あるいはアプリケーションプログラムでは，アプリケーションサーバ70との通信に対して新たに要求する通信品質を決定する。ここで，通信品質の決定は，モバイル端末自身が予め保持している情報に基づいて決定しても良いし，図中に破線で示しているように通信相手となるアプリケーションサーバ70と通信して情報交換することによって必要な通信品質を決定してもよい。通信品質が決定すると，次にモバイル端末60がモバイルアプリケーション基盤サーバ1に通信品質要求メッセージを送る。なお，アプリケーションサーバ70が決定した通信品質を把握している場合には，アプリケーションサーバ70が通信品質要求メッセージをモバイルアプリケーション基盤サーバに送信してもよい。この通信品質要求メッセージには，通信相手の情報と，通信帯域幅，通信遅延などの指標による要求する通信品質の情報を含んでおり，ここでは通信品質として，”通信帯域幅(BW)が2Mbps以上”かつ”通信遅延(Delay)が200msec以下”を要求しているとする。また，通信相手は複数あっても良い。

モバイルアプリケーション基盤サーバ1は，保持している無線ＮＷ通信状況テーブル131及び有線ＮＷ通信状況テーブルを参照し，受け取った通信品質要求メッセージに含まれる通信品質の経路に関して，調停及び経路の再配分の要否判定を行う。本ケースは，通信帯域幅はRAN#1の値とVN#1の値で小さい方は2Mbpsであり要求を満たすが，通信遅延はRAN#1の値とVN#1の値との和230msecとなり要求を満たせないことがわかる。したがって，モバイルアプリケーション基盤サーバ1は，調停及び経路の再配分処理への移行が必要となる。このときモバイルアプリケーション基盤サーバ1は，仮想ネットワーク調停サーバ4に対して，利用中であるVN#1の通信帯域幅(2Mbps以上)は維持したまま，通信遅延を80msec以下から50msec以下に変更するための通信品質要求メッセージを送信する。仮想ネットワーク調停サーバ4は，その通信品質メッセージを受信すると，VN#1を形成している装置を制御し，通信遅延の改善、調整1001を試みる。

本ケースでは，VN#1の通信遅延50msecへの改善が不可能であり、調停が失敗し，さらに別の仮想ネットワークVN#2を使っても通信遅延の50msecへの改善が失敗した場合を表しており，仮想ネットワーク調停サーバ4は，モバイルアプリケーション基盤サーバ1に対して，変更失敗(“NG”)の通知1002を，変更されていない通信品質（通信帯域幅が2Mbps以上，かつ，通信遅延が80msec以下）と共に２度返信している。なお、ここで変形例として少しだけ対応する、例えば、10msecだけ短縮するという対応もありうる。

次に，モバイルアプリケーション基盤サーバ1は，配分判定1003で無線アクセスネットワーク側での調停を試み，RAN#1内のゲートウェイ310に対して，RAN#1を使用して通信帯域幅2Mbps以上のまま，通信遅延を150msec以下から120msec以下への変更を要求するための通信品質要求メッセージ1004を送信する。

RAN#1内のゲートウェイ310は，その通信品質要求メッセージを受信すると，RAN#1での調整1005を試みる。本ケースでは，その調整が成功した場合を想定しており，RAN#1内のゲートウェイ310は，モバイルアプリケーション基盤サーバ1に対して，RAN#1での調停成功(“OK”)の通知と共に提供できる通信品質（通信帯域幅が2Mbps以上であり，かつ，通信遅延が120msec以下）1006を返信している。

次に，モバイルアプリケーション基盤サーバ1は，RAN#1内のゲートウェイ310からの通信品質調停成功の通知を受けて，保持しているアプリ管理テーブル133に，新規で開始されるアプリケーション情報を追加する。さらに，モバイルアプリケーション基盤サーバ1は，モバイルネットワークゲートウェイ2に対して，モバイル端末60とアプリケーションサーバ70との間のアプリケーションが使用するネットワークの情報（”RAN#1”と”VN#1”）を通知する。モバイルネットワークゲートウェイ2は，受信した情報を元に，ルーティングテーブルの対応する値を更新し，モバイルアプリケーション基盤サーバ1に更新完了（”OK”）の通知を返信する。次に，モバイルアプリケーション基盤サーバ1は，アプリケーションサーバ70に対して，モバイル端末60と今回のアプリケーションAP#1を実行する場合に仮想ネットワーク”VN#1”を使うように通知する。アプリケーションサーバ70は，受信した情報を元に今回のアプリケーションが使う仮想ネットワーク”VN#1”を設定し，設定完了（”OK”）の通知を返信する。最後に，アプリケーション基盤サーバ1は，通信品質の要求元であるアプリ端末60に，確保できた通信経路に関して，使用する無線アクセスネットワーク(“RAN#1”)と，使用できる通信品質(通信帯域幅が2Mbps以上，かつ，通信遅延が(120msec以下+80msec以下=)200msec以下)を返信する。モバイル端末60は，要求した通信品質が確保できたことを確認し，このアプリケーションAP#1で使用する無線アクセスネットワーク(“RAM#1”)を設定した上で，アプリケーションサーバ70との通信を開始する。

図１１にRANを切り替えることによりRAN間で吸収可能な場合のシーケンス図を示す。なお，本ケースの前提として，モバイル端末60とアプリケーションサーバ（アプリサーバ）70の間の通信経路は無線アクセスネットワークRAN#1と仮想ネットワークVN#1を介して既に確立されており，無線アクセスネットワークRAN#1は通信帯域幅（BW）2Mbps以上かつ通信遅延(Delay)が150msec以下の通信品質で提供され，仮想ネットワークVN#1は通信帯域幅(BW)2Mbps以上かつ通信遅延(Delay)が80msec以下の通信品質で提供されているものとする。

このシーケンスでは，まずモバイル端末60でユーザの操作などによりアプリケーション（QoSアプリ）プログラムが起動される。すると次に，モバイル端末60あるいはアプリケーションプログラムでは，アプリケーションサーバ70との通信に対して新たに要求する通信品質を決定する。ここで，通信品質の決定は，モバイル端末自身が予め保持している情報に基づいて決定しても良いし，図中に破線で示しているように通信相手となるアプリケーションサーバ70と通信して情報交換することによって必要な通信品質を決定してもよい。通信品質が決定すると，次にモバイル端末60がモバイルアプリケーション基盤サーバ1に通信品質要求メッセージを送る。なお，アプリケーションサーバ70が決定した通信品質を把握している場合には，アプリケーションサーバ70が通信品質要求メッセージをモバイルアプリケーション基盤サーバに送信してもよい。この通信品質要求メッセージには，通信相手の情報と，通信帯域幅，通信遅延などの指標による要求する通信品質の情報を含んでおり，ここでは通信品質として，”通信帯域幅(BW)が2Mbps以上”かつ”通信遅延(Delay)が200msec以下”を要求しているとする。また，通信相手は複数あっても良い。

モバイルアプリケーション基盤サーバ1は，保持している無線ＮＷ通信状況テーブル131及び有線ＮＷ通信状況テーブルを参照し，受け取った通信品質要求メッセージに含まれる通信品質の経路に関して，調停及び経路の再配分の要否判定を行う。本ケースは，通信帯域幅はRAN#1の値とVN#1の値で小さい方は2Mbpsであり要求を満たすが，通信遅延はRAN#1の値とVN#1の値との和230msecとなり要求を満たせないことがわかる。したがって，モバイルアプリケーション基盤サーバ1は，調停及び経路の再配分処理への移行が必要となる。このときモバイルアプリケーション基盤サーバ1は，仮想ネットワーク調停サーバ4に対して，利用中であるVN#1の通信帯域幅(2Mbps以上)は維持したまま，通信遅延を80msec以下から50msec以下に変更するための通信品質要求メッセージを送信する。仮想ネットワーク調停サーバ4は，その通信品質メッセージを受信すると，VN#1を形成している装置を制御し，通信遅延の改善を試みる。

本ケースでは，図１０のケースと同様に，VN#1の通信遅延50msecへの改善が失敗し，さらに別の仮想ネットワークVN#2を使っても通信遅延の50msecへの改善が失敗した場合を表しており，仮想ネットワーク調停サーバ4は，モバイルアプリケーション基盤サーバ1に対して，変更失敗(“NG”)の通知を，変更されていない通信品質（通信帯域幅が2Mbps以上，かつ，通信遅延が80msec以下）と共に２度返信している。

次に，モバイルアプリケーション基盤サーバ1は，無線アクセスネットワーク側での調停を試み，RAN#1内のゲートウェイ310に対して，RAN#1を使用して通信帯域幅2Mbps以上のまま，通信遅延を150msec以下から120msec以下への変更を要求するための通信品質要求メッセージを送信する。

RAN#1内のゲートウェイ310は，その通信品質要求メッセージを受信すると，RAN#1での調整1101を試みる。本ケースでは，さらにここでも不可能とされ、調整が失敗した場合を想定しており，RAN#1内のゲートウェイ310は，モバイルアプリケーション基盤サーバ1に対して，RAN#1での調停失敗(“NG”)の通知1102を返信している。

次に，モバイルアプリケーション基盤サーバ1は，別の無線アクセスネットワークでの調停判定1103を試み，RAN#2内のゲートウェイ320に対して，RAN#2を使用して通信帯域幅2Mbps以上，かつ，通信遅延が120msec以下の通信品質の提供を要求するための通信品質要求メッセージ1104を送信する。本ケースでは，RAN#2での調停1105が成功した場合を想定しており，RAN#2内のゲートウェイ320は，モバイルアプリケーション基盤サーバ1に対して，調停成功(“OK”)の通知と共に，RAN#2が提供可能な通信品質（通信帯域2Mbps以上，通信遅延120msec以下）1106を返信している。

次に，モバイルアプリケーション基盤サーバ1は，RAN#2内のゲートウェイ320からの通信品質調停成功の通知を受けて，保持しているアプリ管理テーブル133に，新規で開始されるアプリケーション情報を追加する。さらに，モバイルアプリケーション基盤サーバ1は，モバイルネットワークゲートウェイ2に対して，モバイル端末60とアプリケーションサーバ70との間のアプリケーションが使用するネットワークの情報（”RAN#2”と”VN#1”）を通知する。モバイルネットワークゲートウェイ2は，受信した情報を元に，ルーティングテーブルの対応する値を更新し，モバイルアプリケーション基盤サーバ1に更新完了（”OK”）の通知を返信する。次に，モバイルアプリケーション基盤サーバ1は，アプリケーションサーバ70に対して，モバイル端末60と今回のアプリケーションAP#1を実行する場合に仮想ネットワーク”VN#1”を使うように通知する。アプリケーションサーバ70は，受信した情報を元に今回のアプリケーションが使う仮想ネットワーク”VN#1”を設定し，設定完了（”OK”）の通知を返信する。

最後に，アプリケーション基盤サーバ1は，通信品質の要求元であるアプリ端末60に，確保できた通信経路に関して，使用する無線アクセスネットワーク(“RAN#2”)と，使用できる通信品質(通信帯域幅が2Mbps以上，かつ，通信遅延が(120msec以下+80msec以下=)200msec以下)を返信する。モバイル端末60は，要求した通信品質が確保できたことを確認し，このアプリケーションAP#1で使用する無線アクセスネットワーク(“RAM#1”)を設定した上で，アプリケーションサーバ70との通信を開始する。

図１２にRAN間でも吸収できない場合のシーケンス図を示す。なお，本ケースの前提として，モバイル端末60とアプリケーションサーバ（アプリサーバ）70の間の通信経路は無線アクセスネットワークRAN#1と仮想ネットワークVN#1を介して既に確立されており，無線アクセスネットワークRAN#1は通信帯域幅（BW）2Mbps以上かつ通信遅延(Delay)が150msec以下の通信品質で提供され，仮想ネットワークVN#1は通信帯域幅(BW)2Mbps以上かつ通信遅延(Delay)が80msec以下の通信品質で提供されているものとする。

このシーケンスでは，まずモバイル端末60でユーザの操作などによりアプリケーション（QoSアプリ）プログラムが起動される。すると次に，モバイル端末60あるいはアプリケーションプログラムでは，アプリケーションサーバ70との通信に対して新たに要求する通信品質を決定する。ここで，通信品質の決定は，モバイル端末自身が予め保持している情報に基づいて決定しても良いし，図中に破線で示しているように通信相手となるアプリケーションサーバ70と通信して情報交換することによって必要な通信品質を決定してもよい。通信品質が決定すると，次にモバイル端末60がモバイルアプリケーション基盤サーバ1に通信品質要求メッセージを送る。なお，アプリケーションサーバ70が決定した通信品質を把握している場合には，アプリケーションサーバ70が通信品質要求メッセージをモバイルアプリケーション基盤サーバに送信してもよい。この通信品質要求メッセージには，通信相手の情報と，通信帯域幅，通信遅延などの指標による要求する通信品質の情報を含んでおり，ここでは通信品質として，”通信帯域幅(BW)が2Mbps以上”かつ”通信遅延(Delay)が200msec以下”を要求しているとする。また，通信相手は複数あっても良い。

モバイルアプリケーション基盤サーバ1は，保持している無線ＮＷ通信状況テーブル131及び有線ＮＷ通信状況テーブルを参照し，受け取った通信品質要求メッセージに含まれる通信品質の経路に関して，調停及び経路の再配分の要否判定を行う。本ケースは，通信帯域幅はRAN#1の値とVN#1の値で小さい方は2Mbpsであり要求を満たすが，通信遅延はRAN#1の値とVN#1の値との和230msecとなり要求を満たせないことがわかる。したがって，モバイルアプリケーション基盤サーバ1は，調停及び経路の再配分処理への移行が必要となる。このときモバイルアプリケーション基盤サーバ1は，仮想ネットワーク調停サーバ4に対して，利用中であるVN#1の通信帯域幅(2Mbps以上)は維持したまま，通信遅延を80msec以下から50msec以下に変更するための通信品質要求メッセージを送信する。仮想ネットワーク調停サーバ4は，その通信品質メッセージを受信すると，VN#1を形成している装置を制御し，通信遅延の改善を試みる。

本ケースでは，図１０，図１１のケースと同様に，VN#1の通信遅延50msecへの改善が失敗し，さらに別の仮想ネットワークVN#2を使っても通信遅延の50msecへの改善が失敗した場合を表しており，仮想ネットワーク調停サーバ4は，モバイルアプリケーション基盤サーバ1に対して，変更失敗(“NG”)の通知を，変更されていない通信品質（通信帯域幅が2Mbps以上，かつ，通信遅延が80msec以下）と共に２度返信している。次に，モバイルアプリケーション基盤サーバ1は，無線アクセスネットワーク側での調停を試みる。また，本ケースは，図１１と同様に，モバイルアプリケーション基盤サーバ1は，RAN#1を使用して通信帯域幅2Mbps以上のまま通信遅延を150msec以下から120msec以下への変更を要求するが，不可能とされ、その調整が失敗し，続けて別の無線アクセスネットワークRAN#2での調停を試みている。本ケースでは，RAN#2での調停1201も失敗した場合を想定しており，RAN#2内のゲートウェイ320は，モバイルアプリケーション基盤サーバ1に対して，調停失敗(“NG”)の通知1202を返信している。

モバイルアプリケーション基盤サーバ1は，配分判定1203で通信品質要求メッセージの通信品質を満たせないと判定した場合，要求元であるモバイル端末60に対して，通信品質を満たす経路を提供できないこと(“NG”)を通知すると共に，提供可能な通信品質を返信1204する。

モバイル端末60は，要求した通信品質を満たす経路が提供できない返答をモバイルアプリケーション基盤サーバ1から受けた場合，同時に受信した提供可能な通知品質に基づいてアプリケーションの要求品質の変更決定（許容できる品質の低下）1205を行い、アプリケーションサーバ70に通知1206を行う。モバイル端末60は，変更した(譲歩した)要求通信品質1207をモバイルアプリケーション基盤サーバ1に送り，再度調停を行う(図７，８，９，１０，１１，１２，それぞれのシーケンスの最初の分岐に戻る)。この動作を繰り返すことで，最初に要求された品質より低い品質ではあるが，通信不可となることなくモバイル端末60とアプリケーションサーバ70との間の通信が可能となる。

なお，図７からの図１２のシーケンスは，動作中のアプリケーションが要求品質を変更する場合も基本的には同じシーケンスとなる。

本実施例における三種類目のシーケンスは，End-to-Endのリンクが確立された状態で，無線側の経路と有線側の経路のいずれか片方あるいは両方の通信特性に変化が生じた場合に行われる品質劣化回復フローである。

図１３に品質劣化回復フローシーケンスの一例を示す。なお，本ケースの前提として，モバイル端末60とアプリケーションサーバ（アプリサーバ）70の間の通信経路は無線アクセスネットワークRAN#1と仮想ネットワークVN#1を介して既に確立されており，無線アクセスネットワークRAN#1は通信帯域幅（BW）2Mbps以上かつ通信遅延(Delay)が120msec以下の通信品質で提供され，仮想ネットワークVN#1は通信帯域幅(BW)2Mbps以上かつ通信遅延(Delay)が80msec以下の通信品質で提供されているものとする。すなわち，End-to-Endでは，通信帯域幅が2Mbps以上であり，かつ，通信遅延が(120msec+80msec=)200msec以下の通信が可能となっている。

ここで無線アクセスネットワークRAN#1に何らかの原因で通信特性に劣化が生じたとする。その結果，RAN#1の通信品質において，通信遅延が120msec以下から150msec以下に劣化したとする。図にも示している通り，この劣化はモバイルアプリケーション基盤サーバ1が検出できる。

モバイルアプリケーション基盤サーバ1は，図６の説明で述べたように，定期的に各無線アクセスネットワーク及び各仮想ネットワークの通信状況問合せメッセージ1301を送信して，その返信として通信状況1302を取得し，取得した通信状況に基づき，有線NW通信状況テーブル132及び無線NW通信状況テーブル131の該当する値を更新する。

図１３の例では，RAN#1の劣化後に，遅くともx[msec]以内に通信品質が劣化したRAN#1の通信状況が無線NW通信状況テーブルに反映更新1303される。モバイルアプリケーション基盤サーバ1は，アプリ管理テーブル133に保持している各アプリケーションが使用している無線ネットワーク（無線アクセスネットワーク）の通信状況を無線NW通信状況テーブル131から取得し，同様に各アプリケーションが使用している有線ネットワーク（仮想ネットワーク）の通信状況を有線NW通信状況テーブル132から取得する。モバイルアプリケーション基盤サーバ1は，各アプリケーションに割当てられている無線ネットワークと有線ネットワークの通信状況からEnd-to-Endの通信状況を算出し，アプリ管理テーブル133に保持しているものが、要求している通信品質を満たしているか否かチェック1304する。例えば、アプリ要求をアプリ管理テーブル133で保持しているアプリ要求値（(EtoE)BW≧2Mbps, Delay≦200msec等）と，更新したNW通信状況テーブルの値との比較評価を行う。図１３の例では，ここでRAN#1の遅延時間が劣化していることが検出される。

図１３において，通信品質の劣化検出後のシーケンスは、図８〜図１２の何れかと同一となるが、図１３では図８と同様の仮想ネットワークのシーケンスである。すなわち本ケースでは，モバイルアプリケーション基盤サーバ1は，仮想ネットワーク調停サーバ4に対して，利用中であるVN#1の通信帯域幅は維持したまま，通信遅延を80msec以下から50msec以下に変更するための通信品質要求メッセージを送信する。仮想ネットワーク調停サーバ4は，その通信品質メッセージを受信すると，VN#1を形成している装置を制御し，通信遅延の改善を試みる。本ケースでは，50msecへの改善が成功した場合を表しており，仮想ネットワーク調停サーバ4は，変更完了(“OK”)の通知を変更後の通信品質（通信帯域幅が2Mbps以上，かつ，通信遅延が50msec以下）と共に返信する。

次に，モバイルアプリケーション基盤サーバ1は，仮想ネットワーク調停サーバ4からの通信品質変更完了の通知を受けて，保持しているアプリ管理テーブル133に，新規で開始されるアプリケーション情報を追加する。さらに，モバイルアプリケーション基盤サーバ1は，モバイルネットワークゲートウェイ2に対して，モバイル端末60とアプリケーションサーバ70との間のアプリケーションが使用するネットワークの情報（”RAN#1”と”VN#1”）を通知する。モバイルネットワークゲートウェイ2は，受信した情報を元に，ルーティングテーブルの対応する値を更新し，モバイルアプリケーション基盤サーバ1に更新完了（”OK”）の通知を返信する。ただし，図１３の例では実際には経路の変更がないためルーティングの変更は発生しない。したがって，モバイルアプリケーション基盤サーバ1は，モバイルネットワークゲートウェイ2に対して使用するネットワークの情報を通知しなくてもよい。

次に，モバイルアプリケーション基盤サーバ1は，アプリケーションサーバ70に対して，モバイル端末60と今回のアプリケーションAP#1を実行する場合に仮想ネットワーク”VN#1”を使うように通知する。アプリケーションサーバ70は，受信した情報を元に今回のアプリケーションが使う仮想ネットワーク”VN#1”を設定し，設定完了（”OK”）の通知を返信する。ただし，図１３の例では，アプリケーションサーバ70が使う仮想ネットワークは”VN#1”で変更がないため，モバイルアプリケーション基盤サーバ1からアプリケーションサーバ70への通知は省略してもよい。最後に，アプリケーション基盤サーバ1は，当初の通信品質の要求元であるアプリ端末60に，確保できた通信経路に関して，使用する無線アクセスネットワーク(“RAN#1”)と，End-to-Endで使用できる通信品質(通信帯域幅が2Mbps以上，かつ，通信遅延が(150msec以下+50msec以下=)200msec以下)を通知する。ただし，図１３の例では，モバイル端末60が使用する無線アクセスネットワークの変更がないため，本通知は省略してもよい。

なお，通信品質の劣化検出後のシーケンスは，各ネットワークの状況によって，図８から図１２のいずれかのシーケンスと同じ動作をたどることは言うまでもない。

次に，本実施例の中心であるモバイルアプリケーション基盤サーバ1に関して，上述した各シーケンスにおけるモバイルアプリケーション基盤サーバ1の動作を，対応するフローチャートを用いて説明する。

図１４に通信状況収集シーケンスに対応するモバイルアプリケーション基盤サーバ1内のフローチャートを示す。通信状況収集のプロセスは同図の(a)に示すＲＡＮ側と、同図の(b)に示す仮想ＮＷ側でパラレルに実行され，それぞれ独立の周期で実行される。モバイルアプリケーション基盤サーバ1は、スタート（1401）以降、周期的に，例えばｘ[msec]周期で，全ＲＡＮの各ＧＷに通信状況を問合せ，各ＧＷから結果を取得（1402）し，取得した結果に従い，無線ＮＷ通信状況テーブル（図４の（ａ））を更新する（1403）。そして、ｘ[msec]待ち（1404）後、繰り返す。

また，スタート(1406)後、モバイルアプリケーション基盤サーバ1は周期的に，例えばｙ[msec]周期で，仮想ＮＷ調停サーバ4に対して，全ての仮想ＮＷの通信状況を問合せ(1407)，結果を取得し，取得した結果に従い，仮想ＮＷ通信状況テーブル（図４の（ｂ））を更新する(1408)。そして、ｙ[msec]待ち(1409)後、繰り返す。なお，テーブル内の値は取得した情報を統計処理した結果（平均，最小値，最大値，など）を保持してもよい（図５の(ａ)及び図５の(ｂ)を参照）。

図１５のフローチャートは，図７から図１２までのシーケンスにおけるモバイルアプリケーション基盤サーバ1の処理フローを示す。この処理フローは図１４のフローチャートと独立に動作する。モバイルアプリケーション基盤サーバ1は，スタート(1501)後、アプリケーション要求の有無をチェックし（1502），要求が無い場合には一定時間（図ではw[msec]）待ってから（1507）、再度アプリケーション要求の有無をチェックする（1508）。

アプリケーション要求がある場合には，要求された通信品質に基づいて後述する図１７のリンク確立フローへ移行する（1504）。リンク確立フローの結果は，要求元に返信する（1506）。リンク確立が成功した場合は，要求元に”OK”の結果と共に提供する経路及びその通信品質を通知する。リンク確立が失敗した場合は，要求元に”NG”の結果と共に提供可能な通信品質を通知する。有無チェックに戻る（1506）。なお，アプリケーション要求の有無チェックを定期的に実行してリンク確立フローに移行する代わりに，アプリケーション要求の受信時に割り込み処理でリンク確立フローへ移行してもよい。

図１６のフローチャートは，図１３のシーケンスにおけるモバイルアプリケーション基盤サーバ1の処理フローを示す。この処理フローは，図１３，図１４のフローチャートと独立に動作する。

モバイルアプリケーション基盤サーバ1は，スタート(1601)後、アプリケーション管理テーブル133，無線ＮＷ通信状況テーブル131，有線ＮＷ通信状況テーブル132を基に，管理対象となっているアプリケーション毎に最新のEnd-to-Endの通信状況を計算して求め，アプリケーション毎に要求されている通信品質を満足するように維持されているかを稼動中の全ての管理対象であるアプリケーションについてチェックする（1602）。チェックした結果，要求に対して通信品質が劣化しているアプリケーションがない場合は，一定時間（図ではz[msec]）待って（1608）から再度通信状況のチェックを行う（1607）。

また，チェックした結果，要求に対して通信品質が劣化しているアプリケーションが抽出されると，後述する図１７のリンク確立フローへ移行する（1604）。状況チェックに再度移る（1605）。なお，通信状況のチェックは，各通信状況の取得の際に実行しても良い。さらに，通信状況の劣化だけでなく，通信状況の改善時に，アプリケーションの通信品質を向上するように通信品質要求を上げてリンク確立フロー移行してもよい。

図１７のフローチャートは，図１５及び図１６から呼び出されるリンク確立フローを示す。アプリケーション要求を受信した場合，あるいは，通信状況の劣化を検出した場合に呼ばれる。なお，通信状況が改善した場合にも呼ばれるように作成してもよい。新規に要求を受信した場合は，スタート（1701）後、仮の無線ネットワークと有線ネットワークの候補を選択する（1702）。なお、ここで品質劣化回復の場合は、現在の接続先組合せを保持する。

まず，仮のネットワーク，あるいは，既割当てのネットワークによって，アプリケーションが要求する通信品質が確保されているか否か，すなわち利用ネットワークの調停が必要か否かをチェックする（1703）。この時点で要求された通信品質を満たしていれば，調停は不要となり，アプリケーション管理テーブル133の更新（1704）へ移行する。

要求された通信品質を満たしていない場合は，初期化(1710)後、調停（1711）を開始する。調停を依頼するネットワークには４パターンあり，次の（１）から（４）までの優先度でいずれかで調停が成功するまで，あるいは（４）まで調停を依頼する。
（１）割当てられている有線ネットワーク（仮想ネットワーク）内での調停，
（２）割当てられている有線ネットワーク以外の有線ネットワークでの調停，
（３）割当てられている無線ネットワーク（ＲＡＮ）内での調停，
（４）割当てられている無線ネットワーク以外の無線ネットワークでの調停。

調停を依頼する場合は，（１）または（２）の有線ネットワークを対象にする場合は，仮想ネットワーク調整サーバ4に調停依頼を送信し，その結果を受信する。また，（３）または（４）の無線ネットワークを対象にする場合は，各無線ネットワークのゲートウェイに調停依頼を送信し，その結果を受信する。

４パターンのいずれかで調停が成功し，アプリケーションが要求する通信品質を満たせば（1713でYES），その割当ての無線ネットワーク及び有線ネットワークに基づいて，アプリケーション管理テーブル133の情報を更新する（1704）。次に，モバイルネットワークゲートウェイ2に対して，割当て割れた有線ネットワーク（仮想ネットワーク）及び無線ネットワーク（RAN）の関連情報を通知し，モバイルネットワークゲートウェイ2からの返信を受信する。次に，アプリケーションサーバ70に使用する有線ネットワーク（仮想ネットワーク）を通知し，続いて，モバイル端末60に使用する無線ネットワーク（RAN）を通知する。結果を”OK”に設定し，図１５あるいは図１６の上位のフローチャートへ戻る。

また，前述の４パターンのいずれでも調停が失敗した場合は，結果を”NG”に設定し，図１５あるいは図１６の上位フローチャートへ戻る。

以上詳述した実施例のように動作すれば，端末毎，あるいは，アプリケーションサービス毎に，端末とアプリケーションサーバとの間で要求する通信品質やその変更，さらに経路の通信特性の変化に対して，ロバストで高信頼な通信ネットワークを提供できる。

本発明は情報通信システム、特に端末とサーバ間の要求通信品質、経路の通信特性の変化に対応する通信制御技術として有用である。

1…通信制御装置（モバイルアプリケーション基盤サーバ）
2…モバイルネットワークゲートウェイ
3，31，32…無線アクセスネットワーク
4…仮想ネットワーク側の通信制御装置（仮想ネットワーク調整サーバ）
5…仮想ネットワーク
60，61，62…端末
70，71，72…アプリケーションサーバ
131…無線ネットワーク通信状況テーブル
132…有線ネットワーク通信状況テーブル
133…アプリケーション管理テーブル。

Claims (12)

1. 複数の経路を有する無線通信区間と複数の経路を有する有線通信区間とに接続された通信制御装置と、前記無線通信区間に接続された端末と，前記有線通信区間に接続されたサーバとからなる通信システムであって，
   前記通信制御装置は，
   前記無線通信区間の複数の経路と，前記有線通信区間の複数の経路の通信特性を取得する手段と，
   データ通信要求を受信する手段と，
   前記無線通信区間の複数の経路及び前記有線通信区間の複数の経路の中からそれぞれ任意の経路を選択し，該選択した経路を前記通信端末および前記サーバへ通知する手段を備え，
   前記端末あるいは前記サーバが要求元となり，前記端末と前記サーバとの間で通信するために必要な通信品質を含むデータ通信要求を送信し，
   前記通信制御装置が，前記データ通信要求を受信した場合に、前記無線通信区間と前記有線通信区間とによる通信特性が，前記データ通信要求で指定された通信品質を満たすように、前記無線通信区間の複数の経路及び前記有線通信区間の複数の経路の中からそれぞれ経路を選択し，前記選択された経路を前記端末および前記サーバへ通知する、
   ことを特徴とする通信システム。
2. 請求項１に記載の通信システムであって，
   前記通信制御装置は，
   前記選択された経路を，データ通信要求毎に該データ通信要求と共に，保持し，管理する手段と，
   前記選択された無線通信区間の通信特性と前記選択された有線通信区間の通信特性とを予め指定された頻度で取得する手段と，
   前記通信特性の変化を検知する手段と，
   前記通信特性の変化により前記データ通信要求を引き続き満たしているか否かを判断する手段を備え，
   前記データ通信要求は，少なくとも前記端末のＩＤ，前記サーバのＩＤ，および通信品質の値からなり，
   前記通信制御装置が，個々のデータ通信要求の単位で，利用している無線側経路と有線側経路のいずれか片方あるいは両方の経路において，通信特性の変化を検知し，かつ，通信特性の変化により前記管理しているデータ通信要求に含まれる通信品質を満たさなくなった場合に，前記無線通信区間の複数の経路及び前記有線通信区間の複数の経路の中からそれぞれ経路を動的に再選択する、
   ことを特徴とする通信システム。
3. 請求項２に記載の通信システムであって，
   前記通信制御装置は，新たなデータ通信要求を受信した際に，該データ通信要求に含まれる通信品質の値の変化を検出する手段を備え，
   前記通信品質の値の変化を検出した場合に，前記無線通信区間の複数の経路及び前記有線通信区間の複数の経路の中から，それぞれ経路を動的に再選択する、
   ことを特徴とする通信システム。
4. 請求項３に記載の通信システムであって，
   前記通信制御装置が，前記無線通信区間の複数の経路及び前記有線通信区間の複数の経路の中から，前記データ通信要求に対して経路を選択する場合に，
   第１ステップとして，有線側経路の通信特性の調整を試み，前記有線側経路の調整に成功した場合には前記有線側経路の調整により経路選択を終了とし，
   前記有線側経路の調整に失敗した場合には第２ステップとして，前記有線側経路の他の経路への切替を試み，前記有線側経路の切替に成功した場合は前記有線側経路切替により経路選択を終了とし，
   前記有線側経路の切替に失敗した場合には第３ステップとして，無線側経路の通信特性の調整を試み，前記無線側経路の調整に成功した場合には前記無線側経路の調整により経路選択を終了とし，
   前記無線側経路の調整に失敗した場合には第４のステップとして，前記無線側経路の他の経路への切替を試み，前記無線側経路の切替に成功した場合は前記無線側経路切替により経路選択を終了とし，
   前記無線側経路の切替に失敗した場合には第５のステップとして，経路選択は失敗とするが提供可能な通信特性を求め，
   最後のステップとして，前記データ通信要求の要求元に対して，経路選択が成功か失敗かの結果を送信し，結果が成功の場合には併せて提供する経路及び通信特性を送信し，また結果が失敗の場合には併せてデータ通信要求には満たないが提供可能な通信特性を送信し，
   前記データ通信要求の要求元である前記端末あるいは前記サーバが，経路選択の結果を受信し，結果が成功であった場合には通信を開始し，結果が失敗であった場合には要求する通信品質を変更して再度データ通信要求を送信する、
   ことを特徴とする通信システム。
5. 請求項４に記載の通信システムであって，
   前記データ通信要求の要求値が上り通信と下り通信で別々に設定されており，
   前記通信制御装置は，前記データ通信要求の要求値を上り通信と下り通信で個別に維持管理する手段を備え，
   前記データ通信要求の要求値が上り通信と下り通信で異なる場合には，上り通信と下り通信で個別に経路選択をし，上り通信と下り通信で個別に維持管理する、
   ことを特徴とする通信システム。
6. 請求項５に記載の通信システムであって，
   前記通信品質，あるいは，前記通信特性は，遅延時間，通信帯域，ジッタのいずれか１つ，あるいは，任意の組合せで表現する、
   ことを特徴とする通信システム。
7. 複数の経路を有する無線通信区間と複数の経路を有する有線通信区間とに接続された通信制御装置であって、
   前記無線通信区間の複数の経路と，前記有線通信区間の複数の経路の通信特性を取得する手段と，
   データ通信要求を受信する手段と，
   前記無線通信区間の複数の経路及び前記有線通信区間の複数の経路の中からそれぞれ任意の経路を選択し，前記選択された経路を前記通信端末および前記サーバへ通知する手段を備え，
   前記無線通信区間に接続された端末と前記有線通信区間に接続されたサーバとの間でのデータ通信要求を受信した場合に、前記無線通信区間と前記有線通信区間とによる通信特性が，前記データ通信要求で指定された通信品質を満たすように、前記無線通信区間の複数の経路及び前記有線通信区間の複数の経路の中からそれぞれ経路を選択し，該選択した経路を前記端末および前記サーバへ通知することを特徴とする通信制御装置。
8. 請求項７に記載の通信制御装置であって，
   前記選択された経路を，データ通信要求毎にそのデータ通信要求と共に，保持し，管理する手段と，
   前記選択された無線通信区間の通信特性と前記選択された有線通信区間の通信特性とを予め指定された頻度で取得する手段と，
   前記通信特性の変化を検知する手段と，
   前記通信特性の変化により前記データ通信要求を引き続き満たしているか否かを判断する手段を備え，
   前記データ通信要求は，少なくとも前記端末のＩＤ，前記サーバのＩＤ，および通信品質の値からなり，
   個々のデータ通信要求の単位で，利用している無線側経路と有線側経路のいずれか片方あるいは両方の経路において，通信特性の変化を検知し，かつ，通信特性の変化により前記管理しているデータ通信要求に含まれる通信品質を満たさなくなった場合に，前記無線通信区間の複数の経路及び前記有線通信区間の複数の経路の中からそれぞれ経路を動的に再選択する、
   ことを特徴とする通信制御装置。
9. 請求項８に記載の通信制御装置であって，
   新たなデータ通信要求を受信した際に，該データ通信要求に含まれる通信品質の値の変化を検出する手段を備え，
   前記通信品質の値の変化を検出した場合に，前記無線通信区間の複数の経路及び前記有線通信区間の複数の経路の中から，それぞれ経路を動的に再選択する、
   ことを特徴とする通信制御装置。
10. 請求項９に記載の通信制御装置であって，
    前記無線通信区間の複数の経路及び前記有線通信区間の複数の経路の中から，前記データ通信要求に対して経路を選択する場合に，
    第１ステップとして，有線側経路の通信特性の調整を試み，前記有線側経路の調整に成功した場合には前記有線側経路の調整により経路選択を終了とし，
    前記有線側経路の調整に失敗した場合には第２ステップとして，前記有線側経路の他の経路への切替を試み，前記有線側経路の切替に成功した場合は前記有線側経路切替により経路選択を終了とし，
    前記有線側経路の切替に失敗した場合には第３ステップとして，無線側経路の通信特性の調整を試み，前記無線側経路の調整に成功した場合には前記無線側経路の調整により経路選択を終了とし，
    前記無線側経路の調整に失敗した場合には第４のステップとして，前記無線側経路の他の経路への切替を試み、前記無線側経路の切替に成功した場合は前記無線側経路切替により経路選択を終了とし，
    前記無線側経路の切替に失敗した場合には第５のステップとして，経路選択は失敗とするが提供可能な通信特性を求め，
    最後のステップとして，前記データ通信要求の要求元に対して，経路選択が成功か失敗かの結果を送信し，結果が成功の場合には併せて提供する経路及び通信特性を送信し，また結果が失敗の場合には併せてデータ通信要求には満たないが提供可能な通信特性を送信する、
    ことを特徴とする通信制御装置。
11. 請求項１０に記載の通信制御装置であって，
    前記データ通信要求の要求値を上り通信と下り通信で個別に維持管理する手段を備え，
    前記データ通信要求の要求値が上り通信と下り通信で異なる場合には，上り通信と下り通信で個別に経路選択をし，上り通信と下り通信で個別に維持管理する、ことを特徴とすることを特徴とする通信制御装置。
12. 請求項１１に記載の通信制御装置であって，
    前記通信品質，あるいは，前記通信特性は，遅延時間，通信帯域，ジッタのいずれか１つ，あるいは，任意の組合せで表現する、
    ことを特徴とする通信制御装置。

Images