JP2011155600A

JP2011155600A - 通信制御装置

Info

Publication number: JP2011155600A
Application number: JP2010017099A
Authority: JP
Inventors: Yoshihiro Nakahira; 佳裕中平
Original assignee: Oki Electric Industry Co Ltd
Current assignee: Oki Electric Industry Co Ltd
Priority date: 2010-01-28
Filing date: 2010-01-28
Publication date: 2011-08-11
Anticipated expiration: 2030-01-28
Also published as: US20110185052A1; JP4935911B2; US8650276B2

Abstract

【課題】通信サービスの体感品質を向上させることができる通信制御装置を提供する。
【解決手段】端末通信最適化機能部１１６０と網側通信最適化機能部１３１０とを有し、端末通信最適化機能部１１６０は、端末上で動作するアプリとアプリの通信先を示す第１の情報を取得する機能部と、第１の情報を転送する機能部と、指示情報である第２の情報に従って、アプリの個々の通信品質を設定する機能部とを含み、通信最適化機能部１３１０は、第１の情報で示される各アプリに必要な通信品質を示す第３の情報と、網の状態に関する第４の情報を取得する機能部と、第１の情報の各アプリに必要な網資源の有無を判断する機能部と、網資源が不足の場合は通信の優先度の高いアプリに第１の通信品質で通信させ、通信の優先度の低いアプリには第１の通信品質を劣化させない範囲における通信を実行させる機能部とを含む。
【選択図】図２

Description

本発明は、通信網に接続された端末で実行中のアプリケーションソフトと網の使用状態とに応じて通信品質（通信帯域、遅延時間、廃棄率など）を制御する通信制御装置に関するものである。

現在の通信アプリケーションサービスは、電話、ＷＥＢブラウジング、ファイル転送、ＶｏＤ（ＶｉｄｅｏｏｎＤｅｍａｎｄ）など多種多様であり、これらの通信アプリケーションサービスに要求される通信品質（通信帯域、遅延時間、廃棄率など）も多種多様である。そこで、通信アプリケーションサービス毎に異なる通信品質を適切に提供することができれば、ユーザが実感する通信品質（体感品質）が高い通信を行うことができる。例えば、フォアグラウンドにおいてインターネットによって動画ストリームを受信し再生しながら、バックグランドにおいて後で使用するフリーソフトをダウンロードする場合に、もしも通信帯域が不足していれば、先ず即時性及び連続性の要求が高い動画ストリームの受信用に必要な通信帯域を確保し、残りの通信帯域で即時性及び連続性の要求が低いフリーソフトのダウンロードを実行すれば、動画ストリームの再生中断が生じ難くなり、体感品質が向上すると考えられる。通信アプリケーションサービス毎に異なる通信品質を提供するために提案された従来の網資源利用技術として、例えば、ＩｎｔＳｅｒｖ（ＩｎｔｅｇｒａｔｅｄＳｅｒｖｉｃｅｓ）系技術と、ＤｉｆｆＳｅｒｖ（ＤｉｆｆｅｒｅｎｔｉａｔｅｄＳｅｒｖｉｃｅｓ）系技術とがある。

ＩｎｔＳｅｒｖ系技術は、Ｅｎｄ−Ｅｎｄ間（例えば、端末とプロバイダ網上のサーバとの間）で通信帯域を確保して通信する技術である。代表的なプロトコルとして、ＲＳＶＰ（ＲｅｓｏｕｒｃｅｒｅＳｅｒＶａｔｉｏｎＰｒｏｔｏｃｏｌ）（ＲＦＣ２２０５）がある。ＩｎｔＳｅｒｖ系技術によれば、確実に通信帯域を確保できる反面、Ｅｎｄ−Ｅｎｄ間で通信機器のすべてが、使用される特定のプロトコルを実装している必要がある。Ｅｎｄ−Ｅｎｄ間に、使用される特定のプロトコルに未対応の通信機器が１台でも存在すれば、ＩｎｔＳｅｒｖ系は動作しない。現状、この技術の対応機器は普及しておらず、ＩｎｔＳｅｒｖ系技術はあまり使用されていない。

ＤｉｆｆＳｅｒｖ系技術は、複数種類の通信アプリケーションサービスの通信品質クラスを設定し、各通信アプリケーションサービスに適した通信品質クラスを選択して通信する技術である。代表的なプロトコルは、ＲＦＣ２４７４で規定されている。ＤｉｆｆＳｅｒｖ系技術に対応できる通信機器は、各パケットのＴＯＳ（ＴｙｐｅＯｆＳｅｒｖｉｃｅ）フィールドのＤＳＣＰ（ＤｉｆｆｅｒｅｎｔｉａｔｅｄＳｅｒｖｉｃｅｓＣｏｄｅＰｏｉｎｔ）に設定された値に従った動作を行い、ＤｉｆｆＳｅｒｖ系技術に対応していない通信機器は通信品質クフスを無視して通信を行う。ＤｉｆｆＳｅｒｖ系技術は、「確実な」通信品質の確保をあきらめるが、取り敢えずデータが届くことを優先し、「なるべく」要求通信品質を満たすようにシステムを動作させるというポリシに基づく技術である。

津川知朗他著、「インラインネットワーク計測手法ＩｍＴＣＰおよびその応用方法の実装および性能評価」、社団法人電子情報通信学会（ＩＥＩＣＥ）発行、信学技報（ＴｅｃｈｎｉｃａｌＲｅｐｏｒｔｏｆＩＥＩＣＥ）、ＩｎｆｏｒｍａｔｉｏｎＮｅｔｗｏｒｋｓ１０５（４７２）、ｐｐ．６１−６６、２００５年１２月８日

特開２００９−０４９４５８号公報

現状では、すべての通信機器が特定のプロトコルに対応していることを要求するＩｎｔＳｅｒｖ系技術だけでなく、通信機器が特定のプロトコルに必ずしも対応する必要がないＤｉｆｆＳｅｒｖ系技術も、十分に普及活用されていない。この原因として、以下の課題の存在が考えられる。
「課題１」：多くのアプリケーションソフト（以下「アプリ」又は「アプリソフト」とも言う）が、通信品質の制御に対応していない。
「課題２」：アプリが通信品質の制御に対応していたとしても、アプリの要求が信用できるとは限らない。例えば、実際には重要でない（すなわち、即時性及び連続性の要求が低い）アプリが、最優先の通信を要求する可能性があり、通信機器がアプリの要求を疑うことなくそのまま信用すると、網全体においてトラヒックの混雑が発生したり、実際に重要な（すなわち、即時性及び連続性の要求が高い）通信の品質が低下したりする可能性がある。
「課題３」：同一アプリであっても、通信の優先度が高い場合と低い場合とがあり、アプリの種類によって通信の優先度を一意に定めることができない。例えば、ＷＥＢブラウザの通信で、ユーザが今見たいサイトのデータ（すなわち、即時性の要求が高い情報）をダウンロードしているのか、ＷＥＢブラウザがバックグランドで、次に読む確率の高いデータ（すなわち、即時性の要求が低い情報）を先読みして事前にダウンロードしているのかによって、通信の優先度が異なる。
「課題４」：端末又は端末のＯＳ（オペレーションシステム）が通信品質の制御に対応しているとは限らない。
「課題５」：網機器の通信品質制御機能（通信帯域や遅延時間をフロー毎に設定する機能）が統一されていない場合がある。
「課題６」：端末、端末のＯＳ、及び端末で動作するアプリに、網の利用状況を伝えたとしても、端末が伝えられた情報を通信品質の制御に活用する仕組みを持っているとは限らない。
「課題７」：網機器が、端末又は端末のＯＳと制御情報の通信をすることができたとしても、その網機器に、ユーザが使用中のアプリや網の使用状況を理解した上で、最適な通信品質制御の操作量を計算する機能があるとは限らない。

これらの「課題１〜７」の内の幾つかについては、既存技術によっても解決策を得ることができると思われる。例えば、ＡＴＭ（ＡｓｙｎｃｈｒｏｎｏｕｓＴｒａｎｓｆｅｒＭｏｄｅ）端末の多くは、指定された通信品質で送信することができるので、ＡＴＭ端末の使用によって「課題４」を解決することができると思われる。また、ＤｉｆｆＳｅｒｖ系技術に基づく機能を有するノードを使用することによって「課題５」を解決することができると思われる。

しかし、現状では、資源に応じて複数のアプリに対して適切な通信品質を提供する網は普及していない。これは、上記「課題１〜７」は互いに関連しており、「課題１〜７」の個々の解決策を組み合わせても、全体として適切に動作しないからである。例えば、ＡＴＭ端末を複数台用意し、ＤｉｆｆＳｅｒｖ系のノードに接続すれば、「課題４」と「課題５」に記載の両方の課題が解決されるように思えるが、実際には通信品質が良好に制御された通信を行うことはできない。これは、一般的なＤｉｆｆＳｅｒｖ系のノードには、ＡＴＭ端末の通信品質要求を理解する仕組みがないからである。

そこで、本発明は、通信網に接続された端末で実行中のアプリと通信網の使用状態とに応じて通信品質を制御することによって、通信サービスの体感品質を向上させることができる通信制御装置を提供することを目的とする。

