JP7099537B2 - 通信装置、通信方法及びプログラム - Google Patents

Description

（関連出願についての記載）
本発明は、日本国特許出願：特願２０１８－１８３８１６号（２０１８年０９月２８日出願）の優先権主張に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。
本発明は、通信装置、通信方法及びプログラムに関する。

近年、モバイルネットワークの高速化及びリッチ化されたインターネットコンテンツ（多くの動画等を含むコンテンツ）の増加に伴いトラフィックデータ量が増加の一途である。そのため、一定エリア内にユーザが集中する事象が発生した際に、通信量が急激に増加（ネットワークの可用帯域が減少）し、データのダウンロード速度や画質などが低下する。その結果、ユーザのＱｏＥ（Quality of Experience）が低下する。

特許文献１には、トラフィック管理サーバにおいて、アプリケーション情報に応じた基地局制御を指示し、基地局管理サーバから算出される無線エリアに関する情報と連携して特定のユーザの特定のアプリケーションに対するトラフィックをコアネットワーク側で制御することを指示することにより、加入者の携帯端末に対して体感品質の向上を実現する構成が開示されている。

特許文献２では、各アプリケーションの通信量、および混雑度から接続ポリシを選択してユーザ毎に適用してトラフィックを制御する技術が開示されている。アプリ・インフラ連携サーバは、特定の携帯情報端末上でアクティブなアプリケーションの種類を検出し、アプリケーションの種類に応じた接続ポリシを、携帯情報端末を特定する情報と共に帯域制御ルータにセットし、帯域制御ルータは、アプリ・インフラ連携サーバによりセットされた接続ポリシに応じ、特定された携帯情報端末からのパケットを優先制御若しくは所定の優先通信帯域で転送する。アプリケーション毎のデータ通信量に基づき、アプリケーション毎の回線通信混雑度を算出し、前記混雑度を表示するユーザに表示するための混雑度表示インターフェイスを生成する。

特開２０１６－０３６０６１号公報 特開２０１７－０６３４８８号公報

なお、上記先行技術文献の各開示を、本書に引用をもって繰り込むものとする。以下の分析は、本発明者らによってなされたものである。

事故や災害など突発的なイベントが発生した際、多くのユーザがＴｗｉｔｔｅｒ（Ｔｗｉｔｔｅｒ, Ｉｎｃ．の商標又は登録商標；以下同じ）などのＳＮＳ（Social Networking Service）から情報を得ようと試みる。しかしながら、多くのユーザがネットワークにアクセスするため、ネットワークが輻輳する。その結果、必要な情報がユーザに届かないという事態が発生し、また通信遅延等によりＱｏＥが低下する。このような情報の不伝達は、社会的にも問題となる可能性がある。

例えば、東日本大震災が発生した際、多くのユーザの情報源がＴｗｉｔｔｅｒとなっていた。しかし、ネットワークの輻輳により、ユーザはＴｗｉｔｔｅｒから必要な情報が取得できず、混乱を招く一因となった。

ＱｏＥの向上を目的とした特許文献１のような技術だけでなく、ネットワークの輻輳に対する技術も存在する。例えば、基地局からのアラームを受け取り、呼制御に影響を及ぼしているアプリケーションを特定して、当該アプリケーションを使用しているユーザ（端末）に対して、帯域制限をかける技術（手法）がある。

当該技術では、アプリケーションの使用量（ネットワーク帯域の消費量）から利用率の高いアプリケーションを特定している。しかしながら、アプリケーションの使用量で判断すると、動画コンテンツなどサイズの大きいコンテンツが帯域を占める為、ネットワークの変動を検知しにくい場合がある。また、例えば、特許文献２等のように、データ通信量でアプリケーションの動きを判定させた場合、ＹｏｕＴｕｂｅ（登録商標；以下同じ）等動画アプリケーションはコンテンツのサイズ（データ量）が大きい為、このような動画により消費される帯域量が大きくなる。その結果、ＷｅｂやＳＮＳ等のコンテンツのサイズが小さいアプリケーションを使用しているユーザが増えたとしても、当該増加したユーザを発見することは困難となる。

つまり、特許文献２等に開示されたような技術では、ＳＮＳ等を利用するユーザが突発的に増加し、ネットワークの輻輳が発生したとしても、当該ネットワークの通信状況の変動を検知することは困難である。