本発明に係る通信制御装置は、端末と網機器との間の通信を制御する通信制御装置であって、第１の通信最適化機能手段と第２の通信最適化機能手段とを有し、
前記第１の通信最適化機能手段は、前記端末上で動作するアプリと、該アプリの通信先に関する情報である第１の情報を取得する第１の機能部と、前記第１の情報を前記第２の通信最適化機能手段に転送する第２の機能部と、前記第２の通信最適化機能手段からの指示情報である第２の情報に従って、前記アプリの個々の通信品質を設定する第３の機能部とを含み、
前記第２の通信最適化機能手段は、前記第１の情報で示される前記アプリに必要な通信品質を示す第３の情報と、網の状態に関する第４の情報を取得する第４の機能部と、前記第３の情報と前記第４の情報から、前記第１の情報の各アプリに必要な網資源の有無を判断する第５の機能部と、各アプリに必要な網資源がある場合は、各アプリに必要な通信品質で通信することを指示する前記指示情報を前記第２の情報とし、各アプリに必要な網資源が不足している場合は、通信の優先度の高いアプリには第１の通信品質で通信させ、通信の優先度の低いアプリには前記第１の通信品質を低下させない範囲における通信を実行させる資源割当又は送信順位設定を前記端末と前記網機器に指示する指示情報を前記第２の情報とする第６の機能部と、前記第２の情報を前記第１の通信最適化機能手段と前記網機器に送信する第７の機能部とを含むことを特徴としている。

本発明によれば、通信網に接続された端末で実行中のアプリと通信網の使用状態とに応じて通信品質を制御することによって、通信サービスの体感品質を向上させることができるという効果を得ることができる。

本発明に係る第１の実施形態の通信制御装置を含むシステムの主要部を概略的に示す図である。第１の実施形態の通信制御装置を含むシステムの構成を概略的に示す図である。本発明に係る第２の実施形態の通信制御装置を含むシステムの構成を概略的に示す図である。本発明に係る第３の実施形態の通信制御装置を含む通信網における通信最適化第２機能部の構成を概略的に示す図である。第３の実施形態の通信制御装置を含む通信網におけるアクセス網の情報の流れを示す図である。第３の実施形態の通信制御装置を含む通信網におけるアクセス網の他の情報の流れを示す図である。本発明に係る第４の実施形態の通信制御装置を含むシステムの構成を概略的に示す図である。第４の実施形態の通信制御装置を含む通信網における通信最適化第２機能部の構成を概略的に示す図である。第４の実施形態の通信制御装置を含む通信網における物理インタフェースリンクを概念的に示す図である。本発明に係る第５の実施形態の通信制御装置を含むシステムの構成を概略的に示す図である。

以下に示す第１乃至第５の実施形態においては、通信網に接続された端末で実行中のアプリケーションソフト（「アプリ」又は「アプリソフト」とも言う）と網の使用状態とに応じて通信品質（通信帯域、遅延時間、廃棄率など）を制御し、ユーザが受ける通信サービスの体感品質を向上させる通信制御装置又は方法について説明する。具体的には、通信制御装置は、網が輻輳している際、ＴＶ会議などの通信の優先度が高い通信の品質を優先して確保し、不要不急なバックグランドでのファイル転送などの通信の優先度を下げ、ユーザの体感品質を向上させるなどの制御を行う。第１の実施形態では、端末で使用アプリを把握し、網側で通信品質の最適化計算と網機器の制御を行う形態を説明する。第２の実施形態では、使用アプリの把握と通信品質の最適化計算及び網機器の制御とを、端末側で行う形態を説明する。第３の実施形態では、第２の実施形態で適用できる範囲を拡大するための形態を説明する。第４の実施形態では、キャリア網上に構築されるＰ２Ｐ（ＰｅｅｒｔｏＰｅｅｒ）網やＶＰＮ（ＶｉｒｔｕａｌＰｒｉｖａｔｅＮｅｔｗｏｒｋ）網などのオーバレイ網を適用する形態を説明する。第５の実施形態では、第１〜第４の実施形態の機能を用い、ピーク電力を平準化する制御を行う形態を説明する。なお、本出願において、「端末」は、通信網に接続された機器であり、サーバ、クライアント、ピアツーピアのコンピュータ、特定アプリ専用機器などを含む。

《１》第１の実施形態
図１は、本発明に係る第１の実施形態の通信制御装置を含むシステムの主要部を概略的に示す図である。図１に示されるように、第１の実施形態の通信制御装置が適用される通信網は、例えば、家庭内網１１００と、アクセス網及び県内網（県内リング網）から構成されるキャリア網１２００と、プロバイダ網１４００と、最適化制御網１３００とから構成される。

家庭内網１１００に設置される端末１１１０は、アプリケーションソフトとしての第１のアプリソフト１１２０及び第２のアプリソフト１１３０と、オペレーションシステム（ＯＳ）１１４０と、（物理）インタフェース（ＩＦ）１１５０と、端末側通信最適化機能部１１６０とを有している。端末側通信最適化機能部１１６０は、例えば、ＯＳ１１４０上で動作するアプリである。家庭内網１１００は、インタフェース１１５０を介して、キャリア網１２００に接続されている。

キャリア網１２００には、網機器として、例えば、第１の網機器１２１０及び第２の網機器１２２０が設置されている。キャリア網１２００内の第１の網機器１２１０及び第２の網機器１２２０は、家庭内網１１００の端末１１１０とプロバイダ網１４００との間で送受信されるユーザデータを転送する。トランスポート機能部１２３０，１２５０は、ＮＥ−ＯｐＳ（ＮｅｔｗｏｒｋＥｌｅｍｅｎｔＯｐｅｒａｔｉｏｎＳｙｓｔｅｍ）１２３１，１２５１によってそれぞれ制御される。

最適化網１３００には、端末・網設定機能部１３２０を有する網側最適化機能部１３１０が配備されている。最適化網１３００は、端末側通信最適化機能部１１６０及びＮＥ−ＯｐＳ１２３１，１２５１と通信する。

第１の実施形態の通信制御装置は、第１の通信最適化機能部としての端末側通信最適化機能部１１６０及び第２の通信最適化機能部としての網側通信最適化機能部１３１０を含む。他の部分は、既存の装置で実現できる。

端末側通信最適化機能部１１６０は、第１のアプリソフト１１２０、第２のアプリソフト１１３０、及びＯＳ１１４０に代わって、通信品質に関する必要な情報（単に「通信品質情報」とも言う）を網側通信最適化機能部１３１０に送信することによって、端末１１１０が通信品質の制御に対応していないという問題を解決する。また、網側通信最適化機能部１３１０は、網側の機器の持つ網資源情報を取得して最適な通信品質を計算すると共に、端末１１１０や各網機器に対して個別に通信品質制御をさせることで、網機器の通信品質制御の仕組みが互いに異なっていても、通信品質制御を動作させることを可能とする。従来技術であるＮＧＮ（ＮｅｘｔＧｅｎｅｒａｔｉｏｎＮｅｔｗｏｒｋ）のＲＡＣＦ（ＲｅｓｏｕｒｃｅａｎｄＡｄｍｉｓｓｉｏｎＣｏｎｔｒｏｌＦｕｎｃｔｉｏｎ）は、端末からの要求に対して受付制御を行っているが、接続のＯＫ／ＮＧ（許可／不許可）を判断するだけであり通信の優先度の低いアプリ用の通信に使用する通信帯域を絞るなどの動作は行わず、且つ、網機器のすべてがＮＧＮ対応機器である必要があった。これに対し、第１の実施形態の通信制御装置では、各網機器の制御ＩＦの違いを吸収することによって通信品質制御を可能とし、現有資源でユーザの体感品質（特に、接続品質）を高めている。

図２は、第１の実施形態の通信制御装置を含むシステムの構成を概略的に示す図である。図２に示されるように、家庭内網１１００は、例えば、端末（例えば、ＰＣ）１１１０，１１７０と、ホームゲートウェイ（ＨｏｍｅＧａｔｅＷａｙ）１１８０とから構成される。家庭内網１１００は、企業内などのＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）であってもよい。

アクセス網１２６０は、例えば、ＯＮＵ（ＯｐｔｉｃａｌＮｅｔｗｏｒｋＵｎｉｔ）１２６１と、スプリッタ１２６２，１２６３，１２６４，１２６５と、ＯＬＴ（ＯｐｔｉｃａｌＬｉｎｅＴｅｒｍｉｎａｌ）１２６６，１２６７，１２６８，１２６９と、ＰＯＮ（ＰａｓｓｉｖｅＯｐｔｉｃａｌＮｅｔｗｏｒｋ）−ＮＥ−ＯｐＳ１２７０と、スイッチ１２７１，１２７２と、ＳＷ（Ｓｗｉｔｃｈ）−ＮＥ−ＯｐＳ１２７３とから構成される。

県内網（例えば、県内リング網）１２８０は、例えば、ＡＤＭ（Ａｄｄ／ＤｒｏｐＭｕｌｔｉｐｌｅｘｉｎｇ）リング装置１２８１，１２８２，１２８３，１２８４と、ＡＤＭ−ＮＥ−ＯｐＳ装置１２８５と、ゲートウェイ（ＧａｔｅＷａｙ）装置１２８６とから構成される。

端末１１１０のＯＳ１１４０には、通信ソフトウェア１１４１と、計算資源割当機能部１１４６とが配備されている。計算資源割当機能部１１４６は、ＣＰＵタイムを各アプリに配分し、配分された時間においてアプリを動作させる。