また、ユーザが同一エリア内に継続して滞在している場合には、上記既存技術は有効である。しかし、車や電車での移動など、ユーザの意思とは関係なく、最適化されているエリア内から外部に移動することが考えられる。この場合、パケット損失などが発生し、ユーザのＱｏＥが低下してしまう。より詳細には、仮に、大規模災害等が発生しているエリアに関しては、「Ｔｗｉｔｔｅｒ」が優先設定されていたとしても、ユーザが当該エリアから移動することで、Ｔｗｉｔｔｅｒに対する当該優先設定は適用されなくなる。その結果、当該エリアから移動したユーザは、Ｔｗｉｔｔｅｒから必要な情報を取得できない、という事態が起こり得る。

本発明は、ネットワークにおいて、例えば突発的に発生する輻輳等に対しても、ユーザのＱｏＥの改善に寄与し得る通信装置、通信方法及びプログラムを提供することを主たる目的とする。

本発明乃至開示の第１の視点（アスペクト）によれば、アプリケーションごとの帯域量を算出する帯域量算出部と、前記帯域量算出部で今回算出された前記アプリケーションごとの帯域量と、その前に算出された前記アプリケーションごとの帯域量とに基づき、前記アプリケーションごとの帯域量の変化率を算出する変化率算出部と、前記アプリケーションごとの帯域量の変化率に基づき、サーバと端末間の通信トラフィックに適用するポリシを選択するポリシ選択部と、を備えた通信装置が提供される。

本発明乃至開示の第２の視点によれば、サーバと端末間の通信を中継する通信装置による通信方法であって、アプリケーションごとの帯域量を算出するステップと、
今回算出されたアプリケーションごとの帯域量と、その前に算出された前記アプリケーションごとの帯域量とに基づき、前記アプリケーションごとの帯域量の変化率を算出するステップと、前記アプリケーションごとの帯域量の変化率に基づき、前記サーバと前記端末間の通信トラフィックに適用するポリシを選択するステップと、を含む通信方法が提供される。

本発明乃至開示の第３の視点によれば、サーバと端末間の通信を中継する通信装置に搭載されたコンピュータに、アプリケーションごとの帯域量を算出する処理と、今回算出された前記アプリケーションごとの帯域量と、その前に算出された前記アプリケーションごとの帯域量とに基づき、前記アプリケーションごとの帯域量の変化率を算出する処理と、前記アプリケーションごとの帯域量の変化率に基づき、前記サーバと前記端末間の通信トラフィックに適用するポリシを選択する処理と、を実行させるプログラムが提供される。本発明によれば、上記第３の視点に係る上記プログラムを記憶したコンピュータが読み取り可能な記憶媒体（非一時的媒体：non-transitory medium）が提供される。記憶媒体は、半導体メモリ、ハードディスク、磁気記録媒体、光記録媒体等の非一時的（non-transitory or non-transient）なものとすることができる。

本発明の各視点によれば、ネットワークにおいて、例えば突発的に発生する輻輳時等に、ユーザのＱｏＥの改善に寄与可能な通信装置、通信方法及びプログラムが、提供される。

一実施形態の概要を説明するための図である。 第１の実施形態に係る通信システムの概略構成の一例を示す図である。 第１の実施形態に係るポリシ決定部の内部構成の一例を示す図である。 第１の実施形態に係る通信装置の動作の一例を示すフローチャートである。 第１の実施形態に係る最適化ポリシ選択動作の一例を示すフローチャートである。 帯域量管理テーブルの一例を示す図である。 第１の実施形態に係る通信装置の動作を説明するための図である。 ポリシ管理テーブルの一例を示す図である。 第１の実施形態に係る通信装置のハードウェア構成の一例を示す図である。

初めに、いくつかの例示的な実施形態の１つのアスペクトについて説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、この概要の記載はなんらの限定を意図するものではない。また、各図におけるブロック間の接続線は、双方向及び単方向の双方を含む。一方向矢印については、主たる信号（データ）の流れを模式的に示すものであり、双方向性を排除するものではない。さらに、本願開示に示す回路図、ブロック図、内部構成図、接続図などにおいて、明示は省略するが、入力ポート及び出力ポートが各接続線の入力端及び出力端のそれぞれに存在する。入出力インターフェイスも同様である。