図２の構成は、アクセス網１２６０の機器にＰＯＮを用いた例を示しており、家庭内網１１００からの出力をＯＮＵ１２６１で受信し（実際には、複数の家庭内網からの複数の出力を複数台のＯＮＵで受信している。）、各ＯＮＵ１２６１からの信号をスプリッタ１２６１，…，１２６５で合波し、合波された各信号をＯＬＴ１２６６，…，１２６９で受信する。各ＯＬＴ１２６６，…，１２６９のＷＡＮ（ＷｉｄｅＡｒｅａＮｅｔｗｏｒｋ）側出力は、スイッチ１２７１，１２７２で集約され、スイッチ１２７１，１２７２で選択されてＡＤＭリング装置１２８１，１２８４などで構成される県内網１２８０に送信される。県内網１２８０に集められたトラヒックは、その１箇所に用意されたゲートウェイ装置１２８６でプロバイダ網１４００（例えば、プロバイダＡ網、プロバイダＢ網など）に接続される。

最適化制御網１３００は、例えば、各網機器を制御するＮＥ−ＯｐＳと通信する回線と、網側通信最適化機能部１３１０とから構成されている。ただし、本発明に係る最適化制御網１３００は、この構成に限定されない。

図２に示す端末１１１０上で、例えば、第１のアプリソフト１１２０がＷＥＢブラウザであり、第２のアプリソフト１１３０がＶｏＩＰソフトであり、第１のアプリソフト１１２０が第１のプロバイダのサーバと通信し、第２のアプリソフト１１３０が第２のプロバイダのユーザと通信している場合、通信データは、ＯＳ１１４０の通信ソフトウェア１１４１、レイヤ１機能部（物理インタフェース）１１５０を介してホームゲートウェイ１１８０に送られ、更に、ＯＮＵ１２６１、スプリッタ１２６２、ＯＬＴ１２６６、スイッチ１２７１、ＡＤＭリング装置１２８１、ゲートウェイ装置１２８６を通って、プロバイダ網１４００に送られる。

アクセス網１２６０のスイッチ１２７１，１２７２の各々は、多数のＯＬＴ１２６６，…，１２６９などからの信号を集約して、いずれかの信号を選択してＡＤＭリング装置１２８１，…，１２８４などに送る機能だけでなく、網側通信最適化機能部１３１０の通信インタフェース機能部１３２３に送る制御信号を、ユ一ザ信号と分離する機能をも有する。制御信号をユーザ信号と分離する機能は、ＯＬＴ１２６６，…，１２６９に実装しても良い。

端末１１１０に実装される端末側通信最適化機能部１１６０の内部には、アプリ監視機能部１１６１と、端末側通信品質制御機能部１１６６と、アプリ別品質情報保持機能部１１６７と、端末設定機能部１１６５と、製造者証明機能部１１６８とが含まれる。アプリ監視機能部１１６１には、アプリ別通信状態監視機能部１１６２と、プロセス監視機能部１１６３と、通信状態監視機能部１１６４とが含まれる。プロセス監視機能部１１６３は、プロセス名とプロセスＩＤを取得し、通信状態監視機能部１１６４は、通信中のプロセスＩＤと５−ｔｕｐｌｅｓの情報（後述する）の一覧を取得する。アプリ別通信状態監視機能部１１６２は、これらの情報を照合し、通信中のプロセス名と５−ｔｕｐｌｅｓの情報を得て、網側通信最適化機能部１３１０に送り、返信で指示される通信品質で通信するように制御する。

網側通信最適化機能部１３１０は、例えば、通信ＩＦ（インタフェース）機能部１３２３と、品質情報集計機能部１３２１と、最適品質計算機能部１３２２と、端末・網設定機能部１３２０と、アプリ別品質データベース１３２４と、網状態把握機能部１５００とから構成される。

品質情報集計機能部１３２１は、端末側通信最適化機能部１１６０と通信して、アプリと、必要な通信品質情報とを収集・集計する。

網状態把握機能部１５００は、例えば、物理トポロジ把握機能部１５１０と、ＩＰ経路把握機能部１５２０と、網利用状態把握機能部１５３０と、ボトルネック把握機能部１５４０とから構成される。

物理トポロジ把握機能部１５１０は、物理トポロジ情報を取得し、ＩＰ経路把握機能部１５２０は、ＩＰパケットの転送経路情報を取得し、網利用状態把握機能部１５３０は、網資源とその使用量の情報を取得し、ボトルネック把握機能部１５４０は、網のボトルネック箇所を調査し、これらの情報は、網側通信最適化機能部１３１０に送られる。

網側通信最適化機能部１３１０は、品質情報集計機能部１３２１で集められた通信品質情報と網状態把握機能部１５００で取得された情報とから、各端末１１１０がアプリに提供するべき通信品質を計算する。計算結果は、端末・網設定機能部１３２０に通知され、端末・網設定機能部１３２０は、端末１１１０と網のＮＥ−ＯｐＳに対して、指定した通信品質で通信するように指示する。

第１の実施形態において、端末側通信最適化機能部１１６０に含まれるプロセス監視機能部１１６３は、ＯＳ１１４０上で実行されているアプリソフトを監視し、プロセス名称とプロセスＩＤの情報を取得する（図２のＰ１）。また、プロセス監視機能部１１６３は、表示部のスクリーンに表示されている映像の状態からアクティブなアプリソフトやスレッドを把握したり、マウスやキー入力等の操作を監視することで、ユーザの意図的な通信であるのか、バックグランドの通信であるのかを把握したりする（「上記「課題３」の解決）。例えば、端末の表示部のスクリーンにＷＥＢブラウザのウインドウが２つ開いていており、それぞれのウインドウについてＴＣＰ（ＴｒａｎｓｍｉｓｓｉｏｎＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ）コネクションで通信を実行しており、いずれのウインドウについても、数秒〜数十秒に１回、端末から送信を行っている場合を想定する。このとき、一方のＷＥＢブラウザの画面上でユーザがキー入力やマウス操作を行っており、他方のＷＥＢブラウザの画面上では、キー入力やマウス操作がされていない場合を想定する。このとき、キー入力をしているＷＥＢブラウザの画面は、ＷＥＢメールやアンケートのフォーム入力をしていると推定でき、通信の優先度が高いと推定できる。他方のＷＥＢブラウザの画面は、キーボードやマウスの操作なしに、定期的に通信していると判断でき、例えば、ＪＡＶＡスクリプトが定期的に、広告を読み込んで入れ替えている処理だけが実行されていると判断でき、通信の優先度が低いと通信であると推定できる。より具体的な例で説明すれば、例えば、マウス操作をしている画面の接続先がネットワーク上の地図情報提供サービス（例えば、「ＧｏｏｇｌｅＭａｐｓ^ＴＭ」）である場合には、地図を開いて拡大や移動を行っていると推定できるので、通信の優先度が高いと推定できる。

また、プロセス監視機能部１１６３は、ＷＥＢブラウザ上で表示されている情報のＵＲＬと、通信内容とを比較し、比較結果に基づいて先読み情報であるのか、現在必要な情報であるのかを識別することができる。例えば、ＷＥＢブラウザ上の表示が、短時間で順次変化しており、通信している現在更新中のデータが含まれている場合は、先読みではなく、ＷＥＢブラウザ上で表示が、変化しないのに、通信している場合を先読みと推定することができる。この判断をより確実にするために、プロセス監視機能部１１６３は、通信している内容を検閲して、通信内容のテキストの内容や図のファイルを、画面上に表示されている情報と比較して、同じであるならば、通信している内容は、更新中のデータと判断し、通信中のテキストや、画像ファイルが画面上に出現しない場合、先読み情報と判断してもよい。

通信状態監視機能部１１６４は、ＯＳ１１４０の通信ソフトウェア１１４１が通信に使用しているＳｏｃｋｅｔＩＦを監視し、各Ｓｏｃｋｅｔを使用しているアプリのプロセスＩＤと、通信における５−ｔｕｐｌｅｓ（送信元のＩＰアドレスとポート番号、あて先のＩＰアドレスとポート番号、プロトコル番号）の情報を取得する（図２のＰ２）。

アプリ別通信状態監視機能部１１６２は、プロセス監視機能部１１６３と通信状態監視機能部１１６４から取得された情報に関して、一致するプロセスＩＤを元に照合し、どのプロセス名のアプリが、どのあて先（あて先のＩＰアドレス）と、どのポートを使って、どのプロトコルで通信をしているかの情報を得ることができる。また、アプリ別通信状態監視機能部１１６２は、端末１１１０の通信状態情報（トラヒック量やＴＣＰのＡＣＫの状態や送信キューの状態など）を取得する。これらの情報は、端末側通信品質制御機能部１１６６、通信ソフトウェア１１４１、ホームゲートウェイ１１８０、ＯＮＵ１２６１、スプリッタ１２６１，…，１２６５、ＯＬＴ１２６６，…，１２６９、スイッチ１２７１，１２７２などを介して、網側通信最適化機能部１３１０の通信ＩＦ機能部１３２３に入力される。

端末側通信最適化機能部１１６０をソフトウェアで実現して内蔵したり、ＵＳＢ接続モジュールで実現したりすることによって、端末１１１０と接続してアプリを監視することで、上記「課題１」を解決することができる。あるいは、ソフトウェアをホームゲートウェイ１１８０やＯＮＵ１２６１に実装し、通信トラヒックの情報からアプリを推定したり、端末１１１０にリモートでログインしてアプリを調べたりすることもできる。

また、端末側通信最適化機能部１１６０と網側通信最適化機能部１３１０の間での通信を暗号化すると共に、端末側通信最適化機能部１１６０の内部に端末側通信最適化機能部１１６０の製造者を証明する情報を保持する製造者証明機能部１１６８を持たせ、製造者証明機能部１１６８が網管理者が信頼する者に作られたもので、ユーザが勝手に作ったものではないことを証明することによって、上記「課題２」の解決、すなわち、各アプリに要求する通信品質情報が正しいことを確認することができる。製造者証明機能部１１６８は、改ざんを許さない通信路によって端末側通信品質制御機能部１１６６と接続されており、通信対象が正規の通信対象であり、偽造や改ざんされたものではないことを証明認証する機能部である。製造者証明機能部１１６８は、例えば、ＩＣカード型定期券に用いられている技術を適用することができる。

網側通信最適化機能部１３１０の品質情報集計機能部１３２１は、各端末１１１０から送られた情報と、アプリ別品質データベース１３２４の情報を照合・集計し、「各端末１１１０が必要とする通信品質情報」の一覧を作成する。以下の表１に、一覧を例示する。この情報は、最適品質計算機能部１３２２に送られる。

網状態把握機能部１５００に含まれる物理トポロジ把握機能部１５１０は、ＮＥ−ＯｐＳ情報から網の物理トポロジや接続機器の状態を調査し、物理トポロジ情報を取得する。ＮＥ−ＯｐＳ情報に含まれるトポロジ情報は、例えば、以下の表２に示すテーブル情報である。

ＩＰ経路把握機能部１５２０は、各ノードが保有するルーティングの情報から、論理的なＩＰ網上でのパケットの転送経路の情報（ＩＰ経路情報）を把握する。

網利用状態把握機能部１５３０は、物理、トポロジ情報と、ＩＰ経路情報と、各端末１１１０から送られてきた「端末１１１０の通信状態情報」と通信機器に内蔵された品質計測機能部で計測された通信品質情報をＮＥ−ＯｐＳ経由で取得し、これらの情報から、網の利用状態（例えば、ノードとリンクを流れる通信帯域）の情報を作成する。一例を、表３〜５に示す。なお、表３〜表５と、表２の物理トポロジの情報は一致しない。これらは、あくまでも例である。

通信機器に、品質計測機能部が内蔵されない場合、専用の品質計測装置を網内に設置することで対応できる。「網の利用状態の情報」は、トラヒック量やボトルネックの把握だけでなく、各端末１１１０の利用可能通信帯域情報も含まれることが望ましい。利用可能通信帯域は、例えば、非特許文献１に記載されているインライントラヒック計測機能部に示される技術を用いることができる。ボトルネック把握機能部１５４０は、網の利用状態の情報からフローのボトルネックを把握し、そこを流れるトラヒックの要素を求め、網の利用状態の情報に付加する。

最適品質計算機能部１３２２は、「各端末１１１０が必要とする通信品質情報」の一覧と「網の利用状態の情報」から、端末１１１０のアプリが行うべき最適な通信品質を計算する。網の資源が十分にあれば、各アプリが必要とする資源を与えれば良い。なお、「必要とする資源を与える」とは、何も制御しない、場合が多い。最適品質計算機能部１３２２は、ボトルネックが存在し、網の資源が不十分な場合、ボトルネック区間における制御可能なトラヒックの要素を求め、有効な通信品質制御が可能か判断する。最適品質計算機能部１３２２は、有効な通信品質制御が可能な場合、通信の優先度の低いアプリの資源を減らし、通信の優先度の高いアプリの通信品質に必要な資源（例えば、通信帯域）を確保する。最適品質計算機能部１３２２は、網機器の、ＭＩＢやＮＥ−ＯｐＳが持つ網の輻輳情報を用いて端末１１１０に通信品質を指示できるので、上記「課題６」を解決できる。通信の優先度は、ユーザによって異なる場合もあるので、外部から個別設定可能な構成とすることが望ましい。これによって、端末１１１０で使用されるアプリの状態に基づく通信帯域割当が可能となり、上記「課題７」が解決される。計算結果は、端末・網設定機能部１３２０に送られる。端末・網設定機能部１３２０は、網内の通信機器のＮＥ−ＯｐＳに対して、計算結果に基づく通信品質で通信を行うよう指示すると共に、端末側通信最適化機能部１１６０に内蔵される端末側通信品質制御機能部１１６６に対して、端末１１１０が指定した通信品質で通信を行うように指示する。端末側通信品質制御機能部１１６６は、端末設定機能部１１６５に対して通信ソフトウェア１１４１を制御したり、レイヤ１機能部１１５０やホームゲートウェイ１１８０に対して、適切な通信品質で通信を行うように指示する。すなわち、端末側通信最適化機能部１１６０と網側通信最適化機能部１３１０とが仲立ちすることで、端末１１１０やＯＳ１１４０が網機器のＤｉｆｆＳｅｒｖ系機器やＩｎｔＳｅｒｖ系機器に対応しておらず、通信品質制御できないという上記「課題４」を解決できる。また、網機器の通信品質制御の仕組みが互いに異なっている場合であっても、網側通信最適化機能部１３１０が差分を吸収して、ＮＥ−ＯｐＳを介して所望の動作をさせるので、上記「課題５」を解決できる。

通信品質（通信帯域、遅延など）を制御する具体的な方法として、例えば、以下に示す第１〜第６の方法がある。

第１の方法では、通信ソフトウェア１１４１に内蔵されるパケットスケジューラ機能部１１４５の設定を変更し、アプリケーション別に送信パケットの通信の優先度や通信帯域を変更する。第１の方法では、下りのトラヒックが問題になっている場合、例えば、上りのＴＣＰ＿ＡＣＫ信号の送信レートを下げることで、通信帯域制御を行うことができる。

第２の方法では、通信ソフトウェア１１４１のレイヤ３機能部１１４３を制御して、通信の優先度に応じて、ＩＰパケットのサービスタイプのフィールド値を設定する。第２の方法は、通信ソフトウェア１１４１のレイヤ２以下の機能部１１４５，１１４４，１１４３，１１４２や、網機器がサービスタイプに応じた優先制御を行う場合に効果がある。

第３の方法では、通信ソフトウェア１１４１と網のある点（ある点は、網の通信ボトルネックを越えた場所）までの間に、ＶＬＡＮ、ＩＰ−ｉｎ−ＩＰ（ＩＰトンネリング・プロトコル）、ＭＰＬＳ（Ｍｕｌｔｉ−ＰｒｏｔｏｃｏｌＬａｂｅｌＳｗｉｔｃｈｉｎｇ）などのトンネリング技術でトンネルを設定する。第３の方法では、トンネルの通信の優先度や通信帯域を、アプリに適したものとして、通信品質制御が必要なアプリをそのトンネルを介して転送する。第３の方法では、網機器は、トンネルの設定が可能でなければならない。

第４の方法では、ＯＮＵ１２６１、ＯＬＴ１２６６，…，１２６９、及びホームゲートウェイ１１８０などの通信機器で、５−ｔｕｐｌｅｓの情報に基づいて、優先制御（シェービングやスペーシングを含む）を行う。第４の方法では、５−ｔｕｐｌｅｓの値と通信の優先度、提供すべき通信品質は、網側通信最適化機能部１３１０が決定し、網機器の設定を行う。

第５の方法では、通信ソフトウェア１１４１の機能部（レイヤ１機能部１１５０のドライバを含む）を用いて、通信の優先度の低いトラヒックを制限し、通信の優先度の高いトラヒックの通信品質を確保する。

第６の方法では、計算資源割当機能部１１４６の設定を変更し、アプリソフトのＣＰＵ時間を増減し、通信量を調整する。

通信品質制御を行う機器の範囲と、効果が得られる条件は、端末１台で行う場合から、ネットワーク全体で行う場合まで、複数の方法が考えられる。通信品質（通信帯域や遅延など）を制御する具体的な手法の実施方法を、以下に例１〜６として、例示する。

（例１）通信品質を制御する手法の一つとして、ある端末１台で送受信する通信の品質制御だけを行う方式が考えられる。この方法は、端末のレイヤ１帯域や、通信ソフトウェアの性能がボトルネックとなっている場合に有効である。例えば、加入者に割当てられるアクセス網の通信帯域が制限されている場合がある。アクセス網がＰＯＮではなく、ＡＤＳＬである場合には、その通信帯域が、下りでも１Ｍｂｉｔ／ｓｅｃに満たない場合が多く存在する。このような環境で、フォアグラウンドで動画の視聴を行いながら、バックグラウンドでセキュリティバッチの自動更新が働くと、ＡＤＳＬの通信帯域がボトルネックとなって、体感品質が低下することが考えられる。このような場合には、端末１台で送受信する通信の品質制御だけを行う方式でも、ユーザの体感品質向上に貢献できる可能性がある。この方式では、端末・網設定機能部１３２０による網機器の設定制御を行わず、第１の方法だけでも体感品質の向上に貢献できる。その場合、網側通信最適化機能部１３１０を網側におかず、端末１１１０内に設置して動作させることも可能であり、通信制御装置を実現し易くなる。ただし、その場合でも、新しいアプリや通信サービスを受けるサーバの変化に対応させるため、アプリ別品質データベース１３２４の更新を外部から随時行うことが望ましい。また、この場合には、端末１１１０側で網状態を把握し、利用可能通信帯域を常に更新させる必要がある。従来から、端末でアプリ別に送受信帯域制御を行う技術が検討されているが、端末側にすべてを実装する場合の特徴は、アプリ別品質データベースの更新を外部から行うことと、網状態把握機能部に内蔵させる点にある。