一実施形態に係る通信装置１００は、帯域量算出部１０１と、変化率算出部１０２と、ポリシ選択部１０３と、を備える（図１参照）。帯域量算出部１０１は、アプリケーションごとの帯域量を算出する。帯域量算出部１０１は、通信トラフィックからアプリケーションを識別し、アプリケーションごとのトラフィック量を、予め定められた所定期間集計することで、アプリケーションごとの帯域量を算出するようにしてもよい。変化率算出部１０２は、算出されたアプリケーションごとの帯域量に基づき、該所定期間における該アプリケーションごとの帯域量の変化率（「帯域変化率」という）を算出する。変化率算出部１０２は、帯域量算出部１０１で今回算出されたアプリケーションごとの帯域量に対して、基準量として、帯域量算出部１０１でその前に算出されたアプリケーションごとの帯域量に基づき、アプリケーションごとの帯域量の変化率を算出するようにしてもよい。ポリシ選択部１０３は、算出されたアプリケーションごとの帯域変化率に基づき、サーバと端末間の通信トラフィックに適用するポリシを選択する。

上記通信装置１００は、定期的にアプリケーションごとのトラフィック量（帯域量）を算出し、アプリケーションごとの帯域変化率（利用伸び率）を監視することにより、突発的に発生したイベントを検知する。例えばＹｏｕＴｕｂｅのような動画に関するアプリケーションでは、上記所定期間に消費している帯域が比較的大きい。一方、例えばＴｗｉｔｔｅｒのようなＳＮＳでは、消費している帯域は比較的小さい。このため、上記所定の期間におけるアプリケーションごとの帯域量（使用量）に基づき、ネットワークの状況を判断しようとすると、利用が伸びているアプリケーションが見落とされてしまう。そこで、通信装置１００は、上記所定期間におけるアプリケーションごとの利用伸び率（帯域変化率）を算出することで、例えばＴｗｉｔｔｅｒのような消費される帯域量が小さいアプリケーションの利用が急増している状況を、的確に把握することを可能としている。一実施形態に係る通信装置１００によれば、当該的確に把握された状況に応じたトラフィック制御が実施されることで、ユーザのＱｏＥを改善することができる。

以下に具体的な実施の形態について、図面を参照してさらに詳しく説明する。なお、各実施形態において同一構成要素には同一の符号を付し、その説明を省略する。

［第１の実施形態］
第１の実施形態について、図面を用いてより詳細に説明する。

図２は、第１の実施形態に係る通信システムの概略構成の一例を示す図である。図２を参照すると、通信システムは、通信装置１０と、複数の端末２０と、オリジンサーバ３０と、を含んで構成される。

通信装置１０は、コンテンツを保持し配信するオリジンサーバ３０と端末２０間の通信を中継する装置である。通信装置１０は、端末２０とオリジンサーバ３０の間の通信トラフィックに対する様々な制御を実行する。例えば、通信装置１０は、静止画、動画、テキストコンテンツに対して圧縮やページング配信などを行うトラフィック制御機能を具備している。さらに、通信装置１０は、ＳＮＩ（Server Name Indication）を取得する機能を具備し、暗号化されたＨＴＴＰｓ（Hypertext Transfer Protocol Secure）通信の場合でも通信トラフィックからアプリケーションを特定することが可能である。通信装置１０は、基地局ごとに各アプリケーションの帯域量を計算し、帯域の利用伸び率（帯域変化率）を算出する機能を備える。

なお、アプリケーションの利用伸び率とは、所定の期間における各アプリケーションの通信量の変化率である。あるいは、アプリケーションの利用伸び率とは所定の期間における各アプリケーションが用いるパケットが消費するネットワーク帯域の変化率である。

端末２０は、無線通信機能を備える端末である。より具体的には、端末２０は、基地局（図示せず）を介してネットワークにアクセスし、オリジンサーバ３０からコンテンツデータを取得する。

図２を参照すると、通信装置１０は、トラフィック制御部２０１と、ポリシ決定部２０２と、帯域量管理テーブル２０３と、ポリシ管理テーブル２０４と、を含んで構成される。

トラフィック制御部２０１は、端末２０とオリジンサーバ３０の間のトラフィックを制御する。トラフィック制御部２０１は、ポリシ決定部２０２が選択したポリシに従いトラフィック制御を行う。より具体的には、トラフィック制御部２０１は、アプリケーションごとに、コンテンツデータを圧縮して端末２０に送信する圧縮制御や通信帯域を所定値以下に抑制するページング制御（帯域制御）を行う。

ポリシ決定部２０２は、端末２０とオリジンサーバ３０の間の通信に適用するトラフィック制御に関するポリシを決定する。ポリシ決定部２０２は、帯域量管理テーブル２０３に格納されたアプリケーションごとの帯域量を参照し、各アプリケーションの利用伸び率を算出する。ポリシ決定部２０２は、当該算出された利用伸び率に基づき、上記ポリシを決定する。