（例２）通信品質を制御する手法の他の例として、１台のＯＮＵ１２６１に収容される全端末が送受信する通信の品質制御を行う方式が考えられる。このような制御によって効果が得られる場合は、例１と同様であるが、家庭内の端末数が多い場合、より大きな効果が得られる。この方式でも、端末・網設定機能部１３２０による網機器の設定制御を行わず、第１の方法だけで対応できる。

（例３）通信品質を制御する手法の他の例として、同一ＯＬＴ１２６６，…，１２６９に収容される加入者の端末が送受信する通信の品質制御を行う方式が考えられる。このような制御方式は、ＯＬＴ１２６６，…，１２６９とＯＮＵ１２６１との間の通信帯域を、複数加入者で共有しており、ＯＬＴ１２６６，…，１２６９より端末側のどこかにボトルネックがある場合に、効果がある。ＰＯＮは、数十人の加入者で通信帯域を共有しており、第１の実施形態のように不要不急の通信帯域を制限することによって、上記ボトルネックが上記範囲内にあるならば、効果が期待できる。

（例４）通信品質を制御する手法の他の例として、同一のスイッチに収容される加入者の端末が送受信する通信の品質制御を行う方式が考えられる。トラヒックを集約するスイッチのＷＡＮ側回線より端末側のどこかにボトルネックがある場合に、対応可能であり、効果が期持できる。スイッチが、ＷＡＮ側の通信帯域を、端末側のインタフェースに割当てる際、ＯＬＴ１２６６，…，１２６９の台数や加入者数に単純比例して固定的に割当てる場合に比べ、上記第３の方法又は第４の方法を用いて必要な通信品質に応じて通信帯域を分配する場合に、効果が得られる。

（例５）通信品質を制御する手法の他の例として、同一のＡＤＭリング装置１２８１，…，１２８４に収容される加入者の端末が送受信する通信の品質制御を行う方式が考えられる。県内網のＡＤＭリング装置１２８１，…，１２８４のＷＡＮ側回線より端末側のどこかにボトルネックがある場合、対応可能であり、効果が期待できる。ＡＤＭリング装置は、各市に１箇所ある電話局毎に設置され、市単位で通信帯域共有を行うことになる。

（例６）通信品質を制御する手法の他の例として、同一県内網に収容される加入者の端末が送受信する通信の品質制御を行う方式が考えられる。県内網のＧａｔｅＷａｙより端末側のどこかにボトルネックがある場合に、対応可能であり、効果が期待できる。上記第３の方法又は第４の方法を用いて制御を行うと、まず、資源側に関して県内網全体の資源を、加入者の要求に応じて最適に配分できる。次に、その資源を利用するトラヒックに関して、この制御を大半の加入者が受け入れている場合、ＧａｔｅＷａｙを流れるトラヒック量全体を制御できる。

第１の実施形態の通信制御装置を用いれば、アプリケーションの通信の優先度に応じた通信品質の提供が可能となり、伝送資源やネットワーク機器をほとんど追加することなく、ユーザの体感品質を向上することができる。

また、第１の実施形態の通信制御装置を用いれば、従来技術のＩｎｔＳｅｒｖの課題であった、Ｅｎｄ−Ｅｎｄ間でのＩｎｔＳｅｒｖ機器での統一は不要である。

また、第１の実施形態の通信制御装置を用いれば、従来技術であるＤｉｆｆＳｅｒｖで課題となっていた、複数の課題に対する個々の解を組み合わせても、それだけでは機能しないという課題は、第１の実施形態に示す構成と、新たに導入する（端末１１１０側／網側）通信最適化機能部１１６０，１３１０によって解決され、網資源が不足する際、個々のアプリの通信品質を最適化して高い体感品質を実現すると言う目的を達成することが可能となる。

《２》第２の実施形態
第１の実施形態では、通信品質を最適化する機能部である端末側通信最適化機能部１１６０及び網側通信最適化機能部１３１０を、端末１１１０と最適化制御網１３００にそれぞれ配備していた。第２の実施形態では、通信品質を最適化する機能部である端末側通信最適化機能部１１６０及び網側通信最適化機能部１３１０に対応する機能部の両方を端末２１００側に配備し、網側の配備を不要としている。ただし、単に配置場所をある１台の端末２１００に変えただけでは、その端末２１００に電源が投入されていない場合に、動作不能に陥る。このような状況の発生を防止するため、全部又は複数の端末２１００が、通信品質を最適化する機能部（通信最適化第１機能部１１６０と通信最適化第２機能部２１１０）を、自律分散的に代替できるようにする端末連携機能部２１２０を配備している。

図３は、本発明に係る第２の実施形態の通信制御装置を含むシステムの構成を概略的に示す図である。図３において、図２の構成と同じ又は対応する構成には、同じ符号を付す。第２の実施形態においては、第１の実施形態で端末側通信最適化機能部１１６０と示した機能部を、通信最適化第１機能部１１６０と呼び、第１の実施形態で網側通信最適化機能部１３１０と示した機能部と新たに加えた機能部を、通信最適化第２機能部２１１０と呼ぶ。第２の実施形態は、第１の実施形態における網側通信最適化機能部１３１０と、端末連携機能部２１２０を加えた通信最適化第２機能部２１１０とを端末１１１０側に配置した点が、第１の実施形態と相違するが、他の点については第１の実施形態に準じた構成を持つ。なお、通信ＩＦ機能部１３２３は、第１の実施形態では、通信ソフトウェア１１４１とレイヤ１機能部１１５０を実現していたが、第２の実施形態では、通信ソフトウェア１１４１とのインタフェースを提供するだけでよい。

通信最適化第２機能部２１１０における端末連携機能部２１２０には、親端末探索機能部２１２１と、端末生存確認機能部２１２２と、親端末機能移譲機能部２１２３と、親端末機能移譲通知機能部２１２４とが含まれ、これらの機能部は、端末連携制御機能部２１２５によって制御され、連携端末情報保持機能部（データベース）２１２６にアクセスすることができる。

第２の実施形態における親端末探索機能部２１２１は、親端末を検索する機能を持つ。端末生存確認機能部２１２２は、ＫｅｅｐＡｌｉｖｅ（キープアライブ）信号によって、端末が機能しているかを確認する機能を持つ。親端末機能移譲機能部２１２３は、親端末が子端末に役割を移譲する機能を持つ。親端末機能移譲通知機能部２１２４は、親端末の機能が別の端末に移譲されたことを、各端末に通知する機能を持つ。

第２の実施形態の動作は、第１の実施形態に準じており、各端末と網機器の通信品質を最適化する動作を行うが、その動作を行う前に各端末の役割を決定し、各端末がそれを知る必要がある。

最も単純な方法は、全ユーザが各自の端末をすべて手動設定する方法であるが、この方法を採用した場合には、ユーザの負担が大きくなる。他の方法として、管理者を定め、管理者の端末がリモートの方法で全端末を監視し、手動又は自動で設定する方法があるが、基本的に第１の実施形態で機能の配置を変更したものである。管理者の端末が停止した場合、すべての通信最適化機能が停止する。第２の実施形態では、自律分散制御で高い生存性を実現する方法を示す。

端末２１００に電源が投入されて起動すると、最初に、通信最適化第２機能部２１１０の親端末探索機能部２１２１は、アプリに応じた通信品質制御を行う端末が自分以外に存在するか否かを調査する。事前登録設定された端末群やサーバを検索する方法や、ブロードキャストで協調動作する端末が存在するかを調べるパケットを投げて、返答を待つ方法がある。返答がなければ、自分が親端末（サーバ）として機能し、返答があれば、先に立ち上がっている端末のいずれかが親端末としで動作しているので、自分が子端末（クライアント）として動作する。先着順に決めるのではなく、親端末機能移譲機能部２１２３で、端末の性能情報を互に交換し、より高い性能のある端末に親端末の権限を委譲する方法もある。その場合、既に他の子端末が存在すれば、親端末機能移譲通知機能部２１２４で親が移動することを通知する。また、子端本は、端末生存機能部で定期的に親端末とＫｅｅｐＡｌｉｖｅメッセージを交換し、生存確認できなければ、他に新たな親端末が居ないか電源投入時と同様に調べ、他に親端末あればその親端末をサーバとして認識し、なければ自分が親端末となって、他の子端末に対して、自分が親候補となったことを通知する。親端末変更の通知を受けた子端末は、従来の親端末の生存確認が取れないことを確認したうえで、親端末を変更する。従来の親端末との通信が確認された場合、新たな親端末を無視する。この動作では、同時に複数の親端末が存在する状態が有り得る。そこで、親端末は親端末探索機能部２１２１で定期的に自分以外の親端末が存在しないか確認し、存在すれば、どちらが親端末となるかを端末性能や乱数で決定する。親端末であることをやめる端末は、親端末を続ける端末に親端末機能委譲機能部で権限と責任を譲り、子端末に親端末機能部委譲通知機能部で新たな親端末を通知する。

親端末は、通信最適化第２機能部２１１０で、第１の実施形態における網側通信最適化機能部１３１０の役割を果たし、以降の動作は、第１の実施形態と同じである。親端末は、自分自身について通信最適化第１機能部で子端末としても動作し自端末内の通信最適化第２機能部２１１０をサーバ機能部として利用する。

第２の実施形態を用いれば、第１の実施形態の効果と同様の効果が得られるだけでなく、サーバとして動作する網側通信最適化機能部１３１０をクライアント側の端末のいずれかが代行し、その端末が動作不能に陥った際、別の端末が機能を引き継ぐため、サーバとしての機能を与えられた装置が故障して通信品質制御が不能になる可能性を低く抑えることができる。

《３》第３の実施形態
第２の実施形態の通信制御装置は、例えば、家庭内網１１００に設置される端末群で協調動作を行う場合には、好適な動作を行うことが期特できるが、家庭内網１１００を超える範囲で動作させるには、親端末の負荷が大きくなり過ぎる可能性がある。そこで、以下の２つの戦略を考える。第１の戦略は、親端末の階梯の上に祖父端末の階梯を作り、祖父端末が親端末より広い範囲で最適化を行う方法である。祖父端末で力バーできない範囲は、曽祖父端末の階梯を作り、それでも力バーできない範囲は、更に上の階梯の端末を作ることで対応する。第２の戦略は、親端末同士が対等な関係で、調整を行う方法である。親端末の数が多すぎて調整が取れない場合、ある範囲の親端末でグループを作り、グループに代表を持たせ、別のグループの代表と対等な関係で調整する方法が考えられる。

図４は、本発明に係る第３の実施形態の通信制御装置を含む通信網における通信最適化第２機能部３１１０の構成を概略的に示す図である。図５は、第３の実施形態の通信制御装置を含む通信網におけるアクセス網における情報の流れ示す図である。図６は、第３の実施形態の通信制御装置を含む通信網におけるアクセス網の他の情報の流れを示す図である。

図４の通信最適化第２機能部３１１０において、第２の実施形態と同じ又は対応する構成には、同じ符号を付す。第３の実施形態は、第２の実施形態の構成に加え、祖父端末探索機能部３１２１と、祖父／親端末生存確認機能部３１２２と、祖父端末機能移譲機能部３１２３と、祖父端末機能移譲通知機能部３１２４とが配備されている。これらの機能部は、端末連携制御機能部２１２５に接続され、端末連携制御機能部２１２５からの指示に従って動作するとともに、共通する連携端末情報保持機能部（データベース）２１２６にアクセス可能な構成となっている。なお、第２の実施形態で端末生存確認機能部２１２２としていた機能は、親／子端末生存確認機能部２１２２と呼び、同端末が子端末の役割を果たす際に、親端末の生存を確認し、親端末の機能を果たす際は子端末を探す機能部となっている。また、品質情報集計機能部１３２１，３３２１と、最適品質計算機能部１３２２，３３２２と、端末・網設定機能部１３２０，３３２０は、親端末時に働くものと、祖父端末時に働くものの２系統を用意する。両方の機能部を１つで済ませることができる場合は、２系統用意する必要はない。

第３の実施形態において、端末に電源が投入されると、端末連携制御機能部２１２５は、第２の実施形態と同様に、親端末探索機能部２１２１が、親端末を検索し、親端末が存在しない場合、自分が親端末となる。端末連携制御機能部２１２５は、自分が親端末の場合、自分がどの程度の仕事なら親端末としてできるか、自端末の性能を調査した上で、対応範囲を決定する。端末連携制御機能部２１２５は、例えば、家庭内網１１００の範囲ならば対応する、又は、同一ＯＬＴ１２６６，…，１２６９に収容される端末の範囲ならば対応する、といった決定を行う。

子端末から、親端末への接続要求が送られた場合、その範囲の端末にのみＡＣＫを返信し、子端末に対し親端末として働く。親端末としての動作は、第２の実施形態と同様に、（親端末時）品質情報集計機能部１３２１で、対応範囲の子端末から送信されたアプリ情報に従って、アプリ別品質データベース１３２４から必要な通信品質の情報を整理する。この情報と、（親端末時）網状態把握機能部１５００によって収集された網の状態情報を元に、（親端末時）最適品質計算機能部１３２２が、子端末と網機器の通信品質制御の設定値（例えば、通信帯域）を決定する。通信品質制御の設定値に基づき、（親端末時）端末・網設定機能部１３２０は、子端末と網機器の設定を行う。親端末機能委譲機能部２１２３及び親端末機能委譲通知機能部２１２４は、第２の実施形態と同じである。

また、親端末としての対応範囲は、子端末に対する対応範囲だけでなく、制御する網側の範囲も規定する。例えば、家庭内網１１００の範囲の対応であれば、ホームゲートウェイ１１８０の通信帯域制御までが対応可能であり、同一ＯＬＴ１２６６，…，１２６９に収容されている端末の範囲での対応であれば、ＯＬＴ１２６６，…，１２６９の通信帯域割当の帯域制御までが対応可能である。

次に、端末連携制御機能部２１２５は、自分が親端末の場合、祖父端末探索機能部３１２１に、祖父端末を探索させる。祖父端末を探した端末は、祖父端末が見つからなければ、自分が祖父端末となる。祖父端末となった端末は、端末連携制御機能部２１２５が、祖父端末としての対応範囲を決定する。祖父端末として働く際の親端末に対する動作は、親端末としての子端末に対する機能とほぼ同じである。

祖父端末は、配下の親端末から、その親端末が対応している範囲のアプリの集約された情報を、（祖父端末時）品質情報集計機能部３３２１が受信し、アプリに必要な通信品質情報をアプリ別品質データベース１３２４の値を参照し、（祖父端末時）網状態把握機能部１５００によって収集された網の状態情報を元に、（祖父端末時）最適品質計算機能部３３２２が、親端末と網機器の通信品質制御の設定値（例えば、通信帯域）を決定する。通信品質制御の設定値に基づき、（祖父端末時）端末・網設定機能部３３２０は、親端末の網状態把握機能部１５００に、親端末が使用可能な資源の情報を通知するとともに、祖父端末の対応範囲の網機器の設定を行う。例えば、親端末の対応範囲が家庭内網１１００で、祖父端末の対応範囲がＯＬＴ１２６６，…，１２６９までの場合、祖父端末が、各加入者別の通信帯域の設定をＯＬＴ１２６６，…，１２６９に対して行い、各加入者に配備された親端末に、割り当でられた通信帯域を通知し、親端末がその情報を元に、ホームゲートウェイの機器や、端末の送信通信帯域を設定する動作を行う。上記の情報の流れを図５に示す。なお、図５は、祖父端末の対応範囲が同一スイッチに収容されるＯＬＴ１２６６，…，１２６９、親端末の対応範囲が家庭内網１１００である場合を示している。また、図５は、祖父端末の機能部は、当初の親端末から、親端末機能委譲機能部で、別の端末に移された場合を示している。

次に、図６を用いて、第２の戦略を用いた場合の動作を説明する。第２の戦略は、第１の戦略と似ているが、親端末の通信帯域を祖父端末が決めるのではなく、親端末同士で情報交換し、互いに必要な通信品質を決める点が、第１の戦略と相違する。この決定方法に関して、親端末同士の要求と譲歩による協議で決定する方法もあるが、決裂する可能性がある。決裂を避ける実装方法として、すべての親端末がまったく同じアルゴリズムで動作し、親端末同士は情報交換を行い、同じ計算結果を出力する実装をとる方法がある。また、複数の親端末を代表する祖父端末が、別の祖父端末と情報を交換した上で、互いに利用する網資源を決定することもできる。図６の例では、親端末は家庭内網１１００の通信帯域割当を行うと共に、同一ＯＬＴ１２６６，…，１２６９に収容される他の親端末と通信帯域割り当てを行っている。祖父端末は同−ＯＬＴ１２６６，…，１２６９に収容されるアプリの状態を把握し、他の祖父端末と協調して、同一スイッチに収容されるＯＬＴ１２６６，…，１２６９の通信品質（通信帯域の割当など）を決定し制御する。

以上に説明したように、第３の実施形態の通信制御装置を用いれば、第１及び第２の実施形態に記載される効果に加え、より広範な範囲での通信品質制御を行うことができるという効果を得ることができる。

《４》第４の実施形態
図７は、本発明に係る第４の実施形態の通信制御装置を含むシステムの構成を概略的に示す図である。図８は、第４の実施形態の通信制御装置を含む構成における通信最適化第２機能部の構成を概略的に示す図である。図９は、第４の実施形態の通信制御装置を含む構成における物理インタフェースリンクを概念的に示す図である。

近年、ＩＰ網を網資源として、その上に別の網を構築するオーバレイ網が頻繁に用いられている。オーバレイ網６１００の例は、図７に示されている。オーバレイ網６１００は、例えば、第１〜第６の端末６２０１，…，６２０６に対応する第１〜第６のオーバレイノード６１０１，…，６１０６と、第１〜第６のオーバレイノード６１０１，…，６１０６を相互に接続する第１〜第７のオーバレイリンク６１１１，…，６１１７とを備えている。オーバレイ網６１００としては、例えば、ＶＰＮやＰ２Ｐ網を用いることができ、オーバレイ網６１００上のトポロジは、ＩＰ網６２００上のトポロジと必ずしも一致しない。図７の例で、第３の端末６２０３による第３のオーバレイノード６１０３から、第４の端末６２０４による第４のオーバレイノード６１０４へのデータ転送は、第６のオーバレイリンク６１１６、第６の端末６２０６、第７のオーバレイリンク６１１７を経由する転送経路か、又は、第５のオーバレイリンク６１１５、第２の端末６２０２、第４のオーバレイリンク６１１４を経由する転送経路で行われる。