ポリシ決定部２０２は、リアルタイムに、アプリケーションごとの利用伸び率の変化を把握し、利用されているアプリケーションの増加が顕著であれば、当該アプリケーションの通信を優先するようなトラフィック制御を実現するポリシ（最適化ポリシ）を選択する。

帯域量管理テーブル２０３は、基地局の識別子ごと、且つ、アプリケーションごとに帯域量を保持するテーブルである。ポリシ管理テーブル２０４は、アプリケーションごとに適用するポリシを保持するテーブルである。帯域量管理テーブル２０３やポリシ管理テーブル２０４の具体的な内容は、通信装置１０の動作と共に後に説明される。

図３は、ポリシ決定部２０２の内部構成の一例を示す図である。図３を参照すると、ポリシ決定部２０２は、帯域量算出部２１１と、利用伸び率算出部２１２と、ポリシ選択部２１３と、を含んで構成される。図３の帯域量算出部２１１と、利用伸び率算出部２１２と、ポリシ選択部２１３は、図１の帯域量算出部１０１と、変化率算出部１０２と、ポリシ選択部１０３にそれぞれ対応している。

帯域量算出部２１１は、アプリケーションごとの帯域量を算出する。具体的には、帯域量算出部２１１は、各端末２０から送信されるパケットから得られるポート番号やペイロードを確認し、受信パケットに対応するアプリケーションを特定する。帯域量算出部２１１は、アプリケーションごとに受信パケットのサイズを計測し、内部の記憶部等に格納する。その後、帯域量算出部２１１は、所定の期間（サンプリング期間：例えば、１分間）に計測されたパケットのサイズの総和を計算し、アプリケーションごとの帯域量として算出する。帯域量算出部２１１は、オリジンサーバ３０から端末２０に転送されるパケット（ダウンリンクパケット）についても、同様にして、アプリケーションごとに受信パケットのサイズを計測し、所定の期間（サンプリング期間：例えば、１分間）に計測されたパケットのサイズの総和を計算し、アプリケーションごとの帯域量として算出する。帯域量算出部２１１は、パケットのサイズの総和（ビット数）を上記所定の期間（＝６０秒）で除算した単位時間当たりビット数（bits per second）を帯域量として求めてもよい。

利用伸び率算出部２１２は、算出されたアプリケーションごとの帯域量に基づき、上記所定の期間（サンプリング期間：例えば、１分間）におけるアプリケーションごとの利用伸び率（帯域変化率）を算出する。具体的には、利用伸び率算出部２１２は、所定のタイミング（例えば、１分ごと）に、直前に算出された帯域量X1（基準量）と、今回算出された最新の帯域量X2の差分(X2-X1)を計算し、当該差分値を、直前に算出された帯域量X1（基準量）で除算することで、アプリケーションごとの利用伸び率（帯域変化率）(=X2-X1)/X1×100 (%))を算出する。なお、利用伸び率算出部２１２による、帯域量のアプリケーションごとの利用伸び率の算出は、上記所定の期間（サンプリング期間：例えば１分）ごと、定期的に行われる。

ポリシ選択部２１３は、算出されたアプリケーションごとの利用伸び率（帯域変化率）に基づき、オリジンサーバ３０と端末２０間の通信トラフィックに適用するポリシを選択する。具体的には、ポリシ選択部２１３は、ポリシ管理テーブル２０４を参照し、算出されたアプリケーションごとの利用伸び率から、現在の通信状況に最適なポリシを選択して、トラフィック制御部２０１に出力する。つまり、ポリシ選択部２１３は、トラフィック制御部２０１がトラフィック制御に使用するポリシを更新する。

図４は、第１の実施形態に係る通信装置１０の動作の一例を示すフローチャートである。

初めに、通信装置１０は、ユーザ（端末２０）がオリジンサーバ３０に接続時（端末２０からのパケットを受信しオリジンサーバ３０に中継する時）に、受信パケットからＣｅｌｌＩＤ（Cell Identification）を取得する（ステップＳ０１）。なお、ＣｅｌｌＩＤは、無線通信網における基地局の識別子である。通信装置１０は、ＣｅｌｌＩＤごと（基地局ごと）に、アプリケーションごとの利用伸び率を管理し、当該利用伸び率に応じた最適なトラフィック制御を実現する。なお、端末２０は、基地局を介して無線接続する際に取得したＣｅｌｌＩＤを、例えばパケットのヘッダのオプションフィールド等に設定し、通信装置１０は当該オプションフィールドを参照することでＣｅｌｌＩＤを取得するようにしてもよい。

次に、通信装置１０は、オリジンサーバ３０からコンテンツデータ（パケット）を受信する（ステップＳ０２）。

通信装置１０は、当該オリジンサーバ３０からコンテンツデータを受信したタイミングにて、ポリシの選択を行う（ステップＳ０３）。なお、通信装置１０におけるポリシの選択動作に関しては後述する。

通信装置１０は、トラフィック制御部２０１にて選択されたポリシに従ったトラフィック制御を行う（ポリシの適用；ステップＳ０４）。

通信装置１０は、端末２０に向けてコンテンツデータを送信する（ステップＳ０５）。

このように、通信装置１０は、トラフィック制御部２０１において、現在の通信状況、環境に最も適したポリシを選択し、当該ポリシ合わせたトラフィック制御を行い、ユーザ（端末２０）に対してコンテンツデータを送信する。

なお、ポリシ選択部２１３における最適化ポリシの選定では、圧縮機能、ページング機能それぞれの適用／非適用の決定だけでなく、圧縮率やページングレートが決定される。換言すれば、各ポリシには、圧縮機能、ページング機能の適用、非適用だけでなく、これらの機能を有効にした際の値（圧縮率、ページングレート）に関する情報が含まれる。

図５は、通信装置１０による最適化ポリシの選択動作の一例を示すフローチャートである。なお、通信装置１０による最適化ポリシの選択動作は、呼処理とは連動せずに、所定の周期（例えば、１分毎）に起動する。

帯域量算出部２１１は、同一ＣｅｌｌＩＤにおける、アプリケーションごとの帯域量を算出し、当該算出した帯域量を帯域量管理テーブル２０３に格納する（ステップＳ１０１）。つまり、帯域量算出部２１１は、端末２０が無線接続する基地局の識別子ごとに、アプリケーションごとの帯域量を算出する。

図６は、帯域量管理テーブルの一例を示す図である。図６に示すように、ＣｅｌｌＩＤごと、且つ、アプリケーションごとに算出された帯域量（直前の帯域量、最新の帯域量）と利用伸び率が帯域量管理テーブル２０３に含まれる。