ＩＰ網における転送経路は、物理網の最適経路と異なる場合が多々ある。例えば、図７で、第１のプロバイダ網６３０１と契約している加入者の第３の端末６２０３から第２のプロバイダ網６３０２と契約している加入者の第４の端末６２０４へのトラヒックは、第１の端末６２０１から、ＡＤＳＬモデム６４０１、ＡＤＳＬモデム６４０２、スイッチ６４０３、第１の県内網６４０４、第１のプロバイダ網６３０１、ＩＸ（ＩｎｔｅｒｎｅｔｅＸｃｈａｎｇｅ）６４０５、第２のプロバイダ網６３０２、第１の県内網６４０４、スイッチ６４０６、ＡＤＳＬモデム６４０７、ＡＤＳＬモデム６４０８、第２の端末６２０２の順の経路で転送される。物理的にはスイッチで折り返せば最適な転送経路となるが、実際には必ずしもそのような転送経路が取られるとは限らない。また、オーバレイ網６１００上のノード接続トポロジやトラヒックの転送経路は、ＩＰ網６２００上のそれと異なる。最短（物理的）距離、又は、最短ホップ数のルーティングが望ましいと思われるが、（１）加入者はＩＰサービスを受ける際にプロバイダと契約しており、トラヒックは先ずプロバイダ網に流れること、（２）プロバイダ間の経路はプロバイダ間の契約内容に依存する部分が大きいこと、（３）物理的には遠回りに見えても、県内網とプロバイダ網の接続線、又は、プロバイダ間の回線の太さの問題から、遠回りに見える経路が実際には最大スループットの経路である場合があること、（４）オーバレイ網６１００のトポロジは、ファイル転送量の実績や、貢献実績などのポリシで決定されることがあることなどの理由から、オーバレイ網６１００上のノード接続トポロジやトラヒックの転送経路は、ＩＰ網６２００上の転送経路は必ずしも一致しない。

第１の実施形態において説明したように、本発明に係る通信制御装置によって通信品質を最適化するには、転送経路とボトルネックを把握し、ボトルネックで通信品質制御可能かどうかを判断できることが重要である。ＩＰ網６２００の場合、転送経路の把握は比較的容易であるが、オーバレイ網６１００の場合には、ＩＰ網６２００と異なる転送経路を取り、転送経路を容易に把握できない場合がある。例えば、図７において、第１のオーバレイノード６１０１から第４のオーバレイノード６１０４に転送されるトラヒックは、第２のオーバレイノード６２０２と第５のオーバレイノード６２０５のいずれを経由しているか解らない場合がある。アプリから送られたトラヒックは、図９に示されるように、他のオーバレイノードから送られたトラヒックと共に暗号化され、オーバレイリンクを通って別のオーバレイノードに転送される。中継ノードの通信インタフェースでペイロードが暗号化されたトラヒックを検閲しても、前段のノードがソースノードであるのか、別のソースノードから送られたトラヒックを、前段のノードが中継して送ってきたのか判別困難な場合が多い。

そこで、第４の実施形態では、図８に示すように、通信最適化第２機能部４１１０内の、網状態把握機能部１５００ａ内に、オーバレイ網経路把握機能部４１２０を設け、オーバレイ網を通過するアプリケーショントラヒックの経路を把握する。ボトルネック把握機能部１５４０は、従来のボトルネックの情報に加え、オーバレイリンクに書き込まれるトラヒックの送受信端末とアプリの情報を網の利用状態の情報に追加する。オーバレイ網経路把握機能部４１２０の実現方法に関しては、例えば、オーバレイ網を実現するアプリ（例えば、「Ｓｋｙｐｅ（登録商標）」や「Ｗｉｎｎｙ」など）が送信しているトラヒック量を変化させ、その変化によって、オーバレイ網の別のノードを流れるトラヒックに変化が発生するかを観測し、経路を推定することという手法を用いることができる。また、オーバレイ網経路把握機能部４１２０の他の実現方法として、例えば、特許文献１（特開２００９−０４９４５８号公報）のオーバレイトラヒック検出システム及びトラヒック監視制御システムを利用することができる。

第４の実施形態の動作は、基本的に第１〜第３の実施形態に準じるが、最適品質計算機能部３３２２が利用する情報である「各端末が必要とする通信品質情報」と「網の利用状態の情報」のうち、後者に、オーバレイ網６１００に関する情報が含まれる点が、第１〜第３の実施形態と相違する。これによって、ボトルネックリンクにオーバレイ網６１００が含まれていれば、そのオーバレイリンクに含まれ要素トラヒックの情報を得ることが可能となり、そのオーバレイ網６１００上で個別に端末が行っている通信アプリも含めて、通信の優先度の高いアプリに高い通信品質を与える通信品質制御が可能かを判断し、可能であれば通信品質の最適化制御を行う。

以上に説明したように、第４の実施形態を用いれば、第１〜第３の実施形態の効果に加え、複数のトラヒックがマージされた上で暗号化されるようなオーバレイ網のトラヒックが含まれる網であっても、アプリの通信の優先度に応じた通信品質の最適化制御ができる。

《５》第５の実施形態
第１〜第４の実施形態では、網資源が限られている場合であっても、ユーザの体感品質を低下させないように、アプリに応じた通信の優先度の制御を行う通信制御装置を説明した。第５の実施形態では、さらに最大消費電力を制限したり、平準化したりすることを第１の拘束条件とし、その範囲で、ユーザの体感品質を低下させないように、アプリに応じて通信の優先度を制御することによって通信品質制御を行う。このような制御によって、例えば、夏期にピーク電力制限が課せられた場合であっても、ユーザの体感品質を高く維持する制御を行うことができる。

図１０は、本発明に係る第５の実施形態の通信制御装置を含むシステムの構成を概略的に示す図である。図１０において、図２の構成と同じ又は対応する構成には同じ符号を付す。図１０に示される第５の実施形態は、端末１１００ａが端末消費電力把握機能部５００１を有する点、並びに、網側通信最適化機能部１３１０ａが消費電力情報集計機能部５００３と、アプリ別品質・消費電力データベース５００２と、網利用状態把握機能部４１１０及び網消費電力把握機能部５００４を含む網状態把握機能部１５００ｂとを有する点が、図２に示される第１の実施形態と相違する。他の点について、第５の実施形態は、第１の実施形態と同様である。

端末１１００ａ内の端末消費電力把握機能部５００１は、ＯＳ１１４０にアクセスすることによって、ＣＰＵ、チップセット、メモリ、磁気ディスクデバイス、通信インタフェース、モニタなどの各種ハードウェア（図示せず）と、使用ＯＳ１１４０や常駐ソフトの情報を収集する機能と、ＣＰＵ稼働率情報などの消費電力に関する情報を収集し、この収集された情報を網側通信最適化機能部１３１０ａに転送する機能とを持つ。

網側通信最適化機能部１３１０ａ内の消費電力情報集計機能部５００３は、端末消費電力把握機能部５００１からの情報と、品質情報集計機能部１３２１で収集した使用アプリの情報、及び、アプリ別品質データベース１３２４に代わって配置されたアプリ別品質・消費電力データベース５００２の情報から、各端末が消費する電力を推定し、最適品質計算機能部１３２２に通知する。

網側の網状態把握機能部１５００ｂには、網設備の消費電力情報を集計する機能を持つ消費電力把握機能部５００４が追加されており、消費電力把握機能部５００４は、最適品質計算機能部１３２２に網設備の消費電力情報を転送する。また、最適品質計算機能部１３２２には、保守者の設定操作により又はネットワーク経由で、許容最大消費電力情報Ｉ０が入力される。

以上に説明した構成において、最適品質計算機能部１３２２には、許容最大消費電力情報Ｉ０、端末と網の消費電力に関する情報、アプリと要求通信品質、そして網の利用状況に関する情報が集められる。最適品質計算機能部１３２２は、これらの情報から、許容最大消費電力を満たす範囲で、かつ、利用可能な網資源を下回る範囲で通信の優先度の高いアプリが必要とされる通信品質での通信を可能とし、通信の優先度の高いアプリの通信を妨げない範囲で通信の優先度の低いアプリによる通信を実施させる制御情報（第２の情報）を算出し、この結果を端末・網設定機能部１３２０を介して、端末と網のＮＥ−ＯｐＳに伝え、ＮＥ−ＯｐＳに、指定された通信品質での動作を実行させる。

以上に説明したように、第５の実施形態によれば、第１〜第４の実施形態の構成の効果に加えて、網と端末の消費電力のおよその最大値を制限することができる。