利用伸び率算出部２１２は、アプリケーションごとに、帯域量管理テーブル２０３に格納された帯域量（直前に算出された帯域量：Mbps (Mega bits per second））と、最新の帯域量に基づき、各アプリケーションの帯域量の利用伸び率（帯域変化率）を算出する（ステップＳ１０２）。利用伸び率算出部２１２は、算出したアプリケーションごとの帯域量の利用伸び率を帯域量管理テーブル２０３に格納する。

図６の「ＣｅｌｌＩＤ＝１」の例では、「Ｔｗｉｔｔｅｒ」の利用伸び率は２０％、「ＹｏｕＴｕｂｅ」の利用伸び率は２％、ＩＰ（Internet Protocol）電話の利用伸び率は１０％と算出される。

次に、利用伸び率算出部２１２は、アプリケーションごとの帯域量の利用伸び率に関する並び替え処理（ソート処理）を実行する（ステップＳ１０３）。利用伸び率算出部２１２は、上記並び替え処理の実行ごとに、算出したアプリケーションごとの利用伸び率を記憶する。

例えば、図６の「ＣｅｌｌＩＤ＝１」の例では、アプリケーションごとの利用伸び率の高い順に、「Ｔｗｉｔｔｅｒ」、「ＩＰ電話」、「ＹｏｕＴｕｂｅ」のように並び替えが行われる。利用伸び率算出部２１２は、アプリケーションごとの利用伸び率の算出のたびに、上記並び替えを行いその順番を記憶する。

ポリシ選択部２１３は、アプリケーションごとの利用伸び率に従って並び替えられたアプリケーションのうち、予め定められた所定の期間（例えば、３分間：３サンプリングの期間）に亘って、予め定めた順位よりも上位にあるアプリケーションが存在するか否かを判定する（ステップＳ１０４）。つまり、ポリシ選択部２１３は、アプリケーションごとの利用伸び率のランキングの上位が、予め定められた所定期間（例えば、３分間：３サンプリングの期間）に亘って、同一か否かを判定する。

所定の期間（例えば、３分間）、上位にあり続けたアプリケーションが存在すれば（ステップＳ１０４、Ｙｅｓ分岐）、ポリシ選択部２１３は、当該アプリケーションを優先すべきアプリケーションと判断し、トラフィック制御に適用するポリシを選択する（ステップＳ１０５）。

具体的には、ポリシ選択部２１３は、ポリシ管理テーブル２０４を参照し、優先すべきアプリケーションと判断されたアプリケーションに対応するポリシを選択する。

図７は、最新の時刻（Ｔ３）よりも２サンプリング前（Ｔ２、Ｔ１）に算出されたアプリケーションごとの利用伸び率を並び替えた一例を示す図である。例えば、図７を参照すると、「Ｔｗｉｔｔｅｒ」は、所定の期間（例えば、３分間；３サンプリングの期間）に亘って上位３番目までにランキングされていることが分かる。その結果、ポリシ選択部２１３は、「Ｔｗｉｔｔｅｒ」を優先すべきアプリケーションと判断する。

図８は、ポリシ管理テーブル２０４の一例を示す図である。上記のように、優先すべきアプリケーションとして、「Ｔｗｉｔｔｅｒ」が選択された場合、ポリシ選択部２１３は、「Ｔｗｉｔｔｅｒ」に関するトラフィック制御のポリシを読み出し、トラフィック制御部２０１に提供（出力）する。

所定の期間（例えば、３分間：３サンプリングの期間）上位にあるアプリケーションが存在しなければ（ステップＳ１０４、Ｎｏ分岐）、ポリシ選択部２１３は、処理を終了する。

例えば、通信装置１０は、Ｔｗｉｔｔｅｒの利用伸び率が連続して３回ランキング１位である場合、Ｔｗｉｔｔｅｒに対する帯域制限の設定を解除する。あるいは、通信装置１０は、Ｔｗｉｔｔｅｒに対する帯域制限の設定を解除すると共に、ＹｏｕＴｕｂｅ等その他のアプリケーションに対して、より強い帯域制限を課すようにしてもよい。この場合、例えば、ポリシ管理テーブル２０４には、「Ｔｗｉｔｔｅｒ」を優先した場合の他のアプリケーションごとのトラフィック制御に関する詳細を含めるようにすればよい。あるいは、図８に示すように、優先すべきアプリケーションのポリシだけが設定されている場合には、他のアプリケーションに対しては、一律に、帯域制限を課すようにしてもよい。

このように、ポリシ選択部２１３は、アプリケーションごとの帯域変化率を変化率の高い順に並び替え、並び替えられた帯域変化率に基づき、通信トラフィックに適用するポリシを選択する。より詳細には、ポリシ選択部２１３は、所定の期間（例えば、３分間：３サンプリングの期間）に亘って、予め定められた所定の順位よりも上の帯域変化率に対応するアプリケーションを、優先するアプリケーションとして選択すると共に、当該優先するアプリケーションに対応するポリシを、ポリシ管理テーブル２０４から読み出す。その後、ポリシ選択部２１３は、読み出したポリシを「最適ポリシ」としてトラフィック制御部２０１に提供する。

［ハードウェア］
続いて、通信システムをなす各装置のハードウェア構成について説明する。

図９は、通信装置１０のハードウェア構成の一例を示す図である。通信装置１０は、図９に例示する構成を備える。例えば、通信装置１０は、内部バスにより相互に接続される、ＣＰＵ（Central Processing Unit）１１、メモリ１２、通信手段であるＮＩＣ（Network Interface Card）１３等を備える。

但し、通信装置１０のハードウェア構成は、図９の構成に制限されるものでないことは勿論である。通信装置１０は、図示しないハードウェアを含んでもよい。通信装置１０に含まれるＣＰＵ等の数も図９の例示に制限されるものでなく、通信装置１０は複数のＣＰＵ１１を含む構成としてもよいことは勿論である。

メモリ１２は、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、補助記憶装置（ハードディスク等）等である。

通信装置１０の機能は、上述の処理モジュールにより実現される。当該処理モジュールは、例えば、ＣＰＵ１１がメモリ１２に格納されたプログラムを読み出して実行することで実現される。また、該プログラムは、ネットワークを介してダウンロードするか、あるいは、該プログラムを記憶した記憶媒体を用いて、更新するようにしてもよい。さらに、上記処理モジュールは、半導体チップにより実現されてもよい。即ち、上記処理モジュールが行う機能は、何らかのハードウェア、或いはハードウェアを利用して実行されるソフトウェアにより実現するようにしてもよい。

なお、端末２０やオリジンサーバ３０のハードウェア構成は当業者にとって明らかであるため詳細な説明を省略する。

以上のように、第１の実施形態に係る通信装置１０は、特定エリア（基地局が提供するセル）に収容された端末２０から送信されるパケットをアプリケーションごとに分類し、各アプリケーションの帯域量を算出する。さらに、通信装置１０は、当該アプリケーションごとの帯域量に基づき、予め定められた所定の期間（例えば１分）ごとに、各アプリケーションの利用伸び率を算出することで、突発的なイベントを検知する。通信装置１０は、突発的なイベント時に利用されることが多いアプリケーションを、優先的に通信できるように、トラフィック制御を行う。こうすることで、通信装置１０は、ユーザのＱｏＥを改善する。つまり、通信装置１０は、例えば突発的に発生したネットワークの輻輳時に、ユーザの優先度に合わせて、トラフィックの制御を行うことで、ユーザのＱｏＥを改善する。その際、通信装置１０は、優先度の低いアプリケーションに対して、より厳しい制限をかけ、必要な帯域を確保する。その結果、当該手法により、ネットワークの輻輳の発生、解消など、変動する通信環境においても、その状態に適した、トラフィック制御を行うことが可能となる。

［変形例］
上記実施形態にて説明した通信システムの構成、動作は例示であって、システムの構成等を限定する趣旨ではない。例えば、帯域量管理テーブル２０３及び／又はポリシ管理テーブル２０４は、通信装置１０の内部に配置するのではなく、通信装置１０がアクセス可能な、ネットワーク上のデータベースサーバ等に構築されていてもよい。

上記実施形態では、アプリケーションごとの利用伸び率を、帯域量に基づき算出しているが、当該利用伸び率を、所定の期間に送受信されるパケット数に基づき算出するようにしてもよい。

また、特定のアプリケーションの帯域の利用伸び率が指数関数的に上昇した場合、一定時間後に利用伸び率が低下することも考えられる。例えば、大規模な災害が発生してから１時間程度経過すると、既に利用しているユーザが多いため、利用伸び率は低下すると考えられる。しかし、このような場合、当該アプリケーションの利用に対する需要は引き続き多い。このため、通信装置１０は、利用伸び率が閾値を超過した場合には、当該アプリケーションを一定時間優先させるポリシを選択するようにしてもよい。

上記の説明により、本発明の産業上の利用可能性は明らかであるが、本発明は、例えばモバイル通信事業者のＩＰネットワーク内に設置するプロキシサーバ等に好適に適用可能である。

上記の実施形態の一部又は全部は、以下の付記のようにも記載され得る（ただし、以下に制限されない）。
［付記１］
上述の第１の視点に係る通信装置のとおりである。
［付記２］
前記選択されたポリシに従って、前記通信トラフィックを制御する、トラフィック制御部をさらに備える、好ましくは付記１に記載の通信装置。
［付記３］
前記変化率算出部は、定期的に前記アプリケーションごとの帯域変化率を算出する、好ましくは付記２に記載の通信装置。
［付記４］
前記ポリシ選択部は、前記アプリケーションごとの帯域変化率を変化率の高い順に並び替え、前記並び替えられた帯域変化率に基づき、前記通信トラフィックに適用するポリシを選択する、好ましくは付記３に記載の通信装置。
［付記５］
アプリケーションごとに適用するポリシを保持するポリシ管理テーブルをさらに備え、
前記ポリシ選択部は、所定の期間に亘って所定の順位よりも上の前記帯域変化率に対応するアプリケーションを優先するアプリケーションに選択すると共に、前記優先するアプリケーションに対応するポリシを前記ポリシ管理テーブルから読み出す、好ましくは付記４に記載の通信装置。
［付記６］
前記ポリシ選択部は、前記ポリシ管理テーブルから読み出したポリシを前記トラフィック制御部に提供する、好ましくは付記５に記載の通信装置。
［付記７］
前記帯域量算出部は、端末が無線接続する基地局の識別子ごとに前記アプリケーションごとの帯域量を算出する、好ましくは付記１乃至６のいずれか一に記載の通信装置。
［付記８］
前記基地局の識別子ごと、且つ、アプリケーションごとに帯域量を保持する帯域量管理テーブルをさらに備える、好ましくは付記７に記載の通信装置。
［付記９］
前記トラフィック制御部は、圧縮制御又はページング制御を行う、好ましくは付記２に記載の通信装置。
［付記１０］
前記ポリシ管理テーブルには、アプリケーションごとに、圧縮制御の要否、圧縮率、ページング制御の要否、ページングレートを対応付けて記憶される、好ましくは付記５に記載の通信装置。
［付記１１］
上述の第２の視点に係る通信方法のとおりである。
［付記１２］
上述の第３の視点に係るプログラムのとおりである。
なお、付記１１の形態及び付記１２の形態は、付記１の形態と同様に、付記２の形態～付記１０の形態に展開することが可能である。

なお、引用した上記の特許文献等の各開示は、本書に引用をもって繰り込み記載されているものとし、必要に応じて本発明の基礎ないし一部として用いることが出来るものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の全開示の枠内において種々の開示要素（各請求項の各要素、各実施形態ないし実施例の各要素、各図面の各要素等を含む）の多様な組み合わせ、ないし、選択（部分的削除を含む）が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。特に、本書に記載した数値範囲については、当該範囲内に含まれる任意の数値ないし小範囲が、別段の記載のない場合でも具体的に記載されているものと解釈されるべきである。

１０、１００ 通信装置
１１ ＣＰＵ（Central Processing Unit）
１２ メモリ
１３ ＮＩＣ（Network Interface Card）
２０ 端末
３０ オリジンサーバ
１０１、２１１ 帯域量算出部
１０２ 変化率算出部
１０３、２１３ ポリシ選択部
２０１ トラフィック制御部
２０２ ポリシ決定部
２０３ 帯域量管理テーブル
２０４ ポリシ管理テーブル
２１２ 利用伸び率算出部

Claims (9)

1. アプリケーションごとの帯域量を算出する帯域量算出部と、
   前記帯域量算出部で今回算出された前記アプリケーションごとの帯域量と、その前に算出された前記アプリケーションごとの帯域量とに基づき、前記アプリケーションごとの帯域量の変化率を算出する変化率算出部と、
   前記アプリケーションごとの帯域量の変化率に基づき、サーバと端末間の通信トラフィックに適用するポリシを選択するポリシ選択部と、
   を備え、
   前記ポリシ選択部は、前記アプリケーションごとの帯域量の変化率を、降順に並び替え、前記並び替えられた帯域量の変化率に基づき、前記通信トラフィックに適用するポリシを選択する、通信装置。
2. 前記選択されたポリシに従って、前記通信トラフィックを制御するトラフィック制御部をさらに備える、請求項１に記載の通信装置。
3. 前記変化率算出部は、定期的に、前記アプリケーションごとの前記帯域量の変化率を算出する、請求項２に記載の通信装置。
4. 前記アプリケーションごとに前記通信トラフィックに適用するポリシを保持するポリシ管理テーブルをさらに備え、
   前記ポリシ選択部は、降順に並び替えられた前記帯域量の変化率に関して、予め定められた所定の期間に亘って、予め定められた順位よりも上位を保つ前記帯域量の変化率に対応するアプリケーションを、優先するアプリケーションとして選択すると共に、前記優先するアプリケーションに対応するポリシを前記ポリシ管理テーブルから取得する、請求項２に記載の通信装置。
5. 前記ポリシ選択部は、前記ポリシ管理テーブルから取得した前記優先するアプリケーションに対応するポリシを、前記トラフィック制御部に提供する、請求項４に記載の通信装置。
6. 前記帯域量算出部は、前記端末が無線接続する基地局の識別子ごとに、前記アプリケーションごとの帯域量を算出する、請求項１乃至５のいずれか一項に記載の通信装置。
7. 前記基地局の識別子の各々に対して、前記アプリケーションごとに帯域量を保持する帯域量管理テーブルをさらに備える、請求項６に記載の通信装置。
8. サーバと端末間の通信を中継する通信装置による通信方法であって、
   アプリケーションごとの帯域量を算出する第１のステップと、
   今回算出されたアプリケーションごとの帯域量と、その前に算出された前記アプリケーションごとの帯域量とに基づき、前記アプリケーションごとの帯域量の変化率を算出する第２のステップと、
   前記アプリケーションごとの帯域量の変化率に基づき、前記サーバと前記端末間の通信トラフィックに適用するポリシを選択する第３のステップと、
   を含み、
   前記第３のステップでは、前記アプリケーションごとの帯域量の変化率を、降順に並び替え、前記並び替えられた帯域量の変化率に基づき、前記通信トラフィックに適用するポリシを選択する、通信方法。
9. サーバと端末間の通信を中継する通信装置に搭載されたコンピュータに、
   アプリケーションごとの帯域量を算出する第１の処理と、
   今回算出された前記アプリケーションごとの帯域量と、その前に算出された前記アプリケーションごとの帯域量とに基づき、前記アプリケーションごとの帯域量の変化率を算出する第２の処理と、
   前記アプリケーションごとの帯域量の変化率に基づき、前記サーバと前記端末間の通信トラフィックに適用するポリシを選択する第３の処理と、
   を実行させるプログラムであって、
   前記第３の処理は、前記アプリケーションごとの帯域量の変化率を、降順に並び替え、前記並び替えられた帯域量の変化率に基づき、前記通信トラフィックに適用するポリシを選択する、プログラム。

Images