１１００家庭内網、１１１０，１１７０端末、１１２０第１のアプリソフト、１１３０第２のアプリソフト、１１４０ＯＳ、１１５０物理ＩＦ、１１６０端末側通信最適化機能部（又は、通信最適化第１機能部）、１２００キャリア網、１２１０第１の網機器、１２２０第２の網機器、１２３０，１２５０トランスポート機能部、１２３１，１２５１ＮＥ−ＯｐＳ、１２６０アクセス網、１２６１ＯＮＵ、１２６２，１２６３，１２６４，１２６５スプリッタ、１２６６，１２６７，１２６８，１２６９ＯＬＴ、１２７０ＰＯＮ−ＮＥ−ＯｐＳ、１２７１，１２７２スイッチ、１２７３ＳＷ−ＮＥ−ＯｐＳ、１２８０県内網、１２８１，１２８２，１２８３，１２８４ＡＤＭリング装置、１２８５ＡＤＭ−ＮＥ−ＯｐＳ装置、１２８６ゲートウェイ装置、１３００，１３００ａ最適化制御網、１３１０，１３１０ａ網側最適化機能部、１３２０端末・網設定機能部、１３２１品質情報集計機能部、１３２２最適品質計算機能部、１３２３通信ＩＦ機能部、１３２４アプリ別品質データベース、１４００プロバイダ網、１５００，１５００ａ，１５００ｂ網状態把握機能部、１５１０物理トポロジ把握機能部、１５２０ＩＰ経路把握機能部、１５３０網利用状態把握機能部、１５４０ボトルネック把握機能部、２１００端末、２１１０通信最適化第２機能部、２１２０端末連携機能部、２１２１親端末探索機能部、２１２２端末生存確認機能部、２１２３親端末機能移譲機能部、２１２４親端末機能移譲通知機能部、２１２５端末連携制御機能部、２１２６連携端末情報保持機能部（データベース）、３１１０通信最適化第２機能部、３１２０端末連携機能部、３１２１祖父端末探索機能部、３１２２祖父／親端末生存確認機能部、３１２３祖父端末機能移譲機能部、３１２４祖父端末機能移譲通知機能部、３３２１品質情報集計機能部、３３２２最適品質計算機能部、３３２０端末・網設定機能部、４１１０通信最適化第２機能部、４１２０オーレイ網通信経路把握機能部、５００１端末消費電力把握機能部、５００２アプリ別品質・消費電力データベース、５００３消費電力情報集計機能部、５００４網消費電力把握機能部、６１００オーバレイ網、６２００ＩＰ網、６２０１，…，６２０６第１〜第６の端末、６１１１，…，６１１７第１〜第７のオーバレイリンク。

Claims

端末と網機器との間の通信を制御する通信制御装置であって、
第１の通信最適化機能手段と第２の通信最適化機能手段とを有し、
前記第１の通信最適化機能手段は、
前記端末上で動作するアプリと、
該アプリの通信先に関する情報である第１の情報を取得する第１の機能部と、
前記第１の情報を前記第２の通信最適化機能手段に転送する第２の機能部と、
前記第２の通信最適化機能手段からの指示情報である第２の情報に従って、前記アプリの個々の通信品質を設定する第３の機能部とを含み、
前記第２の通信最適化機能手段は、
前記第１の情報で示される前記アプリに必要な通信品質を示す第３の情報と、網の状態に関する第４の情報を取得する第４の機能部と、
前記第３の情報と前記第４の情報から、前記第１の情報の各アプリに必要な網資源の有無を判断する第５の機能部と、
各アプリに必要な網資源がある場合は、各アプリに必要な通信品質で通信することを指示する前記指示情報を前記第２の情報とし、各アプリに必要な網資源が不足している場合は、通信の優先度の高いアプリには第１の通信品質で通信させ、通信の優先度の低いアプリには前記第１の通信品質を低下させない範囲における通信を実行させる資源割当又は送信順位設定を前記端末と前記網機器に指示する指示情報を前記第２の情報とする第６の機能部と、
前記第２の情報を前記第１の通信最適化機能手段と前記網機器に送信する第７の機能部とを含む
ことを特徴とする通信制御装置。
前記第１の通信最適化機能手段を前記端末内に配置し、前記第２の通信最適化機能手段を前記端末外の最適化制御網内に配置したことを特徴とする請求項１に記載の通信制御装置。
前記第１の情報は、前記端末上で動作している前記アプリがフォアグランドで動作しているかバックグランドで動作しているかを示す情報、及び／又は、前記アプリに対するユーザからの操作内容に基づく情報を含むことを特徴とする請求項１又は２に記載の通信制御装置。
前記第１の通信最適化機能手段は、該第１の通信最適化機能手段の製造者を証明する情報を保持する製造者証明機能部を有することを特徴とする請求項１乃至３のいずれか１項に記載の通信制御装置。
前記第２の通信最適化機能手段が取得する網の状態情報は、網のノードとリンクの利用状況の情報と、利用可能通信帯域の情報とを含むことを特徴とする請求項１乃至４のいずれか１項に記載の通信制御装置。
前記第６の機能部は、通信ソフトウェアに内蔵されるパケットの送信スケジュール機能の設定を変更して、前記アプリのそれぞれについて送信パケットの通信の優先度及び／又は通信帯域を変更することを特徴とする請求項１乃至５のいずれか１項に記載の通信制御装置。
前記第６の機能部は、下りのトラヒックを削減する際に、上りの受信応答信号の送信レートを下げることによって、通信帯域の制御を行うことを特徴とする請求項１乃至６のいずれか１項に記載の通信制御装置。
前記第６の機能部は、前記優先度に応じて、ＩＰパケットのサービスタイプのフィールド値を設定することを特徴とする請求項１乃至７のいずれか１項に記載の通信制御装置。
前記第６の機能部は、前記優先度の高いアプリが必要とされる通信品質での通信を可能とする資源設定又は送信順序設定を行い、前記優先度の高いアプリのトラヒックをトンネリング技術を用いて転送することを特徴とする請求項１乃至８のいずれか１項に記載の通信制御装置。
前記第６の機能部は、送受信する機器のアドレス、ポート番号、プロトコル番号の情報に基づいてアプリを特定し、通信の優先度の低いアプリの通信帯域を狭窄したり、送信順序を遅らせることで通信の優先度の高いアプリの通信品質を向上させることを特徴とする請求項１乃至９のいずれか１項に記載の通信制御装置。
前記第６の機能部は、通信ソフトウエア及び、レイヤ１の機能を用いて、通信の優先度の低いアプリの通信帯域を狭窄したり、送信順序を遅らせることで通信の優先度の高いアプリの通信品質を向上させることを特徴とする請求項１乃至１０のいずれか１項に記載の通信制御装置。
前記第６の機能部は、アプリのＣＰＵ時間を増減することで通信量を調整することを特徴とする請求項１乃至１１のいずれか１項に記載の通信制御装置。
前記第６の機能部は、前記端末と前記網機器との間に配置されたゲートウェイ装置がボトルネックである場合、前記ゲートウェイ装置を通過する通信を行う端末のアプリのトラヒックに対し、通信の優先度の高いアプリが必要とされる通信品質での通過を可能とする資源割当及び／又は送信順位設定を行い、前記資源割当及び／又は送信順位設定を妨げない範囲で通信の優先度の低いアプリによる通信を実施させることを特徴とする請求項１乃至１２のいずれか１項に記載の通信制御装置。
前記第１の通信最適化機能手段と前記第２の通信最適化機能手段の両方が前記端末に配備され、
前記第２の通信最適化機能手段は、
端末相互を連係して動作させるための制御を行う端末連携機能部を含み、
端末起動時に、事前設定された他の１つ又は複数の端末、あるいは、通知可能な全端末に問合せ信号を送出し、他の端末からの応答がない場合に、前記端末連携機能部を起動して動作させる
ことを特徴とする請求項１に記載の通信制御装置。
前記第２の通信最適化機能手段は、
端末相互を連係して動作させる端末連係機能を有する他の端末の生存を確認する第１の端末生存確認機能部を有することを特徴とする請求項１４に記載の通信制御装置。
前記第２の通信最適化機能手段の役割を他の端末に委譲する第１の端末機能移譲機能部と、
前記第２の通信最適化機能手段の役割を他の端末に委譲したときに、該委譲を他の端末に通知する第１の端末機能移譲通知機能部と
を有することを特徴とする請求項１５に記載の通信制御装置。
前記第２の通信最適化機能手段は、端末相互を連係して動作させるための制御を行う他の端末連係機能を有する他の端末の生存を確認する第２の端末生存確認機能部を有することを特徴とする請求項１４乃至１６のいずれか１項に記載の通信制御装置。
前記第２の通信最適化機能手段の役割を他の端末に委譲する第２の端末機能移譲機能部と、
前記第２の通信最適化機能手段の役割を他の端末に委譲したときに、該委譲を他の端末に通知する第２の端末機能移譲通知機能部と
を有することを特徴とする請求項１７に記載の通信制御装置。
前記第２の通信最適化機能手段は、
オーバレイ網のアプリとそのトラヒック量及びオーバレイ網上の論理トポロジにおける転送経路を求めて前記第１の通信最適化機能手段に転送する機能部と、
オーバレイ網上の論理トポロジにおけるノードと、物理的なノードとの対応を求め前記第１の通信最適化機能手段に転送する機能部とを有することを特徴とする請求項１乃至１８のいずれか１項に記載の通信制御装置。
前記第１の通信最適化機能手段は、端末の消費電力を計測する機能部で計測された消費電力の情報、又は、消費電力を推定することが可能となる情報を取得し、取得された情報を前記第１の情報に追加して前記第２の通信最適化機能手段に送信する機能部を含み、
前記第２の通信最適化機能手段は、前記第１の情報を受信する端末消費電力情報集計機能部と、網設備の消費電力情報を集計する網消費電力把握機能部とを含み、
前記第６の機能部は、外部から設定される最大消費電力の許容値を満たす範囲で、かつ、利用可能な網資源を下回る範囲で、前記資源割当又は送信順位設定を前記端末と前記網機器に指示する
ことを特徴とする請求項１乃至１９のいずれか１項に記載の通信制御装置。